Store Only Essential Data in iCloud

Bandwidth, network availability, and storage are limited resources and have real, financial consequences for your users. When you design your schema, store in iCloud only information that can’t be re-created.

Core Data’s managed object model configuration feature simplifies working with data that’s split between two storage locations. With model configurations, you can set where specific entities—or even individual attributes—are stored. Use managed object model configuration to separate attributes and entities that need only be stored locally from those that should be persisted to iCloud. See Managed Object Models in Core Data Programming Guide for further discussion about model configurations. Additionally, Core Data efficiently persists external data to iCloud. Use the external data setting on attributes that are likely to hold more than 4 KB of data.

For an example of how to reduce what you store in iCloud, consider a Newsstand app that downloads and caches high-resolution magazines in Core Data and has a feature that allows the user to add bookmarks. Rather than store the entire model in iCloud, the app stores only the bookmark entities, with attributes containing the unique identifier of the magazine that each bookmark corresponds to.

A good approach is that if your app seeds a large set of initial data, it should not be stored in iCloud, because those records can be re-created. If the records are to be modified, it may be beneficial to design a schema and associated configurations that allow you to store only the changes in iCloud.

Design Your Core Data Stack to Be Efficient

iCloud-enabled Core Data apps are not only aware of data created on the device, they’re aware of data on other devices. It’s a good idea to keep this fact in mind when designing your Core Data stack.

For example, you traditionally use merge policies when you want to merge changes that were made in separate managed object contexts and persistent store coordinators. With iCloud, in contrast, you use merge policies to merge changes made to a record on multiple peers. For further discussion of merge policies, see Change Management in Core Data Programming Guide.

Avoid using nested managed object contexts with iCloud-enabled persistent stores. Because changes saved in child contexts are not persisted to iCloud until the parent context is also saved, nested contexts create unnecessary complexity. If your app doesn’t persist changes to iCloud quickly, you may confuse your app’s users or, worse, fail to meet their expectations.

Know When to Save Your Context

When you save a managed object context, Core Data creates, in the ubiquity container, a set of transaction changes that are guaranteed to be applied together on other peers. The size of this transaction set, and the frequency with which you save your context, both directly impact the performance of your app.

You decide when to save your managed object context by mapping actions in your user interface to the managed objects that are created, changed, and deleted in your model. Because a save corresponds to a complete set of changes that will be applied at the same time, you meet users’ expectations when you consider the events the user expects to be persisted to other peers. By tuning your save points to match complete sets of changes, you meet users’ expectations, avoid incomplete data from being persisted to other peers, and reduce the complexity of merging. You also increase performance by limiting the number of changes in a single merge and by limiting the frequency at which your context performs a merge.

For example, consider a recipe app that persists the user’s recipes to iCloud. Rather than save the context every time an attribute is set, the context is saved when the user finishes creating an entire recipe. Because factors like network availability, bandwidth, and storage were taken into account, each peer will either receive the entire recipe or nothing, rather than a partial record.

If your app creates, changes, or deletes managed objects in large batches, be sure to save and reset your managed object context frequently or divide the task up into smaller parts so that you divide the changes among multiple transaction containers.