NSPersistentCloudKitContainer

I'm really excited about the new public database options introduced in the Sync a Core Data store with the CloudKit public database talk! I see in the documentation that the databaseScope refers to the CKDatabase.Scope which includes an option for the shared database. Does this mean that we will be able to automatically sync CoreData records to a shared CloudKit database this year? I would really like to add support to my app to sync data with friends through CloudKit, but with the existing system it is too much work to sync shared objects through a CKShare, so I have avoided building it so far. I'm really excited to start using the new changes. Thanks!

I have an app that uses NSPersistentCloudKitContainer to store all the data so it's backed by iCloud and synced between devices. Such app has a Share Extension, that can be triggered both from iOS (and iPadOS) and macOS (Catalyst). I was wondering if it's safe to instantiate an NSPersistentCloudKitContainer from a Share Extension due to it being very short lived. At the moment, I'm sending the data straight to iCloud instead of instantiating an NSPersistentCloudKitContainer, but it feels wrong because I'm using the keys that NSPersistentCloudKitContainer created internally (CD_MyEntity, CD_myProperty, etc.) to send it to iCloud and then being correctly pulled by my clients. The only concern that I have is that bringing up an NSPersistentCloudKitContainer that has to pull data, might delay or even loose the data that I'm saving right now because it gets killed after some amount of time since the share action has been completed. Any insights will be much appreciated,

In the previous version of my app, I used this pattern for previews that depended on a NSManagedObjectContext: struct ContentView_Previews: PreviewProvider { static var previews: some View { tttt let managedObjectContext = (UIApplication.shared.delegate as! AppDelegate).persistentContainer.viewContext return ContentView().environment(.managedObjectContext, managedObjectContext) } } With the delegate gone, I've swapped to this: class PreviewData { static var persistentContainer: NSPersistentContainer = { let container = NSPersistentCloudKitContainer(name: Structure) container.loadPersistentStores(completionHandler: { _, error in if let error = error { fatalError(Unresolved error (error)) } }) return container }() static var previewContext: NSManagedObjectContext { persistentContainer.viewContext } This works for previews some of the time. For example, I have this FilteredList: import CoreData import SwiftUI protocol StructureManagedObject { static var defaultSortDescriptors: [NSSortDescriptor] { get }

In session wwdc20-10650 - https://developer.apple.com/videos/play/wwdc2020/10650/ Sync a Core Data store with the CloudKit public database at 14:22, Nick says NSPersistentCloudKitContainer can't use CKFetchRecordZoneChangesOperation with the public database, it has to use CKQueryOperation. I was wondering why didn't you use CKSubscription? Create a subscription for each record type and the CKQueryNotification can contain CKQueryNotificationReasonRecordDeleted. It's been a while since I worked on my own public database sync but I think that is how I did it. This is the second time I've heard of the sync design being affected by limitations of CloudKit and it worries me. The first time it was when you decided not to use CKReference and instead create your own relation records because you said CloudKit had a limit on the number of references. Personally I didn't think the number was too low and I didn't understand why it couldn't just be raised, and if you had paired that with the non-public CKReference