@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?

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.

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.

Thank you for the explanation! Xcode did add the localized string key %@ timer started. to my string catalog as you correctly assumed, and I have provided a proper translation: %@ Timer gestartet. However, I still don't understand why Siri does not translate the %@ part properly. When it's "10 seconds" in English, it also reads "10 seconds" when Siri is set to German with the number "10" being correctly translated ("zehn" instead of "ten") but not the unit ("seconds" where it should read "Sekunden"). Summary & Overview: Localized String Key: %@ timer started. English output: Displayed text: "10 seconds timer started." Spoken by Siri: "Ten seconds timer started." 🇺🇸🇺🇸🇺🇸🇺🇸 German output: Displayed text: "10 seconds Timer gestartet." Spoken by Siri: "Zehn seconds Timer gestartet." 🇩🇪🇺🇸🇩🇪🇩🇪 where "zehn" is German, but "seconds" is English. This seems to be a bug? I will wrap this as a minimal example in an Xcode project to file a Feedback report and share the ID here once I've done that, as you suggested. Thanks! Mischa

I have now filed a Feedback report. The ID is: FB21836555

Does this happen every time when the alarm fires or only every once in a while? I have the same issue, but it only happens very rarely (like once a month when using the app on a daily basis) and I cannot reproduce it. Could you post the code where you schedule the alarm and the LiveActivity code? It might be an issue with AlarmKit, but if it's not, the error must be in that code.

My guess is that your Live Activity crashes because it relies on data that is only accessible when the device is unlocked. In case you haven't resolved the issue yet, I would start looking where you read data or perform an operation that is not available when the device is locked.

@LucaTuna Could you elaborate on where you added exception handling? When scheduling and canceling the alarms? I have the same issue, but I cannot reproduce it. It appears to be happening randomly every once in a while. What do you mean by "if I dismiss the Live Activity by tapping somewhere other than the X button"? Normally, when you tap on the live activity and it's not a button, it just opens your app, but does not cancel the live activity – unless your app has a logic that cancels the live activity when it comes into foreground.

@dasun_tharanga I consider it very unlikely that AlarmKit would always show a blank Live Activity when the alarm fires. Other apps (including mine) prove otherwise. So in your case, it must have something to do with the way you set the alarm up in your code.

Thank you for sharing your analysis and this well-structured post! I can confirm these findings and apparently, this is what's causing the blank live activity I described in my post as well. Judging from your observations, I agree with the assessment that this seems to be an issue inside the framework. This information should help the engineers at Apple to identify and fix it.