See this discussion WebRTC running from WKWebView AVAudioSession development roadblock
I added these recent notes:
It might not be helpful. But I fought with this issue for years on a WkWebView based app.
Due to changes Apple made in WkWebView it runs in a different thread than CallKit. That's what I figured out after a lot of work debugging native code and using SWIFT to control CallKit.
Long story story short, AVAudioSession on the main SWIFT-APP thread that where CallKit was being managed is, due to being on a separate thread, independent from the AVAudioSession in the WebRTC code running in the WKWebView.
As a result the two FIGHT with each other. Further the CallKit authorization of the Microphone and Speakers etc for the main-thread SWIFT code does not have any relationship nor does it propagate to the AVAudioSession etc in the WKWebView WebRTC.
Roll back a little in time and this was never a problem. Because the WebView used to be on the same thread.
So AFAIK the WebRTC in a WKWebView is not integratable with CallKit since they are now segregated on different AVAudioSessions and there USED TO BE no way to access the WKWebView thread's AVAudioSession.
But in iOS 16.4 release notes there is brief mention of Support for a subset of the AudioSession Web API.
For which is there a brief explanation here in this WKWebView AudioSession explainer.
And in iOS17+ you can verify that window.AudioSession and navigator.audioSession both exist.
So, perhaps there is finally some movement on this problem.
I have filed WebKit radar bugs regarding this. If you care or have this issue, then I encourage you to also file bugs.
See also: WebKit sources
- WKWebView runs on a separate thread, which means separate memory is allocated to WKWebView. If WKWebView exceeds its memory, then it only crashes the web view but not the app.
- WKWebView uses the latest javascript engine and thus renders the page faster than the older UIWebView javascript engine.
