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

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?

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.

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.

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.

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?

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.

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.

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.

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.

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!

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!

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.