Dear Ziqiao Chen, thank you for your reply and the hints pointing me in the right direction. I managed to solve my problem no. 1 and now the sync works both between the app and the widget, but also between different devices. I had already observed the .NSPersistentStoreRemoteChange notification in my sample project, but it turns out that wasn't even necessary when automaticallyMergesChangesFromParent is set to true on the viewContext. The Problem with Syncing from a Widget Now the problem is the following: Regarding using Core Data + CloudKit (NSPersistentCloudKitContainer) in an extension, I'd like to suggest against doing that ⬆️ Your reply and the linked Technical Note both imply that syncing data with iCloud this way from both the app and its widget is not reliable as two NSPersistentCloudKitContainers pointing to the same persistent store can get in conflict (running on different threads) and throw the following error: CloudKit setup failed because there is another instance of this persistent store actively syncing with CloudKit in this process. In other words: I cannot do that in a production app. From Avoid synchronizing a store with multiple persistent containers: When working with an extension, you don’t control its lifecycle. It is perfectly possible that your extension is launched when your app is running, or vice versa, and both of them try to load the shared store. To avoid the conflict, consider having the app in charge of the synchronization. An extension that has the capability to present UI can remind users to launch the app to synchronize with CloudKit, if that is an appropriate user experience. So now I know what doesn't work. My question is: What does? What's the recommended, safe approach to sync data from an interactive widget with iCloud? Showing a hint to users inside the widget that they should open the main app in order to sync is hardly a practical solution and destroys not only the user experience, but the very purpose of interactive widgets. If I need to open the app each time I've pressed a button on the widget, it's not very interactive after all.

PS: What's curious: When someone downloads my app from the App Store, the synchronization between the app and the widget actually seems to work. I get lots of user feedback and only once has a user reported that the widget is not in sync with the app. However, when I run the app directly from Xcode on my (real) devices, I observe the buggy behavior described above. I could hope that it magically works once I release it on the App Store, but that's too risky and I don't want to do that until I have figured out what the underlying problem is.

@Engineer Thanks for sharing the sample project. It shows several examples how to use CloudKit, however, it doesn't include a Widget Extension or any references to WidgetKit. Is there another project that showcases this concrete use case, updating the same Core Data objects from both a Widget and an app? @Jordan wrote in 2022: Do note they also said NSPersistentCloudKitContainer does not support multi-process sync so only your app should be attempting to sync. And even if a widget were to attempt sync, it’ll never really be able to because iOS doesn’t give it enough time to execute, and widgets don’t run in the background they’re only running when they need to get more timeline entries for example, and widgets don’t get the app’s push notifications which is what enables background syncs to be scheduled. Your app will need to try to keep the widget up to date as opposed to the widget attempting to sync and keep itself up to date. Is this (still) correct (in 2025)? If so, then any attempt to update Core Data entities in a NSPersistentCloudKitContainer from the Widget itself would fail and in such a case, we would always have to find some workaround (like waking up the app from the widget), correct?