Hello,
We watched the WWDC25 presentation about Apple Wallet on the upgrade boarding pass features with Live Activities. We’re interested in integrating this into our app for iOS 26 beta testing.
Could you please provide:
Sample code or example projects
API documentation
Implementation guidelines
Details on sharing functionality
Thanks in advance!
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
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 with Live Activities using the ActivityKit(Activity), and I'm trying to find a way to detect when a user manually dismisses a Live Activity by swiping it away — either from the Lock Screen or the Dynamic Island.
Currently, when a Live Activity ends, the activityState changes to .dismissed, which is defined as:
/// The Live Activity ended and is no longer visible because a person or the system removed it.
case dismissed
This doesn’t allow me to determine whether the dismissal was triggered by the user or by the system.
Is there any way — either through ActivityState, notifications, or another approach — to distinguish if a Live Activity was manually dismissed by the user vs. ended by the system?
Thanks in advance!
Hello,
We are using the Firebase Admin SDK (firebase-admin framework) to send push notifications via Firebase Cloud Messaging (FCM) for Live Activity updates in our iOS app.
With the introduction of iOS 18, a new key "input-push-token": 1 has been added to the Live Activities push payload structure.
1) Can this new key ("input-push-token": 1) be used when sending payloads via FCM?
We noticed that FCM is still using the push update format introduced in iOS 17.2. Will FCM be updated to support the new push structure introduced with iOS 18? Or is the "input-push-token" feature only available when sending notifications via direct APNs?
2) We are concerned about the expiration of the Live Activity start push token.
If a user doesn't open the app for a long time, the token may expire, and this could result in failed updates. That’s why we are looking into the new "input-push-token" behavior in iOS 18.
Do you have any recommendations on how to manage or prevent token expiration?
Is there any official guidance on the lifespan of the Live Activity push tokens?
Will FCM support the delivery of start/update/end Live Activity actions even when the app is completely terminated?
We would highly appreciate any official clarification or roadmap regarding this. It would help us determine whether we should wait for FCM support or switch to sending notifications directly via APNs.
Thank you for your help!
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!