CloudKit framework provides API for data transfer from iOS devices to iCloud similarly to Parse and other cloud storages. We wrote a post which explains how to work with CloudKit. We also created a demo project in Objective-C and Swift which you can absolutely use.
But is CloudKit really worth its salt, at least for now?
We promised you to compare CloudKit with Parse, the most popular cloud database out there. We hope this article will help you get a better understanding of what to expect from both solutions, and give you the answer to why we think CloudKit needs lots of improvements.
Read also: What is Parse?
What did we analyse?
We picked up the following features to compare the platforms: dashboard, server-side logic, import/export of data, analytics, local storage, cross-platform, support for social networks, web hosting, and REST API. So let’s start our comparison!
Dashboard is a page that shows you the data you already stored, and lets you organize it in your own way. You can login to Dashboard after setting up your app for iCloud / CloudKit in your iOS Developer account.
CloudKit Dashboard is quite limited, since everything you can do here is create and edit data. What is more, it doesn’t look like a usual table view, which is a characteristic of Parse. The structure of models is represented in the section Record Types, and the data itself is stored in Default Zones (one Default Zone for Public database, and one for Private database).
CloudKit Dashboard also allows you to see what’s included in your Team and with what privileges, as well as setup a data storage for working in the development and production mode.
That’s pretty much it for CloudKit Dashboard functionality. Hope they add more features soon.
2. Server-side logic
As a developer who worked with Parse, I can say that a feature called CloudCode is a very useful tool which lets you implement some tasks directly on the server, and even connect some libraries to it. So, for example, if you want to calculate statistics, you can totally do it with CloudCode.
CloudKit is deprived of this possibility. Apple should definitely build an analogue of CloudCode so that we could write code to run on the backend.
3. Background Task
As a consequence from the lack of server-side tooling infrastructure, there is no Background Task which could be implemented whenever you need it. Thus, we lose the flexibility of data processing on the server.
4. Import / Export of data
Parse lets you backup your data in JSON. This way you can be sure that it’ll be securely stored on your local server. CloudKit ... again doesn’t let you do that.
Read also: From JSON to CoreData fast and effectively
As you know, Parse supports data-based analytics. You can monitor traffic, frequency of requests, push-notification activities, etc. You can also track crashes complete with stack trackes and metadata. Besides, Parse lets you view your data on a graphic dashboard.
Unfortunately, CloudKit framework doesn’t provide the same feature.
6. Local storage support
If you use Parse, you can store your data locally, right on your device (this functionality is available on both iOS and Android). Here is how:
//iOS NSArray *objects = [query findObjects]; [PFObject pinAllObjectsInBackground:objects];
//Android List<ParseObject> objects = query.find(); ParseObject.pinAllInBackground(objects);
In CloudKit, there is no mechanism which lets you choose how you’d like to store your data (locally or remotely). But you’re welcome to use CoreData, or a third party service like Realm database for this purpose.
Needless to say, CloudKit only works with iOS and OSX devices. Parse, on the other hand, supports a whole bunch of devices and OS, such as iOS, OSX, Android, Windows, Windows Phone.
Parse lets you create your own website and take a domain name on their platform. (By default, you get the second level domain name, but you can set the first-level name as well). In other words, you get a Project Directory with website content, settings, and support requests.
There is nothing like that in CloudKit.
9. REST API
Parse lets you use REST API. This means that there are a lot of third party libraries for receiving and transferring data which work with Parse.
CloudKit doesn’t support REST API.
10. Support for social networks
If your users log in through Facebook, Twitter, or another social network, their data is stored in Parse’s Users table. CloudKit also has a Users table, but I haven’t found a built-in mechanism for logging in through Facebook/Twitter accounts. However, you can use the information of the users who logged in through iCloud. All you have to do is use iCloud user account without having to build login and registration functionality.
Read also: 4 MBaaS solutions compared
Now we’re through with a portion of criticism of CloudKit. But there’s got to be something that Apple actually did well. Let’s take a look at CloudKit’s light side.
Advantages of CloudKit
The size of the storage is an obvious advantage of CloudKit. The amount of storage and data transfer allocated to your apps will scale and grow with every user - all the way up to 1 PB in asset storage and 10 TB in database storage - all for free. With Parse, on the other hand, users can exhaust your resources much faster.
CloudKit allows you to use containers. CKContainer is an object that encapsulates content associated with an app. In other words, CKContainer is responsible for communicating your app with a server. It also allows for increased flexibility, since a few apps may have a single container, and a single app may have access to a few containers. Every app has at least one container by default. Parse, on the other hand, provides a single database for every app. What’s more, CKContainer helps you protect and isolate data, and prevents unauthorized interception of data. CloudKit is in general a highly protected system, because it’s based on iCloud, and you know how passionate Apple is about security issues.
NOTE: A user should be logged in in iCloud. Otherwise, you can’t access CloudKit containers.
As you can see, Apple’s CloudKit is not a bad product, but it desperately needs enhancement. One more reason for CloudKit being worse than Parse is a lack of development experience. So far, I haven’t found any examples of projects that were developed using CloudKit. Anyway, we’re excited about what’s ahead of CloudKit, and will surely tell you more once Apple introduces changes to their framework.