What we're doing During time-limited sales, our app shows a countdown Live Activity on the Lock Screen. It's started locally when the user opens the app (no push, no pushType, no push tokens), and its end is scheduled for the sale's start/end time: let activity = try Activity<SaleAttributes>.request(attributes: attributes, contentState: .init()) await activity.end(using: .init(), dismissalPolicy: .after(saleEndDate))The sale time is the same for every user, so the Live Activity ends at the same second on every device. What we expected At saleEndDate, the system removes the Live Activity from the Lock Screen, and nothing else happens. What actually happens If the app isn't running at that moment (the user left it earlier and didn't swipe it away), the system removes the Live Activity and then launches our app in the background: 01:18:59.995 SpringBoard [BundleID: com.example.app] finished, removing from the list... 01:19:00.019 liveactivitiesd Sending request to open "com.example.app" 01:19:00.023 SpringBoard Received trusted open application request … from <… com.apple.liveactivitiesd …> 01:19:00.069 SpringBoard Bootstrapping app<com.example.app> with intent backgroundThe app receives a normal application(_:didFinishLaunchingWithOptions:) with applicationState == .background and empty launchOptions. No other app delegate callback follows. Our app can't tell this apart from any other launch, so it runs its full startup: it builds the home screen and calls our backend APIs. Because this happens on a large number of devices in the same second, our backend gets a sharp burst of traffic exactly at sale start and sale end, from users who never opened the app. What we've checked App still running in the background at the end time: no new launch. App swiped away by the user before the end time: no launch. Live Activity removed by the user before the end time: no launch at the end time. Steps to reproduce Open the app; it starts a Live Activity with its end scheduled 15 minutes ahead. Leave the app with the Home gesture (don't swipe it away) and lock the device. Wait until the system terminates the app process. At the scheduled end time, the Live Activity is removed and the app is launched in the background (log above). Environment iPhone 15, iOS 26.6 (23G71) UIKit app, UIApplicationDelegate lifecycle (no scenes) NSSupportsLiveActivities = YES; UIBackgroundModes = [processing, remote-notification] Questions Why does the system launch the app when a Live Activity reaches its scheduled end? Is this intended? Can we avoid it? Is there a supported way to end a Live Activity at a scheduled time without the system launching the app? If not, how should we handle it? Is there a way to know at launch that it was caused by the Live Activity ending, or what's the recommended way to avoid running the full startup (UI and network calls) for this launch?

We develop an iPhone app that performs user-started Bluetooth discovery for 1–5 minutes, with visible progress, cancellation and a Live Activity. We need to discover arbitrary BLE advertisers, including nonconnectable devices, and receive repeated RSSI samples during that bounded scan. The app declares bluetooth-central, creates its central manager before starting the Live Activity in the foreground, and scans with nil service filters and duplicates enabled. Discovery continues behind another app while the display is on, but saved observation timestamps stop advancing after the phone is locked with its display off. We understand the restriction described in https://developer.apple.com/forums/thread/815189. Is there an iPhone managed entitlement or supported program that permits this use case? If so, what are the eligibility criteria and application route? We also found com.apple.developer.bluetooth-central-screen-off-scanning mentioned in https://developer.apple.com/forums/thread/835684. That discussion concerns watchOS medical use; we are asking whether any corresponding iPhone capability exists. If no route exists, should we submit an enhancement request through Feedback Assistant?

Live Activities: API gaps for ProgressView, Text(timerInterval:), and compact/minimal icons Thanks for organizing a session on Live Activities — looking forward to it. We're shipping a Live Activity for train departures (a countdown to departure, plus a custom indicator for the platform the train leaves from), and we've run into a handful of limitations where the public API doesn't seem to expose behavior that first-party experiences appear to have. We'd love either guidance on how to achieve these today, or confirmation that they're on the roadmap. Grouping them by API below. ProgressView 1. Height isn't adjustable. (FB23091027) A linear ProgressView renders at a fixed height. The only lever we've found is scaleEffect, but scaling the whole view also scales the corner radius, so the rounded caps end up distorted (stretched ovals instead of clean pills). We'd like a supported way to set the bar's height — or at least a fixed-radius style that survives scaling. 2. Only the fill is stylable, not the track. (FB23091058) .tint(...) and progress view styles let us color the progress portion, but we can't find a way to style the background/remaining track (color, opacity, etc.). First-party progress bars clearly have a styled track, so we assume there's a path we're missing. 3. No separator/border between filled and remaining. (FB23091078) We'd like a visible border or divider at the boundary between the active (filled) and remaining segments. There's currently no hook for this without abandoning ProgressView entirely and hand-rolling the bar. 4. ProgressView(value:) carries extra vertical padding that ProgressView(timerInterval:) doesn't. (FB23091242) The value-based initializer renders with an additional ~3 pt of top/bottom padding that the timerInterval: initializer doesn't apply. When the two are placed together — or swapped for one another — their bars don't line up vertically, since one has extra vertical inset and the other doesn't. We'd like the vertical insets to be consistent across the two initializers (or a supported way to control them) so progress bars can be aligned reliably. Collectively, points 1–4 push us toward reimplementing the progress bar with Canvas/Shape, which feels like it shouldn't be necessary for something the system already draws. Text(timerInterval:) 5. No minute-granularity ("3 min.") countdown. (FB23091094) We want a self-updating timer that ticks down in whole minutes — "3 min." → "2 min." → "1 min." — rather than MM:SS. Apple already does this: in the Dynamic Island compact trailing region, the system Timer renders a coarse, minute-granularity countdown that updates itself (it shows e.g. "3 m"). We'd love exactly that, but with a localizable, slightly longer unit such as "3 min.". Today Text(timerInterval:countsDown:) only gives us the full digit-ticking format, and we can't find a supported way to drive a minute-granularity self-updating timer. 6. It always reserves full horizontal width. (FB23091111) A Text(timerInterval:) claims the maximum horizontal space its widest value would need (presumably to avoid layout jitter as digits change). Concretely: placing a Text(timerInterval:countsDown:) in compactTrailing stretches the Live Activity to fill that direction. Apple's own Timer doesn't do this — its countdown in the same compact trailing region hugs its content. We'd like a supported way to opt into that content-hugging layout, accepting the jitter trade-off ourselves. Compact Dynamic Island 7. Animating between two icons while the timer stays visible. (FB23091159) In the compact presentation we want to transition between two graphics on a state change — in our case, cross-fading between a vehicle/line glyph and our custom platform indicator (showing which platform the train departs from) in the compact leading slot, while the departure countdown stays visible in the trailing slot. Today the swap hard-cuts. First-party activities show smooth content transitions in these regions, so we assume there's a supported approach we're missing. Guidance on supported transitions for the compact slots would be very welcome. If any of these are already achievable, we'd genuinely appreciate pointers — we may simply be holding the API wrong. And if they aren't, consider this a consolidated feature request. We've filed each as an individual Feedback item (FB numbers inline above) and are happy to attach sample projects and screen recordings.

We are experiencing a Dynamic Island rendering issue on a physical iPhone Duo. When the Dynamic Island content updates, the view visibly jitters during rendering. We expect the content to update smoothly without unintended movement or layout shifts. The issue persists even when we use @Environment(.isDynamicIslandLimitedInWidth) to adapt the layout for a width-constrained Dynamic Island. It also occurs with a minimal layout containing only a basic view. Environment iPhone Duo iOS 27.1 Xcode 27.1 Is this a known issue with Dynamic Island on iPhone Duo? Is there a recommended workaround to prevent the content from jittering during updates? Thank you for your help

Is there a recommended way to include a resource bundle (images, json config) inside a Swift Package so it works correctly when the package is used as a local dependency vs a remote one? Running into path resolution differences between the two.

When using AlarmKit (AlarmPresentation.Alert), the native system buttons (Stop / Open) successfully trigger the assigned AppIntent (e.g., implementing AppIntent with perform()) when running on the iOS Simulator. However, on physical devices (Real iOS Devices), these native buttons are completely dead. Even with a paid Apple Developer Program account, Production/Release-level code signing, and a clean build, tapping the native buttons on the Lock Screen / Full Screen alert results in zero calls to perform() (no logs, intent handler is never invoked). OS Version: iOS 27.0 Xcode Version: Xcode 27.1 (27A9275) Device: iPhone Air Provisioning: Paid Apple Developer Account (Production / TestFlight build) Is this a known system-level bug in AlarmKit where SpringBoard fails to route intent events to third-party apps on real devices? If so, is there any workaround to capture the action of the native Stop/Open buttons, or are developers expected to rely solely on custom Live Activities (.widgetURL) for navigation? Any guidance would be greatly appreciated!

We're building an app for colleges and employers in India. On a person's own iPhone, with their explicit consent, it would use Family Controls and ManagedSettings during class or work hours to block apps except those on an organisation's approved list. The person approves it on their device and can withdraw at any time. The organisation sees only whether the block is active, not which apps are used. Section 3.3.3 of the licence says the framework may not be used in organizational settings or to manage another adult's device. Is our use permitted? If not, is there an approved way to do this without supervising the device? We'd also like to confirm whether Network Extension or URL Filter is allowed for this use.

Developer account; where do I got for support. I am trying to launch an called wealthontracker that was submitted for feedback. I havent had feedback so Im thinking its good to launch but in developer connect it said add your bank details in which I have done the IBAN. its being haning like that for more than 24 hrs maybe 4 to 5 days. PLEASE GET IT DONE

On iOS 27.2, triggering RunSystemShortcutIntent from a Home Screen widget leaves all buttons in that widget unresponsive when the action does not navigate away from the current screen. Toggling the flashlight is a simple example. Steps to reproduce Add an interactive Home Screen widget with a button that uses RunSystemShortcutIntent. Trigger an action that stays on the current screen, such as toggling the flashlight. Try tapping the same button and other buttons in the affected widget. None respond. Swipe to another Home Screen page, then swipe back. The buttons respond again. Expected behavior Once the action finishes, the widget should remain responsive to subsequent taps without requiring the user to navigate away and return. Impact Based on my observations, this issue affects all apps that provide interactive widgets when the reproduction conditions above are met. A single routine system shortcut action leaves every button in the affected widget unresponsive, making important features effectively unavailable. For products built around interactive widgets, this blocks core functionality until the user switches Home Screen pages and returns. I have submitted this through Feedback Assistant: FB25377135. Given the impact on all apps that provide interactive widgets under these conditions, please prioritize investigation and a fix. Has anyone else reproduced this behavior on iOS 27.2? A consistent distinguishing symptom is that simply swiping to another Home Screen page and back restores responsiveness to all buttons in the affected widget.

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.

Hi. It is not as much as widgets itself but it goes along with live activities for sure I believe. Question 1: Hybrid Intelligence & Proactive Context How can developers leverage the Intelligence Platform (specifically intelligenceplatformd) to ensure 3rd-party apps provide the same deep proactive context as first-party services like Spotlight, but strictly through on-device processing to maintain total user privacy? Question 2: Autonomous Diagnostics & Private Reporting Is there a roadmap for Feedback Assistant to autonomously aggregate complex system-level interactions—using spindump or system_profiler—to generate "ready-to-implement" solutions for users, while ensuring these diagnostic insights remain local and are never transmitted to Apple or Google without explicit, granular consent? Question 3: Deep Indexing for Hybrid Data Sources With the shift toward ecosystem-wide intelligence, are there upcoming APIs that will allow Siri or App Intents to more deeply index "hybrid" private data sources—such as external databases or complex Markdown structures in Obsidian—without compromising the local-first security model?

Environment: iPhone 12 Pro Max, iOS 26.6.1 (23G83), App Store build. The Live Activity is started in-app with pushType: .token and updated over APNs (production). What happens: An update push arrives and is applied, but the Lock Screen keeps the previous content with a system spinner over it. The sysdiagnose shows the system launching our WidgetKit extension to render the new state, and the kernel killing it at its memory limit about 0.5 s later, three times in a row: liveactivitiesd [activitykit:outputParticipant] Activity updated: <activity id> runningboardd [<WidgetExtension>:24466] Memory Limits: active 30 inactive 30 kernel memorystatus: <WidgetExtension> [24466] exceeded mem limit: ActiveHard 30 MB (fatal) chronod [chrono:activity.store] Reload failed; next attempt due at … New state: failedThe retry about 10 minutes later failed the same way. The device had plenty of free memory; only the per-process limit was hit. A render of the previous state two hours earlier, in an extension process that was already running, succeeded. ReportCrash then discards the report, so we got no crash log and no MetricKit diagnostic: ReportCrash (OSAnalytics) report not saved because it is non-actionable (ie: extension hangs or internal-only) ReportCrash no MetricKit for process <WidgetExtension> type 385The extension links a crash-reporting SDK (12 dynamic frameworks) that is configured at launch. We suspect it but haven't confirmed it yet.

I'm building an App, that is drawing power values in the Dynamic Island area. So the primary indicator is a circle presenting the charge. I've noticed the first issue with this in the landscape orientation, that it then gets clipped by the camera. So I've moved it a few pixels up, which also makes it look really snug with equal distance to the upper outline of the layout. However this then causes issues, when my app gets pushed into the minimal detached position. This is the same view and I can't seem to differentiate, which is which. So either I offset the camera and clip in the detached island or i render perfectly there and clip the camera. iOS 27 added isDynamicIslandLimitedInWidth, which sounds like the right indicator, but what's there before? I've tried measuring the area to get any indication, but it's equal in all regards. Did anyone solve this?

Hi everyone, I’m developing an iOS app and would like to know if it’s possible to dynamically show or hide a widget in the iOS Widget Gallery based on the user’s login status in the app. For example: When a user logs in to the app, the widget should appear in the Widget Gallery. When the user logs out, the widget should be hidden or removed from the Widget Gallery. Is this behavior supported by iOS? Can an app dynamically control the visibility or availability of its widget in the Widget Gallery based on the user’s authentication status? If this is not directly supported, is there an alternative or recommended approach using WidgetKit? Since my app has multiple widgets, some of them specifically require users to log in before they can be used. That’s why I wanted to implement this kind of behavior. Any guidance or suggestions would be appreciated. Thank you!

After updating an internal test app through TestFlight, newly started Live Activities sometimes fail to render. Activity.request succeeds, but the Dynamic Island shows an empty tappable area and the Lock Screen shows no Live Activity. Rebooting the device restores rendering. Is there a supported way to recover from this state without asking the user to reboot? Configuration Device: iPhone18,1 OS for the captured reproduction: iOS 27.0.1 (24A446) Distribution: TestFlight, internal testers only. This app bundle is not published on the App Store. We have reproduced the issue with builds made using both Xcode 26 and Xcode 27. Deployment target: iOS 17.0 The widget extension contains an ActivityConfiguration for Live Activities only, with no Home Screen widgets. Our QA team also reported similar symptoms after app updates on iOS 17.4.1 (iPhone 15 Pro Max) and iOS 26.5 (iPhone 11). We do not have diagnostic logs from those devices, so we cannot confirm that they have the same underlying cause. Bundle identifiers below have been consistently replaced with com.example.internalapp and com.example.internalapp.widgets for this public post. Steps to reproduce Install a build of the app containing the Live Activity widget extension. Update to a newer build through TestFlight. After the update completes, launch the app and start a Live Activity using Activity.request(attributes:content:pushType: nil). Check the Dynamic Island and Lock Screen. This is intermittent: it has happened after several app updates, but not every update. In the captured reproduction, the activity was started about two minutes after installation completed. Expected and observed behavior We expect the Live Activity to render on the Dynamic Island and Lock Screen, with taps opening the app through its widgetURL. Instead: Activity.request succeeds and liveactivitiesd starts the activity. The Dynamic Island has an empty tappable area and the Lock Screen shows nothing. Tapping the empty area opens the app without the activity's widgetURL. Updating the activity's content does not restore rendering. After rebooting, newly started Live Activities render normally. QA has also seen rendering recover after an undetermined wait without rebooting. Relevant diagnostic observations The following is an abbreviated, redacted excerpt from a locally collected sysdiagnose. Times are JST (UTC+09:00), on 2026-10-18. Ellipses indicate omitted fields; the activity identifier has also been redacted. During installation, runningboardd records a RBSPreventLaunchLimitation covering the app and its extensions. While installation is still in progress, chronod ignores the widget extension: 22:38:45.295 runningboardd ... RBSPreventLaunchLimitation ... ... com.example.internalapp.widgets ... com.example.internalapp ... 22:38:45.549 chronod [com.apple.chrono:extensions] Ignoring restricted or unknown extension com.example.internalapp.widgets 22:38:47.178 installcoordinationd -[IXSCoordinatedAppInstall setComplete:] ... com.example.internalapp ... complete! 22:38:47.292 chronod [com.apple.appinstallation:TransactionLog] com.example.internalapp ... applicationsDidInstall When a Live Activity is started later, chronod repeatedly reports zero extensions for the app's container: 22:40:41.221 liveactivitiesd [com.apple.activitykit:activityManager] Starting activity: id: <activity-id>; ... state: active ... 22:40:41.254 chronod [com.apple.chrono:descriptor] Reloading descriptors for 0 extensions in container com.example.internalapp with reason: activityRendererInitiated 22:40:53.543 chronod [com.apple.chrono:descriptor] Reloading descriptors for 0 extensions in container com.example.internalapp with reason: activityRendererInitiated 22:40:55.707 chronod [com.apple.chrono:descriptor] Reloading descriptors for 0 extensions in container com.example.internalapp with reason: reload descriptors requested by client The installation logs also show the widget extension's provisioning profile being found and its data container being created. These observations suggest that extension discovery may not have recovered after the installation restriction was lifted, but we have not established the root cause. We noticed a potentially related watchOS WidgetKit report referencing FB24619522. Its author reported that their issue was resolved with watchOS 27.0 / iOS 27.0; we do not know whether our Live Activity issue is related. Questions Is there a supported API or recovery procedure that makes the system rediscover the Live Activity extension after an app update? Are there known TestFlight installation or extension configuration conditions that could explain this sequence? Which additional ActivityKit/WidgetKit diagnostics would help distinguish an app configuration issue from a system extension discovery issue? The full sysdiagnose is being kept out of this public post because it contains device and account diagnostics.

I am encountering an issue where the Lock Screen Quick Action fails to visibly open my app. My app is a camera application that utilizes a CameraCaptureIntent to launch a standalone, lightweight camera view (accessible while the device is locked), distinct from the main application. Steps to Reproduce: Open the lightweight camera view using the Lock Screen Quick Action. From this view, launch the Main App. Lock the iPhone (put it to sleep). Attempt to launch the lightweight camera view via the Quick Action again. A slight animation occurs, but the camera view does not appear on screen. After multiple tests, it seems the view is actually launching but remains in an "invisible state." I suspect that the system hides the lightweight camera view when transitioning to the Main App, but fails to reset this hidden state when the Quick Action is triggered subsequently. I would appreciate any guidance on a potential workaround or confirmation if this is a known issue awaiting a system update.

I am working on a live activity showing realtime NYC subway arrival countdowns at a station. As trains arrive I want to remove them from the live activity so that only inbound trains are displayed. As I understand it this will require a broadcast push notification every time a train arrives, but this is incredibly inefficient (and will likely be throttled) as trains can arrive many times per minute at a busy station. MTA data includes approximately 90 minutes of train arrivals. Is there no way to create a live activity timeline the way widgets can update at planned intervals? The only viable option I've found is keeping the entire app alive in the background to update the live activity when required by registering for background location updates, but this seems like an unfriendly solution.

Environment: iOS Version: iOS 27.0 Framework: ActivityKit Xcode Version: Xcode 26.1 Issue Description: In iOS 27, Live Activities fail to adapt to the system colorScheme. Regardless of whether the system theme is set to Light or Dark mode, @Environment(.colorScheme) inside the Live Activity view always returns .dark. This behavior worked as expected on iOS 26, where the Live Activity correctly responded to light/dark mode changes and rendered the appropriate theme. Expected Behavior: The Live Activity view should respect the system's current colorScheme (returning .light when the system is in Light Mode) on iOS 27, consistent with the behavior on iOS 26. Actual Behavior: The Live Activity view strictly defaults to .dark mode on iOS 27, even when the device is explicitly set to Light Mode. struct LockScreenView<T: BaseLiveActivityAttributes>: View { let context: ActivityViewContext<T> @Environment(\.colorScheme) var colorScheme var isLight: Bool { colorScheme == .light } var body: some View { Color(isLight ? .white : .black) .overlay(alignment: .topTrailing) { VStack(alignment: .trailing, spacing: 2) { Text("colorScheme: \(String(describing: colorScheme))") } .font(.system(size: 9, weight: .bold, design: .monospaced)) .foregroundColor(.yellow) .padding(4) .background(Color.black.opacity(0.6)) .cornerRadius(4) .padding(.trailing, 8) .padding(.top, 4) } } } Any insights or workarounds would be greatly appreciated. Thanks!

Is there a supported way to schedule a Live Activity update on the device for a known future date, so the system applies it while the app is suspended? It should update on the Lock Screen when the phone is locked, and in the Dynamic Island when the user is in another app, ideally with an alert. Local notifications can be scheduled for an exact date, but I haven't found an equivalent for Live Activities. My use case is a rest timer in a workout app that keeps all data on the device, with no server. When a rest starts, the app knows when it ends, and at that moment the Live Activity should show the next set and the time since the rest ended. Today the app schedules a local notification for the alert and sets the Live Activity's stale date to the rest's end. That has some problems: The stale date is applied a minute or two late in my testing, so the Live Activity shows 0:00 after the notification has already arrived. Updating from the app only works while it's running, which in practice means during a workout mirrored from Apple Watch. Even then, an alert sent with the update while the phone was locked appeared about a minute late, so the Live Activity never alerts. Push updates need a server, which this app doesn't have by design. A scheduled Live Activity start (iOS 26) creates a second activity instead of updating the existing one. Am I missing an API or a pattern for this? I've filed FB25210471 asking for it in case there isn't one.

I am using ActivityKit push-to-start Live Activities on iOS 17.2 and later. In a small number of user reports, the app is never able to obtain Activity<LiveActivityAttributes>.pushToStartToken. The flow is: Task { if let token = Activity<LiveActivityAttributes>.pushToStartToken { // cache and upload token } else { // logged: current push-to-start token is nil } for await token in Activity<LiveActivityAttributes>.pushToStartTokenUpdates { // cache and upload token } } This task is started when the app launches. For the affected users: Activity<LiveActivityAttributes>.pushToStartToken returns nil at app launch. Activity<LiveActivityAttributes>.pushToStartTokenUpdates never emits any value. After waiting for a while, reading Activity<LiveActivityAttributes>.pushToStartToken again still returns nil. When an existing Live Activity ends or expires, the app retries and reads Activity<LiveActivityAttributes>.pushToStartToken again, but it is still nil. Example log from the retry after the Live Activity ended: [Live Activity][retryDisplayCreationAfterLiveActivityEnded] Failed to read PushToStart token. local entity is nil: true In this case, the local entity is empty because no push-to-start token was ever received from ActivityKit. This is not about the per-activity activity.pushToken; the issue is specifically with the app-level Activity<Attributes>.pushToStartToken. Because the push-to-start token remains empty, our server cannot send a push-to-start request for that user. I have seen a previous forum response mentioning a timing issue before iOS 26, but this affected case is on iOS 26.5, so I am not sure whether this is the same issue or a different condition. Questions: Under what conditions can Activity<Attributes>.pushToStartToken remain nil indefinitely? Is pushToStartTokenUpdates expected to emit the current token after app launch, or only future token changes? If the initial pushToStartToken read returns nil, what is the recommended retry strategy on iOS 26.5? Does Live Activities authorization, notification permission, APNs registration state, app install source, or device state affect generation of the push-to-start token? What logs or sysdiagnose information would be useful to confirm whether this is an ActivityKit issue? Environment: iOS version: 26.5 Device model: iPhone 17 App install source: TestFlight Xcode version: 26.3 ActivityKit usage: push-to-start Live Activity Any guidance on whether this is expected behavior, a known issue, or something we should file through Feedback Assistant would be appreciated.