Filing a bug since I couldn't find another bug to track progress on this. WebRTC is currently not supported in Safari in-app browser, which is making the end-user experience of going to url-based video conferencing platforms like appear.in or Confrere hard to use.
An example is that a user receives a link on e-mail or in Slack. User clicks the link and is taken to Safari in-app version of the browser. getUserMedia is not supported here, so call fails.
We want getUserMedia and other WebRTC related APIs to work in Safari in-app as well as WKWebView (I believe this is what Facebook uses?) so that WebRTC APIs may also work here.
Alternatively, an escape hatch has to be made available to open a link in "proper" Safari where we can use WebRTC APIs. Currently I have found no way of achieving this. In our user testing, regular users have difficulty finding or understanding why they have to click the little "Open in Safari" icon to make video calling work. Facebook makes matters worse by hiding this option behind a kebab menu, but to be fair, they also don't support WebRTC on Android inside Facebook Browser.
Steps to reproduce:
- Send yourself the following link in an application which triggers the in-app browser: https://webrtc.github.io/samples/src/content/getusermedia/gum/
- Observe that getUserMedia does not complete, and the frame remains black. No feedback to the user is given of this error.
This is a known limitation.
PeerConnection should work but not yet getUserMedia unfortunately.
Thanks youenn! Is there any public timeline for when this will be supported? I suspect it's a security & UX issue rather than technical limitations at this point. Support for WebRTC in the in-app browser could be critical to our product, so naturally we are very focused on this issue.
For what it's worth, these past few patches we've seen great improvements in the WebRTC platform on iOS, and are now more and more comfortable letting "regular" end users use it on a daily basis. But the link issue opening randomly in standalone Safari and sometime in-app (as seen from the user's perspective) is making the end user experience very confusing still.
Just bumping this. Will santa give me this for iOS 12? :) It's a huge limitation because most e-mail apps and calendar apps now use the in-app version, meaning we have to have ugly UI to make people click the Safari button...
@daginge can you explain how you detect in-app browser and switch to Safari?
We only detect Safari in-app, we aren't able to automatically upgrade, so we have to direct the user to do so. We detect in-app by saying: If we are on an iOS device, and the Safari version SHOULD support WebRTC, but doesn't, then we can assume it's an in-app browser and we render a specific message telling the user to click to go to the full version of Safari.
Again, it would be a MUCH better user experience if at least the in-app version of Safari supported WebRTC in the near future...
Any news on support in Safari in-app for the next release?
+1 for this feature