“NSPersistentCloudKitContainer”

Operational transforms that model scalar values are typically implemented by collections of contributions (the operations). For example a vector or array of integers that represent the value. The implementations are necessarily aligned with application requirements like language, technology stack, supported distributed systems primitives etc. With NSPersistentCloudKitContainer such a counter is trivially implemented using a one-to-many or many-to-many relationship that joins the transformations to the root entity. If you have specific questions about that we are happy to help, but will require a little more context like your model and desired contribution structure.

When there's a crash in WidgetKit, it often goes unnoticed by developers and users because there's no clear indication within the widget itself. In contrast, a crash in the main app is more apparent because it causes the app to close suddenly. One theory, as discussed in this https://developer.apple.com/forums/thread/668649, is that the main app and the widget are attempting to perform a migration simultaneously. However, I'm skeptical of this theory because our last CoreData migration began last year. Therefore, it's surprising to see a high number of crashes after a year. Here's where fatal error occurs. It is a pretty standard CoreData stack used in widget. private static func setupNSPersistentContainer() -> NSPersistentContainer { precondition(Thread.isMainThread) let container = NSPersistentCloudKitContainer(name: xxx, managedObjectModel: NSManagedObjectModel.xxx) // Integrate AppGroup with CoreData. If we are assigning a new store description to CoreData, it is important // to finish all sto

I’m seeing the same error on both Xcode 15.0 and Xcode 15.1 Beta. For me, I think this issue stemmed from NSPersistentCloudKitContainerOptions. I’m using NSPersistentCloudKitContainer in my app. If I set NSPersistentStoreDescription.cloudKitContainerOptions to nil, this error would go away. Of course my app can’t sync via CloudKit if I do that. Another issue may or may not related to this warning: ever since I built my app on Xcode 15, I’ve seen excessive disk read on the sqlite file of CoreData on launch. The amount of disk read can be as much as twice the size of the sql file, basically making the app impossible to use for some users with large data set. But if cloudKitContainerOptions is nil, this excessive disk read would disappear. Last issue may or may not related to this warning: the size of CoreData sqlite file in my app is 130 MB. But in iPhone Settings → [User Name] → iCloud → Manage Account Storage, it says my app takes up a whopping 2.7 GB of space. No matter how the calculation is done,

What does a sysdiagnose from the watch tell you about your process' activity? i.e. Is it receiving push notifications? Are NSPersistentCloudKitContainer's activities being run? Reviewing this WWDC session may be helpful for interpreting the logs: https://developer.apple.com/videos/play/wwdc2022/10119/

One root cause that we have identified for this issue is removing a many-to-many relationship from your model. This is supposed to be a supported migration, so we are collecting feedback reports to track against that as a bug. If you would like to be notified of a fix for that share your feedback number here and we can relate them together. As a workaround you can simply add the relationship back. Or, attempt a more detailed / invasive solution described below. Our schema is public and described here: https://developer.apple.com/documentation/coredata/mirroring_a_core_data_store_with_cloudkit/reading_cloudkit_records_for_core_data Your container will contain CDMR records that identify the offending relationship. The fields CD_entityNames and CD_relationships can be used to tell which relationship a record represents. One (or more, depending on how many relationships you removed) of those records may be causing this issue. You can choose to: Add the missing relationship back to your model Delete the offending