CloudKit as MBaaS
These days, almost every mobile application is connected to a server. Very frequently, companies decide to write their custom servers, but when your application doesn't need to run a complicated task on a server, maybe it is worth to use BaaS (Backend as a Service).
Services such as Google Firebase or Microsoft Azure after a short configuration are able to provide backend that is enough to meet the needs of most applications. In this blog post, I'll try to present capabilities of Apple's BaaS, which is CloudKit. I will start with the three biggest advantages of CloudKit which are Initial configuration, Price and Security & Privacy.
Configuration
Initial configuration is extremely easy and consists of two parts:
• Configuration in project
In the project we need to select just one checkbox in the capabilities tab and everything else should be done automatically:
We don't need to import external libraries because CloudKit.framework is one of the libraries that Apple provides within iOS and macOS systems. It guarantees that this framework will never become outdated, which is an additional benefit.
• Configuration in dashboard
In dashboard we can specify Record Types which will be basis for each record stored in the database, however, this is not necessary because:
Record types will be automatically created in the development environment when you use the native API to create records of that type.
And that's all, our backend is ready to use.
Price
CloudKit is free for all enrolled developers.
Security & Privacy
This is the best part of using CloudKit. We don't need to worry about security and privacy on the backend side, because everything is covered by Apple. It can make debugging a little bit harder because we (developers) haven't got access to users' private data, but this is a small inconvenience. We all know that Apple strives for users’ privacy. This is an additional benefit of using CloudKit. Data is not send to servers that belongs to other company.
Database structure
Now it is time to talk about the database structure. There are always two environments:
- Development
- Production
Inside each environment there are three databases:
- Public
- Private
- Shared
These databases contain zones. Public databases have only one default zone. Private databases may have default zone and custom zones. Shared databases contain private zones shared by other users.
Lastly, zones contain records with data.
Data types
If we need a service such as CloudKit, it means that we have data for storage. So what kind of data can we keep there?
| Field Type | Class | Description |
|---|---|---|
| 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/Time | NSDate | A single point in time |
| Double | NSNumber | A double |
| Int(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 |
As you can see, there is no boolean type, but beside this, there are all the necessary types of data.
Usage
CloudKit is not a relative type of database, which means objects can't be nested inside other objects, instead we can create references. This solution has got pros and cons. Data usage is much smaller because when we fetch an object, his connected objects are not fetched. However, as a result of this, whenever we want to get related data we need to fetch each record separately. Another inconvenience is that we can't create models with defined structure; every record needs to be handled by CKRecord. This makes that CloudKit based on strings, which is tedious to use. My subjective opinion is that competition such as Google Firebase or Microsoft Azure is better in this regard.
Accounts
One of the most important parts of a database is handling users' accounts. Competition like Firebase support login by Facebook, Google Plus or Twitter out of the box. CloudKit does not provide such functionality, but instead, we can use iCloud accounts witch almost every user of Apple devices has, so if we don't want to provide social network features and don't need additional data from users, then we can forget about register / login part of the app.
Cross-platform
One of the most common myths about this service is that CloudKit can't handle Android or other platforms. This has not been true, since Apple presented CloudKit JS. However, using CloudKit on Android will not be as easy as using similar services, because Apple does not provide official SDK and all requests need to be sent by REST.
Sharing
Sharing is one of the strongest assets of CloudKit. You can easily share records and files using only emails or phone numbers. It provides excellent experience for users, although this feature is available only to Apple ID owners.
Summary
CloudKit is a great alternative to simple applications focused on Apple products users, but if you plan to create a cross platform or more advanced application you should consider different products.
