An Overview of Apple Cloud Kit Framework Recently Announced at WWDC 2014

Cloud Kit allows developers to leverage iCloud and build apps with the new CloudKit framework. Developers can securely store and retrieve app data, like structured data, in a database or assets directly from iCloud. CloudKit also enables users to anonymously sign in to apps with their iCloud Apple IDs without sharing their personal information.

With Cloud Kit, developers can focus on client-side app development and let iCloud eliminate the need to write server-side application logic. CloudKit provides authentication, private and public database, structured and asset storage services for free with very high limits.

In a nutshell, Cloud Kit is a way to move structured data between an app and iCloud. Whereas document-based storage operates on files, Cloud Kit operates on records. A record is a dictionary of key-value pairs, with each key representing a field of the record. The value of each field is usually a simple data type such as a string, number, or date but developers can also store entire files or arbitrary blocks of data. Fields can also store pointers to other records, making it possible to define relationships between records.

Cloud Kit’s use of records and the ability to create relationships between is not a way to store data locally. It is a service for moving data to and from iCloud and is not meant to replace an app’s existing data model objects. The objects of this framework complement existing data objects by providing a way to package data for iCloud and receive updates to that data later.

With Cloud Kit, developers decide when to move data from an app to iCloud and from iCloud to an app. Although Cloud Kit provides facilities to keep developers informed when changes occur, they still must still fetch those changes explicitly. With the ability to decide when to fetch and save data, developers are responsible for ensuring that data is fetched at the right times and in the right order, and are responsible for handling any errors that arise

Before using Cloud Kit, an app must enable the iCloud capability for the app, as described in Request Access to iCloud Storage By Using Entitlements. That is all the setup that is needed.

Like other iCloud technologies, Cloud Kit organizes data using containers. A container serves as the local representation of an app’s iCloud storage, and apps must request entitlements for each of their containers. At runtime, developers can perform tasks against a specific container using a CKContainer object.

In Cloud Kit, containers are divided into public and private areas, each of which is represented by a CKDatabase object. Any data written to the private database is visible only to the current user and is stored in that user’s iCloud account. Data written to the public database is visible to all users of the app and is stored in the app’s iCloud storage.

For a running Cloud Kit app, access to a container’s public database requires only access to the network. By contrast, access to a private database requires the presence of an active iCloud account on the device. If the user is not logged into iCloud on the current device, or if the current user account changes, an app needs to respond appropriately. 

All apps that access a private database must do the following:

- Check for the availability of an iCloud account at launch time by checking the value of the ubiquity Identity Token property of NSFileManager. If the value of this token is nil, attempts to access the private database will fail.

- Register as an observer of NS Ubiquity Identity Did Change Notification and respond to changes in the current iCloud account. When an app receives that notification, delete local copies of records and custom data objects that contain user-specific data.

When accessing containers in Cloud Kit, developers do not need to call the URLForUbiquityContainerIdentifier: method or otherwise prepare the user’s iCloud storage directory in advance.

During development, there is the ability to define new record types and add fields to existing record types programmatically or using the Cloud Kit Dashboard. The first time a record is saved successfully to the server, the server records each field name and its corresponding type. Thereafter, the data type associated with a field cannot be changed. After deploying record types to a production environment, developers cannot change them programmatically; all changes must be made using the Cloud Kit Dashboard.

Managing Data in Cloud Kit

Inside the public and private databases, an app’s data is organized using records. Use records to move data between an app and iCloud. Records are dictionaries of key-value pairs represented by the CKRecord class. Each record has a record type, which is a string used to differentiate between records with different types of information.

Apps must fetch the records they need to run and save changes to those records explicitly. Nothing is automatic. Cloud Kit does not initiate fetch and save operations for an app. The must be done using operation objects or using the convenience methods of the CKContainer and CKDatabase classes. Operation objects are the preferred way to fetch and save data because they can be used to fetch and save batches of records and can use dependencies to execute the operations in sequences.

In addition to fetching records whose IDs a developer knows, Cloud Kit also provides the ability to search for records that match specific criteria. A CKQueryobject defines the criteria for selecting records from the database. When executing a query using a CKQueryOperation object, what comes back is the set of records that currently match the criteria specified. If a developer wants to be notified when the search results change, they can set up a CKSubscription object instead, which acts like a persistent query on the server and reports changes to an app using push notifications.

To learn more on how to use the CloudKit Framework for apps click here.