Some users are reporting that they don't see Live Activities, but our logs show that the trigger was sent successfully. Is there a way to investigate on the client side why the Live Activity didn't appear? Logs on client side? anything?

Hi all, very new "developer" trying to build my own app. The app works, just trying to improve it. I’m implementing a Live Activity in a widget extension (Swift/SwiftUI) for an app built with Flutter as the host app. ActivityKit is functioning correctly—activities start, update, and end normally, and the widget extension receives all state updates. However, the Live Activity UI renders as a completely black capsule (both compact and expanded Dynamic Island, as well as the Lock Screen presentation). The system shows the Live Activity container, but none of the SwiftUI content displays. Verified so far: ActivityAttributes contains at least one stored property (previously empty). ContentState fully Codable + Hashable. All Dynamic Island regions return visible test UI (Text/Image). No .containerBackground() usage. Added explicit .activityBackgroundTint() + system foreground colors. All Swift files included in widget extension target. No runtime errors, no decode failures, no SwiftUI logs. Widget previews work. Clean build, app reinstall, device reboot. Entitlements and Info.plist appear valid. Problem: The widget extension returns a completely black UI on-device, despite valid SwiftUI content in ActivityConfiguration. The Live Activity “shell” renders, so the activity is recognized, but the widget’s view hierarchy is visually empty. Question: Under what conditions would a widget extension produce a black, empty UI for a Live Activity even when ActivityKit, previews, and the SwiftUI layout are correct? Are there known cases where: Widget extension Info.plist misconfiguration, Incorrect background/tint handling, Rendering issues in Dynamic Island, Host app integrations (Flutter), Or extension isolation issues cause valid SwiftUI to fail to render in a Live Activity? Any guidance on deeper debugging steps or known system pitfalls would be appreciated.

I'm working on adding Live Activities to my app but I'm running into a problem, and I'm wondering if anyone knows what's going on. The live activities are started and updated entirely via push notifications (sent through FCM). On the lock screen, updates come through fine for a while, but then the activity gets stuck while the phone is locked. The moment I unlock the device, it immediately jumps to the latest state. I've tried different update frequencies and sending with both priority 5 and priority 10, but no luck. I've also looked through the liveactivitiesd logs, but I'm not really sure what I should be looking for. And yes, NSSupportsLiveActivitiesFrequentUpdates is enabled.

I create a Live Activity remotely via push-to-start, then use its per-activity token (Activity.pushTokenUpdates) so my server can send update/end pushes. To make sure I'm not missing tokens, I observe Activity.activityUpdates and prime from the Activity.activities snapshot at launch and on sceneWillEnterForeground, then subscribe each activity's pushTokenUpdates and POST the token to my server. This works reliably while the app is running or backgrounded/suspended — the system wakes it and I capture the token. The problem is the user force-quit case (swiped from the App Switcher, never reopened): Push-to-start still creates the Live Activity and it renders correctly on the Lock Screen. But pushTokenUpdates never fires, so my server never receives the per-activity token and can't update or end that activity. A backgrounded (not force-quit) app, as a control, captures the token every time. So it seems specific to user-termination rather than all "not running" states. I understand force-quit apps generally aren't granted background runtime — I'm trying to confirm whether that applies here and what the right pattern is. What's the recommended approach? Specifically: Is there any supported way to get the per-activity token to my server while the app stays force-quit — e.g. from the widget extension (does it have any access to Activity.pushToken, or only ActivityViewContext?) or a Notification Service Extension? 2. If not, is setting stale-date on the start push the intended way to let the card expire gracefully when it can never be ended via push? 3. Is there a better pattern for keeping a push-started Live Activity correct when the app is never relaunched?

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.

Good morning, We are implementing Live Activities in a push-to-start flow. We wrap the listener for push to start tokens in a high priority task: if ptsListenerTask == nil || ptsListenerTask?.isCancelled == true { ptsListenerTask = Task(priority: .high) { [weak self] in for await pushToken in Activity<LiveAuctionAttributes>.pushToStartTokenUpdates { //Send token to back-end } } I've tried a few variations of this and they work well on most devices. I have seen a couple of devices that refuse to issue a push to start token. The user will have logging for the init flow and starting the PTS listener then the logs just go silent, nothing happens. One thing that seemed to work was getting the user to start a Live Activity manually (from our debugging tool) then the PTS token gets issued. This is not very reliable and working a mock live activity into the flow for obtaining a PTS token is a poor solution. Is anyone else seeing this and is there a known issue with obtaining PTS tokens? Thanks! Brad

Hello, I'm trying to add a new Live Activity to my app showing a timer to a specific date and time. I thought I could use some TimeDataSource so that the timer would be updated automatically by SwiftUI without relying on Live Activity updates. That's not the case with .dateRange(endingAt:) though. Text(.dateRange(endingAt: targetDate), format: .components(style: .narrow)) Something like this correctly shows the timer exactly how I want it, but it never updates. Other TimeDataSource like .currentDate and .durationOffset(to:) do update automatically, but are not what I'm looking for. Am I missing something? Should I use another formatter to make it work?

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") } }

I find these sample projects quite valuable: https://developer.apple.com/documentation/widgetkit/emoji-rangers-supporting-live-activities-interactivity-and-animations https://developer.apple.com/documentation/coredata/sharing-core-data-objects-between-icloud-users . Both use Swift 5, and it is not trivial to adopt Swift 6 with them. Any plans to update them? What is best approach for adopting Swift 6 on such sample code?

Hey everyone, We're using Push to Start Live Activities in our app (District: Movies Events Dining) where all Live Activities are entirely server-driven. At District, we've taken a unique approach to Live Activities. Since our customers often plan ahead reserving restaurant tables early in the week or booking movies days in advance we needed a way to surface timely, relevant information without requiring the app to be open. We power our Live Activities entirely from the server using Push to Start and Push to Update. This means the Live Activity is initiated and kept up to date by our backend from reservation confirmation all the way to the day of the experience. Whether it's a dining slot or a movie showtime, the Live Activity automatically appears in the notification tray with all relevant details, right when you need it no app launch required. FB Number: FB22062904 Problem: When a Push to Start payload is sent from the server, the user sees an Allow / Don't Allow prompt on their lock screen. If the user ignores this prompt (neither taps Allow nor Don't Allow), the Live Activity card stays stuck in the notification tray permanently with zero way to dismiss it programmatically. This happens because: The activity never officially "starts" on device Activity.end() cannot be called — there's nothing to end Sending an update/end push has no effect dismissal-date is not honoured in the start payload Steps to Reproduce Send a push-to-start APNs payload to a device Do NOT tap Allow or Don't Allow on the prompt Observe — card stays in notification tray indefinitely Send an end push from server — no effect Current Payload { "aps": { "timestamp": 1234567890, "event": "start", "alert": { "title": "Your table is reserved", "body": "Tap to view your reservation" }, "content-state": { ... }, "attributes-type": "ReservationActivityAttributes", "attributes": { ... } // ❌ dismissal-date has no effect here } } Expected Behaviour dismissal-date should be honoured in the push-to-start payload, so that if the user ignores the prompt, the notification auto-dismisses after the specified time — consistent with how standard Live Activity expiry works. Suggested Fix { "aps": { "timestamp": 1234567890, "event": "start", "content-state": { ... }, "dismissal-date": 1234568490 // ✅ honour this } } Impact This affects any app using server-driven Live Activities — dining reservations, movie bookings, food delivery, ride hailing, ticketing etc. Without this, there is no way to prevent permanent notification tray pollution for users who ignore the Allow prompt. Has anyone found a workaround for this? Would love to know if others are hitting the same issue.

I'm seeing a Live Activity that successfully starts via Activity.request() — activityState returns .active, a valid ActivityKit push token is issued and works correctly — but nothing ever appears on the Lock Screen, and the widget extension process never shows up in Xcode's Debug → Attach to Process list (the main app process does appear). This happens consistently across many clean rebuilds. Setup: Flutter app (using the live_activities Flutter plugin, which wraps ActivityKit) with a native iOS Widget Extension target for the Live Activity Xcode 26.5, iOS 18.7.9 on a physical iPhone XS Max Bundle ID: com.santitech.foodboda, extension: com.santitech.foodboda.FoodbodaLiveActivity NSSupportsLiveActivities = YES confirmed in both the main app's Info.plist and the extension's Info.plist (verified in the compiled .appex binary itself, not just source) App Group entitlement confirmed present in both compiled provisioning profiles via security cms -D on embedded.mobileprovision Deployment target 16.6 on both targets (Live Activities require 16.1+) Settings → [App] → Live Activities toggle confirmed ON; Low Power Mode OFF What I've already ruled out: Target membership of Swift source files — confirmed correct in File Inspector WidgetBundle only references the real Live Activity widget (removed unused Control/home-widget/AppIntent boilerplate) Info.plist NSExtensionPointIdentifier = com.apple.widgetkit-extension — correct Built a brand-new, separate, minimal test app+extension from Xcode's default template, using the exact same Attributes/ContentState/SwiftUI view code as the main app (copy-pasted verbatim) — this minimal test successfully renders on the Lock Screen on the same physical device. This proves the Swift code itself, the device, and the Apple ID/provisioning are all capable of supporting Live Activities correctly. Confirmed areActivitiesEnabled() returns true and getActivityState() returns .active on every test Tested with full app delete + device restart + DerivedData wipe between attempts — no change Question: Given that identical code works in an isolated minimal project but not in the main app's bundle ID, what could cause this specific symptom — ActivityKit registering an activity as active while WidgetKit never instantiates the extension to render it — tied to one specific app/bundle identifier rather than the device or account in general? Is there a known interaction with App Groups that have been reconfigured many times during development, or any way to fully reset WidgetKit's registration state for a specific bundle ID short of changing the bundle identifier entirely?

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.

Hi team, I’m working on an ActivityKit use case where a Live Activity is useful on the Lock Screen, but not in the Dynamic Island. Today, Live Activities appear to be treated as a unified presentation across system surfaces: Lock Screen, Dynamic Island, StandBy, etc. For our app, the Lock Screen presentation is the right user experience, but showing the same activity in the Dynamic Island creates unnecessary persistent foreground UI while the user is actively using the device. Is there any supported way to create a Live Activity that appears on the Lock Screen but opts out of Dynamic Island presentation on supported iPhones? If not, I’d love to request an ActivityKit enhancement that lets developers specify supported presentation destinations for a Live Activity, for example something like: Lock Screen only or Lock Screen + StandBy, but not Dynamic Island This would be useful for apps where the Live Activity is meant to act as a passive lock-screen status/reminder, rather than an ongoing foreground indicator. Thanks!

On earlier iOS versions Live Activity displays correctly according to mode set.  Can't find an opened issue for that version: iOS 26 device: iPhone 16

LiveActivity using colorScheme to adapt to dark mode in iOS 26 system does not work The system keeps returning. mark, unable to switch

I'm trying to nail down the correct mental model for keeping a push-to-start Live Activity updatable, and want to confirm my understanding rather than design around an assumption. Flow: my server creates the activity via push-to-start, then I capture its per-activity token (Activity.pushTokenUpdates) and send it to the server for update/end pushes. I observe Activity.activityUpdates and also prime from the Activity.activities snapshot at launch and on foreground. What I'd like to understand for each app state: Foreground / backgrounded (in memory): I capture the token reliably — is that the intended guarantee? System-terminated (jettisoned for resources): does the system relaunch the app in the background to deliver the per-activity token, and is that something I can rely on? User force-quit (swiped from the App Switcher, not reopened): what should I expect here for per-activity token delivery, and what's the recommended strategy if the app stays force-quit — e.g. stale-date on the start push for graceful expiry, or any extension-based path? Essentially: across these states, what's the supported strategy to keep a push-started Live Activity correct? Tested on iOS 18 and 26. Related question from the implementation side: https://developer.apple.com/forums/thread/834934

Problem Description We are encountering a pushToken retrieval failure when creating Live Activities using the ActivityKit framework in our iOS application. Problem Symptoms Failure Rate: Approximately 40% of Live Activities created in production fail to obtain a pushToken Behavior: The Activity is created successfully, but activity.pushToken and the activity.pushTokenUpdates stream remain empty / return nothing Impact: Unable to update Live Activities via APNS Offline Issue Environment iOS Version: iOS 26.5 Device: Physical iPhone device Deployment Environment: Production environment, release build Code Sample Task { // Executed after Live Activity creation for await activity in Activity<T>.activityUpdates { ... if let activityTokenData = activity.pushToken { // Report token to APNS service reportTokenToAPNS(tokenString) } // Start async monitoring self.registerPushTokenUpdates(...) Log("actObserver: Live Activity registered successfully") } } // Async monitoring private func registerPushTokenUpdates<T: SAKActivityAttributes>(...) { Task { self.pushTokenObserveRecords.safe{ $0.append(activity.id) } Log("Monitoring pushToken updates for Live Activity <\(activity.id)>") for await data in activity.pushTokenUpdates { let pushToken = pushTokenString(with: data) // Report token to APNS service reportTokenToAPNS(pushToken) } } } System Log Evidence System logs, log and log

Hi everyone, I'm working on a Live Activity implementation for a ticketing app (written in Swift/SwiftUI with ActivityKit), and I've encountered an unexpected behavior on iOS 26.2.1 that contradicts my understanding of the documentation. What the docs say: The official ActivityKit documentation states: "The system uses the minimal presentation when more than one app has an active Live Activity." This implies the two minimal slots are intended for two different apps. There is no documented scenario where a single app occupies both minimal positions simultaneously. What I observed: On a device running iOS 26.2.1, with two active Live Activities from the same app running at the same time, both minimal views appeared on the Dynamic Island simultaneously — one attached to the island, one as a detached floating pill. Questions: Is this behavior intentional in iOS 26, or is it a regression / unintended side effect? Has the system policy changed in iOS 26 to allow a single app to occupy both minimal slots? If this is expected, is there any updated documentation or release notes that cover this change? Environment: Device: iPhone 14pro iOS: 26.2.1 Xcode: xcode26 Any insights from Apple engineers or developers who've seen this would be greatly appreciated. Thanks!

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?

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?