We are adding a live activity to our app that is started by a push to start live activity token that we supply to our server backend. In the app I have a Task that is retrieving pushToStartTokens from the asynchronous stream provided by the Apple API It looks similar to: // Iterate the async stream from the system for await tokenData in try await Activity<MyActivityAttributes>.pushToStartTokenUpdates { let tokenString = tokenData.map { String(format: "%02x", $0) }.joined() logger.log("Received push start token: \(tokenString, privacy: .public)") } } catch { logger.error("Failed to monitor push start tokens: \(error.localizedDescription, privacy: .public)") } When my app is launched from Xcode and connected via the debugger this code vends a pushToStartToken reliably. However if I run this same code by directly launching the app by tapping the icon on the phone, it almost never vends a pushToStartToken. It only occasionally works. I've tried a variation on the code where instead of always executing the asynchronous stream to obtain the token it first checks for the existence of a pushToStartToken using the this synchronous check prior to entering the for await if let pushStartTokenSync = Activity<AttributeType>.pushToStartToken { let tokenStr = pushStartToekSync.map { String(format: "%02x", $0) }.joined() nextPushToStartToken = pushStartTokenSync logger..log("**** Queried PushToStart Token: \(tokenStr, privacy: .public) ***") } else { logger..log("**** Queried PushToStart Token is nil! ***") } This works more reliably than just falling directly into the stream but I still see many instances where the result is nil. I'm trying to understand what is the correct way to obtain and manage the pushToStartTokens so that getting one is as reliable as possible especially in production builds. When I do get a token, should I persist it somewhere and use that (even across different app executions) until a new one is vended? Appreciate hearing ideas, thoughts and any code samples that illustrate a good management scheme Thank, You. Rob S.

I have implemented the logic to display live activity with push notification. As of now, only in the foreground only, the live activity is getting triggered. For background, it is displaying some times and for killed state, it is not even trying to trigger.

I am developing Live Activities using Swift. The same code can display the lock screen view and Dynamic Island on most devices, but on one specific iPhone 16 Pro Max, the Dynamic Island is not shown. The system version is iOS 18.0. However, other apps on this phone can display the Dynamic Island normally. How should I troubleshoot the issue? Can anyone help me? Thank you.

Hi, I've watched the WWDC video "Discover streamlined location updates" As detailed here: https://developer.apple.com/videos/play/wwdc2023/10180/?time=364 In order for my app to receive location updates in the background, the video states that I can either use a live activity or a CLBackgroundActivitySession My app has a live activity, however the location updates stop shortly (10 seconds, this is the normal "grace period" described) after backgrounding the app, even when the live activity is visible. If I acquire a CLBackgroundActivitySession, location updates continue in the background. I have reproduced this behavior in the Simulator in a barebones app for testing and confirmed that it's not working as described. My question is: Should I hold a CLBackgroundActivitySession even when I already have a Live Activity?

I'm currently seeing that OS gets a new push-to-start token immediately after receiving the first notification. Should my server immediately invalidate the push-to-start token upon usage? Or invalidating the push-to-start token should only be done if my iOS device gets a new one and then I have to send it back to my server.

Hi all, I’m developing a timer app with Live Activity support. On iOS 18.5 (iPhone 14 Pro Max), I cannot get Live Activity to start. When I call Activity.request(...) in my main app, it throws an unsupportedTarget error, and nothing appears on the Lock Screen or Dynamic Island. What I’ve done: Widget Extension Info.plist: <key>NSExtension</key> <dict> <key>NSExtensionPointIdentifier</key> <string>com.apple.widgetkit-extension</string> </dict> <key>NSSupportsLiveActivities</key> <true/> <key>NSSupportsLiveActivitiesFrequentUpdates</key> <true/> Live Activity UI: Implemented with ActivityConfiguration(for: xxx_Clock_liveactivitiesAttributes.self) and Dynamic Island support. App Group: Both main app and extension use the same App Group, and it’s enabled in Apple Developer Center and Xcode. Tested on: iPhone 14 Pro Max, iOS 18.5 (official release) Xcode [your version] (I have not tested on iOS 17.x, so I am not sure if this issue is specific to iOS 18.5.) What I’ve tried: Cleaned build folder, deleted Derived Data, uninstalled and reinstalled app. Rebooted device. Double-checked all Info.plist and entitlements settings. Tried creating a new Widget Extension from scratch. Problem: Activity.request always throws unsupportedTarget. No Live Activity appears on Lock Screen or Dynamic Island. No other errors or crashes. Questions: Has anyone encountered this issue on iOS 18.5? Are there any new requirements or changes for Live Activity in iOS 18.5? Any suggestions or workarounds to make Live Activity work? Any help or suggestions would be greatly appreciated!

I am using live activity in my app. Functionality is start, update & end events are started from the server. There is one interaction button added using app intent in live activity widget. That button needs to update widget ui locally using activity kit. Issue is when os receives first start event push then update ui works fine and reflecting on live activity widget but when update notification receives by os after 1 mins then action button stops updating the ui locally. Can anyone please add some suggestions to fix this.

I have an ongoing activity in progress. Think of: a delivery in progress house internet reboot in progress some water / electricity / internet / tv outage. (food) order processing I want to show a persistent toast message above the tab bar, across all tabs and screens across the app. It could take 15 minutes until the activity is finished. Obviously there's a challenge of: accessibility content overlaying with each other extra engineering effort. What we've thought of doing is: Option1: show a toast message, but when a modal is presented then it presents on top of the toast message. The toast message no longer updates itself. Once the modal is finished, then the toast message re-appears and continues to update. Option2: keep the toast message across all tabs and modals and work through the challenges mentioned Question: What are some other design approaches that could be taken to persist an ongoing activity (much like 'Live Activity', but just across the app when it's in foreground) or what are some design reasons that the two options considered are bad?

Confusion Based on the fact that the subscription is requested on a Activity type, I assumed that the push-to-start tokens would be different. But the push-to-start token for WidgetExtensionAttributes and WidgetExtensionAttributesOther were identical. This is misleading. The code below prints identical tokens even though the name of the token and their underlying schema are different. Code Sample func getTokens() { Task { if let data = Activity<func getTokens() { Task { if let data = Activity<WidgetExtensionAttributes>.pushToStartToken { print("exists:", data.hexadecimalString) } else { print("requesting pushToStartToken") for await ptsToken in Activity<WidgetExtensionAttributes> .pushToStartTokenUpdates { let ptsTokenString = ptsToken.hexadecimalString print("new:", ptsTokenString) } } } Task { if let data = Activity<WidgetExtensionAttributesOther>.pushToStartToken { print("other exists:", data.hexadecimalString) } else { print("other requesting pushToStartToken") for await ptsToken in Activity<WidgetExtensionAttributesOther> .pushToStartTokenUpdates { let ptsTokenString = ptsToken.hexadecimalString print("other new:", ptsTokenString) } } } }>.pushToStartToken { print("exists:", data.hexadecimalString) } else { print("requesting pushToStartToken") for await ptsToken in Activity<WidgetExtensionAttributes> .pushToStartTokenUpdates { let ptsTokenString = ptsToken.hexadecimalString print("new:", ptsTokenString) } } } Task { if let data = Activity<WidgetExtensionAttributesOther>.pushToStartToken { print("other exists:", data.hexadecimalString) } else { print("other requesting pushToStartToken") for await ptsToken in Activity<WidgetExtensionAttributesOther> .pushToStartTokenUpdates { let ptsTokenString = ptsToken.hexadecimalString print("other new:", ptsTokenString) } } } } Activity Types struct WidgetExtensionAttributesOther: ActivityAttributes { public struct ContentState: Codable, Hashable { var age: Int } var addresses: [String] } struct WidgetExtensionAttributes: ActivityAttributes { public struct ContentState: Codable, Hashable { var emoji: String } var name: String } Docs After much investigation I noticed the wording of the docs kind of hint that the push-to-start token is per ActivityKit as it says: An asynchronous sequence you use to observe changes to the token for starting a Live Activity with an ActivityKit push notification. But docs and the API don't align well. Questions Is it correct that the push-to-start token is per app? If so then is there a reason that that API designers decided to still have to pass a specific type and not just make a request without passing a type? Should I maybe file a radar? Is it correct to say push-to-start is per app, while update tokens are per instance. i.e. if I have two soccer matches, then unless the push-to-start token was refreshed by the OS, then both would use the same push-to-start token, however each match would have a unique update token?

Hello, I'm working with Live Activities and noticed that sometimes an activity transitions to .dismissed, even though the user hasn't manually swiped it away and system conditions appear to be completely normal — such as: The activity is still within its intended 8-hour lifetime The battery level is high The app is active or recently active The activity is lightweight (not using frequent updates) According to the ActivityKit documentation: /// The Live Activity ended and is no longer visible because a person or the system removed it. case dismissed This doesn’t clarify why the system would dismiss an activity when all conditions seem fine. Additional context: When reviewing system logs via Console.app, we’re seeing messages such as: liveactivitiesd Removing activity from replicator: 381F3DDC-585B-4021-B075-548606F543DA for relationship IDs: [C7AB9C2A-49DD-43FC-BB58-D768ECF9D354] This suggests that the system is actively removing the activity, but there’s no API or reason provided that helps us understand why this is happening. Questions: What are the system-level triggers that could cause a Live Activity to be dismissed under normal conditions? Is there a known set of heuristics (e.g., memory pressure, resource constraints) that might apply? Is there a way to distinguish between system-triggered dismissal and user-initiated swipe-to-dismiss? Any best practices to reduce the likelihood of unexpected system removal? This is especially important for our use case, where users rely on Live Activities to view real-time flight and boarding information — and losing the activity unexpectedly negatively affects user experience. Thanks in advance for any insight!

Hi everyone, I’m working on implementing Live Activities in my app, and I’ve encountered an issue where the Live Activity updates work intermittently when the app is in the background. Sometimes they update correctly, but at other times, they don’t update at all, even though they should be running in the background. However, when the app is brought to the foreground, the updates happen correctly. A few things I’ve checked: The app is using ActivityKit to update the Live Activity with Activity.update(). I’ve enabled the necessary background modes in the Capabilities section. Is there a possibility that I’m hitting the system budget limit while experiencing this issue? If this is a limitation, how can I avoid it or manage this situation? Has anyone else faced this issue? Any advice or potential solutions would be greatly appreciated! Thank you!

Desired Behavior I want the app to be able to handle multiple Push-to-Start notifications even when it is completely terminated. Each Live Activity should: Be successfully displayed upon receiving a Push-to-Start notification. Trigger background tasks to send its update token to the server, regardless of the time interval between notifications. Problem I am facing an issue with iOS Live Activities when using Push-to-Start notifications to trigger Live Activities in an app that has been completely terminated. Here’s the detailed scenario: When the app is completely terminated and I send the first Push-to-Start notification: The Live Activity is successfully displayed. didFinishLaunchingWithOptions` is triggered, and background tasks execute correctly, including sending the update token to the server. When I send consecutive Push-to-Start notifications in quick succession (e.g., within a few seconds or minutes): Both notifications successfully display their respective Live Activities. Background tasks are executed correctly for both notifications. However, when there is a longer interval (e.g., 10 minutes) between two Push-to-Start notifications: The first notification works perfectly—it displays the Live Activity, triggers didFinishLaunchingWithOptions, and executes background tasks. The second notification successfully displays the Live Activity but fails to execute any background tasks, such as sending the update token to the server. My HypothesisI suspect that iOS might impose a restriction where background runtime for Push-to-Start notifications can only be granted once within a certain time frame after the app has been terminated. Any insights into why this issue might be occurring or how to ensure consistent background task execution for multiple Push-to-Start notifications would be greatly appreciated!

I am developing a live activity for my app and am running into issues on devices with dynamic islands. The live activity will randomly get in a state where it displays a spinner and does not update. For devices without dynamic islands, the activity works perfectly fine. I have tried breaking down the views to determine the root cause, but at times it seems very random. These are all TestFlight builds as we are currently developing the feature. I have tried using the console app and looking at the various processes that have been called out in other threads and cannot see any actual errors being logged. Looking for any pointers on how to pinpoint the root cause of this issue.

When my app is in the background, I create a Live Activity through a push notification with token get from pushToStartTokenUpdates, and this process works fine. However, without opening the app, how can I retrieve the new push token for this Live Activity again and use it for subsequent updates to the Live Activity content?

Hello everyone, I’m currently receiving feedback from clients in a production environment who are encountering a BadDeviceToken error with Live Activities, which is preventing their states from updating. However, for other clients, the token is working fine and everything functions as expected. I’m collaborating with the back-end developers to gather more information about this issue, but the only log message we’re seeing is: Failed to send a push, APNS reported an error: BadDeviceToken I would greatly appreciate it if anyone could provide some insight or information on how to resolve this issue.

Our watchOS App isn't opened when tapping on a Live Activity. Added the following to our Info.plist and still get the Open on iPhone option. <key>WKSupportsLiveActivityLaunchAttributeTypes</key> <array/> Is there something else we need to configure?

I have a live activity, that works fine when the Lock Screen showing, but as soon as it "sleeps" dims down for always on display, everything in the widget disappears and an Activity Indicator(spinner), displays in its place, but non-animating.