Design the Launch Sequence (iCloud)

[rskokan]

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; your app, on the device it is being launched on, 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.

iCloud might or might not be available.
The user might have set the device to Airplane mode, or the network might be otherwise unavailable. Determine how you want your app to behave when iCloud is unavailable. One option, for example, is to allow the creation of new records but to keep existing records read-only. If you allow editing of existing records, be prepared for additional data reconciliation when your app next connects to iCloud.

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.”

[rskokan]

Basic support to react on iCloud disabled added.
Must be described that after the iCloud config change the user must restart the app. (Issue #18).

iOS 6 will support notification about iCloud state changes better, e.g. NSUbiquityIdentityDidChangeNotification.

Removing issue from First release.