Designing for Core Data in iCloud

Adopting iCloud Core Data storage makes the content in a shoebox-style app (like iPhoto) or a database-style app (like Bento) available on all of a user’s devices. See iCloud Programming Guide for Core Data for a complete implementation strategy.

Note: To create a Core Data app, you design a managed object model and work with managed objects. If you are not already familiar with Core Data, read Core Data Programming Guide.

Core Data Sends Incremental Changes to iCloud

Each instance of your app, on each device attached to an iCloud account, maintains its own local Core Data store file. When data changes locally, Core Data writes change log files to your app’s default ubiquity container.

The change log files, not the store file, are uploaded to iCloud and downloaded to each of a user’s other devices. When a change log arrives from another device attached to the same iCloud account, Core Data updates your app’s local copy of the SQLite database, based on the received change log. iCloud and Core Data ensure that each local database is updated with the same set of changes.

To learn more about using SQLite persistent stores with iCloud, see “Using the SQLite Store with iCloud” iniCloud Programming Guide for Core Data.

Managed Documents Support iCloud

The UIManagedDocument class is the primary mechanism through which Core Data stores managed documents in iCloud on iOS. TheUIManagedDocument class manages the entire Core Data stack for each document in a document-based app. Read “Using Document Storage with iCloud”in iCloud Programming Guide for Core Data to find out how to use managed documents in your app.

In OS X, Core Data integrates with the document architecture through the NSPersistentDocument class. However, in OS X v10.8, instances of this class do not provide specific support for iCloud.

Design the Launch Sequence for Your iCloud Core Data App

When you adopt iCloud, take special care when designing the launch sequence for your app. The following factors come into play and you must account for them:

• The user might or might not have previously indicated a preference to use iCloud in your app; the local instance of your app might or might not have already established its initial store in a ubiquity container.
  As a first step in your launch sequence, read the local user defaults database using the shared NSUserDefaults object. During operation of your app, use that object to save user choices that you’ll need on next launch.
• The user might log out of iCloud or switch to another account.
  If a user logs out of iCloud, or switches to another account, the ubiquity containers for the previously-used account are no longer available to your app.
• The local Core Data store might be newer or older than the store on another device owned by the same user.
  During app launch, Core Data might need to reconcile the local store with change logs from iCloud. This can involve detection and resolution of duplicate records and conflicts. Testing is critical. To get started with some tips, refer to “Testing and Debugging Your iCloud App” as well as “Best Practices” and “Troubleshooting” in iCloud Programming Guide for Core Data.