Design a CloudKit-compatible data model and initialize your CloudKit schema.
- Core Data
To pass records back and forth, Core Data stores and the CloudKit database need a shared understanding of the data’s structure. You define this information first in the Core Data model, then use it to generate a schema for CloudKit.
Design a CloudKit-Compatible Core Data Model
The CloudKit schema doesn’t support all Core Data model features. As you design your model, note the following limits of the CloudKit schema and make sure you design a compatible model.
Core Data Model element
CloudKit Schema limitation
Unique constraints aren’t supported.
All relationships must be optional. Due to operation size limitations, relationship changes may not be saved atomically.
All relationships must have an inverse, in case the records synchronize out of order. (In a Core Data model, an inverse is strongly recommended but not required.)
The Deny deletion rule is not supported.
Entities in a configuration must not have relationships to entities in another configuration.
For more information about how Core Data translates managed objects to CloudKit records, see Reading CloudKit Records for Core Data.
Initialize Your CloudKit Schema During Development
Once you’ve created your Core Data model, you tell CloudKit what types of records CloudKit needs to store by initializing a development schema. The development schema is a draft that you can rewrite as often as needed during development, before the record types and attributes become immutable in production.
Initialize the schema from your developer tooling, for example, from an integration test. If you like, you can initialize the schema as part of every test run.
In the code that sets up your
NSPersistent, initialize an
NSPersistent on the container. Toggle the shouldInitializeSchema property on the container options to initialize the schema.
Set shouldInitializeSchema to true.
Run your app on a device. Look for this log line in your console output:
Kit Mirroring Delegate: 0x7f9699d29a90>: Successfully set up Cloud Kit integration for store
Set shouldInitializeSchema to false.
During initialization, Core Data creates representative
CKRecord instances for all stores in the container that use Core Data with CloudKit and uploads them to CloudKit. Finally, the schema becomes visible in the CloudKit dashboard, and Core Data deletes the representative records.
Reset shouldInitializeSchema after initialization to ensure that you only create these records once.
Throughout Development, Reset the Environment
As you change the model during development, periodically visit the CloudKit dashboard to reset the development environment and delete the existing development schema, before initializing a new one. For more information about resetting the development environment, see Using CloudKit Dashboard to Manage Databases.
Push Your Schema from Development to Production
When you’re satisfied with your model, have tested your app, and are ready to submit it to the app store, it’s time to promote your schema from development to production.
Initialize your schema one last time, then promote it from the CloudKit dashboard. For more information about promoting a schema from development to production, see Deploying the Schema.
Update Your Production Schema
Plan carefully how your app will handle forward compatibility and major changes to the model, because you can’t rename or delete CloudKit record types and fields in production. Consider these strategies:
Migrate users to a completely new store, using
NSPersistentto associate the new store with a new container.
Cloud Kit Container Options
Incrementally add new fields on existing record types. However, earlier versions of the app can’t read these new fields.
Version your entities by including a version attribute from the start. Use a fetch request with a predicate to direct different versions of the app to access the records they support. Older versions of the app ignore new data.
For example, consider a
Post entity with a
version attribute. In earlier app versions, fetch only those records created with the entity’s original fields. For later app versions, fetch both original records and records that contain added fields.
Along with these choices, consider your timelines for supporting multiple versions of your app, and for migrating users to newer app versions.
For tips on migrating records to a new schema, see Designing for CloudKit.