Other background types can allow for more frequent updates, but this behavior is not explicitly supported. This contradicts the documentations of the Activity class, which states: The Activity object offers functionality to start, update, and end a Live Activity from within your app. You can update or end a Live Activity while your app is in the background, but you can only start a Live Activity while the app is in the foreground. This is reiterated here, in the Displaying live data with Live Activities documentation: Your app can only start Live Activities while it’s in the foreground. However, you can update or end a Live Activity from your app while it runs in the background — for example, by using Background Tasks. Additionally, you can enable Live Activity updates with ActivityKit push notifications. This makes it sound that background running apps can definitely update Live Activities (and, in addition, push notifications can as well). So some questions: What exactly does "while it runs in the background" in these docs mean, if apps that are using supported background modes cannot update Live Activities? Does the "NSSupportsLiveActivitiesFrequentUpdates" Info.plist key apply only to push notifications? One would assume that it enables local frequent updates, without having to pipe things through push notifications. Is it only audio apps that are exempt from updating Live Activities in the background? It would be great if the docs were explicit about how exactly apps can update live activities in the background, if at all, and what the constraints are, so folks can design within those constraints. Sorry if this comes across as a bit of rant, but I spent a fair bit of effort on something that is basically unlaunchable because the docs, WWDC talks, and the simulator behavior did not match the device behavior (my fault for not testing on device sooner).

Thanks for the Console.app tip. It looks like audio apps are specifically blocked from performing background LA updates: error 00:01:07.480710-0700 liveactivitiesd Process is only playing background media so is forbidden to update activity: 62125 error 00:01:07.480978-0700 liveactivitiesd Client is not permitted to update activity That's unfortunate since it seems like you could build some neat LAs tied to playback experiences (not necessarily now-playing style UIs, but timed activities associated with something the user is doing). This exception should probably be documented in the HIG, so audio app developers don't waste their time trying to build LAs only to find out that they would silently fail. Overall, this doesn't seem related to update frequency but rather the specific background assertion that the app has taken. I'd be curious to understand the rationale for why Apple feels that audio apps wouldn't be good candidates for interesting LAs. I don't think widgets expose the same type of experience as a potentially more dynamic LA on the lock screen.