TN3135 describes the exception that lets a watchOS app use low-level networking while it holds an active audio session. I have that working, and the app functions — but the network path is withdrawn and restored on a strikingly regular cycle, and I would like to know whether that is expected behaviour rather than something I am doing wrong. Setup Apple Watch Series 10 (Watch7,9), watchOS 26.5. Reproduced on a Series 6 (Watch6,2). UIBackgroundModes: [audio]; AVAudioSession category .playAndRecord, mode .spokenAudio; activated with the async activate(options:completionHandler:). NWConnection with NWProtocolWebSocket to a WebSocket relay over TLS. The app streams 16 kHz mono PCM continuously while transmitting and holds the socket open otherwise. Symptom NWPathMonitor reports .unsatisfied, then .satisfied about two seconds later, over and over. Measured with the iPhone powered off, so the watch was on its own Wi-Fi: Uptime between drops Outage 36.4 s 2.1 s 36.7 s 1.9 s 36.9 s 2.1 s The regularity is what prompts the question — uptime varies by ±0.3 s and the outage is consistently 2.0 s. That reads as a timeout expiring rather than radio behaviour. What I have ruled out Not the network or the server. A browser client on the same relay, same TLS, same wire protocol, holds a WebSocket indefinitely. Not the interface. Identical cadence over the companion ipsec1 tunnel with the iPhone present, and over the watch's own en0 with the iPhone powered off. Pinning requiredInterfaceType = .wifi while the iPhone is reachable fails outright — the path offers only ipsec1. Not audio-session interruption. I observe interruptionNotification, routeChangeNotification, mediaServicesWereResetNotification and silenceSecondaryAudioHintNotification. None fire at a drop. At the moment the path goes .unsatisfied, the engine is running and the player node is actively playing. Not session idleness. Playing continuous silence for the whole session, rather than only while reconnecting, made no difference — still 36.4 s. The control that surprised me To test whether this affects any long-lived watch socket or only audio-unlocked ones, I built a second app with no AVAudioSession at all, no audio background mode, holding a URLSessionWebSocketTask and kept alive by a WKExtendedRuntimeSession so screen sleep was not a factor. It never connected. NWPathMonitor reported .unsatisfied once and never changed, across a 30 s run, and every request failed with "The Internet connection appears to be offline." I had expected URLSession to be permitted regardless. Questions Does the audio-session networking exception in TN3135 have a defined lifetime, and is a periodic revoke/re-grant cycle expected? If so, is there a supported way to hold it continuously — or is the correct design simply to expect the interruption and reconnect through it? Is it expected that an app with no audio session gets no network path at all on watchOS, including via URLSession, even in the foreground with an extended runtime session?

I am trying to stream audio from a USB input to a set of AirPlay speakers. I can get this to work to a single AirPlay speaker when I use .playAndRecord and don't use .longFormAudio in the AVAudioSession setup but I hear some audio glitches. I believe these glitches to be audio under-run at the speaker due to differences in clock rates, etc. As I understand the API, to get rid of the audio glitches, I need to use .longFormAudio to enable AirPlay2 and get the speaker to deal with tracking the audio sample timing and have the speaker do any re-sampling when the clocks drift. But if I turn on .longFormAudio, the API will not allow me to use .playAndRecord. Is there a way to get AirPlay2 re-timing behaviors and also enable mic input in the same IOS app?

iOS already gives users a simple per-app Microphone permission: Settings → Apps → [App] → Microphone: On/Off Why isn’t there an equivalent permission in the other direction? Settings → Apps → [App] → Audio Output: On/Off This would solve a surprisingly common problem: I may deliberately be listening to Spotify, an audiobook or a podcast, then open another app which suddenly produces audio from an advertisement or autoplaying video. That audio may mix with, duck, or even interrupt what I actually chose to listen to. As I understand the current architecture, apps use AVAudioSession to describe how their audio should interact with other audio. But much of that policy is therefore controlled by the application producing the unwanted audio, rather than by the device owner. The simplest solution wouldn’t require a per-app mixer or complicated audio controls. Just one user-controlled permission: Allow Audio Output: On / Off When disabled, iOS would prevent that app from producing audible media output, while audio sessions belonging to other apps would continue normally. Conceptually, this seems very similar to the existing Microphone permission: Microphone: Can this app receive audio from my device? Audio Output: Can this app produce audio on my device? More advanced controls — per-app volume, permission to interrupt other audio, ducking policy, etc. — could potentially come later. But they aren’t necessary to solve the fundamental problem. I’m curious from an AVAudioSession perspective: Is there a technical reason why iOS could not enforce an OS-level per-app Audio Output permission in the same way it already enforces Microphone access? And if there isn’t, would others find this useful?

I am the developer of MIDIDeviceManager, an iOS and iPadOS application used by musicians to control external MIDI hardware during live performance. Before enabling any background execution mode, I would like to ask which architecture Apple intends for this type of application. What the application does The app organises the patches of a musician's MIDI instruments into Pads, Scenes and Setlists so they can be recalled during a performance. It sends MIDI to external hardware such as guitar processors, synthesisers and vocal processors, and it also receives incoming MIDI that triggers its own Scenes — typically from a Bluetooth foot controller, a wired MIDI controller, or another app on the same device. Its purpose is to function as the software equivalent of a programmable hardware MIDI controller. It is not a lyrics app or an audio player, and it produces no audio. The problem During a performance, musicians commonly run more than one app. A typical setup is lyrics or chord charts displayed in one app while a Bluetooth foot controller recalls presets on a Line 6 Helix through MIDIDeviceManager. This requires the app to keep receiving and processing incoming CoreMIDI events while another app is frontmost. Once iOS suspends the app, those events are no longer delivered and the foot controller stops working. This affects iPhone as much as iPad. Several of my TestFlight users perform with iPhone alone, where the device sits on a stand and is not touched during a song. What I have observed I tested this directly on an iPhone 17 Pro Max. With two apps running simultaneously, an app legitimately using the audio background mode continued to receive and act on incoming CoreMIDI events from a Bluetooth foot controller while backgrounded. At the same moment, MIDIDeviceManager received nothing once iOS suspended it. This suggests that, under certain circumstances, an app executing under an appropriate background mode may continue receiving CoreMIDI while backgrounded. Background modes considered audio — appears to provide the required behaviour, but my app produces no audio output. I do not wish to declare a background capability that does not accurately describe what the app does. bluetooth-central — does not appear applicable, since Bluetooth MIDI connections are established through CoreMIDI and managed by the system MIDI server rather than by my own Core Bluetooth session. I have not been able to identify any mode intended for continuous MIDI reception, so UIBackgroundModes is currently empty. A previous rejection An earlier submission did declare audio, and was rejected under Guideline 2.5.4 on 7 July 2026 (submission ID eab58179-8177-4d05-9c37-5e1006828a96): "The app declares support for audio in the UIBackgroundModes key in the Info.plist but we are unable to locate any features that require persistent audio. Background audio is intended for use by apps that provide audible content to the user while in the background, such as music player, music creation, or streaming audio apps." That assessment is correct — the app produces no audio, and I removed the key. But the functional requirement remains: the app needs to receive MIDI while another app is frontmost. I am asking here rather than resubmitting, because I would rather understand the intended architecture than guess again. My questions Which background mode, if any, is appropriate for an app whose purpose is to continue receiving and processing incoming CoreMIDI events while another app is frontmost? If background MIDI reception is supported, is CoreMIDI expected to continue delivering incoming MIDI to a backgrounded app, or is there a different recommended architecture for apps of this type? If the answer is that no background mode applies and this capability is not available to apps of this kind, I would very much appreciate knowing that clearly. I can then document the limitation for my users and design accordingly rather than pursue an unsupported approach. My objective is not to find a workaround, but to implement this the way Apple intends professional MIDI applications to work. Thank you.

Hi all, I’m developing a watchOS app that uses a WebSocket API to process voice audio. However, I keep encountering this error when trying to establish the connection: nw_endpoint_flow_failed_with_error [C1 <server URL>:443 failed parent-flow (unsatisfied (Path was denied by NECP policy), interface: ipsec2, ipv4, ipv6, proxy)] already failing, returning I’ve read Technical Note TN3135, which outlines an exception for audio streaming apps. My app is an audio streaming app, and I’ve already added background audio mode to the app’s capabilities. However, I’m not sure what else is required to meet the exception described in TN3135. Questions How do I meet the exception outlined in TN3135 for WebSocket audio streaming on watchOS? Does NECP enforce additional restrictions even with background audio enabled, and how can I address this? Any guidance or examples of implementing WebSocket audio streaming on watchOS would be greatly appreciated. Thanks!

Hey y'all, I'm new here and in the process of building some audio software. I'm hitting a roadblock trying to incorporate VPIO into audio playback states without it ducking what's currently playing in my DAW. I have a few questions: Can VPIO other-audio ducking be completely disabled on macOS, beyond fixed/minimum? Minimum is not enough for professional audio environments. Is attenuation of an unrelated application routed through a different Core Audio output device expected? Is split-device VPIO—built-in microphone input with Apollo/Universal Audio output—supported? Why can AVAudioEngine.start() succeed while the engine remains stopped and immediately emits a configuration-change notification? Thanks for any insight into this!

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

Short version, in case it saves someone the trip I just took: if your app plays audio AND uses a background URLSession with sessionSendsLaunchEvents = true, playback can be killed mid-episode the moment you call the handleEventsForBackgroundURLSession completion handler, but only in a process that was launched into the background and never went foreground. There is no crash log and no jetsam event: applicationWillTerminate simply fires. To users it looks exactly like the app crashed while playing, which is how it was reported to me, and why I wasted a while looking for a crash that did not exist. My setup: podcast app, audio background mode a background URLSession (sessionSendsLaunchEvents = true, isDiscretionary = false) used only to refresh RSS feeds those feed downloads are started from a BGAppRefreshTask What happens: iOS launches the app into the background to run a BGAppRefreshTask. The scene connects unattached; the process never becomes foreground. The task starts a batch of feed downloads on the background session. They outlive the ~10 s refresh window and finish about two minutes later. Meanwhile the user presses Play on their AirPods. Playback starts, inside that same never-foreground process. The downloads finish. iOS calls handleEventsForBackgroundURLSession. I store the handler and invoke it on the main thread from urlSessionDidFinishEvents, as documented. ~1 ms later applicationWillTerminate fires and the audio stops. At that moment the app is playing audio: AVAudioSession active, category .playback, and -[UIApplication backgroundTimeRemaining] returning greatestFiniteMagnitude. A sysdiagnose shows audiomxd holding a MediaPlayback isPlayingProcessAssertion for the process, taken 27 s earlier, invalidated only as part of the teardown, and CMSessionMgr logging "pid ... is now Terminated. Background entitlement: YES" while IsPlayingOutput:YES. The tell, and the thing that took me longest to spot: if the process HAS been foreground at some point in its life, calling the identical completion handler on the identical session does not kill it, and playback carries on. Across a full day of logs, "has this process ever been foreground" is the only variable that predicts the kill. The audio background mode is not the problem, the app happily played for ~6 minutes as a never-foreground process on another occasion, and died only at the completion-handler call. Half of this is documented behaviour: the system takes a power assertion when it resumes you for the session, and calling the completion handler releases it. What I did not expect is that the audio assertion does not take over at that point. My workaround so far is sessionSendsLaunchEvents = false on the feed session. RSS refreshes are not urgent: the transfers still run in the background, and the system hands the results to me at the next launch, where my refresh task parses them. I'm still verifying if this works as expected. So, questions for anyone who has been here: Has anyone else with an audio app hit this? I have a hunch it shows up in the wild as unexplained "the app crashed while playing" reports, particularly for podcast and audiobook apps that refresh content in the background, because there is no crash log to point at. If you combine background audio with a background URLSession, how do you handle it? Do you avoid launch events entirely, or split urgent from non-urgent transfers across separate sessions? Is there a better pattern than turning launch events off for transfers that genuinely are not urgent? Filed as FB23789310 with a sysdiagnose and a timestamped log excerpt. If you have seen this too, a dupe would help.

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!

Hello, I'm in the early planning stages of an iOS app and I'm trying to determine what's technically possible before designing around assumptions. Is it possible for a third-party iOS app, with the user's permission, to access or analyze audio that is being played by another app (for example Apple Podcasts, Spotify, Audible, or YouTube) in real time? Or is microphone input the only supported way for an app to analyze audio that is audible in the user's environment? I'm not asking about recording the screen or capturing video. I'm specifically trying to understand whether another app's audio output is ever available to third-party apps, or whether iOS intentionally isolates apps from each other's audio. If the answer depends on the audio source (for example Apple Podcasts versus Spotify versus audio coming through the microphone), I'd appreciate understanding those distinctions as well. Thank you.

Hi everyone, I am facing a critical issue where the CallKit provider delegate method provider(_:didActivate:) is intermittently not triggered. This occasionally results in a total loss of audio during some VoIP calls, while other calls work perfectly fine. Here is the sequence of steps I am currently implementing: Report Incoming Call: The app receives a VoIP push notification and reports the call using reportNewIncomingCall(with:update:completion:). Answer Action: The user taps the answer button, and the app processes the CXAnswerCallAction. Configure Audio Session: Inside the provider delegate, I configure the AVAudioSession category and mode (e.g., setting category to .playAndRecord and mode to .voiceChat). Note: As per Apple's guidelines, I do not call setActive(true) manually, expecting CallKit to activate it automatically. Despite following this standard flow, there are times when provider(_:didActivate:) is skipped entirely, meaning the audio engine fails to initialize for that specific call session. We are currently receiving a large volume of user complaints regarding this issue, as it heavily impacts the core calling experience in production. Could an Apple engineer or anyone from the community look into this? Any insights into what might be causing CallKit to occasionally fail to activate the audio session or how to work around this would be highly appreciated. Thank you!

We have a long-form audio recording app built on AVAudioEngine. We install a tap on inputNode, accumulate the PCM buffers, and encode them to AAC in ~60-second chunks. Setup is essentially: let session = AVAudioSession.sharedInstance() try session.setCategory(.playAndRecord, mode: .default, options: [.defaultToSpeaker, .allowBluetooth, .allowBluetoothA2DP]) try session.setActive(true) let engine = AVAudioEngine() let input = engine.inputNode let format = input.inputFormat(forBus: 0) // valid, e.g. 48 kHz, 1 ch input.installTap(onBus: 0, bufferSize: 1024, format: format) { buffer, _ in // In the failure case, buffer.floatChannelData is entirely 0.0 // (accumulate + encode to AAC) } engine.prepare() try engine.start() Intermittently — and so far only reported from the field, never reproduced in normal testing — a recording comes out completely silent. When we decode the resulting AAC and inspect the raw PCM, every sample is exactly 0.0. The signature is very specific: The engine is running and the tap keeps firing for the full duration (normal number of buffers / full-length chunks). inputFormat is valid (sampleRate ≠ 0, e.g. 48 kHz). No error is thrown anywhere — setCategory, setActive, start(), and the tap callback all succeed. The PCM is literally all zeros (not low-level noise / room tone — exact 0.0). Two separate silent recordings decode to byte-identical AAC, confirming pure digital silence rather than corruption. So as far as our error handling, format checks, and tap-liveness are concerned, everything looks healthy — yet the microphone is delivering pure silence. One way we can reproduce it: recording while the iPhone is being driven via macOS iPhone Mirroring (the iPhone stays locked, the mic is effectively unavailable from the device, but our session still activates with a valid format and the tap fires zero-filled buffers for the whole recording — with no error at any point). What we've ruled out: microphone permission is granted; it's not truncation or short capture (full-length, full frame count); it's not our encoding step (the input buffers themselves are zero); it's not a quiet/obstructed mic (that would be low noise, not exact 0.0). We also found two existing threads describing what looks like the same symptom: https://developer.apple.com/forums/thread/834950 https://developer.apple.com/forums/thread/808072 Both of those are PushToTalk apps where the system activates the audio session, and an Apple engineer notes it may be related to a CallKit issue (r.157725305). For context on our side: we do use CallKit, but only CXCallObserver — purely to detect whether a phone call comes in while a recording is in progress, so we can pause and resume around it. We do not use CXProvider or PushToTalk, and we activate our own AVAudioSession ourselves with setActive(true). I'm trying to understand whether there are other scenarios or device states that could leave a running AVAudioEngine tap returning all-zero buffers like this, and whether this is the same underlying CallKit issue (r.157725305) from those threads . And since nothing throws an error, any guidance on how to detect this at runtime and recover from it would be really helpful.

Hello! Thank you for bringing the new iPhone experience with the PushToTalk framework. I have a working walkie talkie app based on the PushToTalk framework. Everything works fine except for an intermittent bug that I face from time to time on different devices with different iOS versions, from iOS 18 to iOS 26.2 Beta. Sometimes the app goes into a state where the AVAudioInputNode input node tap returns buffers with a constant size that contain only silence. Leaving and rejoining a channel helps, but relaunching or reinstalling (from Xcode) the app does not. Rebooting the device or deleting and reinstalling the app also helps. I do not activate the audio session in my app. I only configure it on launch using setCategory(.playAndRecord, options: [.defaultToSpeaker, .allowBluetooth]) So the flow is: channelManager?.requestBeginTransmitting(channelUUID: globalChannelUUID) func channelManager( _ channelManager: PTChannelManager, channelUUID: UUID, didBeginTransmittingFrom source: PTChannelTransmitRequestSource ) func channelManager( _ channelManager: PTChannelManager, didActivate audioSession: AVAudioSession ) { /// ... installTapAndStart() } private func installTapAndStart() { let inputNode = audioEngine.inputNode let hardwareFormat = inputNode.outputFormat(forBus: 0) guard let targetFormat = AVAudioFormat( commonFormat: .pcmFormatFloat32, sampleRate: configuration.audioSampleRate, channels: configuration.audioChannelsCount, interleaved: true ) else { handleError(RecorderError.invalidAudioFormat) return } let converter = AVAudioConverter(from: hardwareFormat, to: targetFormat)! print("[QUICOpusRecorder]: installTap") inputNode.installTap(onBus: 0, bufferSize: tapBufferSize, format: hardwareFormat) { [weak self] buffer, _ in guard let self else { return } // Here I handle audio data and sometimes get silence } //... do { audioEngine.prepare() try audioEngine.start() } catch { print(" ⚠️ Audio engine start error: \(error)") handleError(error) } } Moreover, if the app is in the foreground and PushToTalk gets stuck in this “silence bug”, I can avoid relying on the PushToTalk flow and simulate audio session activation manually in code. In this case I do not request a transmission and do not use any PushToTalk related code, and the app captures audio data perfectly. Once I leave the channel and rejoin it again, the issue is fixed and I start to receive non silent buffers of varying size, as expected. It works for a while. It can work fine for a day or more, communicating without launching the app, or with the app in the foreground. But it can also go into the “silence” state 30 minutes after working normally. I have no clue why this happens. The only thing I notice is that when the app is in this “stuck silence bug” state, iOS does not play its “chirp” system sound when audio recording starts. P.S. Channel descriptor restoration code: extension PushToTalkEngine: PTChannelRestorationDelegate { public func channelDescriptor(restoredChannelUUID channelUUID: UUID) -> PTChannelDescriptor { print("☀️ \(#function) channelUUID: \(channelUUID)") Task { @MainActor in // Here I fetch more detailed channel data asynchronously do { await initChannelManagerIfNeeded(channelUUID: channelUUID) let channelDescriptor = currentChannelDescriptor() lastChannelDescriptorName = channelDescriptor.name try await channelManager?.setChannelDescriptor( channelDescriptor, channelUUID: channelUUID ) } catch { handleError(error) } } return PTChannelDescriptor(name: "Loading...", image: nil) } } private func initChannelManagerIfNeeded(channelUUID: UUID? = nil) async { guard let channelUUID = channelUUID ?? currentUser?.globalChannelUUID else { print("❌ No global channel uuid found") return } do { guard channelManager == nil else { try await channelManager?.setTransmissionMode(.halfDuplex, channelUUID: channelUUID) return } channelManager = try await PTChannelManager.channelManager( delegate: self, restorationDelegate: self ) try await channelManager?.setTransmissionMode(.halfDuplex, channelUUID: channelUUID) } catch { handleError(error) } }

Hi I developed a music app that plays offline audio and displays lyrics using Live Activities. According to ActivityKit documentation, Live Activities can be updated from the background. However, in my case, updates stop after ~30 seconds when the app goes to the background or the device is locked. Important points: The app continues running in the background (audio playback works fine using AVAudioSession with .playback) Background code execution is working as expected Only the Live Activity stops updating I am not using push updates since this is an offline app. Is there any limitation or requirement for updating Live Activities continuously in the background during audio playback? Audio Session Configuration let session = AVAudioSession.sharedInstance() try session.setCategory( .playback, mode: .default, options: [.mixWithOthers] // ✅ DO NOT interrupt other audio ) try session.setActive(true) print("✅ [AudioSession] Activated with mixWithOthers") } catch { print("❌ [AudioSession] Error: \(error)") } Live Activity Update Methods guard let activity = getLiveActivity(for: recordID) else{ print("⚠️ No Live Activity found for recordID: \(recordID)") return } guard activity.activityState == .active else { print("⚠️ Activity is not active") return } Task { let content = ActivityContent( state: state, staleDate: Date().addingTimeInterval(60 * 60 * 12), relevanceScore: 1.0 ) await activity.update(content) print("✅ Live Activity updated with ActivityContent") } }

I’m seeing a Bluetooth call audio routing issue on a new iPhone 17 Pro running iOS 26.5.1, build 23F81. Bluetooth media audio works normally. Music and video audio stay on Bluetooth headphones without issues. The problem appears only when the device switches into call audio / HFP mode. Tested with multiple earbuds: Samsung, OPPO, Huawei and CMF Buds Pro 2. The behavior is similar with all of them. There are no other Bluetooth devices connected. Call Audio Routing is already set to Bluetooth Headset in Accessibility settings. The issue affects cellular calls, FaceTime Audio, Telegram and Signal. In some cases the earbuds seem to switch into call mode, but the call audio route falls back to the iPhone receiver or speaker instead of staying on the Bluetooth headset. After the call ends, Bluetooth media audio returns normally. I captured a sysdiagnose right after reproducing the issue. Relevant observations from the logs: Device: iPhone18,2 iOS: 26.5.1 Build: 23F81 Sysdiagnose time: 2026-06-03 11:22:03 +0300 In Bluetooth/CoreCapture/bluetooth_status.txt, Bluetooth was ON 3 paired devices were present 1 device was connected Connected device at the time: CMF Buds Pro 2 So the headset was not simply disconnected from the phone. In the powerlog, before the call the audio route was HeadphonesBT for media playback. Around the FaceTime Audio test, HeadsetBT / PhoneCall appeared, but then the route moved to ReceiverAndMicrophone / Speaker instead of staying on HeadsetBT. During a later cellular call, the active PhoneCall route was also ReceiverAndMicrophone rather than HeadsetBT. After the call ended, the route returned to HeadphonesBT for media playback. This looks like the Bluetooth connection remains alive, but call audio / HFP routing fails. The same sysdiagnose also contains CentauriFirmwareEvent entries under crashes_and_spins from the previous day. They show: subsystem = BT host-reason = firmware crash BTMAIN panic faulting_task = link_manager_thread LMAC_5G watchdog expired SCAN watchdog expired These firmware crash events do not happen at the exact same timestamp as the call test, so I’m not claiming that every call directly crashes Bluetooth firmware. But the sysdiagnose shows both incorrect Bluetooth call audio routing and separate BT firmware crash events. Has anyone seen similar behavior on iPhone 17 / iOS 26 with Bluetooth HFP call audio? Could this be a known iOS 26 / Apple N1 / Bluetooth firmware issue, or does it look more like a hardware defect of this particular device?

Title AVAudioSession microphone recording changes Bluetooth audio route in vehicle Hi everyone, I’m developing an iOS app called HearSave to help drivers safely remember and save songs they hear while driving. The app performs a very simple task: the user presses a button, the app records a short audio sample for music recognition, then immediately stops recording. I’m trying to understand whether the behaviour I’m seeing is an expected limitation of iOS audio routing or whether there is a better AVAudioSession configuration. Test setup iPhone connected to a vehicle via Bluetooth. Vehicle playing DAB radio. App requests microphone access and starts recording. Recording lasts approximately 7 seconds. Behaviour observed As soon as recording begins: The vehicle changes into a voice-call style audio route. DAB audio becomes muted. The vehicle’s volume control changes to voice volume. When recording finishes, the radio does not automatically recover until the user manually changes the audio source away from DAB and back again. I’ve experimented with several Expo Audio / AVAudioSession configurations, including releasing the audio session immediately after recording and adjusting audio session options, but the behaviour remains the same. My questions Is this expected behaviour when an iOS app starts microphone recording while connected to a vehicle over Bluetooth? Is there an AVAudioSession configuration that allows brief microphone capture without causing the vehicle to switch audio routes? Is it possible to explicitly use the iPhone’s built-in microphone while remaining connected to the vehicle via Bluetooth? If this behaviour is unavoidable over Bluetooth, is this also expected behaviour for native CarPlay apps, or are different audio routing capabilities available to CarPlay applications? Any guidance or documentation would be greatly appreciated. Thank you.

I can reproduce the bug that CallKit doesn't active audiosession after the outgoing call put on hold because of an incoming call. VoIP calling with CallKit Steps to reproduce: Download SpeakerBox example app from the link above and start it with XCode Start a new outgoing call Call your phone from other phone Hold and Accept the call After a few secs finish the call from the other phone The outgoing call will be still on hold Click on the call and click Toggle Hold The call won't be active again because the audiosession is activated. Logs: Received provider(_:didDeactivate:) Received provider(_:didDeactivate:) Received provider(_:didDeactivate:) Received provider(_:didDeactivate:) Received provider(_:didDeactivate:) Requested transaction successfully Starting audio Type: stdio AURemoteIO.cpp:1162 failed: 561017449 (enable 3, outf< 1 ch, 44100 Hz, Float32> inf< 1 ch, 44100 Hz, Float32>) Type: Error | Timestamp: 2024-08-15 12:20:29.949437+02:00 | Process: Speakerbox | Library: libEmbeddedSystemAUs.dylib | Subsystem: com.apple.coreaudio | Category: aurioc | TID: 0x19540d AVAEInternal.h:109 [AVAudioEngineGraph.mm:1344:Initialize: (err = PerformCommand(*outputNode, kAUInitialize, NULL, 0)): error 561017449 Type: Error | Timestamp: 2024-08-15 12:20:29.949619+02:00 | Process: Speakerbox | Library: AVFAudio | Subsystem: com.apple.avfaudio | Category: avae | TID: 0x19540d Couldn't start Apple Voice Processing IO: Error Domain=com.apple.coreaudio.avfaudio Code=561017449 "(null)" UserInfo={failed call=err = PerformCommand(*outputNode, kAUInitialize, NULL, 0)} Type: Notice | Timestamp: 2024-08-15 12:20:29.949730+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d Route change: Type: Notice | Timestamp: 2024-08-15 12:20:30.167498+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d ReasonUnknown Type: Notice | Timestamp: 2024-08-15 12:20:30.167549+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d Previous route: Type: Notice | Timestamp: 2024-08-15 12:20:30.167568+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d <AVAudioSessionRouteDescription: 0x302c00bc0, inputs = ( "<AVAudioSessionPortDescription: 0x302c01330, type = MicrophoneBuiltIn; name = iPhone Mikrofon; UID = Built-In Microphone; selectedDataSource = (null)>" ); outputs = ( "<AVAudioSessionPortDescription: 0x302c004d0, type = Receiver; name = Vev\U0151; UID = Built-In Receiver; selectedDataSource = (null)>" )> Type: Notice | Timestamp: 2024-08-15 12:20:30.167626+02:00 | Process: Speakerbox | Library: Speakerbox | TID: 0x19540d

I created a minimal sample project that reproduces a microphone issue with nearby SharePlay / Window Sharing on Apple Vision Pro. Sample project: https://github.com/JerryNee/mic-demo Screen recording: https://youtu.be/aMj_A_leJWU Issue I first implemented SharePlay through FaceTime and found that local microphone capture was unavailable. That seemed understandable because FaceTime itself uses the microphone. I then moved the app to a nearby SharePlay / Window Sharing session specifically to avoid a FaceTime call, but local microphone capture still fails. Local microphone capture works before starting nearby SharePlay. After starting a nearby SharePlay / Window Sharing session with GroupActivities, the same app fails at: try audioEngine.start() This does not require a FaceTime call. It happens with an in-room nearby SharePlay / Window Sharing session. The screen recording also goes silent when the Share Window UI appears. I checked the MP4 audio track with ffmpeg silencedetect; audio becomes silent at about 00:00:22.60, matching the moment nearby sharing starts: silence_start: 22.600612 silence_end: 55.051927 | silence_duration: 32.451315 Environment Two nearby Apple Vision Pro devices Xcode device list: visionOS 27.0 and visionOS 26.5 Xcode 27.0, build 27A5194q Frameworks: GroupActivities, AVFoundation, Speech Entitlement: com.apple.developer.group-session Microphone and speech recognition permissions granted Steps Run the sample on Apple Vision Pro. Tap Start Listening and speak. Transcription works. Tap Stop Listening. Tap Start Nearby Session. Share with another nearby Apple Vision Pro. Tap Start Listening again while the nearby session is active. audioEngine.start() fails. Ending the nearby session makes microphone capture work again. Minimal microphone code let recognizer = SFSpeechRecognizer() let audioEngine = AVAudioEngine() let request = SFSpeechAudioBufferRecognitionRequest() request.shouldReportPartialResults = true let session = AVAudioSession.sharedInstance() try session.setCategory(.record, mode: .measurement, options: [.duckOthers]) try session.setActive(true) let input = audioEngine.inputNode let format = input.outputFormat(forBus: 0) input.installTap(onBus: 0, bufferSize: 1024, format: format) { buffer, _ in request.append(buffer) } audioEngine.prepare() try audioEngine.start() Minimal nearby SharePlay code struct MicDemoActivity: Codable, GroupActivity, Transferable { static let activityIdentifier = "com.example.mic-demo.nearby-mic-repro" static var transferRepresentation: some TransferRepresentation { CodableRepresentation(contentType: .micDemoActivity) } var metadata: GroupActivityMetadata { var metadata = GroupActivityMetadata() metadata.type = .generic metadata.title = "Mic Demo Nearby Session" return metadata } } for await session in MicDemoActivity.sessions() { session.join() } _ = try await MicDemoActivity().activate() Questions Is local microphone capture expected to be unavailable during a nearby SharePlay / Window Sharing session? Is screen recording audio expected to become silent during nearby sharing? What is the recommended way to support nearby shared UI/state while still allowing local voice input?

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.

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?