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-typeheaders, confirmed working viaHTTP/2 200and 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.