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 behavior is improved soon.

I shared some thoughts on this a month ago in another answer. In summary: Saving to Core Data itself is reliable from an extension The extension likely is killed before the sync to CloudKit is scheduled/complete. This is why you see the behavior of needing to launch your app for syncing to occur. There is no workaround at this point, as the syncing is done in their internal API, but I'm hoping my conversation with the Apple engineer was enough for them to consider improvements this year.

I'm seeing this error and I'm not even using SwiftData in this app. It's occurring when I update an array property on an Observed model class. Like other comments, this only started with Xcode 16.