“NSPersistentCloudKitContainer”

Everything appears fixed for me in Beta 5. I don’t use NSPersistentCloudkitContainer, just staight CloudKit calls. I wish Apple was more diligent in documenting this in release notes though. There’s nothing about this in Xcode or iOS beta release notes.

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.

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.

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

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.

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.

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.

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.

https://developer.apple.com/documentation/coredata/nspersistentcloudkitcontainer/event When you get a successful .import event your device is current with whats in iCloud. You can then use a fetch request to identify / check for interesting data. Note that current here is caught-up-to the iCloud server, it doesn't imply anything about the state of other devices.

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.

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