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.

We are using Live Activities in our iOS app to show real-time flight information on the Lock Screen and Dynamic Island. Our implementation currently works as follows: The Live Activity is created using the push-to-start token. After the Live Activity is started, our backend receives and uses the Live Activity update token to send updates to the Live Activity through APNs. The Live Activity content is updated through push notifications from our backend. These updates include flight status changes such as check-in status, boarding status, gate changes, delay updates, arrival status, and other journey-related states. We are observing an issue where some Live Activity state updates are not reflected on the device. From our backend logs, the APNs request is successfully sent, but in some cases the update does not appear to be received by the device, and the Live Activity remains in an older state. We understand from Apple documentation and platform behavior that Live Activity push updates may be subject to system-level throttling or delivery limitations. We would like to confirm the expected behavior and understand the recommended approach. Could you please help clarify the following? Are Live Activity update pushes subject to throttling by iOS/APNs even when the backend sends the update successfully? If APNs accepts the request successfully, is there still a possibility that the update may not be delivered to the device or may not update the Live Activity because of system-level throttling, device state, power conditions, network conditions, or Live Activity limits?

For some reason since iOS 26.5, a ControlWidgetButton or a Button in a widget configured with an AppIntent conforming to OpenIntent fails to receive its AppEnum parameter correctly if the intent and enum are defined inside a shared Swift Package. Tapping the control widget button opens the main application, but it doesn't pass the AppEnum parameter value in, leaving the app on its default screen instead of navigating to the intended view. This was working perfectly in iOS 26.4, where the app would launch and receive the correct enum case from the intent. No code, configuration, or scheme changes were made between the two runs, only the simulator/OS version differs. Has anyone else run into what seems to be a regression on iOS 26.5? I filed feedback with a sample project: FB22848510

Environment App: Web app (Sign in with Apple JS / redirect flow) Hosted over HTTPS (valid TLS cert via AWS ALB) Tested on latest Chrome, Safari, and Firefox Reproducible in normal + incognito/private windows Expected behavior When clicking "Sign in with Apple", the popup should render the Apple login form and then redirect to our configured callback endpoint Actual behavior Apple Sign-In popup opens successfully Page loads only the Apple header shell: • Apple logo • "Apple Account" • Collapsed "Sign in" section The actual login form (email/password entry) never renders No visible error shown to the user No requests ever reach our backend callback endpoint Configuration status Services ID created and enabled for Sign in with Apple Domain verified and added to Services ID: Return URL configured exactly: Primary App ID has Sign in with Apple capability enabled Key created and associated with the App ID CSP allows What we have already tried Re-saving Services ID configuration multiple times Regenerating Key and re-binding to App ID Verifying client_id matches Services ID identifier exactly Waiting >24 hours for propagation Testing across multiple browsers and devices Key observation The flow appears to stop before authentication UI renders fully, and no redirect/callback is ever triggered, suggesting the issue occurs within Apple’s authorization session before completion. Question Is there any known requirement or verification step for Services IDs using a domain-style identifier, or any additional Apple-side configuration/activation step that could prevent the login form from rendering even though the initial authorize page loads?

I’m running into an issue with Live Activities and was wondering if anyone else has seen something similar. Some users occasionally see a spinning/loading indicator instead of the normal Live Activity UI. The push payloads look valid and consistent across users, nothing appears to be missing or malformed. Has anyone encountered this before or knows what could cause the Live Activity to fall back into a loading state?

Platform: iOS 26.5 · PassKit (semantic boarding pass) Summary When a .pkpass boarding pass uses the iOS 26 upgraded semantic format (preferredStyleSchemes: ["semanticBoardingPass", "boardingPass"]) for a real, scheduled flight that Apple's live flight data feed recognizes, the Wallet Live Activity (Lock Screen, Dynamic Island, and Wallet card "Welcome to …" copy) renders the destination city name in English, regardless of the value supplied in semantics.destinationCityName or the device's locale. On a German-locale iPhone, a flight arriving at MUC produces the grammatically broken string "Willkommen bei Munich" — German system-supplied prefix concatenated with the English city noun from Apple's flight data, instead of the expected "Willkommen in München". Steps to reproduce Build a .pkpass for any real, currently-scheduled flight whose destination city has a German-language variant (e.g. SK2657 CPH→MUC, 4Y1261 HER→MUC). Populate semantics with full iOS 26 fields including: "destinationAirportCode": "MUC", "destinationAirportName": "München", "destinationCityName": "München", "destinationLocationDescription": "Flughafen München Franz Josef Strauß" Install on an iPhone running iOS 26.1+ with Language: Deutsch, Region: Deutschland. Open the pass within Wallet's live-activity window. Expected: "Willkommen in München" Actual: "Willkommen bei Munich" What I believe is happening Apple's live flight data feed overrides the destinationCityName semantic tag with an English-only value sourced from the feed (presumably IATA / OAG). The iOS 26.1 liveDataConfiguration.excludedSemantics allow-list does not include destinationCityName or destinationAirportName, so there is currently no developer-side mechanism to either: submit a localized destination city, or opt out of the override while keeping live updates active. The PassKit destinationCityName schema is typed as a plain localizable string (single value), with no translations variant comparable to what some third-party pass APIs expose. The "localizable" annotation in the docs is misleading for this field, because pass.strings lookups are not applied to semantic values once the live flight feed supplies them. What I'd like to know Is this the intended behavior, or is destinationCityName missing from the documented excludedSemantics allow-list by omission rather than design? Is there a supported way for an airline (or a developer issuing passes on an airline's behalf) to ship localized destination city names that survive the live-data merge? If neither (1) nor (2): is there an intent to either localize Apple's flight-data city tokens by device locale, or expand excludedSemantics to cover destination/departure city + airport names in a future iOS 26.x release?