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: 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)? 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? 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)?

I'm implementing the new NowPlaying framework's remote-session push-to-start flow (per Publishing remote media sessions) to show a Sonos-like remote speaker's playback on the Lock Screen/Control Center without requiring my app to be running. The docs say: Your server can start, update, or end sessions when your app isn't running. Use this approach when playback starts from a remote device without someone opening your app. That section never mentions requestToBecomeSystemPrimary() — that's only documented under "Start and update sessions from your app," with a note that it's a no-op unless the app is foregrounded. In my testing, though, a session created purely via a push-to-start "event":"start" push never shows up anywhere in system UI (not Control Center, not the Lock Screen) until I open the app at least once. The mechanism itself works correctly — RemoteMediaSessionExtension.session(_:) fires reliably, decodes the attributes correctly, and returns a valid RemoteMediaSessionRepresentable (confirmed via on-device logging: no errors, clean construction every time, across dozens of test pushes). It just isn't surfaced. To rule out anything on my end, I've tested: Sending via my own server (correct apns-topic/apns-push-type headers, confirmed working via HTTP/2 200 and correct decode) Sending via the Push Notifications Console directly, with Environment explicitly set to Production (my push-to-start token only validates against production, matching the known dev-signed-token-provisions-against-production quirk) A hand-built, minimal, fully valid payload for a completely fresh, never-before-registered session id Every combination produces a correctly-constructed session that's invisible until the app opens — at which point my own app code (unrelated to the push) independently constructs and promotes its own session via RemoteMediaSession.start() + requestToBecomeSystemPrimary() in the foreground. Has anyone gotten a push-to-start session to actually appear on the Lock Screen/Control Center without opening the app first? Is there an additional step beyond what's in the current docs (some other registration, entitlement, or timing requirement) that's needed for that, or is this expected behavior right now and the docs are ahead of the implementation? FB24876585 filed on Feedback Assistant with app logs attached.