NSPersistentCloudKitContainer

I've not experience that with UserDefaults. I wouldn't give up on finding that issue. But anything I want protected in cases where a user might lose or change their device, I use CoreData with NSPersistentCloudKitContainer. Which is easy to remember if you watch this video as this Nick Gillet says it 1.5 times per minute.

It works in the simulator but syncs only on app startup when you set the automaticallyMergesChangesFromParent-option on the viewContext. See https://stackoverflow.com/questions/56601716/how-to-get-default-project-with-nspersistentcloudkitcontainer-up-and-runningThe actual sync via push notification only works on real devices.

This issue is still ongoing. Thus far we have not been able to figure out what is going on but have reduced complaints quite a bit by rolling back to minimum OS / Devkit of iOS 17. So it is some kind of bug or behavioral issue with iOS 18 SDK. We cannot find a pattern to it other than that most users are in Europe and are not using iCloud to backup. This means we are using the NSPersistentCloudKitContainer regardless of if users enable or do not enable iCloud usage. This might be the root so if anyone is aware of what might have changed in iOS 18 that would do this PLEASE let me know. We have also now default always enable iCloud usage without asking if we find an account present. They can turn it off (with big warnings) if they want but we no longer ask on launch. Also we will investigate not always using NSPersistentCloudKitContainer if iCloud is not used.

It's not getting removed in iOS 13. In fact, much of the new NSPersistentCloudKitContainer workflow is based on persistent history tracking. See session WWDC 2019 session 202 Using Core Data With CloudKit and session 230 Making Apps with Core Data.

Do you check if the store URL you pass to NSPersistentCloudKitContainer is valid in the failure case, and if the URL is exactly the same as the one in the successful case (after you restart your iPhone)? I am wondering if the system returns you the right root path of the App Group container after you restore from backup... Best, —— Ziqiao Chen  Worldwide Developer Relations.

In case others get stuck with this, I created a new container and ensured the container = NSPersistentCloudKitContainer(name: name) , and the CoreData file was the same name and all went fine afer. I also made sure the container name, et.al. was a short name and was different from the BundleID. Blessings, --Mark

I'm having the same issue with an established app with Xcode 12 & iOS14 using NSPersistentCloudKitContainer. When I try to run the exact code with iOS15 & Xcode 13 (Developer Beta 1 for both) I see the Failed to sync user keys error. I suspect this is an early beta bug so hopefully it will disappear in subsequent betas.

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.

That worked purfectly, thank you so much! I honestly did not try that becouse I did not think it would work with line one and three in that block of code. I did not know that even though you set persistentContainer with type of NSPersistentContainer that you could alter that with type NSPersistentCloudKitContainer on line three. I will have to keep that in mind for the furture, thank you.

I've seen that the documentation of NSPersistentCloudKitContainer has been updated after the WWDC with two new Type Properties: class let eventChangedNotification: NSNotification.Name and class let eventNotificationUserInfoKey: String I think that are related to your question but I haven't tried them. I'm looking for this feature from the last year and I hope that in iOS 14 it will be implemented.

_pcs_data is tied to the iCloud account (Apple ID), and is needed when an app accesses a CloudKit private database. When the device is logged out and then logged in with a new iCloud account, NSPersistentCloudKitContainer deletes the data owned by the original account. Unless you do something interesting that allows one account to access the database owned by the other, you don't need to worry about _pcs_data. The BAD_REQUEST error isn't quite concerning to me because NSPersistentCloudKitContainer takes care the requests and may retry them if needed. Worth mentioning though, CloudKit has some limits, as discussed in Avoid hitting a CloudKit limit. You might want to confirm that your app doesn't hit any of them. QUOTA_EXCEEDED is what I would concerned. It is related to the iCloud storage quota of the current logged in account. If that account did have plenty of un-used storage, as you had mentioned, it can be something on the system side went wrong – Either the device showed a wrong un-used

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)