Live Activity Stops Updating after iPhone Lock

I’m going to start you out with a pointer to this thread. Please read it through and reply here if you have follow-up questions.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for the pointer, Quinn, but I'm afraid that doesn't answer my question. My app is using the "background audio mode" and successfully running in the background both when the device is unlocked & when it's locked. (I know it's running in the background because I can hear the audio it generates and see new statements in the log)

The problem is, even though my app is running in the background and pushing live activity content updates, iOS stops updating content after the screen is locked and doesn't resume until the user opens the app in the foreground. (Again, the app is running, generating audio, and log statements continually - it's ONLY the live activity that stops updating)

Below is the method I'm using to update the live activity:

	fileprivate func updateLiveActivity(liveActivity:ActivityKit.Activity<LiveActivityAttributes>, contentState:LiveActivityAttributes.ContentState){
		log.debug("LiveActivityManager.updateLiveActivity() with new ContentState")
		Task{
			await liveActivity.update( ActivityContent(state:contentState, staleDate:nil) )
		}
	}

A shown in the log above, I normally see my log.debug message immediately followed by an iOS generated "Updating content for activity <UUID>" message, but the iOS update message only updates once after the protectedDataWillBecomeUnavailableNotification, so my live activity display is out of date until the user returns my app to the foreground.

Thanks for the clarification. Sadly, I’ve reached the end of my Live Activities expertise )-: We’ll have to see if someone with more experience chimes in.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Apps using the background audio mode with the common audio modes cannot actually update live activites; an update silently fails; they do not update nor do they throw an error.

This is mentioned in this thread: https://developer.apple.com/forums/thread/716458 and I have confimed the behavior. This is contrary to the documentation which implies any backgrounded app can update the activity, and has wasted a lot of peoples' time, especially since it doesn't throw an error, it just doesn't work.

Workarounds would be to use an unnecessary background mode like location, or spam push notifications which will update the live activity widget as long as the user receives them.

APNs with frequent updates enabled is the supported way to update a Live Activity that needs a lot of updates. Other background types can allow for more frequent updates, but this behavior is not explicitly supported.

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:

1. 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?

2. 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.

3. 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).

How often are you trying to update your live activity?

We purposely discourage and throttle update frequencies similar to a now playing experience in Live Activities, which you generally can achieve with a Widget. The behavior for Widgets and Live Activities with background audio is not 1:1. You can plug your device into Console.app and monitor various processes related to your Live Activity to see why the system is not taking to your update requests, but usually priority and budget matter the most here.

Another consideration with updating from your app to your Live Activity is that your LA is actually tied to the system (Lock Screen, Springboard) so those processes also have a say in whether an update takes place, independent from your app's request.

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.