There are now some patches on the develop branch that should help with this issue.
We kept the initially-suggested change, as it seems like a good idea to request the exact buffer size we want:
On iOS 18, we now ensure the audio device is deactivated when requesting a particular buffer size, and then activate the device and wait for it to deliver an audio callback before requesting the real buffer size. This could take a long time when querying a lot of buffer sizes, but it’s the most consistent technique we found to get the correct results.
Because querying lots of buffer sizes could take a long time, we now hard-code the list of buffer sizes on iOS 18. The list of supported buffer sizes should be treated more like a list of suggestions. It’s possible that applying a very large or very small size could fail, but the system should fall back to a sensible supported size in this case. It seems that other iOS audio apps (Logic, AUM, Loopy Pro) take a similar approach, though it’s difficult to say for sure.
This fix isn’t perfect - we still managed to trip it up by changing the buffer size lots of times in a row, but it’s definitely an improvement. The root cause of the issue is an undocumented change in the contract of AVAudioSession on iOS 18. We’ve filed an issue with Apple and will update the solution if we receive new guidance on the approach we should be using to query audio device capabilities.