“NSPersistentCloudKitContainer”

How can I check that an entity already exists remotely ? In theory you could write some CloudKit code to execute a CKQueryOperation that checks for your seed content. But that won't handle the race between a device exporting the data and another device launching the app and parsing the json file. You can also check if records exist in the local store using NSFetchRequest. However for the same reason that won't prevent you from inserting duplicate records on multiple devices if they haven't synced with the CloudKit server yet. There are a number of approaches to seeding your application store with content in a reliable way: Don't sync the seed content, instead use an un-synced store to hold the data from the JSON file and a synced store to hold user data Unique the seed content on each device as it is updated by NSPersistentCloudKitContainer Unfortunately NSPersistentCloudKitContainer does not support unique constraints yet, you can file a feedback request for that though.

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.

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)

This won’t answer your question, sorry… but it might be related to the problem several of us are having with NSPersistentCloudKitContainer - it seemed to appear with beta 4 and is still present with beta 7. Something fundamental was modified in beta 4 and sure hope it’s fixed before release otherwise I’m in real trouble (from my users!). See here for my thread on the issue.

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

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, ——

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

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.

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

Yes. the current design of NSPersistentCloudKitContainer is to sync everything. There are other sync engines available between CoreData and CloudKit, such as CKSyncEngine in iOS 17, and open source sun engines like CloudCore, which might provide more fine-grain control over sync. And of course, you can always write your own that best suits your needs.

@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