“NSPersistentCloudKitContainer”

What worked for me was setting cloudKitContainerOptions = nil before calling container.loadPersistentStores lazy var persistentContainer: NSPersistentContainer = { . . . if !UserDefaultsManager.shared.syncWithCloudKit { container.persistentStoreDescriptions.forEach { $0.cloudKitContainerOptions = nil } } container.loadPersistentStores( completionHandler: { (_, error) in ... } )This is a hack since this works only when persistentContainer is first initialized.Trying to do this after persistentContainer is initialized would require that I safely teardown and reinitialize the CoreDataStack. Reinitializing CoreDataStack creates a new managedObjectContext which then must be passed down the view hierarchy and to any services or managers that cache the managedObjectContext.There are many reasons to want to toggle or pause syncing with CloudKit, and since NSPersistentCloudKitContainer is privy to all the inner workings of syncing with CloudKit, NSPersistentCloudKitContainer should be the one to hand

Did you get this to work? I have a similar need, that is, to offer iCloud storage and sync as a premium feature. I have CloudKit sync working but how do I switch it off? I want to disable CloudKit sync and only enable it when a customer pays for the premium version. I've tried setting the container's cloudKitContainerOptions property to nil but CloudKit sync still happens.Here's my Core Data stack:private lazy var persistentContainer: NSPersistentContainer = { let container = NSPersistentCloudKitContainer(name: modelName) let localDescription = NSPersistentStoreDescription(url: configurationsURL.appendingPathComponent(local.sqlite, isDirectory: false)) localDescription.configuration = Local let cloudDescription = NSPersistentStoreDescription(url: configurationsURL.appendingPathComponent(cloud.sqlite, isDirectory: false)) cloudDescription.configuration = Cloud cloudDescription.cloudKitContainerOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: cloudKitContainerIdentifier) cloudDescrip

If I'm reading between the lines, after looking at Persistent History Tracking, I think the content will be downloaded in the order it was created. Although the single article, Consuming Relevent Store Changes, I read in the developer docs assumes some familiarity with the technology, which I have none, it doesn't actually mention iCloud or CloudKit. I still have to watch the WWDC video that introduces Persistent History Tracking, so I'm hoping What's New in Core Data 2017, answers a lot of questions, (although I don't have my hopes up considering it's pre-Core Data for CloudKit), because the Persistent History section in the documentation, is just an API reference with zero actual explanation of the technology. When I said my data model represents something like the macOS file system, I was implying it was an analogy. My app doesn't really have concrete directories or files. It's the tree structure I was trying to explain.My situation is slighly more complex than you might imagine, because of the seed data I

I am unfamilar with NSPersistentCloudKitContainerbut I note that the following references the private database:https://developer.apple.com/documentation/coredata/nspersistentcloudkitcontainer?language=objcA container that encapsulates the Core Data stack in your app and mirrors select persistent stores to a CloudKit private database.

How do you set the store description to nil.....I see its key/value but I tried to set it on the description after loading the store and it says its read only? // MARK: - Core Data stack lazy var persistentContainer: NSPersistentCloudKitContainer = { /* The persistent container for the application. This implementation creates and returns a container, having loaded the store for the application to it. This property is optional since there are legitimate error conditions that could cause the creation of the store to fail. */ let container = NSPersistentCloudKitContainer(name: name) container.loadPersistentStores(completionHandler: { (storeDescription, error) in {tried to set it here storeDescription.options = nil}

OK so it turns out that setting my store descriptions to be added asyncrounsly was the issue. I was hoping it would parallelize the adding of multiple stores within a larger synchronous operation, but the implications are wider. The entire loadPersistentStores method becomes asynchronous, in my experience.It did create two scemas. One in each iCloud container. The problem is that schema designer, isn't capable of supporting multiple iCloud container configurations. And that makes sense because there is nowhere in the schema designer to set the iCloud container IDs. So it will simply complain that CloudKit backed configurations need to have the same entities in them. You'll see a lot of errors like this...xcdatamodel: error: CloudKit Integration: Container.children destination entity ContainerRelation is missing from these configurations: Appture, CloudDataKit.Both configurations Appture, and CloudDataKit have CloudKit enabled for each, and each only has a single entity in it, with zero relations.So it's proba

More info: I have experimented with code similar to yours to initialize two CloudKit schemas with one single request on the single NSPersistentCloudKitContainer instance. It does indeed work, however,there are limitations with the Xcode schema designer which render the results, effectively useless. The problems start when you create multiple configurations in your schema model, that are declared to be used with CloudKit. The schema designer has no knowledge of container identifiers, nevermind multiple container identifiers. I discovered that as soon as I added a new CloudKit backed configuration and added a single new entity to it with zero relationships, my project no longer compiled. Xcode told me that I had to add the entities from the other CloudKit backed configuration to this new configuration with it's single isolated entity. Bizarrely, it never instructed me to add the new isolated entity to the previous CloudKit configuration. It was complaining about relationships in the older CloudKit conf