I need to apply headphone-specific scenario only when headphones are the sole active playback device in my iOS audio app. Problem that there is no absolute way to definitively understand that headphones are the sole active playback device AVAudioSession.currentRoute.outputs portTypes don't guarantee headphones: let session = AVAudioSession.sharedInstance() let outputs = session.currentRoute.outputs let headphonesOnly = outputs.count == 1 && (outputs.first?.portType == .headphones || outputs.first?.portType == .bluetoothA2DP || outputs.first?.portType == .bluetoothHFP || outputs.first?.portType == .bluetoothLE) The issue in code above that listed bluetooth profiles (A2DP, HFP, LE) can be used by any audio device, not only headphones Is there any public API on iOS that can: Distinguish Bluetooth headphones vs Bluetooth speakers when both use A2DP/LE? Expose the user’s “Device Type” classification (headphones / speaker / car stereo, etc.) that is shown in Settings → Bluetooth → Device Type? Provide a more reliable way to know “this route is definitely headphones” for A2DP devices, beyond portType and portName string heuristics?

I’m building a teleprompter-style app that relies on Picture in Picture. PiP starts correctly on device. Everything works — until another app (e.g. TikTok / Instagram) starts active video recording. When camera capture begins in the foreground app, iOS terminates my PiP session. Some teleprompter apps appear to keep PiP active while recording in other apps, so I’m trying to understand the recommended architectural pattern for this scenario. Is there a documented approach or best practice to keep PiP stable during third-party camera capture? Looking specifically for guidance on the correct AVKit / AVAudioSession configuration for this use case.

I've got a streaming Radio app that loads an HLS stream into an AVAudioPlayer. I've set up an Intents extension that notifies SiriKit that my app must handle the INPlayMediaIntent in app, and, I'm able to successfully initiate the stream playing from my phone using the string "Play ". My intent handler in app looks like this: completionHandler(INPlayMediaIntentResponse(code: .success, userActivity: nil)) DispatchQueue.main.async { AudioPlayerService.shared.play() } The Audio Player service, in its init, does the following: try AVAudioSession.sharedInstance().setCategory( .playback, mode: .default, policy: .longFormAudio ) Additionally, in my Info.plist, I have the AirPlay optimization policy set to Long Form Audio. Having said all that, when I try to route my app to play "on a given HomePod speaker" ("play on ") the speaker routing instructions are never followed. I've looked and not been able to find where I might be able to instruct my app to follow the correct path here. I was assuming I could not trigger this behavior manually, as I believe I don't really have any control over AirPlay routing. Is there any guidance for working with SiriKit to do the right thing with regards to audio routing?

Hi everyone, We’re encountering an issue where AudioQueueNewOutput blocks indefinitely and never returns, and we’re hoping to get some insight or confirmation if this is a known behavior/regression on newer iOS versions. Issue Description When triggering audio playback, we create an output AudioQueue using AudioQueueNewOutput. On some devices, the call hangs inside AudioQueueNewOutput and never returns, with no OSStatus error and no subsequent logs. This behavior is reproducible mainly on iOS 18.3. Earlier iOS versions do not show this issue under the same code path. if (audioDes) { mAudioDes.mSampleRate = audioDes->mSampleRate; mAudioDes.mBitsPerChannel = audioDes->mBitsPerChannel; mAudioDes.mChannelsPerFrame = audioDes->mChannelsPerFrame; mAudioDes.mFormatID = audioDes->mFormatID; mAudioDes.mFormatFlags = audioDes->mFormatFlags; mAudioDes.mFramesPerPacket = audioDes->mFramesPerPacket; mAudioDes.mBytesPerFrame = audioDes->mBytesPerFrame; mAudioDes.mBytesPerPacket = audioDes->mBytesPerFrame; mAudioDes.mReserved = 0; } // Create AudioQueue for output OSStatus status = AudioQueueNewOutput( &mAudioDes, AQOutputCallback, this, NULL, NULL, 0, &audioQueue ); code-block The thread blocks inside AudioQueueNewOutput, and execution never reaches the next line. Additional Notes / Observations ASBD is confirmed to be valid Standard PCM output Sample rate, channels, bytes per frame/packet all consistent Same ASBD works correctly on earlier iOS versions AudioQueue is created on a background thread Not on the main thread Not inside the AudioQueue callback On first creation, AVAudioSession may not yet be active setCategory and setActive:YES may be called shortly before creating the AudioQueue There may be a timing window where the session is still activating Issue is reported mainly on iOS 18.3 Multiple user reports point to iOS 18.3 devices Same code path works on iOS 17.x and earlier No OSStatus error is returned — the call simply never returns. Questions Is it expected that AudioQueueNewOutput can block indefinitely while waiting for AVAudioSession / audio route / HAL readiness? Have there been any behavior changes in iOS 18.3 regarding AudioQueue creation or AudioSession synchronization? Is it unsafe to call AudioQueueNewOutput before AVAudioSession is fully active on recent iOS versions? Are there recommended patterns (or delays / callbacks) to ensure AudioQueue creation does not hang? Any insight or confirmation would be greatly appreciated. Thanks in advance!

I’m implementing a custom playback pipeline using AVSampleBufferAudioRenderer together with AVSampleBufferRenderSynchronizer. hasSufficientMediaDataForReliablePlaybackStart appears to be the intended signal for determining when enough media has been queued to start playback. For local playback, this works well in practice — the property becomes true after a reasonable amount of media is enqueued. However, when the output route is AirPlay, using this property becomes difficult: AirPlay requires significantly more buffered media before the renderer reports sufficient data. The required preroll amount is much larger than for local playback. For short assets, it is possible to enqueue the entire audio track and still never observe hasSufficientMediaDataForReliablePlaybackStart == true. In that situation there is no more media data to enqueue, but the renderer still reports that playback is not ready. Given this behavior, what is the recommended way to determine playback readiness when using AVSampleBufferAudioRenderer with AirPlay?

I’m building a standalone Apple Watch metronome app for running. My goal is for these 3 apps to work at the same time: Runna owns the workout session Spotify plays music my app plays a metronome click in the background So far this is what I've found: Using HKWorkout​Session in my metronome app works well with Spotify, but conflicts with Runna and other workout apps, so I removed that. Using watchOS background audio with longFormAudio allows my app run in the background, and it can coexist with Runna. However, it seems to conflict with Spotify playback, and one app tends to stop the other. Is there any supported watchOS audio/background configuration that allows all 3 at once? More specifically this is what I need: another app owns HKWorkout​Session Spotify keeps playing my app keeps generating metronome clicks in the background Or is this simply not supported by current watchOS session/background rules? My metronome uses AVAudio​Engine / AVAudio​Player​Node with generated click audio. Thank you!

We have an VoiP application, our application can be configured to amplify the PCM samples before feeding it to the Player to achieve volume gain at the receiver. In order to support this, We follow as below. If User has configured this Gain Settings within application, Application applies the amplification for the samples to introduce the gain. Application will also set the AVAudioSessionCategory to AVAudioSessionCategoryPlayback Provided the User has chosen the output to Speaker. This settings was working for us but we see there is a difference in behaviour w.r.t Volume Level System Settings between OS 26.3.1 and OS 26.4 When user has chosen earpiece as Output, then we will set the AVAudioSessionCategory to AVAudioSessionCategoryPlayAndRecord. User would have set the volume level to minimum. When user will change the output to Speaker, then we will set the AVAudioSessionCategory to AVAudioSessionCategoryPlayback. The expectation is, the volume level should be of AVAudioSessionCategoryPlayback what was set earlier instead we are seeing the volume level stays as minimum which was set to AVAudioSessionCategoryPlayAndRecord Could you please explain about this inconsistency w.r.t Volume level.