CloudKit is a remote datastore provided by Apple. One of the most common usage patterns for it is to persist data across app installs and devices.

Unlike iCloud Core Data (which is now defunct), you need to provide your own local storage mechanism. You can use Core Data, SQLite, plists, among many other options. This also works particularly well if you use your local datastore as a cache for CloudKit. Unlikely solutions like the soon-to-be-defunct Parse, CloudKit doesn't support server side code. So an easy way to think about CloudKit is to think of it as a remote database that you can read-write directly from your apps.

I'll list a few important concepts in CloudKit and mention the closest RDBMS concept. Note that since CloudKit isn't a RDBMS, the terms usually don't mean exactly the same thing:

• Database - there is a public database and a private database. Every user can access the public database and each user can only access their own data in the private database.
• Zones - zones group records together. Updates to records in a zone can be an atomic transaction. There is a default zone in both the public database and private database. You can only create custom zones in the private database. This is similar to a database in an RDBMS.
• Record type - a collection of records. This is similar to a table. A record type consists of fields which can be one of several built-in types such as String, Date/Time, Int(64) or a list of these types, such as a List of Strings.
• Record - a row of data. This is equivalent to a row in a table.
• Dashboard - CloudKit provides a web-based dashboard

Code to use CloudKit is too long for a nugget, so I'll point you to Apple's CloudKit quick start guide.

CloudKit is practically free for most usage patterns, so check it out.

Your feedback is valuable: Do you want more nuggets like this?   Yes   or   No