RemoteMediaSessionExtension: Lock Screen / Dynamic Island occasionally fail to redraw mid-track; only recovers at the next track change or by foregrounding the app

I'm seeing an intermittent split between how different Now Playing surfaces reconcile with a RemoteMediaSessionExtension (the iOS 27 com.apple.nowplaying.remote-media extension point). Control Center and Apple Watch reliably show the current track. The Lock Screen and Dynamic Island occasionally get stuck on the previous track for the remainder of that track. They'll often self-correct once the next track change happens — but not always and never mid-track. The only way to fix it before the track ends is to bring the host app to the foreground.

Setup: the extension receives APNs pushes carrying playback/metadata payloads from a third-party speaker system. Each push either resumes an already-alive extension process (update(:)) or cold-starts it (session(:)), which sets content/the Artwork provider closure and returns. All three surfaces read from that exact same synchronous content value — there is no code path in the extension that could serve them differently.

Cleanest isolated repro on record (device log timestamps): one track was displaying correctly everywhere. The next track triggered a cold start; the extension decoded the push, resolved and prefetched real artwork, and had content fully populated within under a second. Moments later, that cached artwork was requested and served at Control Center's own request sizes, and Control Center updated correctly. Lock Screen and Dynamic Island made zero requests of any kind — no content query, no artwork fetch — for the entire remainder of that track.

This doesn’t appear to be a problem with the apns pushes, I can see from my server that they are successfully sent and Control Center updates correctly but lockscreen and Dynamic Island do not.

I tried reducing the artwork size as a test to see if this worked more reliably, but still faced similar issues.

Apple Watch remains a consistently-correct surface alongside Control Center, reinforcing that this is isolated to whatever presentation machinery Lock Screen and Dynamic Island specifically share.

Ruled out on my side: • Push delivery/decoding — the extension's own receive-time debug dump shows the correct decoded attributes before any surface renders. • Process suspension — this has been observed with the extension actively running throughout, proven by Control Center rendering fresh data from it during the same window.

Questions:

  1. Is there a known issue where Lock Screen/Dynamic Island stop re-querying a RemoteMediaSessionExtension's content mid-track, after it's already been correctly delivered and rendered elsewhere (Control Center, Watch)?
  2. Is Lock Screen/Dynamic Island's own redraw path gated on the app process being foreground, similar to requestToBecomeSystemPrimary()'s documented foreground-only effect? If so, is there any supported way to trigger that reconciliation from a background extension update, short of the user opening the app?
  3. Is there a supported way to force-invalidate/redraw Lock Screen's and Dynamic Island's cached presentation for an existing session, without ending and restarting it (which would reset the user's Lock Screen state)?
RemoteMediaSessionExtension: Lock Screen / Dynamic Island occasionally fail to redraw mid-track; only recovers at the next track change or by foregrounding the app
 
 
Q