NSPersistentCloudKitContainer

I believe that yes, it will create two stores and two different containers with private databases. I used to think, incorrectly, that there was a 1 to 1 mapping between an instance of NSPersistentCloudKitContainer, and a single CloudKit store description, but I've come to realize that one instance can handle multiple cloud synced stores.When working with multiple stores, create an instance of NSPersistentCloudKitContainerOptions for each store you wish to use with CloudKit.And no, you can't access the public, or shared database with Core Data for CloudKit. Also, if you want to write to the public database but not as an individual user, you can't do that through the iOS CloudKit API. CloudKit CKRecord instances are always owned by the user who created them. You'd have to use a server to server key and use their REST API from your app. That way you can write records as admin. I was thinking of using the public database to store app configuration data, but I'm not sure I want to develop with yet another

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

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

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}

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.

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