Cloudkit is a solution made by Apple allowing iOS and macOS apps to use the data cloud – iCloud. It offers interfaces for moving data between an app and the containers, providing the users with access to data located on all of their devices. Apart from that, CloudKit allows storing data in a public space available for all the app’s users. Data limits depend on the number of app’s users. The solution was first introduced at the WWDC conference in 2014.
1. Types of database
Apple provides three types of databases which can be used by iOS apps: private, public, and shared.
It’s available for every user who has an account on iCloud. The data limit is shared among all of the used applications. It’s employed to store sensitive data or those linked only to a particular user. It’s not accessible for developers.
It’s available for all of the app’s users – also those who don’t have an iCloud account. The data limit depends on the type of developer’s account and applies to all the instances of one application. Data read is possible for developers through the dashboard.
The database used for sharing the information among other users. The data limit depends on the iPhone user’s account. It’s necessary to have an iCloud account, too.
|Some articles that might interest you as well:|
Azure Face – facial recognition without machine learning knowledge
All you need to know about Size Classes
Apple Watch – a cool and useful gadget, but can it be more?
2. CloudKit Framework
To start using CloudKit, first you need to configure the App ID adding the iCloud service. Default iCloud container should be configured, as well.
iCloud layer managing the access to databases. Every app has a default container’s object which manages its own content. All the operations between the server and the application are coordinated by the container’s instance to check the correctness of the iCloud account configuration or download database objects (CKDatabase). What’s more, the application can refer to other containers than the default one if it can access them freely entering their identificator during the initialization. It helps create the suite of the apps that can have a common database. Every container diversifies the public and private data connected with only one iCloud account.
2.2. Types of records
Data in the CloudKit bases are stored in the form of records in the CKRecord class instances. Every record can have any number of specified type fields. In CloudKit, we can store both simple types (Integer, Double, String) and the more complex ones such as Location (CLLocation) or assets. Assets are CKAsset class objects for storing a larger amount of data such as pictures or photos. CloudKit limits the size of a single record to 1 MB. Thanks to the assets being stored separately, their limits are significantly higher, reduced by a chosen iCloud plan. Furthermore, records can be linked to references similarly as in relational databases. To do that, we use CKReference class objects.
The table presents all of the possible types.
|Asset||CKAsset||A large file that is associated with a record but stored separately|
|Bytes||NSData||A wrapper for byte buffers that is stored with the record|
|Date||NSDate||A single point in time|
|Integer (64)||NSNumber||An integer|
|Location||CLLocation||A geographical coordinate and altitude|
|Reference||CKReference||A relationship from one object to another|
|String||NSString||An immutable text string|
|List||NSArray||Arrays of any of the above field types|
3. Cloudkit Dashboard
CloudKit Dashboard provides a detailed preview of the app’s and users’ activity and can be used for configuring and creating the databases’ schemes. It’s divided into 6 sections:
- API Access: generating and managing the keys and tokens to use CloudKit by other apps than iOS (e.g. web).
- Data: preview of data saved in the base with the possibility of filtering, creating kwerends, adding indexes, etc.
- Schema: section for managing schemes of database. The developer determines what data and in what form will be stored by the app.
- Logs: iCloud server logs that consist of all the successful and erroneous referrals to the database.
- Telemeters: usage and performance of the iCloud server presented in the graphic form (charts).
- Usage: statistical data with information about active users, requests per second, etc.
NSUbiquitousKeyValueStore is not a part of the CloudKit framework, but an interesting alternative for storing a small amount of user’s private data in iCloud. A programmer can use it in the same manner as local NSUserDefaults. It allows saving values like Bool, NSNumber, NSString, NSDate, NSData and NSArray, or NSDictionary collections consisting of the mentioned classes’ objects. First, the data is saved locally on a particular device, and then sent to the cloud if the user is logged into the iCloud service. If not, NSUbiquitousKeyValueStore works like a local cache – data is not synchronized among all devices, but is available on the devices it was saved. Nevertheless, you should consider the fact that the limit of data is significantly reduced and amounts to 1 MB for one user.
5. Summing up
Using CloudKit is an interesting solution for local iOS applications requiring synchronization among different devices. It allows simple storage of binary data such as photos or films as well as creating a more complicated database. However, if you want to store and synchronize a small amount of data among one user’s devices (e.g. a common configuration), it’s worth thinking about using NSUbiquitousKeyValueStore which also employs iCloud and doesn’t require configuring the CloudKit container.