Activity.pushToStartToken is nil and pushToStartTokenUpdates never emits, even after delayed retry

Question

nemo_xie OP

Created 3d

Replies 1

Boosts 0

Participants 2

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.

Answer 1

DTS Engineer OP

Apple

2d

Thanks for your very interesting post. Thanks for your patience on this.

It seems like ActivityKit's push-to-start functionality is a common question lately the underlying token generation relies heavily on the Apple Push Notification service.

The push-to-start token can remain nil indefinitely under a few specific conditions if the device cannot establish a connection to APNs due connections issues or the user has disabled Live Activities either globally or specifically for your app in Settings, make sure you get logs for those to know why the start token remains nil.

The pushToStartTokenUpdates sequence is designed to emit the token immediately upon subscription if one has already been generated and is valid. Make sure to read the static pushToStartToken. Immediately subscribe to pushToStartTokenUpdates in a long-running Task. Ensure you are calling UIApplication.shared.registerForRemoteNotifications() at app launch.

If ActivityAuthorizationInfo().areActivitiesEnabled is false, the token will not generate. You should check this property before attempting to read the token. Standard user-facing notification permissions (Alert, Sound, Badge) are not strictly required to get a push-to-start token.

What logs or sysdiagnose information would be useful to confirm whether this is an ActivityKit issue? The most critical information to include is a Sysdiagnose taken immediately after the app launches and fails to get the token.

Albert  WWDR