I filed FB24725256 with a live macOS Bluetooth diagnostic, Sysdiagnose, and System Information Report. Environment: MacBook Pro (Mac17,6), Apple M5 Max, 128 GB RAM macOS 26.5 (25F71) AirPods Pro 3, firmware 8B41 AirPods selected for both input and output because microphone input is required for dictation and voice typing Problem: Bluetooth playback repeatedly stutters and cuts out during sustained local development and AI-agent workloads. The AirPods signal is strong (roughly -46 to -52 RSSI), and the Mac remains otherwise usable. Unified logs recorded repeated AudioSkywalkReadLoop overwait events in bluetoothd, commonly 50–69 ms and previously up to 795 ms. CoreAudio also reported HALS_OverloadMessage failures because a client exceeded its I/O-cycle budget and a safety violation occurred. Steps to reproduce: Connect AirPods Pro and keep them selected for input and output. Stream audio. Run sustained CPU- and memory-intensive development work, such as multiple builds, browser workloads, simulators, or local AI agents. Observe repeated playback interruptions as CPU load and memory compression increase. Expected: macOS should protect real-time CoreAudio and Bluetooth transport deadlines on this hardware without requiring productive work to be paused or throttled. The same AirPods stream reliably from much smaller Apple devices; Apple's highest-end Mac should maintain audio continuity too. This is a platform-quality failure on a high-end Mac. This appears related to longstanding reports: Simulator/Xcode causing AirPods distortion: https://developer.apple.com/forums/thread/668170 CoreAudio overloads and dropouts associated with memory pressure: https://developer.apple.com/forums/thread/677383 Bluetooth headset interruptions on newer macOS releases: https://developer.apple.com/forums/thread/763848 If you can reproduce this, please boost this thread and file your own Feedback Assistant report with fresh Bluetooth logs and a Sysdiagnose. Include the exact occurrence time and reference FB24725256 so Apple can connect the reports.I filed FB24725256 with a live macOS Bluetooth diagnostic, Sysdiagnose, and System Information Report. Environment: MacBook Pro (Mac17,6), Apple M5 Max, 128 GB RAM macOS 26.5 (25F71) AirPods Pro 3, firmware 8B41 AirPods selected for both input and output because microphone input is required for dictation and voice typing Problem: Bluetooth playback repeatedly stutters and cuts out during sustained local development and AI-agent workloads. The AirPods signal is strong (roughly -46 to -52 RSSI), and the Mac remains otherwise usable. Unified logs recorded repeated AudioSkywalkReadLoop overwait events in bluetoothd, commonly 50–69 ms and previously up to 795 ms. CoreAudio also reported HALS_OverloadMessage failures because a client exceeded its I/O-cycle budget and a safety violation occurred. Steps to reproduce: Connect AirPods Pro and keep them selected for input and output. Stream audio. Run sustained CPU- and memory-intensive development work, such as multiple builds, browser workloads, simulators, or local AI agents. Observe repeated playback interruptions as CPU load and memory compression increase. Expected: macOS should protect real-time CoreAudio and Bluetooth transport deadlines on this hardware without requiring productive work to be paused or throttled. The same AirPods stream reliably from much smaller Apple devices; Apple's highest-end Mac should maintain audio continuity too. This is a platform-quality failure on a high-end Mac. This appears related to longstanding reports: Simulator/Xcode causing AirPods distortion: https://developer.apple.com/forums/thread/668170 CoreAudio overloads and dropouts associated with memory pressure: https://developer.apple.com/forums/thread/677383 Bluetooth headset interruptions on newer macOS releases: https://developer.apple.com/forums/thread/763848 If you can reproduce this, please boost this thread and file your own Feedback Assistant report with fresh Bluetooth logs and a Sysdiagnose. Include the exact occurrence time and reference FB24725256 so Apple can connect the reports.

I’m developing a native visionOS application that uses an external HDMI capture device connected to Apple Vision Pro through the Developer Strap. The goal is to use Apple Vision Pro as a low-latency display for external HDMI sources such as an Xbox Series X, including both the HDMI video and the original digital game audio. My current hardware path is: Xbox Series X → HDMI → Elgato 4K X → USB-C → Apple Vision Pro Developer Strap The Elgato 4K X receives both video and audio from the Xbox over HDMI. What is working UVC video capture is working successfully on visionOS. The external Elgato capture device can be used as the video source and the Xbox video is displayed correctly inside the Vision Pro application. I have also verified the Elgato 4K X independently on macOS, where the device is recognized correctly. The problem I cannot find a supported way on visionOS to access the USB Audio Class (UAC) audio interface associated with the capture device. I specifically need the digital game audio originating from: Xbox HDMI → Elgato 4K X → USB/UAC → visionOS I do not want to use the Apple Vision Pro’s built-in microphone. Selecting/capturing the Vision Pro microphone would only record environmental sound and is not a substitute for the digital HDMI audio stream. Apple’s visionOS documentation for external devices through the Developer Strap appears to focus on UVC video capture. I haven’t been able to determine whether the accompanying UAC interface of a UVC/UAC composite capture device is exposed to visionOS applications. What I’ve tried / verified Connected an Xbox Series X to the HDMI input of an Elgato 4K X. Connected the 4K X to Apple Vision Pro through the Developer Strap. Successfully discovered and received the external UVC video stream. Successfully displayed the Xbox video feed in visionOS. Confirmed that the 4K X itself is recognized and functional on macOS. Attempted to obtain audio corresponding to the external capture source. The Vision Pro microphone is available as an audio source, but this is not the audio source required. I have not found a documented visionOS API that exposes the 4K X’s USB/UAC audio endpoint through the Developer Strap. Questions Does visionOS currently support USB Audio Class input devices connected through the Apple Vision Pro Developer Strap? If a device exposes both UVC video and UAC audio interfaces, is there a supported way to associate/access both interfaces from a visionOS application? If UAC is supported, which framework/API should be used to discover the external audio endpoint — AVFoundation, Core Audio, or another API? Does accessing the UAC interface require an entitlement in addition to UVC device access? If generic UAC access through the Developer Strap is currently unavailable to third-party visionOS applications, is there a restricted/managed entitlement that developers can request? If this isn’t currently supported, what is Apple’s recommended architecture for receiving synchronized video and audio from an HDMI capture device on Apple Vision Pro? Ultimately, I’m trying to achieve: HDMI source → UVC video + UAC audio → visionOS application → video displayed in Vision Pro + audio played through Vision Pro speakers/AirPods Since UVC video from this exact hardware is already working, I’m primarily trying to determine whether access to the accompanying USB audio interface is possible with the current visionOS SDK, requires another entitlement/API, or is currently unsupported. Any guidance from Apple or developers who have worked with composite UVC/UAC devices on Vision Pro would be greatly appreciated.

Good morning! I work on a meditation app, and since Sleep Detection was introduced for AirPods in iOS 26, we've been receiving complaints from users reporting that their meditation sessions unexpectedly stop after approximately 15–20 minutes when Sleep Detection is enabled. This seems to happen particularly during deep meditation sessions, where the user may remain still and exhibit behavior that could potentially be interpreted as falling asleep. I've also tested this on iOS 27 with the latest beta firmware available for AirPods Pro, and the same behavior still occurs. While investigating and debugging the issue, I found that there doesn't appear to be any public API that allows an app to determine that playback was paused specifically because of AirPods Sleep Detection. From the application's perspective, the AirPods appear to simply send a standard pause command to the AVPlayer, without providing any additional context or reason. There also doesn't seem to be an API that allows us to determine whether the user has Sleep Detection enabled. Even having access to that information would allow us to warn users that their meditation session could potentially be interrupted. AVAudioSession.InterruptionReason does not seem to help in this case either: https://developer.apple.com/documentation/avfaudio/avaudiosession/interruptionreason Is there currently any supported way for an app to: Detect that playback was paused specifically because of AirPods Sleep Detection? Determine whether Sleep Detection is enabled for the connected AirPods? Prevent Sleep Detection from pausing playback for specific apps or specific types of audio sessions? If none of these are currently possible, could Apple consider providing either a notification/callback indicating that Sleep Detection triggered the pause, or an option for users to exclude specific apps from Sleep Detection? This behavior is particularly problematic for meditation apps, since a user in a deep meditation session can easily be mistaken for someone who has fallen asleep. Other meditation apps appear to be affected by the same behavior as well. Best regards, Carlos Antunes

Hi, I’m developing an iOS app that captures the user’s voice and sends the microphone input to an AI model for speech processing. For this use case, Voice Isolation provides a significantly better input signal in noisy environments. However, I’m currently unable to enable Voice Isolation programmatically when the app starts recording. As I understand it, microphone modes such as Automatic, Standard, Voice Isolation, and Wide Spectrum are controlled by the user through the system UI. My app can detect/observe the current microphone mode, but I have not found a public API that allows the app to select Voice Isolation itself. My questions are: Is there currently a supported public API to programmatically switch the microphone mode from Automatic/Standard → Voice Isolation? If direct selection is not supported, is there a recommended way for an app that primarily processes speech/voice input for an AI model to request or prefer Voice Isolation? Would using AVAudioSession with an appropriate voice-processing configuration, such as .voiceChat, or enabling voice processing through AVAudioEngine, provide equivalent Voice Isolation processing? Is AVCaptureDevice.showSystemUserInterface(.microphoneModes) the intended approach when an app needs the user to change the microphone mode? I understand that Apple may intentionally keep microphone-mode selection under user control. I’m mainly trying to determine whether there is a supported programmatic approach that I may have overlooked, rather than relying on a custom noise-suppression implementation. Any guidance on the recommended architecture for this use case would be greatly appreciated. Thank you!

Product: Vozzy — custom keyboard + containing app for user-initiated dictation. Bundle: br.com.buddyapps.FlowType App Group: group.br.com.buddyapps.FlowType Flow: User selects our keyboard in a host app (Notes/Messages). Without Full Access, QWERTY input works locally. With Full Access, user taps Microphone to dictate. Containing app owns mic permission, AVAudioSession, capture, SpeechAnalyzer, Foundation Models. Keyboard never captures audio; it reflects shared state and inserts via textDocumentProxy. Already settled (do not re-ask): No public API to identify the host app. No public API to return to the host app. Feedback: FB22247647. Question (single issue): App Review Guideline 4.4.1 says keyboard extensions must not launch apps other than Settings. Is there any public, App-Review-compliant mechanism for a custom keyboard to request its containing app to activate audio capture for this user-initiated dictation flow? If yes: Which public API / App Intent surface? Is a visible switch to the containing app required? May the audio session continue while the user returns to the host app? May Stop/Cancel commands travel through an App Group while the containing app is backgrounded? Our current policy: Launch uses public NSExtensionContext.open (Debug only). Release has no keyboard path that opens the containing app. Release does allow in-place signaling when the app is already resident (App Group command + Darwin notification; launches nothing). We will not enable Release launch without a written answer naming an allowed public mechanism. App Group payload inventory + retention, Full Access-off QWERTY behavior, onboarding privacy copy. I do not have a focused Xcode sample because this is an API / App Review policy question, not a crash or incorrect return value. The keyboard extension never captures audio. Debug uses public NSExtensionContext.open; Release compiles that path out. I can attach flow diagrams and a device screen recording. Related: FB22247647 (return to host — already answered No; not re-asking).

Hi there, I recently launched a dj app to the mac app store, and was wondering how I could access songs for mixing purposes via Apple Music just like how serato, rekordbox, djay, and other DJ apps do? Thanks, Gunek

Hi, I have implemented a custom audio streaming protocol in my iOS app using AVCustomRoutingController to select my custom device. Playback and streaming works. However when the app is the background, it gets killed in a couple of seconds, like if it was not playing audio. My app has the Audio/AirPlay/PIP background mode and can play audio from the background when the route is a normal AVRoute from the system (Speaker/AirPlay/Bluetooth, etc). I tried starting an AVAudioSession (playback category, activated, with and without MPRemoteCommandCenter bindings and with and without populating NowPlayingInfoCenter) was hoping that if that is active, my app won't be killed. But it seems like it does get killed if the app is not producing audio using AudioOutputUnit/AVAudioEngine/AVPlayer. How does one supposed to stream audio from an app in the background using a custom protocol? The infamous "let's play silence to not get killed" solution works, but obviously that can't be the answer.

Is there any supported API for a third party app to access live audio from a call it isn't itself carrying?

If an app allows people to create a playlist and add more songs to that created playlist, it would make sense to guard them from accidentally adding the same song to the playlist more than once. In this code, even though it is successfully receiving the existing playlist from the request, its tracks and entries always show as nil even when there are songs in the playlist. Any suggestions for how to guard against adding duplicates to a playlist? Thank you! var request = MusicLibraryRequest<Playlist>() request.filter(matching: \.name, equalTo: "AppGeneratedPlaylist") let response = try await request.response() if let existingPlaylist = response.items.first { if let tracks = existingPlaylist.entries, tracks.contains(where: { $0.id == song.id }) { print("Song is already in the playlist, so don't add again") return } else { try await MusicLibrary.shared.add(song, to: existingPlaylist) print("Added song to existing playlist: \(existingPlaylist.name)") print("Count of tracks: \(existingPlaylist.tracks?.count)") print("Count of entries: \(existingPlaylist.entries?.count)") print("Current tracks: \(existingPlaylist.tracks?.map(\.id))") print("Current entries: \(existingPlaylist.entries?.map(\.id))") } }

Hello, I am developing a native CarPlay application and would appreciate some clarification regarding AVAudioSession behaviour when using the vehicle microphone. The application is intentionally simple and designed to minimise driver distraction. The user presses a single button on the CarPlay screen, the application performs a brief (approximately five second) audio capture, performs application-specific processing on the captured audio, displays a simple confirmation to the user, and immediately releases the audio session. The goal is to allow the driver to continue their journey with as little interaction as possible. Because the audio being captured is often originating from the vehicle’s native DAB/FM radio rather than from the iPhone itself, preserving the existing listening experience during the brief capture is fundamental to the intended design. To better understand what is supported by CarPlay, I have carried out a number of controlled experiments. Test Environment Native CarPlay application Swift AVFoundation AVAudioSession AVAudioRecorder Vehicle connected via CarPlay Vehicle playing its native DAB radio Experiment 1 Configuration Category: AVAudioSession.Category.playAndRecord Mode: AVAudioSession.Mode.default Observed Route Input: CarPlay — CarAudio Output: CarPlay — CarAudio Result Recording succeeds using the vehicle microphone. Native DAB audio is muted during recording. The vehicle changes from “Audio Volume” to “Voice Volume”. When recording finishes and the AVAudioSession is deactivated, DAB resumes normally. Experiment 2 Changed only the session mode to: AVAudioSession.Mode.measurement Result Behaviour was identical to Experiment 1. Experiment 3 Changed only the session mode to: AVAudioSession.Mode.videoRecording Observed Route Input: iPhone microphone Output: CarPlay — CarAudio Result Input automatically switched from the vehicle microphone to the iPhone microphone. The vehicle remained in normal “Audio Volume”. However, the head unit switched away from its native DAB source to the CarPlay media source. Observation These experiments appear to suggest that the behaviour is specifically related to using the CarPlay “CarAudio” microphone route, rather than audio recording itself. Question Is this the expected behaviour for third-party CarPlay applications? More specifically: Is there any supported AVAudioSession configuration or CarPlay API that allows a third-party CarPlay application to perform a brief, user-initiated audio capture using the vehicle microphone without causing the head unit to enter its communications/voice audio mode or interrupt the vehicle’s native radio playback? If this behaviour is by design and no supported mechanism exists to achieve this, confirmation of that would be extremely valuable, as it would allow us to design the application accordingly. If additional information, sample code, AVAudioSession logs or detailed reproduction steps would be helpful, I would be more than happy to provide them. Thank you very much for your time. Kind regards, Neil Jenner Developer, HearSave

I'm seeing crashes in _MPRemoteCommandEventDispatch on iOS 26.x devices in 3 apps. According to Bugsnag logs they are: NSInternalInconsistencyException: event dispatch <_MPRemoteCommandEventDispatch: <MPRemoteCommandEvent: 0x11c049500 commandID=THV0 command=<MPRemoteCommand: 0x109ad1ea0 type=Play (0) enabled=YES handlers=[0x109b6a310]> sourceID=(null) ([HostedRoutingSessionDataSource] handleControlSendingCommand<2W5E>)> state:201> deallocated without calling continuation I attached a log from Xcode organizer matching Bugsnag crash. mpr_remote_command_event.crash When I set the brakpoint on the -[_MPRemoteCommandEventDispatch dealloc] I can see it it's hit every time I tap play or pause on locked screen play button. Thread 0 Crashed: 0 libsystem_kernel.dylib 0x00000002370420cc __pthread_kill + 8 (:-1) 1 libsystem_pthread.dylib 0x00000001e975c810 pthread_kill + 268 (pthread.c:1721) 2 libsystem_c.dylib 0x0000000198f8ff64 abort + 124 (abort.c:122) 3 libc++abi.dylib 0x000000018a7cf808 __abort_message + 132 (abort_message.cpp:66) 4 libc++abi.dylib 0x000000018a7be484 demangling_terminate_handler() + 304 (cxa_default_handlers.cpp:76) 5 libobjc.A.dylib 0x000000018a6cff78 _objc_terminate() + 156 (objc-exception.mm:496) 6 xxxxxxxxxxxxxx 0x00000001003a7db8 CPPExceptionTerminate() + 416 (BSG_KSCrashSentry_CPPException.mm:156) 7 libc++abi.dylib 0x000000018a7cebdc std::__terminate(void (*)()) + 16 (cxa_handlers.cpp:59) 8 libc++abi.dylib 0x000000018a7ceb80 std::terminate() + 108 (cxa_handlers.cpp:88) 9 CoreFoundation 0x000000018d7341c4 __CFRunLoopPerCalloutARPEnd + 256 (CFRunLoop.c:769) 10 CoreFoundation 0x000000018d70bb5c __CFRunLoopRun + 1976 (CFRunLoop.c:3179) 11 CoreFoundation 0x000000018d70aa6c _CFRunLoopRunSpecificWithOptions + 532 (CFRunLoop.c:3462) 12 GraphicsServices 0x000000022e31c498 GSEventRunModal + 120 (GSEvent.c:2049) 13 UIKitCore 0x00000001930ceba4 -[UIApplication _run] + 792 (UIApplication.m:3902) 14 UIKitCore 0x0000000193077a78 UIApplicationMain + 336 (UIApplication.m:5577) 15 xxxxxxxxxxxxxx 0x00000001000c0134 main + 308 (main.swift:15) 16 dyld 0x000000018a722e28 start + 7116 (dyldMain.cpp:1477) Is the crash happening when the app is being terminated? Thank you!

I would need to know which gender is used by the iOS system for speechSynthesis. I have tried let aVoice = AVSpeechSynthesisVoice() print(#function, #line, aVoice.gender.rawValue) But always get 0, for unspecified

Hello, I'm looking for advice from developers who have successfully published internet radio applications on the App Store. My app has been rejected multiple times under Guideline 5.2.3 with the following message: "The app provides potentially unauthorized access to third-party audio or video streaming, catalogs, and discovery services." Apple asks me to provide: "documentary evidence evidencing that you have all necessary rights or permissions to the third-party audio or video streaming, catalogs, and discovery services in the app." However, I'm not sure what documentation App Review actually expects. My application works as follows: • It does NOT host, proxy, cache, retransmit, record, convert, or modify any audio streams. • Playback uses Apple's AVPlayer. • Audio is streamed directly from the original broadcaster to the user's device. • The application only retrieves publicly available station metadata and stream URLs from the Radio Browser API. • The app no longer contains any built-in curated station list. • Music identification uses Apple ShazamKit together with metadata lookup (MusicBrainz, Last.fm and Apple iTunes Search API). These services are used only for metadata and artwork, not for streaming audio. I have already contacted the Radio Browser maintainers asking whether they can provide written permission or an official statement, but I have not yet received a reply. My questions are: Has anyone successfully published an App Store internet radio application that uses the Radio Browser API (or another public radio directory)? What documentary evidence satisfied App Review? Does Apple expect permission from the Radio Browser project, or from every individual broadcaster whose publicly available stream is listed in the directory? If your app was approved, what documentation did you provide? Any experience or guidance would be greatly appreciated. Thank you. Has anyone received a successful approval for an internet radio app under Guideline 5.2.3 in 2025 or 2026?

Tested iPhone 16 Pro Max running DB2 Since using iOS 27 Developer Beta, Progressive Web Apps (PWAs) and applications using WKWebView that route live streaming audio (such as Icecast/SHOUTcast streams) through the Web Audio API (AudioContext / MediaElementAudioSourceNode for canvas visualizers) experience silent playback freezes during track changes. The JavaScript context remains active, and the HTMLMediaElement reports no errors or pauses, but the low-level system audio daemon (audiod) disconnects. The logs indicate a state desynchronization in MediaToolbox triggered by inline metadata frame updates, coupled with massive sandbox violations. Steps to reproduce: Run a PWA or WKWebView on iOS 27 Developer Beta that loads a live audio stream using an tag. Route the media element into the Web Audio API (e.g., audioContext.createMediaElementSource(audioElement)). Play the stream and lock the screen or let it run in the foreground. Wait for a track transition to occur on the live stream server (which pushes an inline ICY metadata update). Observed Result: Audio instantly goes silent at the track boundary. JavaScript rendering loops remain active, but the stream is dead. List of important errors: MediaToolbox parsing failure: <<<< FigStreamPlayer >>>> fpfs_CacheRenderChain: Caching unexpected mediatype metadata Reasoning: When the stream updates its inline metadata, MediaToolbox (FigStreamPlayer) fails to handle the frame descriptor correctly, halting the stream decoder render chain. Audio engine state desynchronization: <<<< FigStreamPlayer >>>> fpfs_SetRateOnTrack: [...] setting rate on track before it has reached playing state - 4 instead Reasoning: WebKit attempts to keep playing or setting the playback rate, but MediaToolbox fails because the underlying decoder track is stuck in an uninitialized/stalled state (4). System Audio Daemon Disconnection: Subsystem: com.apple.audioanalytics | Process: audiod Reporter disconnected. ( function=sendMessage, reporterID=... ) Reasoning: Because the rendering stream stalled, the system audio daemon (audiod) forcibly severs the audio session connection to the browser container. Massive Sandbox Log Flooding (WebKit.WebContent): Sandbox: com.apple.WebKit.WebContent(2719) deny(1) syscall-unix 179 Reasoning: WebKit's WebAudio thread tries to log trace markers to XNU's kdebug_trace64 (syscall 179) but is blocked by the WebContent sandbox profile, resulting in a loop of thousands of denials that clog the thread. What needs to be fixed: MediaToolbox (FigStreamPlayer): Fix the regression where incoming live stream metadata frames stall the render chain when connected to a Web Audio node. WebKit Sandbox Profiles: Update the iOS WebContent, Network, and GPU sandbox rules to allow necessary tracing/diagnostic calls (syscall-unix 179 and mach-lookup com.apple.diagnosticd) in developer beta builds to prevent thread-blocking loops.

I'm building a free web-based music trivia game (guess the release year of a song). I'd like to use the Apple Music API in the following way and want to confirm it complies with the Apple Music API / MusicKit terms: The app requests only 30-second preview clips (previews[].url from the Catalog API), played through a standard HTML element. No user ever signs in with an Apple ID — there is no Music User Token; only my developer token is used, server-side, to query the catalog. The app is free, does not gate playback behind any payment, and displays "Music previews via Apple Music" attribution. Full-track playback and user subscriptions are not used at all. The Apple Music API terms describe the purpose as facilitating access to end users' Apple Music subscriptions — since a preview-only integration never touches a subscription, I want to make sure this usage is sanctioned before launching publicly. Is preview-only, unauthenticated playback of catalog previews permitted in this scenario?

It appears that recording video of a device in Device Hub does not record the associated audio of the device. Are there any plans to do this? (Or a workaround that's easier than rerouting the audio output to an audio editor app and recording it separately?) It would be incredibly useful for making app demonstrations and tutorials.

Hey everyone, quick disclaimer before jumping in - I used my LLM to structure this around notes/observations I've been taking the last several months. I apologize for the length but felt this was the best distillation of an important challenge my peers and I are facing in mixing music for the largest device/service segment of the listening community - Airpods Pro/Max via Apple Music. Thanks in advance for reading and any feedback you can offer! -Kyle I'm a professional mix engineer working primarily in contemporary pop, indie, and country. After 20+ years of working in stereo, I've started delivering Dolby Atmos ADM masters for Apple Music distribution. I want to share some specific observations about the Apple Spatial Audio re-render in the hope that it's useful to the team that owns this rendering pipeline — and to ask a few questions I haven't been able to find answered in public documentation. I recognize this sits at an unusual intersection of the developer platform and the Apple Music delivery side of the house, but since the rendering behavior is ultimately a platform-level decision, this felt like the right place to start. Background: the three-format problem When delivering an Atmos ADM master, a mixer effectively has to satisfy three distinct listening contexts simultaneously: Speaker playback (7.1.4 or similar) via the Dolby renderer Dolby binaural re-render (AC-4), as heard on TIDAL and Amazon — which respects the OFF/NEAR/MID/FAR binaural mode settings on beds and objects Apple Spatial Audio headphone re-render on Apple Music The first two have reasonably predictable translation. The third is where I'm running into consistent issues — and where I'd value any guidance Apple is able to share. The core issue: Apple's re-render discards binaural mode metadata As best I can tell from testing and from community documentation, Apple's pipeline ingests the ADM, creates an internal 7.1.4 render, and then applies its own proprietary binaural spatialization — one that does not reference the OFF/NEAR/MID/FAR binaural mode parameters embedded by the mixer. This is distinct from the Dolby AC-4 path, which does honor those settings. In practice, this means: Apple's re-render applies a consistent room character regardless of what the mixer has specified for individual elements Elements like lead vocals and kick/snare — which I'm routing through beds or objects with OFF or NEAR binaural settings specifically to preserve intimacy and punch — receive the same ambient room treatment as wider, more spacious elements The result on Apple Music has noticeably more perceived distance and "room" on transient-heavy and close-mic'd elements than either the speaker mix or the Dolby binaural render To be specific about the perceptual effect: the Apple re-render's virtual room introduces early reflections and a sense of speaker-to-listener distance that significantly undercuts the intimacy and impact of close elements. On a pop or country vocal, this is the difference between a performance that feels present and direct versus one that feels recessed in a listening space. On drums, transient attack is softened in a way that doesn't happen in any other delivery context for the same master. Questions for the team I'd be grateful for any clarity on the following: Is the behavior of ignoring OFF/NEAR/MID/FAR metadata intentional and permanent, or is it something that may change as the rendering pipeline evolves? Is there any mechanism — existing or planned — by which a mixer can influence the room character or "closeness" of elements in Apple's re-render, outside of object positioning metadata? Is there any documentation of how Apple's binaural spatialization layer translates object distance metadata (as opposed to binaural mode) — i.e., does Z-axis positioning in the Atmos object space affect perceived distance in the re-render? Is there a recommended workflow or set of delivery parameters that Apple's audio team considers optimal for music content specifically, as opposed to film/TV? Notes on the Audiomovers Binaural Renderer for Apple Music I'm aware of and have used the Audiomovers plugin, which I understand was developed in collaboration with Apple and accurately reflects the Apple Spatial re-render during session monitoring. It's a genuinely useful tool and has improved my ability to anticipate Apple's output. My questions above are about the underlying rendering behavior — not the monitoring workflow, which is solved. Why this matters for music specifically Film and TV post content has different expectations around spatialization — a consistent room or "cinema" quality to the binaural render is arguably appropriate for that material. For music, particularly in contemporary genres where the stereo mix is already highly produced and intimate, an added room layer competes with the mix's own space design and consistently pushes elements further from the listener than intended. I'd argue music content would benefit from a rendering mode with a more "dry" or near-field room character — and I suspect I'm not alone in this among working Atmos music mixers. I'm happy to provide specific A/B examples or additional technical detail if that's useful to anyone on the platform team. Thanks for reading.

Certain apps (eg. DJay) at least seem to have access to audio data from Apple Music streams, either directly or via an indirect dataset for visualization purposes either generated from audio data on the device or delivered from a remote service. Is there any framework provided by Apple or special agreement with Apple that gives access to Apple Music audio data, or sets of visualization meta data, or the ability to run processing of audio data on device or remotely (either on-demand or via preprocessing)?