Hello everyone,
I'm implementing the new AVInputPickerInteraction API on iOS 26 to allow users to select their microphone from a custom settings menu before recording.
The implementation seems correct, but I'm encountering a strange issue where the input selection immediately reverts to the previous device.
The Situation:
The picker is presented correctly via a manual call to .present(). I can see all available inputs (e.g., "iPhone Microphone" and "AirPods").
The current input is "iPhone Microphone".
I tap on "AirPods".
The UI updates to show "AirPods" as selected for a fraction of a second, then immediately jumps back to "iPhone Microphone".
The same thing happens in reverse.
It seems like the system is automatically reverting the audio route change requested by the picker.
My Implementation:
My setup follows the standard pattern discussed in the WWDC sessions.
- Setup Code:
This setup is performed once before the user can trigger the picker.
@available(iOS 26.0, *) var inputPickerInteraction: AVInputPickerInteraction?
// Note: The AVAudioSession is configured to .playAndRecord
// and set to active elsewhere in the code before this setup is called.
if #available(iOS 26.0, *) {
// Setup the picker
let picker = AVInputPickerInteraction()
self.inputPickerInteraction = picker
self.view.addInteraction(picker) // Added to establish context
}
- Presentation Code:
When a user selects "Change Input" from my custom settings menu, I call .present() on the main thread.
// In a delegate method from a custom menu
if #available(iOS 26.0, *) {
DispatchQueue.main.async {
self.inputPickerInteraction?.present(animated: true)
}
}
What I've already checked:
The AVAudioSession is active and its category is .playAndRecord.
The inputPickerInteraction object is not nil.
The .present() method is being called on the main thread.
The picker is added to a view using view.addInteraction() in the setup phase.
I've reviewed my code to ensure there is no other logic that could be manually resetting the AVAudioSession's preferred input.
Has anyone else experienced this behavior? I suspect this might be a bug in the new API, but I want to make sure I'm not missing a crucial step in managing the AVAudioSession state.
Any insights or potential workarounds would be greatly appreciated.
Thank you.