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"?

@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?

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

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

Your answer is conflicting this other answer from Argun Tekant: https://developer.apple.com/forums/thread/759827?answerId=795829022#795829022 Would be great if both answers say the said the same thing

Your answer is conflicting this other answer from another Apple Engineer: https://developer.apple.com/forums/thread/785281 I think yours is more accurate, but would be great if both answers say the said the same thing.

Thanks Albert. I see. So dismiss won't launch. but the rest launch the app. I have read / watched those links multiple times before (including the emoji ranger app). My ultimate question is: when OS launches the app, is it necessary to use beginBackgroundTask or by virtue of being launched (by OS into background) app has some allowed time to process whatever it was that launched the app? If so, does that negate the need of using beginBackgroundTask? Asking because we often get -1005 errors

(deleted comment)

I interpreted docs saying "unless your application retrieves the same device token" as 'it's possible that a token becomes invalid and then valid again'. I guess what you're saying is: even if a given token becomes invalid and then valid, then you still have to stop using an unregistered token — unless and until the server re-issues is to you again. (2/2)

Thank you so much Argun. This was really helpful. "This reads like you are sending background notifications and expecting the app to be launched in response". That's not our case. In our logs, we saw a "410 - unregistered" for a token and then later saw the app re-issuing the same token to us again. I thought it was due to the app temporarily marking the token as unregistered. (1/2)

Just wanted to follow up on this.

Thanks. If we didn't include the indicator, then would things break? or are we somehow able to retrieve if a Live Activity event was emitted from server vs device? I'm saying this, because so far things have worked fine for us on iOS 18 (in dev env) — without sending this field.

Thanks Rico. I only used Live Activity and Core Location as 'examples' to explain my question. The heart of my question is: “if some observation triggers an app launch. Should the app launch also re-do the observation immediately so the newly launched process is again subscribed to things it needs?” If so then architecturally how should that be? The case of push-to-start token is a fairly simple case. Wondering what you should for app launches in background for CoreBluetooth / CoreLocation

should deleting and then re-installing the app reset things?

@Sumbo when app is launched, you get the token. Send it to the server. Then any time else when the token is updated, then whether app is in foreground or background, again update your server with the newer token. Once you do this, this means server 'always' has the updated the token — before it sends a live activity notification to app.