Hey everyone, I need to reorder a four-song Apple Music application queue while keeping the same selected occurrence, playback time, and playing/paused state. I reproduced two distinct failures in a standalone app without persistence or synchronization. I do not yet know whether these failures have a common cause. Device: iPhone 16 Pro, iOS 27.0.1 (24A446), built-in audio. Music authorization and catalog subscription checks succeed. Four distinct catalog songs resolve successfully in the Japanese storefront, in the order A, B, C, D. These letters are anonymized labels for the songs used in the measured runs; the actual catalog IDs are omitted from this public post. This does not establish that the issue occurs with every four-song selection. Repeat and shuffle are off. MusicKit reorder after a stable paused baseline Install ApplicationMusicPlayer.Queue once, starting at song D. Play once, then pause after several seconds; verify all four entries and unchanged Current/time for over ten seconds. Move the non-Current prefix in one operation: queue.entries.move(fromOffsets: IndexSet(integersIn: 0..<3), toOffset: 4) Expected: [A,B,C,D*] becomes [D*,A,B,C], retaining Current and elapsed time. RemotePlayerService instead terminates with SIGABRT during queue modification. The exception stack includes _componentsForContentItemID: and _qfa_performInsertPlaybackContext:atPosition:afterContentItemID:sectionIdentifier:actions:completion:. The client then hangs in synchronous XPC connection establishment on main. This also occurred with all app-initiated post-move SDK reads suppressed; the service report predates the first scheduled read. A direct Current move 3→0 produced a matching service exception stack in a separate run. MediaPlayer alternative fails before any reorder Using applicationQueuePlayer instead, set one MPMusicPlayerStoreQueueDescriptor for the same songs A–D with startItemID set to song D's actual catalog ID. Set repeat/shuffle off, activate an AVAudioSession playback/default session and call play once. Immediately call performQueueTransaction:completionHandler: with an empty transaction block. Completion is on main and error is nil. All queue access is synchronous inside that callback. The relevant Objective-C read order is: id raw = queue.items; NSUInteger currentIndex = player.indexOfNowPlayingItem; id current = player.nowPlayingItem; NSArray *items = raw; // raw was checked to be a nonnil NSArray NSUInteger count = items.count; for (NSUInteger i = 0; i < count; ++i) { id item = [items objectAtIndex:i]; if (!item) { /* record index and end observation */ break; } // Validate MPMediaItem and copy its nonempty playbackStoreID. } count was 4, currentIndex was 2, current was nonnil, and elements 0 and 1 validated. objectAtIndex:2 returned nil. No queue object escapes the callback. The guard ended the read with audio continuing and UI responsive. An earlier Swift queue.items.map observation crashed in Swift element dynamic casting. This newer result does not establish which song occupies returned index 2. There was no queue mutation or repeat read in this MediaPlayer trial. Both startup sequences logged "ping did not pong"; the MusicKit reorder trial subsequently reached the stable paused baseline. I cannot rule out startup's contribution. I have not established the behavior on another device/OS. Questions Is modifying entries the supported way to reorder the full application queue across Current while retaining its occurrence and continuous audio? For MediaPlayer, is a successful read-only transaction completion expected to provide a fully readable nonnull items array? Is there a documented readiness condition before enumeration that this sequence is missing? If MediaPlayer transactions are a suitable alternative, how should callers target duplicate occurrences (not just song IDs) for removal/insertion? I can provide a minimal project and the two separate failure reports through Feedback Assistant. Which component and additional diagnostics would be most useful? No Feedback ID exists yet.

We develop Donuts, an AUv2 MIDI processor (aumi), using JUCE 8.0.12 on Apple Silicon. Test environment: Logic Pro 12.4 (6707), macOS 27.0.1 (26A434). Instances within one Logic project need to share an editable chord chart automatically, while retaining independent voicing/output settings. Instances in different open projects must keep separate charts, without manual pairing. Is there a supported Logic/AU API that supplies a project-scoped identity or ownership context to an AU MIDI FX instance? If not, does Logic guarantee that an AUHostingService process cannot contain live instances from different projects, including during project switching, loading and recovery? Can one project's instances be distributed across more than one hosting process? Do these guarantees depend on Logic version or hosting configuration? We completed labelled native captures on 18 October 2026 using a diagnostic observer at the AudioUnitSDK AUMethodSetProperty entry dispatcher, after the original setter returns. This includes properties handled by AUBase before the JUCE SetProperty override. It records status, selected property metadata and top-level restored state key names/types; it does not dereference opaque host client data. Automatic AU sharing remains disabled. Observed in the corrected 0.2.40 probe: Original track and duplicate in project A were both in PID 27015. Each received a different HostCallbackInfo.hostUserData value and a different ContextName. We compare process-local hashes, not dereferenced pointers. Both received all four transport callback functions; AUHostIdentifier matched within the process. No NickName assignment was observed before the captures. There were no recorded capture losses. Keeping A's project window open and opening a separate project B unloaded both A processors at 18:12:27, reaching a live count of zero. B's fresh instance loaded in PID 27146 at 18:12:50. A previous labelled project-switch test also unloaded the original processors and loaded the new project's instance in a different process. These observations do not establish a general isolation guarantee. Restored state in A contained data, jucePluginState, manufacturer, name, subtype, type and version. B was a fresh insertion with no state restore. Payload contents were not recorded. Saved plug-in IDs alone cannot distinguish ownership when tracks, presets or projects are duplicated. ContextName and hostUserData equality do not group the original and duplicate in this test. We have not established a project-ownership contract for either. The application identity also does not distinguish projects. Please advise on the supported mechanism or hosting-process ownership and lifetime guarantees for this use case. Our aim is automatic discovery without ever combining charts from different projects. Local evidence: context-evidence-0.2.40/01-original-and-duplicate and context-evidence-0.2.40/02-separate-project contain raw captures, lifecycle logs, SHA-256 hashes and observations. Nothing has been submitted externally.

I am looking for the documented observability boundary of Audio Unit version 3 MIDI output in Logic Pro. When an Audio Unit submits events through AUMIDIOutputEventBlock, is there a supported public interface or documented ordering guarantee that can establish that all events accepted for a particular output route and stopped session have been processed, with none still pending for later delivery? I mean that component's route, not unrelated tracks or every queue in the host. I have reviewed the public documentation for AUMIDIOutputEventBlock, scheduleMIDIEventBlock/AURenderEvent, render observers, transportStateBlock, contextPresentationLatency, tailTime, and AUMessageChannel. I have not found a route-completion acknowledgment. A successful submission callback, stopped transport, received event list, or finite silent recording seems to describe a different observation point from completion of all pending delivery. Does Logic support a documented AUMessageChannel protocol or other public mechanism for this purpose? If so, which Logic/macOS versions support it, what is the completion notification's scope and clock domain, and what are its ordering and caller-thread requirements? In particular, does it remain available if transport stops and no final render callback occurs? If receiving every expected event at a downstream Audio Unit can establish completion instead, what documented guarantee rules out later delivery or duplicates from the same stopped session? Instrument processing, effects tails, and actual hardware playback are separate observation boundaries; I am not treating their completion as implied by MIDI receipt. Confirmation that this internal state is not exposed by a supported public interface would also be useful. This is an API-capability question, not a report of an observed Logic defect. I am not seeking private APIs, confidential implementation details, queue flushing, process instrumentation, virtual drivers, or audio-device reconfiguration. No project source, logs, recordings, or account information are included.

A small number of our users can’t connect Apple Music because DefaultMusicTokenProvider.userToken(for:options:) always throws MusicTokenRequestError.unknown. Most users connect without problems and we can’t reproduce the failure on any of our own accounts. Flow: let status = await MusicAuthorization.request() // .authorized let subscription = try await MusicSubscription.current // canPlayCatalogContent == true let provider = DefaultMusicTokenProvider() let developerToken = try await provider.developerToken(options: []) // succeeds let userToken = try await provider.userToken(for: developerToken, options: []) // throws .unknown On failure we retry once with options: .ignoreCache for both the developer token and the user token. The retry fails in the same way. What we see on affected devices: MusicAuthorization.currentStatus == .authorized MusicSubscription.current.canPlayCatalogContent == true The developer token is returned successfully. userToken(for:) throws MusicTokenRequestError.unknown. The NSError has code 0 and the localized description “Unknown error”, and there is no NSUnderlyingError. The ignoreCache retry fails after anywhere from about 10 ms to 2.5 s, so it sometimes appears to go out to the network. For a given account it fails every time: across days, app versions, and after reinstalling both our app and the Music app. Apple Music plays normally in the Music app for these users. Ruled out so far: iOS version: seen on iOS 26.6.1 and 27.2. Device model: seen on iPhone 13 and iPhone 14 Plus. Region: seen in Hungary, Italy, Romania and Japan. Subscription type: one affected user has an individual trial. A family member with her own individual trial on a separate account connects without problems. Family Sharing in general: family plan members connect fine for us. Questions: What conditions cause userToken(for:) to return .unknown instead of a specific case such as .userNotSignedIn, .permissionDenied or .privacyAcknowledgementRequired? Is there a way to get more detail about the cause? Is there a step affected users can take to fix it?

The documentation for AVAudioSession.Mode.measurement says that this mode will "minimize the amount of system-supplied signal processing to input and output signals" https://developer.apple.com/documentation/avfaudio/avaudiosession/mode-swift.struct/measurement Is there any documentation regarding specifically what processing is applied in the .default or .videoRecording modes and how it is different in .measurement mode? If my app adds its own signal processing, is it best practice to always use .measurement mode? What should I use for an app that applies its own signal processing to the audio in a video recording? Is it possible to "minimize system-supplied signal processing" while recording a video?

With a joined PTChannelManager channel and setAccessoryButtonEventsEnabled(true) completing successfully, what supported condition makes a classic Bluetooth headset's AVRCP Play event start PTT transmission instead of routing to a media app? The headset microphone and physical Stop button work. The next physical Start press produces no didBeginTransmittingFrom callback, while an on-screen Start request works again. Tested environment Observed on 3 October 2026: iPhone 13 Pro Max, iOS 26.6.1. Xcode 26.6, macOS 26.5.2. boAt Rockerz 255 Pro+, classic Bluetooth A2DP/HFP. Push to Talk capability, microphone permission, and audio/push-to-talk background modes enabled. Default half-duplex transmission mode and Ready service status retained. Isolation and setup The reproduction uses an independent UIKit controller initialized before the host app runtime. No React Native, Expo audio module, Live Activity, MPRemoteCommandCenter, Now Playing metadata, audio player, transcription, or backend participates. The controller retains its channel manager, leaves a restored channel before joining a fresh channel, and enables accessory button events in didJoinChannel. The revised test configures the audio session at launch, before manager initialization: let session = AVAudioSession.sharedInstance() try session.setCategory(.playAndRecord, mode: .voiceChat, options: [.allowBluetoothHFP]) The relevant join callback is: func channelManager(_ channelManager: PTChannelManager, didJoinChannel channelUUID: UUID, reason: PTChannelJoinReason) { channelManager.setAccessoryButtonEventsEnabled(true, channelUUID: channelUUID) { error in // The test logs successful completion here. } } PTT owns audio activation/deactivation; the diagnostic never calls setActive. In didActivate, it reapplies the same category/mode/options, clears a speaker override, selects an available HFP input, waits for the route to settle, and starts an AVAudioEngine input tap. It verifies HFP input/output and incoming frame counts; samples are discarded. It removes the tap and stops the engine on Stop/deactivation. The full focused sample was already supplied privately to DTS. Its controller was tested on the physical phone through the native-only launch path. The standalone Xcode project packaging passed an unsigned iPhoneOS build, but has not independently been installed on the phone. Reproduction Connect the headset, launch the diagnostic, grant microphone permission, and join a fresh PTT channel. Confirm that enabling accessory events succeeds. Tap on-screen Start, which calls requestBeginTransmitting(channelUUID:). Wait for HFP input/output and incoming audio frames to be verified. Press and release the headset multifunction button. The delegate reports didEndTransmittingFrom with handsfree/headset source (raw 3); PTT deactivates audio and the channel remains joined. Press and release the same headset button again. Expected: PTT begin callback and microphone activation. Observed: no begin callback; Console shows AVRCP Play routed to Music. Tap on-screen Start again: transmission works. Headset Stop works again. Selected evidence The revised launch-configuration test produced this native trace on 3 October (UTC): 04:32:10 launch: native-only; launch audio configuration v2 04:32:10 category=PlayAndRecord; mode=VoiceChat; options=4 04:32:11 fresh channel joined 04:32:11 accessory mapping accepted 04:32:19 app start requested 04:32:19 BEGIN source=2 04:32:20 available inputs=MicrophoneBuiltIn,BluetoothHFP 04:32:20 discard engine running 04:32:21 HEADSET VERIFIED: BluetoothHFP input/output; frames=4096 04:32:22 END source=3 04:32:23 audio deactivated No physical-headset BEGIN appeared in the native event snapshot copied at 04:32:49 UTC. Selected Console observations from the same run, converted from IST to UTC: 04:32:30.529053 AVRCP Play routed to com.apple.Music 04:32:30.535720 Music launch failed: NotFound 04:32:35.852134 the same command timed out after 5.326288 seconds Music had been removed during troubleshooting. Before removal, the user observed Music opening; the supplied timestamped excerpts were captured after removal. Removal explains the launch failure, but does not explain why the joined PTT channel is bypassed. An earlier native-only fresh-channel control also showed Play routing to Music before any app-requested transmission, with no BEGIN or audio activation in the callback trace. That earlier control configured the category in didActivate; it was not a fresh-start test of the revised launch-configuration variant. The revised test above establishes that configuring the category at launch did not fix the post-Stop failure. Questions I reviewed the accessory mapping explanation in https://developer.apple.com/forums/thread/804205 and the launch audio configuration guidance in WWDC22 session 10117. Is a discrete AVRCP Play command from this type of consumer headset supported for PTT Start in this state, or is a different command form required? Does the playback-mode qualifier in that forum guidance require an additional supported setup step? Could the category/route sequence described above bypass accessory mapping despite successful completion? What targeted diagnostic or controlled configuration would distinguish accessory-command compatibility from an iOS routing defect? The observations establish a routing/callback mismatch in this tested configuration; I am not assuming an iOS defect or that the headset is unsupported.

Hello, I need guidance on diagnosing an intermittent audio failure on an iPhone 12 running iOS 26.6.2. My app, Timer Workout Fitness, plays short bundled MP3 voice recordings for countdowns, repetition numbers and workout announcements. It uses React Native / Expo SDK 57 and expo-audio. The native playback implementation uses AVQueuePlayer, AVPlayerItem and AVURLAsset. Users can listen to Spotify while the app plays spoken cues, with ducking of the background music. Observed behavior: Playback can work correctly for an entire workout. Audio sometimes fails after background/foreground transitions, pausing Spotify, or completing one workout and starting another. The exact sequence is not consistently reproducible. The app may remain navigable while recorded audio becomes unavailable. Force-quitting does not always restore reliable playback. Restarting the iPhone has restored it in our tests. Speech-based voices have generally behaved more reliably before the failure. Evidence from a device Console capture: At 15:03:35 on October 12, the kernel reported termination of audiomxd with reason "per-process-limit" and a recorded footprint of 66866 KB. ReportSystemMemory confirmed the jetsam termination. Shortly before this, the Console contained AudioConverter construction messages associated with our app through mediaplaybackd. Our app subsequently reported media-services loss/reset and errors including: "Server was dead" OSStatus 1836282486 We have not established whether our playback implementation causes an accumulation of native resources, a temporary peak, or another issue. We do not assume that this is an iOS defect. The implementation originally retained up to 56 players for individual recordings and loaded them concurrently. We recently changed it to load only the recordings required by a workout: 15 players for 10 repetitions and 35 for 30 repetitions. Failures have still occurred in development testing, but we have not measured the corresponding native memory footprint. We also have a custom native patch affecting activation/deactivation and handling of media-services loss/reset. Current Expo Go tests do not include that patch; our TestFlight builds do. We can provide the patch for review. What is the recommended way to: Attribute audiomxd memory usage to our app’s playback resources? Verify that AVQueuePlayer items and associated decoding resources are released? Capture useful diagnostics for this service termination? Choose an appropriate playback architecture for frequent short local voice clips alongside background music? We have device Console logs and application diagnostic traces. We do not yet have a minimal native Xcode reproduction project and would appreciate guidance on what it should include.

Hi, I'm working on a project that uses the AVSpeechSynthesizer and AVSpeechUtterance. I discovered by chance that the AVSpeechSynthesizer automatically completes some words instead of just outputting what it's supposed to. These are abbreviations for days of the week or months, but not all of them. I don't want either of them automatically completed, but only the specified text. The completion transcends languages. I have written a short example program for demonstration purposes. import SwiftUI import AVFoundation import Foundation let synthesizer: AVSpeechSynthesizer = AVSpeechSynthesizer() struct ContentView: View { var body: some View { VStack { Button { utter("mon") } label: { Text("mon") } .buttonStyle(.borderedProminent) Button { utter("tue") } label: { Text("tue") } .buttonStyle(.borderedProminent) Button { utter("thu") } label: { Text("thu") } .buttonStyle(.borderedProminent) Button { utter("feb") } label: { Text("feb") } .buttonStyle(.borderedProminent) Button { utter("feb", lang: "de-DE") } label: { Text("feb DE") } .buttonStyle(.borderedProminent) Button { utter("wed") } label: { Text("wed") } .buttonStyle(.borderedProminent) } .padding() } private func utter(_ text: String, lang: String = "en-US") { let utterance = AVSpeechUtterance(string: text) let voice = AVSpeechSynthesisVoice(language: lang) utterance.voice = voice synthesizer.speak(utterance) } } #Preview { ContentView() } Thank you Christian

I am testing an audio-only MediaDeviceExtension on an iPhone 17 Pro, with Xcode 27.0 (27A266a). The same application build reproduces this on iOS 27.0 (24A437), after a full reboot, and on iOS 27.0.1 (24A446). The extension advertises .realtimeAudioStreaming, one stable device UUID and a reachable, nonzero-port endpoint. It connects to the receiver before reporting activatedDevice. From startRealtimeSampleDelivery(session:), it calls AudioServerPlugInRegisterMediaDeviceExtension. The plug-in exposes one output device with the same UID and kAudioDeviceTransportTypeRemoteStreaming. The driver interface lives for the extension process and is registered on each delivery start. Stop/deactivation closes the transport and stops forwarding samples; it does not terminate the extension or register a null interface. Reproduction: start audio, select the extension's route, confirm audio flows, switch to iPhone Speaker, then reselect the same route while the source keeps playing. First selection works; subsequent selections briefly deliver audio before reverting to Speaker with AVOutputContextDeviceConnectionFailureReasonMDERouteRevertedToLocal. Pausing the source before route selection, waiting five seconds and resuming worked repeatedly in the same extension process; uninterrupted reconnection is the required behavior. The normal test uses Spotify and a separate receiving app. A diagnostic control on iOS 27.0 also reproduces first-success/reconnect-failure using a native AVAudioPlayer PCM source and a separate Mac receiver that counts/discards the samples. That control has no Spotify, DSP processing, local receiver playback session or same-phone transport endpoint. Stored device logs on 27.0.1 show two failed reconnects: Observation Reconnect 1 Reconnect 2 System policy chooses fallback before startRealtimeSampleDelivery 11.103 ms earlier 26.956 ms earlier MusicVAD reported present after fallback decision 364.019 ms later 409.215 ms later Driver registration result OSStatus 0 OSStatus 0 New captured frames before system stops delivery 52,224 47,104 Time from fallback decision to Speaker selection 1,507.218 ms 1,507.904 ms The policy logs identify the active, non-video source as not supporting the extension's protocol, then attempt AirPlay fallback. On the first successful connection, MusicVAD is already present and the policy explicitly permits that same source. On reconnect, successful driver publication and subsequent I/O do not cancel the earlier fallback decision. Transport reports show zero drops and socket errors; StartIO/StopIO counts balance, the stream-active setter is honored, and callback session IDs match. No registration interruption is captured during these attempts. Creating a media device extension directs publication from startRealtimeSampleDelivery. The registration API describes the interface, UID and transport requirements, but I have not found the supported teardown/re-registration contract for this retained-process case. Between stopRealtimeSampleDelivery / deactivation and the next delivery start, should the extension retain and re-register the same driver interface, recreate it, or withdraw the audio device through a documented operation? How should an audio-only extension using the documented publication callback ensure the system's compatibility check waits for its audio device? Is there a supported readiness or completion signal that the implementation must provide? The evidence identifies an ordering difference; I am not assuming it proves an OS defect. Guidance on the required lifecycle, or a reference implementation demonstrating uninterrupted reconnects, would help isolate the remaining driver-versus-system boundary.

Our music player plays library and Apple Music catalog content with MusicKit's ApplicationMusicPlayer. On the Mac, we want a volume slider that changes only our app's playback level, like the slider in Music.app. We found no supported way to do this: ApplicationMusicPlayer and MusicPlayer have no volume property. The audio plays in com.apple.MediaPlayer.RemotePlayerService, not in our process, so we cannot change the stream level. MPVolumeView and the deprecated MPMusicPlayerController.volume control the system output volume, not the app's level. AVPlayer cannot play Apple Music catalog content. Questions: Is there a supported API to set the playback volume of ApplicationMusicPlayer on macOS or Mac Catalyst? If there is none, what does Apple recommend for Mac apps that need an app-level volume control for MusicKit playback?

We are developing a voice call application that uses AVRoutePickerView, allowing users to switch between an iPhone, a speaker, and Bluetooth earphones. However, we have encountered an intermittent issue: when switching from the speaker to Bluetooth earphones, the earphones remain in a loading state, and the audio channel subsequently switches back to the speaker. How can we resolve this issue? Here is the sample code: let session = AVAudioSession.sharedInstance() do { try session.setCategory(.playAndRecord, mode: .default, options: [.allowBluetooth]) try session.overrideOutputAudioPort(isBluetoothConnected ? .none : .speaker) try session.setPreferredSampleRate(48000) try session.setPreferredIOBufferDuration(0.02) try session.setActive(true, options: []) INFO(" >>> start: hasBluetooth=\(isBluetoothConnected), inputs: \(session.currentRoute.inputs.map { $0.portType }) outputs: \(session.currentRoute.outputs.map { $0.portType })") } catch { ERROR("(error.localizedDescription)") }

We are developing an iOS app that plays individual prerecorded spoken-audio files in response to background triggers. The user explicitly enables this functionality while the app is in the foreground. Subsequently, playback may need to start while the app is backgrounded or the device is locked, with silent intervals between files. For this question, please assume that the app is legitimately executing in the background when a trigger arrives. We are not asking how to wake a suspended app or keep it running artificially. Desired behavior Temporarily interrupt other media playback while an audio file is playing. Release the audio session afterwards, allowing the other app to resume. Repeat this for subsequent triggers without requiring foreground interaction. We do not need to override phone calls, Siri, or other higher-priority system audio. Current configuration try session.setCategory( .playback, mode: .voicePrompt, options: [.duckOthers, .interruptSpokenAudioAndMixWithOthers] ) try session.setActive(true) After playback finishes: try session.setActive( false, options: .notifyOthersOnDeactivation ) This provides ducking for other music playback. However, we would prefer non-mixing playback during each file. We are considering .playback with .spokenAudio and no mixing options, but Apple's documentation describes cannotInterruptOthers when attempting to activate a non-mixable session from the background. Questions Is there a supported audio-session lifecycle that allows this intermittent, non-mixing background playback after the user initially enables the feature in the foreground? If we deactivate the session between files, does the background activation restriction apply again to every subsequent file, regardless of the earlier user interaction? Does implementing a CarPlay audio app with the appropriate entitlement change these restrictions? In particular, is there a distinction between playback explicitly initiated through the CarPlay interface and later background-triggered playback? If this behavior is not supported, is ducking/mixing the recommended approach for this use case? We want to use public APIs and avoid silent playback or retaining an active audio session solely to prevent other apps from playing. Any clarification on the intended behavior and recommended configuration would be appreciated. Thank you for your time and guidance! regards, Carsten :-)

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.