NSPersistentCloudKitContainer

So... the root cause of this issue is that you're calling recordID(for:) on the main thread during container setup (it looks like there is a fairly substantial import at the time you call it). NSPersistentCloudKitContainer can't concurrently serialize records and perform other work. You could file an enhancement request for that, but that would come with other consequences (like cache-miss issues for records that are in the process of being serialized). You can move this call to a background queue to avoid blocking the main thread's run loop on this work. As an aside, it looks like you're attempting to use the CKRecordID to coordinate data across multiple sync mechanisms. This is unlikely to lead to success. While it is exceedingly rare NSPersistentCloudKitContainer reserves the right to change the recordID for a managed object. We recommend that clients invent a foreign key of their own that they can pass to the other sync mechanism as a way of tracking related data.

You can use the feedback assistant to file bugs against NSPersistentCloudKitContainer. Include the following: A sysdiagnose from all of the participating devices The persistent store files from all of the participating devices If your dataset is large, a detailed accounting of the affected records and the mutations made to them from each device (as well as you recall, history tracking is the truth)

> Then I'd say it's safe to just keep hitting CloudKit with the same request until it succeeds, keeping any additional errors silenced. Here I see that you are able to listen if quota is exceeded or if the sync is successful or not. Is it a manual sync you are doing to the CloudKit or is the container configured as NSPersistentCloudKitContainer? If it is the later, how are you able to listen to these status callbacks? Any leads would be appreciated. TIA

Thanks for filing the feedback report. Other than that, if you would like to figure out what really happens when synchronization fails, please follow this technote to capture and analyze a sysdiagnose: TN3163: Understanding the synchronization of NSPersistentCloudKitContainer I am guessing that it is the system delaying or throttling the synchronization for some reason (reasonable or not), and am curious to see your findings. Best, —— Ziqiao Chen  Worldwide Developer Relations.

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

You can use the feedback assistant to file bugs against NSPersistentCloudKitContainer. Include the following: A sysdiagnose from all of the participating devices The persistent store files from all of the participating devices If your dataset is large, a detailed accounting of the affected records and the mutations made to them from each device (as well as you recall, history tracking is the truth)

Did you ever run your app and save some data to the CloudKit-backed Core Data store? NSPersistentCloudKitContainer only creates the custom zone when there is data. Also, you need to initialize the CloudKit schema, if not yet. See Create the CloudKit schema for the more details. Best, —— Ziqiao Chen  Worldwide Developer Relations.

If you are using SwiftData + CloudKit in both your main app and extension, which uses NSPersistentCloudKitContainer under the hood, I'd start with pointing you the following technote: Avoid synchronizing a store with multiple persistent containers Please feel free to follow up with further questions, if any. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Thank you for your reply. I have tried something like the following, however the quotaExceeded never gets printed even though the above error message does. I can see also that the code enters the .partialFailure section of the if, however ckerror.partialErrorsByItemID is always nil or an empty list. Any suggests on how to unpack the error and get to the underlying .quotaExceeded? class SyncMonitor { /// Where we store Combine cancellables for publishers we're listening to, e.g. NSPersistentCloudKitContainer's notifications. fileprivate var disposables = Set() init() { NotificationCenter.default.publisher(for: NSPersistentCloudKitContainer.eventChangedNotification) .sink(receiveValue: { notification in print(notification: (notification)) if let cloudEvent = notification.userInfo?[NSPersistentCloudKitContainer.eventNotificationUserInfoKey] as? NSPersistentCloudKitContainer.Event { // NSPersistentCloudKitContainer sends a notification when an event starts, and another when it // ends. If it has

Having used this API for two of my apps, and speaking with an Apple engineer, it sounds like we can assume the following: NSPersistentCloudKitContainer can be safely used in a Share Extension for storing data locally. It will complete the save operation locally. Uploading to CloudKit requires a scheduled background operation on the part of the API. Because of this, by the time the Extension is terminated, the background operation is not completed, and thus the CloudKit sync does not occur. In my testing, this leads to predictable behavior: Data is never uploaded from an Extension, however, Data is saved locally in your persistent container. And upon launching your app, with the container alive once more, it will sync your data to CloudKit. It's a bit unwieldy having to launch your app after an operation in an Extension, but from my own usage, I think it's safe to say that you can safely use NSPersistentCloudKitContainer, even if it doesn't sync as you or I would like. I truly hope this behav

@DTS Engineer We are not currently using any APIs specifically for iCloud account switches. Our app’s data is managed entirely through Core Data, backed by NSPersistentCloudKitContainer for synchronization with iCloud. When my colleague checked the CloudKit Console after logging into their iCloud account, they did not see the custom zone we use to store Core Data records. This absence has us concerned about whether the data is still recoverable. If the iCloud account is still active, should Core Data records managed via NSPersistentCloudKitContainer automatically sync back? Or does switching iCloud accounts result in the permanent deletion of associated Core Data records? Our plan is to recommend that the user logs back into their original iCloud account, ensures that iCloud is enabled for our app, and opens the app to allow time for the data to sync back. Is this the correct approach for recovering the data, or are there additional steps we should take? Any guidance would be greatly appreci

Have you set automaticallyMergesChangesFromParent = trueI choose to do this after I load my persistent container... lazy var persistentContainer: NSPersistentContainer = { let container = NSPersistentCloudKitContainer(name: persistentStoreName) container.viewContext.automaticallyMergesChangesFromParent = true container.loadPersistentStores(completionHandler: { (storeDescription, error) in if let error = error as NSError? { fatalError(Unresolved error (error), (error.userInfo)) } container.viewContext.automaticallyMergesChangesFromParent = true return container }()

CloudKit sync is very unstable. Sometimes it just stops syncing for no reason, other times it works almost instantly. When CoreData + CloudKit stops syncing, it can be that the system intentionally throttles the synchronization to balance the use of system resources and achieve the best overall user experience on the devices. To determine if that is the case and understand how the system works, you might want to read through the following technotes: TN3162: Understanding CloudKit throttles TN3163: Understanding the synchronization of NSPersistentCloudKitContainer TN3164: Debugging the synchronization of NSPersistentCloudKitContainer I also created a ticket: #FB14531806. Thanks for filing the feedback report. To investigate the issue, we would need to gather more information. If you don't mind, please follow the Provide actionable feedback section to gather the appropriate information and use it to update your feedback report. That would be a great help for the team's investigation. Best, ——

You can't save and delete the same record Assuming that you are using Data + CloudKit, I am guessing that this can be triggered by your code and data. Consider the following configuration as an example: Delete Rule: cascade articleA.associatedArticles -> [articleB, articleC...] articleB.associatedArticles -> [articleA, articleC...] If you delete articleA, Core Data will delete articleB due to 1 and 2, and change articleB due to 3 at the same time. You can review your code to see if the above case can happen. When you use Core Data + CloudKit, NSPersistentCloudKitContainer configures and performs the CloudKit operations without any involvement of your code, and so it is worth filing a feedback report for the Core Data team to investigate why the case isn't handled – If you do so, please share your report ID here. Already have a mirrored relationship registered for this key Based on the (more) information you provided to DTS, this seems to indicate that you has a reflexive relationship (a relatio

No, unfortunately if you hadn't set true for key NSPersistentHistoryTrackingKey, they will never get it to cloud, they will stay only in your device. A workaround that I used and worked fine, is to add a property to all entities (I used cloudReady: Bool, and at the first run of the app, after you adopt NSPersistentCloudKitContainer, change that property to true for all entities. This will force iCloud to sync those objects.