Apple CloudKit Brings Remote Data Storage to Your Apps

Welcome to the second of a three-part series on iOS 8, where we will dive into the world of CloudKit. (We introduced you to HealthKit in an earlier article.)

With CloudKit, Apple’s answer to Dropbox, Parse and other cloud-based solutions, the developer does not have to deal with server-side application logic and can instead focus on client-side development. CloudKit exposes the standard cloud interfaces of authentication, public databases and asset storage. Most importantly, it’s free, with generous bandwidth and storage limits--10TB of database storage and 1PB of asset storage. (For storage above and beyond, refer to Apple’s pricing chart.)

Benefits of Product/Service to Developer, Customer

While there is no shortage of third-party options out there, and Apple has come to the party quite late, the company brings to the table a really strong and secure solution package that distinguishes between public and private data, with the latter not visible to anyone other than the client. If you plan to release an iOS-only app, Apple’s CloudKit is certainly worth looking at. And, even if you decide to move on to hosting your own server-side solution, making available an initial product through CloudKit is a good way to go.

CloudKit is also very simple to use. You can get started simply by registering in the iOS Developer Program. You don’t need to install any third-party frameworks, and can trust in the consistency and clout Apple has in maintaining its data servers. Further, users who are logged into iCloud on their devices are already logged into CloudKit, so you don’t even have to bother with fancy login and registration screens, providing a seamless experience.

Your 20-Minute Guide to Integrating CloudKit Into Your App

Stack Overview

Apple provides a set of APIs for interfacing with iCloud and a Web dashboard that provides developers with a way of interacting with the public database records. CloudKit also contains private database records that are visible only to the client.

Let’s start by setting up a project to enable CloudKit.

You do this in XCode, by enabling entitlements for the app to use iCloud, in the Build Settings. Enabling it as such provides you with a generated entitlements file, or amends an existing one, setting up your app-specific iCloud Documents folder to access the iCloud container, which is named based on your app’s bundle ID.

iCloud enabling

iCloud data is stored in what is called iCloud containers, a local representation (on the device) of its corresponding iCloud storage equivalent. What you may not have presumed is that your app is able to access more than one iCloud container and share containers with other apps, allowing multiple apps to write to the same container. Quite neat!

iCloud architecture (courtesy of Apple)

The Dashboard

Now, going back to XCode, enabling iCloud provides you with direct access to the CloudKit Dashboard, which you can also access via your browser.

Dashboard

On the left-hand side, you get to set the higher-level containers, consisting of Record Types, Security Roles and Subscription Types. Working with a Record Type, you set the attributes (columns) that define each individual record, so you are defining the structure of a particular record type. The other options on the left-hand side are out of the scope of this mini-tutorial, but we encourage you to explore and read up more on the options you have when working with User Records and Default Zones, for both public and private data. Create a few Record Types, and add some attributes, to get yourself familiar with working with Record Types:

Adding attributes

After you have set up one or two Record Types, you select Default Zone under PUBLIC DATA on the left, select a Record Type from the top left, then select the + option on the main/right-hand side. Then start entering some sample data to work with.

Adding live data

So you have created the schema and added some records to your public database. Now let’s start querying your database via your app.

CloudKit Querying

You query using a CKQuery object type, describing how to find all records that match a specific criterion and filter requirement. These are expressed using the NSPredicate, which is also used in CoreData. NSPredicate on CloudKit is a subset of the full-fledged CoreData version. However, it does include the distanceToLocation:FromLocation: function, which was added to allow records to be compared using location radius properties.

In your code, once you have defined your predicate, create a CKQuery object:

let container : CKContainer let publicDatabase : CKDatabase

init() { // 1 container = CKContainer.defaultContainer() // 2 publicDatabase = container.publicCloudDatabase

} ….

let query = CKQuery(recordType: SubjectsType,
                   predicate:  classPredicate) 
publicDB.performQuery(query, inZoneWithID: nil) { 
results, error in
if error != nil {
  //handle error here
} else {
  self.classesArray.removeAll(keepCapacity: true)
  for record in results{
    let subject = Subject(record: record as CKRecord, database: self.publicDB)
    self.classesArray.append(subject)
  }
  //handle any post-call updates
  }
 }
}  
}

Summary and Conclusion

There you have it--a quick introduction and a bit of a hands-on for using CloudKit in your existing (or new) applications. Some developers may opt to stick with Parse.com or other third-party back ends, or even create their own in-house. Nevertheless, there is a strong argument for Apple’s proposition, which at the very least, for an initial MVP milestone, will allow developers to focus on their core competencies and defer complex server-side configurations. In doing so, developers get seamless access to cloud-based data, without having to import custom frameworks or libraries.

We also saw how easy it is to create a schema and a couple of records, and then, in XCode, to query our public database. Of course, this is just touching the surface. We encourage you to start exploring complex CloudKit exercises, such as writing to a database and syncing with a local database, like CoreData.

If you're interested in learning more, you can view the CloudKit documentation online as well as a getting started guide.

In the next series on iOS 8, we will look at HomeKit and how Apple has made having an automated home and appliance ecosystem one step closer to reality.

Doron Katz A keen passion for emerging technologies, practices and methodologies, Doron embraces the vision of lean development with continuous customer development. Consultant for various startups, as a Project and Product Manager, with a mobile engineering background in iOS, and over 10 years of professional web development experience.

Comments

Comments(1)

evermeer

Now there is also a convenience library for CloudKit called https://github.com/evermeer/EVCloudKitDao that will remove the need for parsing objects back and forward to CKRecord objects. It also has support for local cashing (to a file and not using CoreData)