The docs are conflicting. https://developer.apple.com/documentation/activitykit/starting-and-updating-live-activities-with-activitykit-push-notifications#End-the-Live-Activity-with-a-custom-dismissal-date says: When you end a Live Activity, by default the Live Activity appears on the Lock Screen for up to four hours after it ends to allow people to glance at their phone to refer to the latest information. However here it says: https://developer.apple.com/documentation/activitykit/displaying-live-data-with-live-activities#Understand-constraints A Live Activity can be active for up to eight hours unless its app or a person ends it before this limit. After the eight-hour limit, the system automatically ends the Live Activity, and immediately removes it from the Dynamic Island. However, the Live Activity remains on the Lock Screen until a person removes it or for up to four additional hours before the system removes it — whichever comes first. As a result, a Live Activity remains on the Lock Screen for a maximum of 12 hours. So is it 4 hrs OR '8 for Dynamic Island vs 12 for Lock Screen'?

I'm struggling to understand what the impact of this flag is. Docs only say: For devices running iOS 18 and iPadOS 18 or later, you can add input-push-token: 1 to your payload to start a Live Activity and receive a new push token. After you receive a new push token, you can use it to send updates to a Live Activity. But things were working fine for iOS 17. Right? Does it somehow make the OS emit update tokens faster/more successfully? Should I include in all start, update, end events?

I'm specifically focused on Live Activity, but I think this is somewhat a general question. The app could get a few callbacks when: There's a new payload (start, update, end) There's a new token (start, update) There's some other lifecycle event (stale, dismissed) Assuming that the user didn't force kill the app, would the app get launched in all these scenarios? When OS launches the app for a reason, should we wrap our tasks with beginBackgroundTask or that's unnecessary if we're expecting our tasks to finish within 30 seconds? Or the OS may sometimes be under stress and give you far less time (example 3 seconds) and if you're in slow internet, then adding beginBackgroundTask may actually come in handy?

Can you please post the sample code?

I've been reading this question: https://developer.apple.com/forums/thread/701945 and watching the videos on background tasks But can't arrive to a concrete solution. Q1: Are there any tips (or sample app) on how to handle a launch in background in a streamlined way? How to have a shared code that is ran for both 'launch in background' & 'launch in foreground'? Specifically the case I'm talking about is: You set up some observance of some OS callback at a Foo screen of your app. Example app should request and then send push-to-start live activity tokens to server. Or setup location tracking. App is then suspended and then later terminated but is eligible for relaunch App is then launched in background because it has requested a push-to-start live activity token or an update for location tracking. User DOES NOT go back to screen Foo. So at this point app is no longer tracking / listening to updates for token update or location changes. How should I architecture my code for this? I'm trying to see if there's a an approach where I can avoid having multiple places in code where I do the same thing. Currently what I'm doing is as such: Q2: Is it then correct to say that anytime you've launched your app, whether it's in foreground or background then you must immediately match 'all observations done by the previous app launch'? Like store items in UserDefaults and upon launch retrieve them and do: handleGeneralAppLaunchFlow() // ALSO if defaults.contains("didLastLaunchSetupLiveActivtiyTokenObservance") { for await ptsToken in Activity<EmojiRangers> .pushToStartTokenUpdates { ... } } if defaults.contains("didLastLaunchSetupLocationTracking") { locationManager = CLLocationManager() locationManager?.delegate = itsDelegate locationManager?.allowsBackgroundLocationUpdates = true locationManager?.showsBackgroundLocationIndicator = true locationManager?.startUpdatingLocation() } // Other checks for prior observance setup Q3: Actually I think even if app is launched in foreground then because you may not end up at screen Foo again, then you must setup things regardless of app state and just based on prior observations set. Right? Q4: And then later if the user ever made it again to screen Foo, then we just skip the re-do of the observance, or maybe to just keep things simple, we'd just redo without over-engineering things? I tried to mark my questions with Q1- Q4.

Confusion Based on the fact that the subscription is requested on a Activity type, I assumed that the push-to-start tokens would be different. But the push-to-start token for WidgetExtensionAttributes and WidgetExtensionAttributesOther were identical. This is misleading. The code below prints identical tokens even though the name of the token and their underlying schema are different. Code Sample func getTokens() { Task { if let data = Activity<func getTokens() { Task { if let data = Activity<WidgetExtensionAttributes>.pushToStartToken { print("exists:", data.hexadecimalString) } else { print("requesting pushToStartToken") for await ptsToken in Activity<WidgetExtensionAttributes> .pushToStartTokenUpdates { let ptsTokenString = ptsToken.hexadecimalString print("new:", ptsTokenString) } } } Task { if let data = Activity<WidgetExtensionAttributesOther>.pushToStartToken { print("other exists:", data.hexadecimalString) } else { print("other requesting pushToStartToken") for await ptsToken in Activity<WidgetExtensionAttributesOther> .pushToStartTokenUpdates { let ptsTokenString = ptsToken.hexadecimalString print("other new:", ptsTokenString) } } } }>.pushToStartToken { print("exists:", data.hexadecimalString) } else { print("requesting pushToStartToken") for await ptsToken in Activity<WidgetExtensionAttributes> .pushToStartTokenUpdates { let ptsTokenString = ptsToken.hexadecimalString print("new:", ptsTokenString) } } } Task { if let data = Activity<WidgetExtensionAttributesOther>.pushToStartToken { print("other exists:", data.hexadecimalString) } else { print("other requesting pushToStartToken") for await ptsToken in Activity<WidgetExtensionAttributesOther> .pushToStartTokenUpdates { let ptsTokenString = ptsToken.hexadecimalString print("other new:", ptsTokenString) } } } } Activity Types struct WidgetExtensionAttributesOther: ActivityAttributes { public struct ContentState: Codable, Hashable { var age: Int } var addresses: [String] } struct WidgetExtensionAttributes: ActivityAttributes { public struct ContentState: Codable, Hashable { var emoji: String } var name: String } Docs After much investigation I noticed the wording of the docs kind of hint that the push-to-start token is per ActivityKit as it says: An asynchronous sequence you use to observe changes to the token for starting a Live Activity with an ActivityKit push notification. But docs and the API don't align well. Questions Is it correct that the push-to-start token is per app? If so then is there a reason that that API designers decided to still have to pass a specific type and not just make a request without passing a type? Should I maybe file a radar? Is it correct to say push-to-start is per app, while update tokens are per instance. i.e. if I have two soccer matches, then unless the push-to-start token was refreshed by the OS, then both would use the same push-to-start token, however each match would have a unique update token?

I'm currently seeing that OS gets a new push-to-start token immediately after receiving the first notification. Should my server immediately invalidate the push-to-start token upon usage? Or invalidating the push-to-start token should only be done if my iOS device gets a new one and then I have to send it back to my server.

I know for start events, sending the timestamp isn't required. So that's easy. However when I'm testing Live Activity using the Apple Push Notification Console. A lot of times I just need to copy/paste the payload and resend it again. But then the timestamp field needs to get updated each time, because if it's from a time in the past, then it won't trigger. This requires me to have to use an EPOCH converter to find the right time and then copy/paste it. Is there a better solution to this? I know I can use curl, but that is not in the scope of my question.

For our Live Activity Tokens, when we fire a payload, often apns is returning a response of 410 unregistered. Docs are saying: The device token is inactive for the specified topic. There is no need to send further pushes to the same device token, unless your application retrieves the same device token, refer to Registering your app with APNs Questions: Why does this happen? Does it only happen because the user changed their permission? Or there are other reasons? And when it does happen, what should we do about it? A. Should we keep the token on the server? Because perhaps the user will change their permission and the token becomes valid? That could leave us with lots of invalid tokens and us firing at them unnecessarily. Docs do say: Don’t retry notification responses with the error code BadDeviceToken, DeviceTokenNotForTopic, Forbidden, ExpiredToken, Unregistered, or PayloadTooLarge. B. Or should we remove the token from the server? That then requires app to re-register the token. But the problem with that is: When I went into App's settings from OS settings and toggled push notifications to on, the app was not launched into the background nor killed i.e. it requires explicit app launch by the user to re-register itself which isn't ideal... It means a user may turn on notifications from the OS settings and then assume that their push notifications should be back in business, but that won't happen if you toggle things from OS settings.

Having some discussion about when we should clear out a token from our servers. Docs say: Don’t retry notification responses with the error code BadDeviceToken, DeviceTokenNotForTopic, Forbidden, ExpiredToken, Unregistered, or PayloadTooLarge. You can retry with a delay, if you get the error code TooManyRequests. The way I see it is that with the exception of PayloadTooLarge, all other errors means you should remove the token from your server. Either because: The token is no longer good The token is good, but this is just not the right: environment (sandbox vs production) topic (the token is from a different bundle id or developer team) target (app vs live activity appex) Do I have it right? Extra context: when using the "JSON Web Token Validator" tool, a colleague reported that a 410 -Expired token (from couple days back) was still valid today. This raises questions about when tokens should actually be deleted and how these error codes should be interpreted. Also is it possible for the docs to get updated for us to explicitly know if a token should get removed and not leave it for interpretation?

I tried dragging an apns file for a live activity into my simulator to begin a Live Activity. It didn't do anything. I didn't see it mentioned in the wwdc videos either. So I'm wondering if this experience is not yet developed, or maybe I'm doing something incorrectly?

I have an ongoing activity in progress. Think of: a delivery in progress house internet reboot in progress some water / electricity / internet / tv outage. (food) order processing I want to show a persistent toast message above the tab bar, across all tabs and screens across the app. It could take 15 minutes until the activity is finished. Obviously there's a challenge of: accessibility content overlaying with each other extra engineering effort. What we've thought of doing is: Option1: show a toast message, but when a modal is presented then it presents on top of the toast message. The toast message no longer updates itself. Once the modal is finished, then the toast message re-appears and continues to update. Option2: keep the toast message across all tabs and modals and work through the challenges mentioned Question: What are some other design approaches that could be taken to persist an ongoing activity (much like 'Live Activity', but just across the app when it's in foreground) or what are some design reasons that the two options considered are bad?

Watching WWDC video: https://developer.apple.com/videos/play/wwdc2023/10185/?time=481 It says: So when encoding your content state, do not set any custom encoding strategies. Otherwise, your JSON will be mismatched, and the system will fail to update your Live Activity So I'm just wondering if using JSONDecoder is allowed for decoding apps payloads for the UI of a Live Activity? Or is there a performance hit for this?

Q1. Can you place a sound on an end event? That doesn't seem to work for us Additionally: Q2. Is there any way that after you send the end event, still have the Live Activity remain on the Dynamic Island until the dismissal-date? Currently when an end event is sent, it's abruptly ended from the Dynamic Island without any sound. Users are confused until minutes/hours later they see their Lock Screen.

(I truly appreciate all the responses you all have written for me :bow: ) I was under the assumption that for Live Activity, in order for you to be able to update the Activity, you need an update token. And for the OS to issue you the update token, user must hit the "Allow" from the lock screen. However based on these screenshots it seems that you don't need to hit "Allow" to be able to update the Live Activity. Live Activity was updated — even without the user hitting "Allow" So now I'm wondering if: Is hitting Allow required for the update token to get issued? Or that assumption is incorrect? In our tests (when connected to Proxyman, the OS emits the update token after user hits "Allow" / "Always Allow") If you don't hit allow, are there alternate ways to update the Live Activity without having the update token? I'm guessing you could set a short stale time and then when the OS launches the app in the background you query the server and then update the Live Activity. Is that a worthy approach? I also noticed that the "The Philly Inquirer" App has 'Background App Refresh" enabled, but this happened in 2 minutes. In our architecture assessments, after reviewing Apple's docs on 'Background Processing", we didn't think of it as a viable option, because it can't guarantee if the OS is given time in the next 2 minutes or 10 hours later when the phone is getting charged again. Are any of these workarounds viable or are there alternate approaches? Our requirement is: be able to use Live Activity between 2-72hrs after app install. (I mention this because perhaps Apple may impost some restrictions for new installs) be able to update an active Live Activity within 1-2 minutes after it has began.