NSPersistentCloudKitContainer

After many months/years of trying to create my own CoreData/iCloud sync engine, and getting about 90% of the way there; I gave up and started using NSPersistentCloudKitContainer, forcing us to drop support for iOS 12-. At first all seemed fine, however, today it all went horribly wrong (still investigating why) I now have 'duplicate' CKRecords of single ManagedObjects in CloudKit, and (it seems, although still tracking down the model) disconnected 'references'. Having looked at CloudKit Dashboard is seems that NSPersistentCloudKitContainer does not use ANY references, but simply a String of the UUID of the referenced CKRecord. I can only presume that this is a workaround to prevent Referencing a (not yet) non-existent CKRecord. So, this presents several questions: Is the lack of CKReference by design, or a bug? What defensive programming is in place to prevent duplications or corrupt references when using Stringly-Typed pseudo-references? Is there a way to inform the NSPersistentCloudKitContainer

I believe that right now there's no way to be notified when the sync status of an NSPersistentCloudKitContainer changes. Is my assumption correct? I'd like to know if there are pending changes to be synced or when the sync starts/ends to be able to reflect it on the UI to inform my users. Any ideas on how (or if it's possible) to achieve what I need? Thank you!

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

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 }

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,

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!