Expected strategy for push-to-start Live Activity updates across app states (incl. force-quit)?

Question

Created 19h

Replies 1

Boosts 0

Participants 2

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

Answer 1

DTS Engineer OP

Apple

17h

Thanks for the post, this is very interesting to me including the user force quit workflow or the system terminated should be similar.

The system starts the Live Activity and your app process is already running. Your Activity.activityUpdates and Activity.pushTokenUpdates observers will fire. You capture the per-activity push token and send it to your server. Because your app is launched in the background, your AppDelegate / App initialization code runs. You must set up your Activity.activityUpdates and pushTokenUpdates observers immediately upon launch. You will have a few seconds of background execution time to grab the token and send it to your server. It is highly recommended to use a background URLSession or wrap the network call in a UIApplication.shared.beginBackgroundTask to ensure the network request completes before the system suspends the app again.

When the user force-quit like by swiping from the App Switcher. The user explicitly killed the app. The system will start the Live Activity, but it WILL NOT wake your app. Because the app is not woken up, your code never runs, and your server will never receive the per-activity update token.

To keep a push-started Live Activity correct across all these states, you should Observe Activity.activities, Activity.activityUpdates, and pushTokenUpdates as early as possible in the app lifecycle.

Albert  WWDR