@PachuLord did you ever figure out a workaround for how to get pushTokenUpdates before user hitting "Allow"

This is only true for us if the live activity was started from the app. When the Live Activity was started from apns, then PushTokenUpdates will only emit new tokens if user hits on "Allow" from Lock Screen. Toggling OS permission off and then back on won't cause how Apple evaluates — at until now. I think is a bug. Since the docs on PushTokenUpdates say: By default, your app can start, update, and end a Live Activity if you use ActivityKit to offer /// Live Activities

@DTS Engineer Q1 From the emojiranger app: for await activityState in activity.activityStateUpdates { if activityState == .dismissed { So doesn't that mean app gets a callback? Q2: Even though upon reaching stale-date UI is updated immediately, the callback from listening to activityStateUpdates and checking for if the state is .stale is ** delayed** until app is foreground. Is that expected?

Can you elaborate what you mean by "primary workflow"? what's a workflow in this context? and how can you start a live activity fro the server without using the "push to start token"?