I am building a personal iPhone prototype with an on-screen record platter. Before enrolling in the Apple Developer Program or developing the Apple Music integration further, I would like to establish whether the core interaction is supported by public APIs. The intended interaction is: Tap the platter to play or pause an Apple Music subscription song. Hold the platter to stop playback at its current position. Move the platter forward or backward to control the direction and speed of audible playback continuously. Change pitch together with speed, like a physical record, rather than preserving the original pitch. Release the platter to smoothly return to normal playback. Hold a separate control to listen continuously at a faster speed. A prototype using an AVAudioEngine-based renderer works with unprotected local audio. I have NOT verified these behaviors with Apple Music subscription content. I understand that this local renderer does not establish feasibility for MusicKit, and I am not seeking to extract protected audio or bypass content protection. MusicPlayer.State.playbackRate is documented as settable, with positive values for forward playback and negative values for reverse playback: https://developer.apple.com/documentation/musickit/musicplayer/state-swift.class/playbackrate For ApplicationMusicPlayer on iOS, is this vinyl-style interaction supported for full Apple Music subscription songs, rather than previews or user-owned unprotected files? In particular: What playback-rate range is supported for subscription songs? Do negative rates produce audible reverse playback, and how should zero-speed holding be implemented? Is there a documented public API to make pitch follow playback speed, or to disable pitch preservation? Are frequent rate and direction changes supported for interactive scratching? Are there documented limitations on update frequency, buffering, seeking precision or responsiveness? If this interaction is outside public MusicKit capabilities, is there an official channel where an individual developer can ask about eligibility for an approved Apple Music DJ integration? I am asking for the supported API path and its limitations, not implementation details of another app. If only ordinary variable-speed playback or seeking is supported, a clear distinction from continuous vinyl-style scratching would be very helpful. The initial goal is personal use; possible App Store distribution is undecided. I have an active Apple Music subscription but am not currently enrolled in the paid Apple Developer Program. Thank you.

For an AUv3 plug-in of type kAudioUnitType_MIDIProcessor how is the plug-in supposed to figure out the sample rate of the host? I think this might be an API limitation. For instruments and effects, we can read the AUAudioUnit's output bus format and check the sample rate. But MIDI FX plug-ins have no audio I/O. And even if I set them, Logic Pro, for example, doesn't update the AU if I change the sample rate in Logic. Looking at AVAudioSession.sharedInstance.sampleRate doesn't work either, because the host can have a different sample rate from the hardware. Is there a solution to this that I'm not aware of?

I'm building a podcast app (AVPlayer, .playback + .spokenAudio). When the user asks Siri a non-media question, such as "What is the capital of France?", our audio pauses as expected. But the interruption-ended notification with .shouldResume, and on iOS 27 the resumption recommendation, arrive only when the user dismisses Siri's answer card. If the card is left up, we stay paused indefinitely. Under the same conditions (same device, same question, card left up), these apps resume within a few seconds while the card is still visible: Apple Music Apple Podcasts Pocket Casts (its log shows interruption-ended with shouldResume 3–7 s after began) Overcast Our app, installed through TestFlight, and a minimal AVPlayer sample both wait for dismissal. What we've ruled out (each changed one variable, no effect): Mode .spokenAudio vs .default (with .default, playback continues but stays ducked until dismissal) Route-sharing policy .longFormAudio vs .default AVPlayer vs AVAudioEngine Calling pause() on interruption vs letting AVPlayer pause itself Now Playing registration on or off Calling setActive(false) 5 s after the interruption began SiriKit: Siri capability plus in-app INPlayMediaIntent handling (Siri found the app and started playback through our handler; no change) Our app responds within 0.05 s once the signal arrives, so the delay is entirely in delivery. AVAudioSession.promptStyle reads .short from Siri's answer until dismissal, then returns to .normal at the same moment our end notification arrives. Seen on iPhone with iOS 27.0 and 27.0.1, and on iPad with iPadOS 26.6, so it isn't new in iOS 27. Questions: What determines whether an interrupted session receives interruption-ended while Siri's answer card is still visible? Is this related to App Store vs TestFlight/development distribution, or is there something an app needs to adopt? A focused sample project is available. I also have an open DTS case on this.

Hello, I am an undergraduate student working on a non-commercial university capstone project. I would like to clarify whether it is permitted to: Temporarily stream the 30-second preview audio provided through the iTunes Search API and process it in memory using the Essentia audio analysis library to extract numerical audio features. Store only the extracted numerical audio features (such as BPM, key, energy, and timbre) in a database, while immediately discarding the original preview audio after analysis. Could you please confirm whether this use of the previewUrl is permitted under Apple's terms and guidelines? Thank you.

My App announces a place name aloud via AVSpeechSynthesizer (through expo-speech) while a background location task detects the user has entered a new town. This works correctly in the foreground. In the background, with the device screen locked, speech that has already started reliably pauses mid-utterance the moment the screen locks, and resumes and completes the moment the screen is unlocked — even though: The app has UIBackgroundModes: ['audio', 'location'] declared. A genuinely active, native-confirmed AVAudioSession is already running continuously in the background (a looping AVAudioPlayer via expo-audio, separate from the speech itself). AVSpeechSynthesizer.usesApplicationAudioSession is at its default (true), so the synthesizer shares that same active session rather than managing its own. This is not a crash, and AVSpeechSynthesizer never reports onError, the utterance simply stalls and then continues later, which looks exactly like a pause/resume cycle tied to the screen lock event itself rather than any audio session interruption we can detect. What is implemented app.config.js declares the audio and location background modes, and expo-audio's config plugin with enableBackgroundPlayback: true. At app launch, expo-audio's setAudioModeAsync is called once with: { playsInSilentMode: true, shouldPlayInBackground: true, interruptionMode: 'duckOthers' } (We also tested interruptionMode: 'doNotMix' see below.) For the duration of a tracked journey, a silent/near-silent AVAudioPlayer-backed loop is started via expo-audio's createAudioPlayer(), specifically so the app has genuine continuous audio output (not just a configured session) for the whole background session. The player is also registered as the active Now Playing session via setActiveForLockScreen() (expo-audio's wrapper around MPNowPlayingInfoCenter / MPRemoteCommandCenter). When a new place is detected (from a background expo-location task), we call Speech.speak() with the place name. onStart, onDone, onStopped, and onError callbacks are all logged for diagnostics. 5. We listen to the player's native playbackStatusUpdate event to know, from real OS-reported status (not just "the .play() call didn't throw"), whether the keep-alive loop is actually playing. Observed behavior: field test evidence Device log example (stationary repeated test): 08:29:01.948 onStart 08:29:02.092 keep-alive loop confirmed playing (native status) 08:29:07.666 onDone That's a 5.7s onStart-to-onDone gap for a phrase that normally takes under 2s — consistent with the utterance pausing mid-speech when the screen locked, then resuming on unlock. A separate test that stayed unlocked completed the same kind of phrase in 1.9s. On a real 68-minute drive, locked cycles showed 9.4-12.5s gaps; some builds with more aggressive session-reactivation never completed at all (onStart with no onDone/onStopped/onError). Throughout, the background AVAudioPlayer loop's native status still reports playing: true, and Control Center shows the app as Now Playing. So the AVAudioSession is confirmably alive — only the speech utterance itself stalls on lock. What we've ruled out: usesApplicationAudioSession already defaults to true (confirmed via WWDC 2020 session 10022), the synthesizer already shares our configured session, this isn't a missing option. Tried both doNotMix and duckOthers interruption modes. Neither stops the pause-on-lock. duckOthers additionally stops the app showing as Now Playing in Control Center (doNotMix does show it). Keep-alive liveness: native playback status confirms the background AVAudioPlayer reaches playing: true within 100-800ms every time — the session itself isn't failing to activate. We can't observe AVAudioSessionInterruptionNotification directly from our React Native audio libraries, only each library's own polled status — so we can't confirm whether a real interruption notification fires at the moment of lock. That's one of our questions below. Questions: Is it expected that AVSpeechSynthesizer, with usesApplicationAudioSession=true and an already-active background AVAudioSession (.playback category, UIBackgroundModes including audio), still pauses an in-progress utterance when the screen locks and resumes on unlock? If so, is there a supported way to prevent that for a navigation/voice-prompt app? Does locking the screen alone generate an AVAudioSessionInterruptionNotification for an app in this configuration, and if so what interruption type is reported? We can't observe this through our current libraries and want to know what native behavior to expect. Apple's "Audio Guidelines By App Type" doc gives two sets of guidance that both partly apply to us: navigation apps (activate the session only when a prompt is needed, deactivate after, use duckOthers) vs. playback apps (don't stream silence to avoid suspension, use a background task instead). Is there a recommended pattern for an app needing short, infrequent spoken prompts to continue through a locked screen, triggered by a background location task rather than continuous media playback?

Apple please put the Walkie-Talkie app back on the WatchOS27 version

When playing TTS on a watchOS 27 device while AirPods or a Bluetooth headset are connected to both the Apple Watch and the iPhone: Playback begins by calling the setActive function of AVAudioSession. A successful response is received, but... ...AVAudioSession.currentRoute.outputs lists only the built-in speaker, with no entry for the Bluetooth headset or earphones. After a brief delay, an AVAudioSession.routeChangeNotification is received, and playback then switches to the AirPods. If TTS is stopped and playback is attempted again: Playback frequently fails. In this state, AVAudioSession.currentRoute.outputs still shows no Bluetooth headset or earphones. However, checking the Bluetooth settings on the Apple Watch confirms that the AirPods or Bluetooth headset are properly connected. If the app is restarted—or if you exit and re-enter the TTS playback screen—the first attempt succeeds (albeit with a delay), but subsequent attempts after stopping fail. Sometimes, playback fails right from the start. Even in this case, the AirPods remain properly connected. The issue is resolved if the AirPods are disconnected from the iPhone and connected solely to the Apple Watch. When connected only to the watch, AVAudioSession.currentRoute.outputs correctly includes the Bluetooth headset or earphones from the start, and playback issues do not occur when repeatedly stopping and restarting. Playback worked fine with simultaneous Bluetooth connections up to watchOS 26, but a strange issue has started occurring since watchOS 27. We suspect this is a bug or error introduced in watchOS 27; could you please fix it? The same issue persists even after the recent update to version 27.0.1. Alternatively, please let us know if there is a way to resolve this within the app itself. It seems impossible to fix this in the current code because there is no way to programmatically trigger a popup on the Apple Watch that forces the selection of a currently connected Bluetooth headset or AirPods. Also, it does not appear to be an issue with the TTS API.

I am testing a native Swift iPhone app that adds synthesized speech to an existing cellular call using: AVAudioApplication microphone injection permission AVAudioSession.setPreferredMicrophoneInjectionMode(.spokenAudio) AVSpeechSynthesizer CXCallObserver The audio background mode Device: iPhone 16 Pro Carrier: Vodafone Romania iOS version: [enter exact version] Both the system “Add Audio in Calls” setting and the app permission are enabled. Confirmed behavior: With the app in the foreground, the iPhone’s accessibility Auto-Answer Calls feature answers the call, and the remote caller hears the synthesized greeting. Problem: With the iPhone locked, the phone answers automatically, but the greeting does not start. Logs show ringing, connected, and ended events being processed together when the app returns to the foreground. This suggests the app was suspended. The app does not record the call or play continuous audio while waiting. Questions: Is there a supported public API that lets this app wake or execute when a cellular call connects while the iPhone is locked? Can microphone injection support this use case without keeping the app in the foreground? If supported, what audio-session configuration and background execution mechanism should be used? If unsupported, can you confirm this limitation? I can provide a minimal sample project and diagnostic logs.

Android App Compatibility This app isn't 16 KB compatible. RELRO alignment check failed. This warning is showing because this is a debuggable app which is currently being tested. If you are not the developer, please report this to the developer and ask for a non-debuggable pp. This app isn't 16 KB compatible. Please follow the steps on https://developer .android.com/16kb-page-size. The following libraries are not 16 KB aligned: • lib/arm64-v8a/libappleMusicSDK.so : RELRO segment not aligned

Hello, I'm building an iOS music quiz game. Players hear a song and answer a question about it, so the song itself is the content of the question, never background music. Each answer screen names the song and links to it on Apple Music. Non-subscribers would hear the catalog 30-second previews, and Apple Music subscribers the full songs through MusicKit (ApplicationMusicPlayer, with standard playback controls). Guideline 5.2.5 says previews "may not be used for their entertainment value (e.g. as the soundtrack to a game)", and the MusicKit terms say not to monetize access to Apple Music. Two questions: Is a preview that is the subject of a quiz question (not a soundtrack) an acceptable use for non-subscribers? Can such a game be a paid app or offer In-App Purchases, as long as the music is only previews or the player's own subscription? Any pointer to the right documentation or team would be appreciated. Thank you!

Hello, I’m evaluating a possible MusicKit integration and would like to clarify whether the following use is permitted. With the user’s explicit and revocable consent, our iOS app would read the song currently playing in Apple Music while our app is active and display the song title and artist to other users of our application. Our app would not play, stream, host, download or redistribute Apple Music audio. Music playback would remain entirely within Apple Music. When our app is closed, it would stop accessing Apple Music. The last synchronized song may remain displayed until the user opens our app again, at which point the currently playing song would be refreshed. If a displayed song is tapped, the user would be redirected to Apple Music. We are happy to follow Apple’s required formatting, attribution and linking rules. Album artwork is not required and can be omitted if necessary. The Apple Music functionality itself would remain free. Any monetization would relate only to separate features of the application. Could someone clarify: Is this use permitted under the MusicKit / Apple Music requirements? May the current song title and artist be displayed to other users in this way? Which official Apple framework/API is recommended for detecting the song currently playing in Apple Music while our app is active? Are there specific attribution or linking requirements for this use? Thank you.

Since iPadOS 27, the 3.5 mm headphone output on iPad (9th generation) is 2.4 to 4.5 dB quieter than on iPadOS 26, depending on frequency, with the same content, system volume and headphones. It's still present in iPadOS 27.2 beta 2 (24B5089g). It isn't app-specific. It reproduces in Safari: Connect wired headphones to the 3.5 mm jack and set system volume to 100%. Open https://www.szynalski.com/tone-generator/, set 3000 Hz, set the generator volume to 50%, and play. Measure with a sound level meter. At 3 kHz we see 2.5 to 2.9 dB less on iPadOS 27 than on iPadOS 26, across three different headphone models. Audio settings are identical between the two OS versions and Bluetooth is off. The only session-level difference we found is AVAudioSession.outputLatency, which went from 97 to 65 frames. Filed as FB24980117.

HDMI and DisplayPort audio devices expose no kAudioDevicePropertyVolumeScalar or kAudioDevicePropertyMute, so System Settings disables the volume slider and the media keys do nothing when such a display is the default output. Users end up installing virtual audio drivers or DDC/CI tools, and DDC does not pass through many HDMI paths at all. I wanted to check whether the behavior users expect can be provided with public API only, and it can: AudioHardwareCreateProcessTap with a CATapDescription that excludes the app's own process and uses CATapMutedWhenTapped, a private aggregate device with the tap as a sub-tap and the display as the main sub-device, and an IOProc that scales the tap input into the device output. The volume keys are captured with a session-level CGEvent tap. Source (three files, Swift and Objective-C): https://github.com/mevlut-geredeli/MonitorKeys Observations that may be useful to others using taps: The tap delivers IOProc callbacks only while some process is rendering; at idle there are none. That is expected, not a failure. Two process taps on the same device from different processes interfere with each other: AudioDeviceStart blocks until the other tap is torn down. The path works inside the App Sandbox with com.apple.security.device.audio-input; no microphone usage string is required for a tap. Since this is achievable in software, I filed FB24965962 requesting a per-device "control volume in software" option for these outputs, which would remove the need for the tap, the system audio permission and the Accessibility permission. If a Core Audio engineer can comment on whether that is a reasonable direction, I would be glad to test a seed build with this display (ViewSonic VX3276-QHD over HDMI, Mac mini M6, macOS 27.0 26A428).

Hello Apple, please bring back a feature called: “Walkie-Talkie”, To WatchOS27. That feature is convenient, it allows close family members and friends to communicate in a really fun way. Sincerely, Beny74

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

Team, I am trying to start PictureInPicture for my video from custom player as mentioned in the following link, but I am getting an error Steps: Created a player using AVPlayer. Initiated AVPictureInPictureController with AVPlayerLayer Added observer on PIP button enable status When PIP button is tapped executed pipController.startPictureInPicture() statement. PIP is not getting started & getting following error Project created in Xcode11 & currently using Xcode13.2 Error Domain=AVKitErrorDomain Code=-1001 "Failed to start picture in picture." UserInfo={NSLocalizedDescription=Failed to start picture in picture., NSLocalizedFailureReason=The UIScene for the content source has an activation state other than UISceneActivationStateForegroundActive, which is not allowed.} I didn't get any solutions online, plz help me on this issue. FYI: PIP button/mode is working if I use AVPlayerViewController(with default playerItem buttons) instead of AVPlayer & AVPictureInPictureController with custom controls Thanks in advance. Adopting Picture in Picture in a Custom Player

Hi everyone, I'm building Sidetick, a concert ticketing and cultural discovery platform. I have an active Apple Developer Program account with MusicKit access. I want to implement the following flow and need to know if it complies with the MusicKit License Agreement: User authenticates via MusicKit (explicit OAuth consent) We read their heavy-rotation and library/artists in memory We calculate a fan affinity score per artist (e.g. "480 XP with Angèle") — entirely in-memory, never written to our DB We show the user: "We found these artists — which ones do you want to follow on Sidetick?" User explicitly picks their favorites ALL Apple Music API data is immediately deleted from our systems What we store is only the user's Sidetick declaration: {artist: "Angèle", xp: 480} — no Apple Music raw data retained After this, ALL gamification (fan ranking, ticket priority, rewards) is based exclusively on Sidetick first-party actions (ticket purchases, attended concerts, referrals) — zero Apple Music data involved. The intent: MusicKit is used as a one-time discovery bootstrap to help users identify which artists to follow on Sidetick. Apple Music data is never stored, never shared with third parties, never used for advertising. My questions: Is this use case compatible with the MusicKit License Agreement? Is storing the calculated XP score (after deleting the source Apple Music data) considered retaining Apple Music data? Is there a specific clause we should be careful about? Thanks in advance — any Apple engineer or experienced MusicKit dev input is very welcome. =D

Hi, I'm trying to do some realtime audio processing on audio served from an HLS stream (i.e. an AVPlayer created using an M3U HTTP URL). And I find that new APIs(AVPlayerItemSampleBufferOutput) are available in iOS 27.0 to achieve it. However, I failed to get the available data via the AVPlayerItemSampleBufferOutputDelegate. And I found some error in the system log: I create AVPlayerItemSampleBufferOutput and set the delegate after receiving the AVPlayerItemStatusReadyToPlay event. And here's my code: @interface OCAudioSamplebuffer () <AVPlayerItemSampleBufferOutputDelegate> @property (nonatomic, strong) AVPlayerItemSampleBufferOutput *bufferOutput; @property (nonatomic, strong) dispatch_queue_t bufferOutputQueue; @property (nonatomic, strong) AVPlayerItem *playerItem; @end - (void)playItem:(AVPlayerItem *)item { if (@available(iOS 27, *)) { AVAudioSession *audioSession = [AVAudioSession sharedInstance]; if([NSThread mainThread]){ [audioSession setCategory:AVAudioSessionCategoryPlayback withOptions:AVAudioSessionCategoryPlayback error:nil]; [audioSession setActive:YES error:nil]; }else{ dispatch_async(dispatch_get_main_queue(), ^{ [audioSession setCategory:AVAudioSessionCategoryPlayback withOptions:AVAudioSessionCategoryPlayback error:nil]; [audioSession setActive:YES error:nil]; }); } AVPlayerItemSampleBufferOutputAudioConfiguration *cfg = [[AVPlayerItemSampleBufferOutputAudioConfiguration alloc] init]; CMFormatDescriptionRef formatDescription = [self createPCMFormatDescriptionWithSampleRate:44100.0 channels:2 isFloat:YES]; cfg.requestedAudioFormat = formatDescription; if (formatDescription) { NSLog(@"create PCM Format Description success"); CFRelease(formatDescription); } else { NSLog(@"fail to create PCM Format Description"); } self.bufferOutput = [[AVPlayerItemSampleBufferOutput alloc] initWithConfiguration:cfg]; NSLog(@"create buffer success, PCM Format Description%@---,%@", cfg.requestedAudioFormat, formatDescription); self.bufferOutputQueue = dispatch_queue_create("audioSamplebufferQueue", DISPATCH_QUEUE_CONCURRENT); [self.bufferOutput setDelegate:self queue:self.bufferOutputQueue]; [item addOutput:self.bufferOutput]; self.playerItem = item; } else { // Fallback on earlier versions } } Any help. Thank you

I have a product that relies on the Apple Music API's "recently played tracks" endpoint. Recently, a few users are reporting that there are songs missing from their history. I was able to observe this myself—the issue corrected itself after re-authenticating with Apple Music, but unfortunately for at least one user this is not helping in their case. What's odd is that there is some inconsistency about what shows in the recently played tracks endpoint. Some examples My own account: ✅ Music from my playlists ✅ Albums and singles ✅ Apple editorial playlists ❌ Playlists created by other users User 1: ❌ Music from their playlists ✅ Albums and singles ❌ Apple editorial playlists ❌ Playlists created by other users In most cases, all four of these would appear in the recent tracks API. What could cause these tracks to be missing from the listening history endpoint? Listening history is already enabled for the devices they're using, but the songs are appearing inconsistently.

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.