The sleep app on my Apple Watch is constantly getting the bedtime wrong. It averages in every nap or if I nod off in my chair, so the resulting moving average is always way off. There should be an ability to edit the bad data entries.

I'm adding live activities to my app and I'm trying to use push notifications to fully remotely start them and end them. The pushToStartTokenUpdates sequence gives start tokens exactly as expected, and triggers even when the app is fully terminated when a new live activity starts. However, the pushTokenUpdates sequence is far less predictable and seems to never trigger when the app is fully terminated. Even when the app is just backgrounded, it's still finicky. I send the "input-push-token": 1 as part of the aps payload too to begin the live activity, but that seems to have little to no effect. Is there any way to ensure that we can receive a push token specifically to update the live activity after it starts? It seems to me that if a live activity can be started via push even when the app is fully terminated, and live activities are meant to reflect active information, then the mechanism to update it via a new token should also be able to work when the app is terminated. Both sequences are subscribed to within the AppDelegate upon initial app launch. This is what my code looks like at the moment: func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { Task { for await newToken in Activity<WidgetAttributes>.pushToStartTokenUpdates { let tokenString = newToken.map{ String(format: "%02x", $0) }.joined() // send to server } } Task { for await activity in Activity<WidgetAttributes>.activityUpdates { Task { for await token in activity.pushTokenUpdates { let tokenString = token.map { String(format: "%02x", $0) }.joined() // send to server } } } } } } Thanks in advance for any insights!

Our application currently supports Live Activities. We’re working on adding a new Widget and are weighing some architectural decisions regarding whether we should add it to the same extension target that our Live Activity lives in or create a new extension that would expose it and other widgets we plan to create in the future. In the Add Support for Live Activities documentation, it suggests adding Live Activity code to the existing widget extension to facilitate code reuse. Beyond code sharing, we’re trying to determine if there are downsides to isolating new Widget(s) into their own extension. Specifically, we are concerned about process isolation and how a failure/crash in one might impact the other. Assuming they did live in the same extension, we’re hoping to better understand some of the finer details as presented by the following questions: If a Widget (e.g., via the TimelineProvider) causes the extension process to crash, what is the guaranteed behavior for a currently running Live Activity? Is the relaunch and restoration of a Live Activity after an extension crash guaranteed, or is it best-effort? Is there a distinction in crash isolation between a TimelineProvider failure and a View rendering crash? Are there any known scenarios where a Widget crash could cause a Live Activity to be permanently dropped? Does keeping them in the same extension affect the memory budget, or does each 'instance' receive its own allocation? In short: we're looking to ensure that an issue with a Widget doesn't inadvertently affect a Live Activity (or vice-versa) when they live in the same WidgetsBundle within the same extension and are seeking guidance on whether it makes sense to keep them together or continue down the path of separate extensions in the interest of process safety. Any pointers to other documentation or known behavior would be greatly appreciated!

Hi, I have a problem with watchOS widget configuration intents. It turns out that watchOS is unable to load text for localization keys. This is how I set configuration parameter in WidgetConfigurationIntent: @Parameter( title: LocalizedStringResource( "watchWidgetConfig.showSymbols", defaultValue: "Symbole", table: "WidgetLocalizable", bundle: widgetBundle ), default: true ) var showSymbols: Bool Unfortunately, on a device always the defaultValue is used. I tried everything and nothing works. What's weird, it correctly works on watchOS simulator and if you configure widgets in iOS "Watch" app. On real Apple Watch, the "defaultValue" is displayed. I'm not sure if it's important but both: the Swift file with WidgetConfigurationIntent and WidgetLocalizable.xcstring are included in two targets: Watch Widget Extension and Watch App. I tried so far: All variants of LocalizableStringResource init. With/without "table", with/without "bundle". Previously I had texts in Localizable.strings, I migrated it to WidgetLocalizable.xcstrings and it didn't work either. Setting only one target for WidgetLocalizable.xcstring and WidgetConfigurationIntent. I checked inside xcarchive to see if WidgetLocalizable.xcstring is copied correctly. Seems like watchOS bug, but I would be happy to know if someone figured out any workaround. Xcode: Version 26.4 (17E192) iOS 26.4.1 watchOS 26.4 I already created a ticket: FB22509406

Hi everyone, I have a question about Live Activity start tokens and update tokens. After reading the documentation, it is still not very clear to me how often these tokens are invalidated, and whether their expiration is time-based or event-based. My current understanding is that the update token is generated when the Live Activity starts, and that it becomes invalid when the activity ends or is dismissed by the user. What I am not clear on is whether the update token can also become invalid at any point while the Live Activity is still active. I have a similar question about the start token. I have noticed that it is generated on the initial app launch, but I have also seen it get regenerated at what seems like random times. I would like to better understand what events or conditions cause a new start token to be issued. Is there any official guidance on the lifecycle of these tokens, specifically: whether they expire based on time, whether they are only invalidated by specific events, and what conditions trigger regeneration of the start token or update token? Any clarification would be appreciated. Thanks.

Hi everyone, I have two questions about Live Activity push notifications that we send from our backend server to iPhones. First, I would like to understand the expected behavior when lowering the APNs priority of a Live Activity update from 10 to 6. How does this affect delivery timing, reliability, or system handling of the notification? Second, my team has been seeing significant delays with some messages sent to the device. In some cases, notifications take anywhere from 1 to 3 hours to arrive on the phone. We are trying to understand what might cause this kind of delay. Is this expected under certain conditions, such as device state, system throttling, network conditions, or APNs behavior? Also, is there any way to inspect logs or delivery details for messages sent to the app so we can better diagnose where the delay is happening? Any guidance would be appreciated. Thanks.

I have a live activity and even after a couple of times that it has shown on my lock screen it keeps prompting the user to tap on Don't Allow or Allow. Can someone help me understand why this is happening? I would like my users to only hit Allow once and not be prompted again, otherwise they would not be registered for updates, since update token only generates after selecting Allow.

It has been five days since we applied for Family Controls (Distribution) permission, but the status still shows as Submitted. Is there any way to expedite the review process?

Hi, I am looking for help. I submitted my request for Family Conotrols Distribution using the form. I have been waiting for days and didn't get any reply or confirmation email. Thanks.

Our app runs offline-first focus sessions using FamilyControls / ManagedSettings shielding and DeviceActivity monitoring. The in-app session timer is protected against wall-clock manipulation by using monotonic elapsed time, and the shield remains active correctly when the user manually changes the iPhone clock. However, the Live Activity and Dynamic Island countdown appear to use the device's wall clock for their timer rendering. If the user changes the device time from Settings during an active session, the Live Activity / Dynamic Island countdown immediately jumps forward or backwards, even though the underlying session has not changed. Is there a recommended ActivityKit approach for rendering a Live Activity / Dynamic Island countdown that is resistant to manual device clock changes? If not, is this an expected limitation of Live Activity timer rendering? And is there any supported way for the host app or widget extension to detect wall-clock manipulation so the Live Activity can be corrected, dismissed, or replaced with a safer non-countdown state?

I have been experiencing many issues trying to integrate the Apple AlarmKit in my app. I essentially keeping getting authorization errors. I was wondering if anyone else was experiencing issues like this and if anyone had guidance or a fix for what I am experiencing. I was under the impression that any devices IOS26+ could use the AlarmKit but maybe I am mistaken. Getting (com.apple.AlarmKit.Alarm error 1.) every time I try and enable alarms.

Heyy, I'm building a music tracking app that logs a user's Apple Music plays to build a personal weekly chart. The core mechanic depends on accurately counting how many times a user plays each track. My current implementation uses MPMusicPlayerController.systemMusicPlayer with beginGeneratingPlaybackNotifications() and observes MPMusicPlayerControllerNowPlayingItemDidChange. This works well when the app is in the foreground or recently backgrounded, but notifications stop firing once iOS suspends the app. To get around this I've implemented: applicationDidBecomeActive - restarts the monitor and logs the currently playing track on every foreground Background fetch (performFetchWithCompletionHandler) - periodically wakes the app to log what's playing. This gives some coverage but misses plays that happen between background fetch intervals or when the user hasn't opened the app in a while. The result is an inaccurate play count which undermines the core feature. My questions: Is there a supported entitlement or capability that would allow an app to receive MPMusicPlayerController playback notifications while suspended? Is MusicKit or MediaPlayer the recommended framework for this use case, or is there a better API I'm not aware of? Are there any supported background modes that would keep playback notification delivery alive without requiring the app to be a full audio player? I've looked at MusicRecentlyPlayedRequest but it only returns the last 25 items with no play counts, so it can't tell me a track was played 10 times vs once. Any guidance on the right approach here would be really appreciated.

Hi, We are the developers of Morning Call (https://morningcall.info), and we believe we may have identified an AlarmKit / system UI bug on iPhone. We can reproduce the same behavior not only in our app, but also in Apple’s official AlarmKit sample app, which strongly suggests this is a framework or system-level issue rather than an app-specific bug. Demonstration Video of producing zombie Live Activity https://www.youtube.com/watch?v=cZdF3oc8dVI Related Thread https://developer.apple.com/forums/thread/812006 https://developer.apple.com/forums/thread/817305 https://developer.apple.com/forums/thread/807335 Environment iPhone with Dynamic Island Alarm created using AlarmKit Device is unlocked when the alarm begins alerting Steps to reproduce Schedule an AlarmKit alarm. Wait for the alarm to alert while the device is unlocked. The alarm appears in Dynamic Island. Instead of tapping the intended stop or dismiss button, swipe the Dynamic Island presentation away. Expected result The alarm should be fully dismissed. The Live Activity should be removed. No empty UI should remain in Dynamic Island. Actual result The assigned AppIntent runs successfully. Our app code executes as expected. AlarmKit appears to stop the alarm correctly. However, an empty “zombie” Live Activity remains in Dynamic Island indefinitely. The user cannot clear it through normal interaction. Why this is a serious user-facing issue This is not just a cosmetic issue for us. From the user’s perspective, it looks like a Live Activity is permanently stuck in Dynamic Island. More importantly: Force-quitting the app does not remove it Deleting the app does not remove it In practice, many users conclude that our app has left a broken Live Activity running forever We receive repeated user complaints saying that the Live Activity “won’t go away” Because the remaining UI appears to be system-owned, users often do not realize that the only reliable recovery is to restart the phone. Most users do not discover that workaround on their own, so they instead assume the app is severely broken. Cases where the zombie state disappears Rebooting the phone Waiting for the next AlarmKit alert, then pressing the proper stop button on that alert Additional observations Inside our LiveActivityIntent, calling AlarmManager.shared.stop(id:) reports that the alarm has already been stopped by the system. We also tried inspecting Activity<AlarmAttributes<...>>.activities and calling end(..., dismissalPolicy: .immediate), but in this state no matching activity is exposed to the app. This suggests that the alarm itself has already been stopped, but the system-owned Live Activity UI is not being cleaned up correctly after the swipe-dismiss path. Why this does not appear to be an app logic issue The intent is invoked successfully. The alarm stop path is reached. The alarm is already considered stopped by the system. The remaining UI appears to be system-owned. The stuck UI persists even after our own cleanup logic has run. The stuck UI also survives app force-quit and app deletion.

Hello everyone, my app A now supports iOS Widget C under the same Xcode project. Now I have another app B under this project, and I hope it can also support this Widget C. What should be done? How should the app group be configured? I have found some solutions: for example, add this key under the info.plist corresponding to app B: NSExtension NSExtensionPointIdentifier com.apple.widgetkit-extension NSExtensionPrincipalClass $(PRODUCT_MODULE_NAME).WidgetEntryView However, when I configured it and started running, not only could I not see the support Widget C, but the screen also went black. Thank you all.

Context I'm building a study-timer feature for an iOS app (Flutter + native ActivityKit) that displays a Live Activity on the Lock Screen / Dynamic Island while a session is running. When the user force-quits the app by swiping it up from the App Switcher, I want the Live Activity to disappear as quickly as possible. I have already confirmed (from on-device testing and Apple Developer Forums thread 732418) that: applicationWillTerminate is not called on swipe-up force-kill, only on OS-initiated termination or crash. So synchronous Activity.end(...) from the app itself is not a solution for the force-kill path. Shortening staleDate does not visually dismiss the Live Activity once the app process is gone — the Widget Extension keeps rendering the last fresh snapshot and there is no body-reevaluation trigger on the stale transition post-app-death. (I implemented and verified this, then rolled it back.) The only Apple-official reliable mechanism is APNs push-to-end (Activity.request(pushType: .token) + server sends event: end via APNs). Current architecture I have APNs push-to-end working end-to-end. Structure: Client: Activity.request(pushType: .token), subscribe to Activity.pushTokenUpdates, forward each new token to the backend. Backend: On every client heartbeat, upsert (user_id, la_apns_token, la_activity_id, last_heartbeat) into Postgres. A separate scheduler polls for rows whose last_heartbeat < now() - grace_ttl and sends APNs event: end to the stored token. Parameters I am currently running with: Parameter Value Client heartbeat interval 60 s Orphan grace TTL (server) 135 s (heartbeat × 2.25, to absorb network jitter) Scheduler poll interval 30 s The observation End-to-end latency from "user force-kills the app" to "Live Activity disappears from Lock Screen" is: Worst case: 60 + 135 + 30 = ~225 s (~3.75 min) Typical: ~3 min (as consistently measured on iOS 26.4.1, iPhone 17 Pro Max) Theoretical minimum (if the kill happens exactly at a heartbeat boundary): ~135 s Users perceive 3 minutes as broken — the timer clearly stopped (no ticking), but the Live Activity "ghost" is still visible on the Lock Screen. My question Is there any Apple-supported mechanism to reliably tear down a Live Activity faster than ~2 minutes after the owning app's process is gone, given that applicationWillTerminate does not fire on swipe-kill? Specifically: Is there any practical lower bound below ~60 s for this scenario using the current ActivityKit + APNs model, assuming we are not willing to spam heartbeats every few seconds? I can push heartbeat to 20–30 s, but the server cost grows linearly with active sessions. Does BGAppRefreshTask / BGProcessingTask have any documented lifecycle hook that fires on user-initiated swipe-kill specifically, so that I could do a "last-heartbeat flush" just before the process dies? My understanding is that background tasks are scheduled for later and do not fire synchronously at termination. Is there any signal from APNs/ActivityKit to my server (e.g. a feedback-service-like mechanism) that indicates "this Live Activity's owning app was force-killed", which would let the server short-circuit the heartbeat-based orphan detection? Are there any new APIs in iOS 18.x or the upcoming release that address this specific force-kill → LA-dismissal latency? I could not find anything in the 18.x release notes, but I may have missed it. What I am NOT asking I am not asking how to implement APNs push-to-end (that works). I am not asking about applicationWillTerminate (I already confirmed it does not fire on swipe-kill). I am not asking about shortening staleDate as a visual workaround (I already verified it does not trigger body reevaluation post-kill). Environment iOS 26.4.1 (also reproducible on 18.x devices I have on hand) iPhone 17 Pro Max, iPhone 15 Pro, iPad Air 11-inch (M3) Xcode 26.x Activity.request(pushType: .token) with ActivityContent + custom stalenessInterval = 120s APNs HTTP/2 via token auth (.p8), targeting api.push.apple.com in production apns-push-type: liveactivity, apns-priority: 10, payload includes event: end What I have tried (for the record, to avoid "did you try" responses) applicationWillTerminate with DispatchSemaphore 3.5 s sync wait + dismissalPolicy: .immediate — works only for OS-terminate, not swipe-kill. stalenessInterval = 30s + 15 s refresh cadence + override to 5 s on AppLifecycleState.paused — verified not to dismiss the LA after app death. Cold-start reconciliation via Activity<...>.activities on next app launch — works, but that only helps if the user relaunches. Current APNs push-to-end with 60 s / 135 s / 30 s configuration — works, but latency is the complaint. Any guidance, even "no, ~2 minutes is the floor by design" with a pointer to the relevant doc, would be very helpful. Thank you.

Description When starting Live Activities via ActivityKit push notifications, the “start” notification is received correctly on iPhone 16 Pro Max, but subsequent update or end push notifications are not. The same implementation on iPhone 16 Pro behaves as expected (both start and update/end notifications are delivered and processed). Environment Property Value Device (failing) iPhone 16 Pro Max Device (working) iPhone 16 Pro iOS Version 18.5 Xcode / SDK 16.2/ActivityKit / Push Notifications Network Wi-Fi / Cellular (both tested) Data Collection Method Devices connected via USB. Logs captured using Console.app. Log filtering applied for the liveactivitiesd daemon to isolate Live Activity behavior. Initial Triage/Observations Payload format confirmed compatible; no incompatible fields. APNs token remains the same across messages (no refresh). Identical ActivityKit subscriptions/participants on both devices. Server-side delivery is confirmed: iPhone 16 Pro receives all messages (start, update, end). Only iPhone 16 Pro Max fails to receive update or end push notifications. Log Analysis iPhone 16 Pro (Working) Push-to-Start successfully received: 13:45:20 - APSXPCDeliverMessageEvent: Created APSIncomingMessage 13:45:20 - Received message: eventType: start(SessionPushNotifications.IncomingMessage.EventType.StartParameters(attributesType: "AchToLSUpgradeAttributes", attributesData: 125 bytes, inputs: [])) 13:45:20 - Created activity: 1C081AC5-01AE-4EC0-8B67-5F2A9FAE2D60 13:45:45 - APSXPCDeliverMessageEvent: Created APSIncomingMessage 13:45:45 - Received message: eventType: end(dismissDate: Optional(2025-07-21 21:00:44 +0000)) 13:45:20 - Activity updated: 1C081AC5-01AE-4EC0-8B67-5F2A9FAE2D60 13:45:20 - Local activity did update: 1C081AC5-01AE-4EC0-8B67-5F2A9FAE2D60 iPhone 16 Pro Max (Failing) 13:56:39 - APSXPCDeliverMessageEvent: Created APSIncomingMessage 13:56:39 - Received message: eventType: start(SessionPushNotifications.IncomingMessage.EventType.StartParameters(attributesType: "AchToLSUpgradeAttributes", attributesData: 125 bytes, inputs: [])) 13:56:39 - Created activity: E6BBF691-0C7A-4791-98D2-6F1440D9932E **No subsequent APNs push-to-update or push-to-end messages received.** 13:56:39 - No destinations for event E6BBF691... of type start 13:56:40 - No destinations for event E6BBF691... of type update Questions for Apple Engineering Are there known issues with ActivityKit push notifications specifically on iPhone 16 Pro Max devices? What additional diagnostic logs (system, APNs, liveactivitiesd) would be most helpful to collect? Could device-specific power management, notification settings, or OS-level changes on Pro Max models affect Live Activity updates? Are there differences in how Live Activity push subscriptions or routing are handled on iPhone 16 Pro Max vs Pro that could lead to this issue?

Hi I developed a music app that plays offline audio and displays lyrics using Live Activities. According to ActivityKit documentation, Live Activities can be updated from the background. However, in my case, updates stop after ~30 seconds when the app goes to the background or the device is locked. Important points: The app continues running in the background (audio playback works fine using AVAudioSession with .playback) Background code execution is working as expected Only the Live Activity stops updating I am not using push updates since this is an offline app. Is there any limitation or requirement for updating Live Activities continuously in the background during audio playback? Audio Session Configuration let session = AVAudioSession.sharedInstance() try session.setCategory( .playback, mode: .default, options: [.mixWithOthers] // ✅ DO NOT interrupt other audio ) try session.setActive(true) print("✅ [AudioSession] Activated with mixWithOthers") } catch { print("❌ [AudioSession] Error: \(error)") } Live Activity Update Methods guard let activity = getLiveActivity(for: recordID) else{ print("⚠️ No Live Activity found for recordID: \(recordID)") return } guard activity.activityState == .active else { print("⚠️ Activity is not active") return } Task { let content = ActivityContent( state: state, staleDate: Date().addingTimeInterval(60 * 60 * 12), relevanceScore: 1.0 ) await activity.update(content) print("✅ Live Activity updated with ActivityContent") } }

Hi, I need your opinion about an issue we faced while trying to implement an iOS widget in our Flutter app. Here is what we did and the problems we encountered: We created a Widget Extension (SwiftUI + WidgetKit) inside the existing Flutter iOS project. The widget files were generated correctly (Widget.swift, WidgetBundle.swift, Info.plist, etc.). However, during the integration, we faced multiple issues: Build Cycle Error We repeatedly got: “Cycle inside Runner; building could produce unreliable results” This was related to embedding the widget extension into the Runner target. Embed Problems Sometimes Xcode did not automatically create the “Embed App Extensions” phase. When we added it manually → build cycle errors appeared. When we removed it → the widget was not embedded at all (no PlugIns folder in Runner.app). Duplicate / Conflicting Embed The extension appeared both in: “Embed Foundation Extensions” “Frameworks, Libraries, and Embedded Content” Removing one often broke the build or removed the other as well. Widget Not Appearing Even when build succeeded: Widget did not appear on device PlugIns/Widget.appex was missing from build output Flutter Linking Errors In another test project, we got: Undefined symbol: _FlutterMethodChannel Undefined symbol: _FlutterBasicMessageChannel etc. This happened because the widget extension tried to link Flutter dependencies, which should not happen. App Group Confusion We also tried adding App Group (group.com.xxx), but behavior didn’t change. Conclusion: We suspect the root issue is: The Flutter template we are using was not designed for WidgetKit integration Xcode embedding phases and Flutter build scripts conflict with extension targets Question: In your opinion: Is this a known limitation with Flutter-based iOS projects? Is there a clean way to integrate WidgetKit without breaking the Runner target? Or is it better to create a separate native iOS module for the widget? Any guidance would be really appreciated. Thanks!

Environment: Xcode 26.4 (17E192) iOS 26.4.1 iPhone 15 Pro Project uses PBXFileSystemSynchronizedRootGroup (Xcode 26 format) Setup: Widget Extension target named ModusWidgetExtension Bundle ID: com.calvin.Modus.ModusWidget NSSupportsLiveActivities = YES in both main app and widget extension Info.plist Live Activities enabled in Settings → Modus Live Activities enabled in Settings → Face ID & Passcode → Allow Access When Locked Background App Refresh enabled Push Notifications capability on both targets ActivityAttributes struct added to both targets via file target membership Behaviour: ActivityAuthorizationInfo().areActivitiesEnabled returns true Activity.request() succeeds and returns a valid activity ID No error is thrown Nothing appears on lock screen or Dynamic Island in foreground or background Widget preview in Xcode renders correctly for all presentations (compact, minimal, expanded, lock screen) Console output from liveactivitiesd filtered logs: "Foreground process is permitted to update activity" "XPCInputParticipant has no activity for update" (ERROR — repeated) "Received state update for [app<com.calvin.Modus>], running-active-NotVisible" The activity is being created and the system is receiving state updates, but the widget extension is not rendering it. The XPCInputParticipant error suggests the widget extension process cannot find the activity created by the main app.

Hi Apple Team, We are facing an issue with Live Activities where the UI intermittently fails to render and shows a loader or blank state. After extensive debugging, we’ve identified that the failure happens during the rendering phase inside the system process (WidgetKit / liveactivitiesd), but there are no actionable signals exposed to the app. Problem: Live Activity launches successfully After a few updates or under certain UI conditions, it: stops rendering shows a loader / blank UI sometimes disappears No crash logs are generated No MetricKit diagnostics available for the extension Console logs show: Invalid frame dimension (negative or non-finite) Archive was nil. LiveActivity will be empty Sometimes because of memory pressure too The extension process appears to terminate silently Challenge Currently, there is no way to detect from the app side that: the Live Activity has failed to render the extension process has crashed/terminated the UI is no longer being updated Questions Is there any callback, delegate, or lifecycle hook that notifies when: a Live Activity rendering fails the extension process crashes or is terminated by the system? Is there any recommended way to detect a “broken” Live Activity state (e.g., stuck loader / non-updating UI)? Are there any diagnostic APIs or logs we can rely on in production to identify such failures? Is this considered expected behavior under certain system constraints (e.g., memory/rendering limits), and if so, are there guidelines to proactively detect or mitigate it? Goal We want to: proactively detect Live Activity failure log it for monitoring optionally fallback or recover gracefully Additional context: We fixed all the issues and the live activity is pretty stable. But asking for methods to track & fix such cases.