So your infrastructure and all is in place. But you have one problem. The OS isn’t issuing the ‘update token’ to you. This post walks you through when the problem occurs and when it doesn’t occur. Attempts I made to fix the issue and final take.

Problem

​WHEN
​When a Live Activity is started from the server, the OS doesn’t issue an update token until user locks the screen and then hits Allow.

​USER IMPACT
​This is detrimental to the user experience. Makes all live Activities go stale because user may not lock their device in time or just assume that the Live Activity experience is identical to live activity experience from other cases where updating a live activity is allowed to happen without explicit user engagement

​Other Live Activity cases: ​- When Live Activity is started from the app ​- When Live Activity is started from a broadcasting Live Activity

​DEVELOPER IMPACT
​This difference is also very confusing to developers since it’s not documented that it works differently.

​REFERENCES
​The following links all mention this issue:

​https://developer.apple.com/forums/thread/800669 ​https://developer.apple.com/forums/thread/807976 ​https://canopas.com/integrating-live-activity-and-dynamic-island-in-i-os-a-complete-guide-part-2

Attempts

I first opened a question in the developer forums. Got no response back.
Later I filed a feedback to Apple. FB21607043. Got no response back.

I finally opened a DTS ticket. The outcome was:

  • You are correct in your finding. Until the user explicitly hits ‘Allow’, the app won’t be granted the update token. This is so Apple can control background time of apps and control battery life.
  • You could instead start the Live Activity from the app. That way the update token is guaranteed. But that means having the app open, which was against what our product wanted.
  • You could instead start the Live Activity from the app — through a silent push. That way the update token is guaranteed. But silent pushes aren’t meant to be delivered immediately.
  • 💡💡💡 They also said tapping and engaging with the live activity should implicitly grant you the update token. This is not documented anywhere in the docs. So I added widgetURL and App Intent to the Live Activity in my sample app. Tapping on neither generated the update token. After multiple emails back and forth, Apple asked me to upload a sysdiagnose to the Feedback. They were thinking that it’s due to budget issues. I also tried with a fresh bundle id; same issue. At the end I uploaded:
  • Sample Project
  • Sysdiagnose
  • Video Recording

Waiting to hear back from Apple.

Where this limitation can have a more negative impact on the overall Live Activity Completion Rate†

The following factors increase / decreases the chances of a user seeing the Live Activity OS Permission Prompt and acting upon int.

Initiated from Server: Is the Live Activity started from the server (via an APNS payload) rather than from the app itself?

❕ If it’s initiated from the app, then you don’t have an update token issue. The OS will grant the Update Token as soon as the live activity begins. This is done because it’s an explicit user interaction.

But if you plan to start the Live Activity from the server, then the following criteria affect the success rate of your feature.

Criteria

How soon after first time app launch: Does it happen in the first day or two after app is installed vs happening weeks after user onboarding? Because the more engagement with an app your user has had, then it’s more likely that they’ve locked their device and been prompted with the OS permission and acted upon it. But if it’s just 20 minutes after installation then it’s less likely.

Duration: The longer a Live Activity takes, the higher the chance the user has to lock the device and hit allow. If a Live Activity ends in 5 minutes, then the window for user to 1. lock device 2. hit allow is very short.

Frequency: Happening 4 times a month vs a major event that user does once every a year.

Does it ‘end’ at a pre-set time? If end is determined before, then you can ‘hack’ the UI update without needing an update token. That is, you can rely on the stale UI re-rendering to update the UI.

Requires Update: If it doesn’t, then you don’t need the update token, as long as your end time is fixed and you are comfortable with using a hack.

Initiated from Server: Is the Live Activity started from server as opposed (through an apns payload) to being started from the app itself?

1. Flash Sale countdown

Title: Black Friday discounts end in 5 hours

Description: Limited-time voucher redemption for online checkout.

How soon after first time app launch: Requires the user to become familiar with the app before discovering this feature.

Duration: 5 hrs

Frequency: Dozens of times a year

Requires Update: No

Does it ‘end’ at a pre-set time? Yes

Is the end-state UI varied? No. It just ends; there’s no success or failure state.

2. Activating a Device

Title: Activating the internet of your house for a specific CMMac as soon as you plug in the router to a coax outlet.

How soon after first time app launch: Happens as soon as the user plugs in their router, which is often one of the first actions a user may take.

Duration: Could take 5 minutes or 15 minutes. Depends on network health, device model, and number of activation steps.

Frequency: 1-2 times a year

Requires Update: Depends. You may want to give the user more information about the activation steps.

Does it ‘end’ at a pre-set time? No

Is the UI of end state varied? Yes. It could end with either success of failure.

Conclusion with Product Considerations

In the ‘Activating a Device’ example, because it could happen after the user has just got a router, then they may not have the app, or just not be logged in. Or not care about using the app. Or care, but just didn’t get to lock their device while a live activity from your app was present, hence never saw the OS prompt to hit ‘Allow’ on the lock screen.

As a result the app isn’t granted the ‘Update Token’.

Final nail in the coffin: Since the duration is short, has a dynamic duration and final state, then you also can’t end the live activity at pre-determined time with a pre-defined UI. This means you must have the update token and can’t come up with any hacks. Be careful in your product design with this.

Foot Note

†: The ability to start and finish a live activity from the server.