Migrating to CloudKit
This document covers information on how to migrate data to CloudKit.
CloudKit powers some of the most popular apps in iOS and OS X. It is designed to help you get started on your app quickly and scale with you as your user base grows.
Before reading this document make sure to read the CloudKit Quick Start and Designing for CloudKit as they walk through core concepts and how to get set up.
What can I migrate?
Some of the high-level features that CloudKit provides are:
Data storage, both user-specific and app-wide, with the ability to synchronize data across users' devices.
Full-featured APIs for iOS, OS X, and the web.
Managed push notifications that allow you to visually notify the user or silently notify the device to new changes.
Automatic user authentication in iOS and OS X for iCloud users.
A web Dashboard for viewing and editing your data and schema, viewing public usage analytics, and more.
How do I migrate?
In order to migrate data into CloudKit, there are two main points to consider:
How should I get data into CloudKit?
Data that is not associated with a user can be migrated with a background process or server-side application. Data that is associated with a user must be written to CloudKit from your client application (iOS, OS X, or web) as a user signed into iCloud.
Where should I write data in CloudKit?
By default, CloudKit offers a private database that is only visible to the user who wrote the data, and a public database that is visible to all users.
Public DB, server-side migration
Private DB, client-side migration
Private DB, client-side migration
In the case of public non-user-specific data, you can use a server-side application to migrate the data, but in the case of private user-specific data you will need to migrate that data from your client application (iOS, OS X, or web). To understand more about why, make sure to read about public and private databases.
What will it cost?
Any data stored in a user's private database counts against their personal iCloud quota whereas data stored in your container's public database counts towards your container's public usage. CloudKit provides up to 1TB of public storage and data transfer that scales with the number of users you have and to find out more, visit iCloud for Developers page.
Migrating public non-user content
To migrate public data that doesn't need to be attached to any specific user, the easiest path is probably to build a server-side application that migrates the data. Here is the recommended approach:
Use the CloudKit Dashboard to:
Configure your schema to support the type of data you will be storing.
Set up a Server-to-Server Key to allow your application to write data into the public database.
Build a node.js application using CloudKit.js that does the following (likely in batches):
Read the public data from your existing data source.
Write that data into CloudKit.
Migrating user-specific content
As mentioned above, you won't be able to migrate user-specific data using a server-side application and instead will need to do so after a user has logged in to your client application (iOS, OS X, or web).
When a user uses your client application to write data to CloudKit it is marked as written by that user. This is often important for controlling who can read and write specific records. On top of this, CloudKit provides you the ability to store a user's private data into their private database so that no other users can access it.
To take advantage of both of these things, your user will need to be signed in with their Apple ID. You can read more about how to do this in the native API, the web services API, and CloudKit.js. On iOS and OS X, once a user is signed in to their Apple ID, they are automatically authenticated so you won't need to prompt them to sign into your app. Because you are migrating a user's data from an existing data source, it's likely that they will also need to be simultaneously logged in with your existing authentication service.
Organizing data in custom zones
When storing data in a user's private database, you have the option of storing related data in a custom zone, giving you the ability to later ask the server for the set of changes in that zone since a certain point in time. To read more, see the CKRecordZone and CKFetchRecordChangesOperation documentation, but consider using zones when migrating your data.
Writing the data to CloudKit
The CloudKit APIs provide various ways to write data and we recommend that you consider the following mechanisms:
Web Services API
Document Revision History
New document that covers information on how to migrate your data to CloudKit.