NSPersistentCloudKitContainer change cloudKitContainerOptions while app is running

I use NSPersistentCloudKitContainer to sync my apps data to iCloud. The app has a settings switch to enable or disable iCloud sync.

As described in this thread, I set cloudKitContainerOptions to nil depending on the users setting. This is done before the persistent stores are loaded and works fine when the app is launched for the first time.

My problem is that I don't know how to apply this settings change while NSPersistentCloudKitContainer is already loaded and active and its ManagedObjectContexts are in use?

I could reload the entire container, but will that work while the app is still using contexts from the other container?


Replies

I've similar concerns.

The contexts from the first container will not be useable (at least in my testing). Short of tearing down the old core data stack, standing up the new one and traversing the view hierarchy to replace all existing managed objects and managed object contexts, there doesn't seem to be a way to toggle sync using NSPersistentCloudKitContainer.

Not being able to pause or toggle sync seems to be a real shortcoming with NSPersistentCloudKitContainer.

For kicks, I tried just disabling iCloud for the app Settings->AppleID->iCloud->App but that just deleted all the data on the device.

I can live with the "eventual consistency" and not knowing sync progress, but not being able to toggle sync is a "show stopper".
Post not yet marked as solved Up vote reply of rdm Down vote reply of rdm
I've posted a suggestion for a sync enabled/disabled switch on NSPersistentCloudKitContainer through the feedback tool (FB8571301). This is the reply I got:

We do not encourage applications to implement their own sync controls. The user can control the sync state of an application using the iCloud Preferences in the Settings app.

The problem is that the iCloud preferences in the settings app are rather hidden.. And there is no way to directly link to this page from my app.

There are inherent ownership challenges with toggling between synced and unsynced data. For this reason we recommend using a separate persistent store to hold unsynced data separately from the user’s iCloud data.

This is necessarily a heavy-weight operation, the local store must be added and the cloud store removed when the user disables sync. You can customize the persistent store descriptions of a container after it is initialized. For example, you can set the store descriptions on it immediately, which will prevent the default descriptions from loading.

If the container is already loaded, you must unload all the persistent stores and then mutate the descriptions accordingly.




Thanks for the update. Not really the answer we're looking for but I guess it clarifies their position.