Ok, so, I’m trying to load something as simple as : https:// meet.jit.si/qpwpeorituy12#config.prejoinPageEnabled=false in a WKWebView app under iOS 16. The WKWebView now supports everything webrtc but jitsi dosent seam to care. The user-agent is the same as safari mobile where jitsi does work… I don’t know what kind of detection is done in the backend but it’s defective because this should work. It fails with : it looks like you’re using a browser we don’t support
Maybe I’m missing something?
Did you override the UA string? Using lockdown mode by any chance?
Yeah, UA string is overwritten but I spoofed that using proxy so that’s not how it’s detecting … and no, no lockdown mode…
We rely on UA detecting for some things. Can you try to not spoof it and try again?
Ok… no changes. Here is the test:
iframe api loaded in iOS WKWebView:
iframe api loaded in iOS Safari:
UA String in WKWebView:
Mozilla/5.0 (iPhone; CPU iPhone OS 16_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Home Assistant/2022.10.1 (io.robbie.HomeAssistant; build:2022.424; iOS 16.1.0) Mobile/HomeAssistant, like Safari
UA String in mobile Safari:
Mozilla/5.0 (iPhone; CPU iPhone OS 16_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Mobile/15E148 Safari/604.1
Webrtc test loaded in iOS WKWebView (RTCPeerConnection test working fine):
You still have a modified UA. Don’t do that and try again.
Can you check the console logs with the remote inspector please?
The remote inspector works only for Safari not the WKWebView… Also, everything seams to load properly but … jitsi server somehow don’t like something (im sure it’s a validation done on the server side) and drop that “it looks like you’re using a browser we don’t support” thingy.
The page you are loading, is it served over HTTPS?
Sorry, I’m out of ideas at the moment.