WKWebView audio interrupted when app AudioSessionCategory changes

Question

TLDR: How to jumpstart a webviews audioSession without reloading its content?

Hello everyone. I am having a very specific issue with the wkwebview on iOS in regards to the AudioSession.Category management. I guess I start with that it is well understood that the wkwebview operates on its own process and therefor owns its own AudioSession. That means that any changes on the APPs AudioSession won't reflect on the webviews AudioSession.

We build an app, which is entirely web based and has to be for reasons I don't want to go into, so our IOS app is essentially a wrapper for the web content. Recent web content required us to use webrtc functionality do do audio recordings which is only available from iOS 14.3 upwards, which required us to work out a solution, which is backwards compatible down to iOS 12. The idea was to create a native audio recorder, which then interfaces with the webview to transfer audio recordings to the web content.

In order to make recordings within the app the AudioSession.Category needs to change to playAndRecord and is triggered by the webviews content through the messageHandler interface. A change of the APP category will trigger an interruption of the webview audioSession, which from then on does not play any media anymore (until a new url is loaded(single page apps do not make new requests in general)). To fix this a reload of the current url is needed to un-interrupted the sound, which can be somewhat masked behind loading screens but isn't a really good solution.

I am looking for ways to start the audio again without reloading the webview.

Thanks for any insights on this.

Answer 1

I've recently stuck with similar problem. Here is what I've found. Whenever background music like YouTube in WKWebView or Music app is playing and your app audio session category or mode (but not options [1]) is changed while app's audio session is active background audio is interrupted. Even when re-configuration of audio session is happen between mixable configurations. The solution I've found is to deactivate app audio session prior applying new configuration and activating it again. And in case of playAndRecord it is important not to forget to add [.mixWithOthers]/[.mixWithOthers, .duckOthers] option. For some reason I can't find formal documentation on this behavior but confirmed it with simple demo app which provide manual way to activate/deactivate audio session and configure it to variety of category/mode/options.

[1] It is possible to switch between [.mixWithOthers] and [.mixWithOthers, .duckOthers] on active audio session and not to interrupt background audio, if category and mode are not changed during reconfiguration.