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.

Thanks I read that and a watched a few wwdc videos. It just seems that if you're going to use BGBackgroundTask then you're not guaranteed to have a 'live-like' experience. Because the update for a 'live' experience is something that should happen within 2s - 20mins. But with BGProcessingTask it could turn out to be 2hrs when device is idle our end of night when device is charged. Or is it that an app that has a Live Activity gets promoted to have sooner and longer background time?

For a framework, once you strip debug symbols, then what else is there left for you to strip? Why is there another flag for STRIP_SWIFT_SYMBOLS? Does STRIP_SWIFT_SYMBOLS only strip non-external symbols? Like if a framework has non-external, then they're not needed for the main app binary. So you can strip them. Does STRIP_SWIFT_SYMBOLS affect the stripping of such non-debug non-external symbols? Like it will strip anything that's marked with internal, private in your Swift module?