Bug 183201 - Support WebRTC in Safari in-app browser
Summary: Support WebRTC in Safari in-app browser
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebRTC (show other bugs)
Version: Safari 11
Hardware: iPhone / iPad iOS 11
: P2 Normal
Assignee: Nobody
Keywords: InRadar
Depends on:
Reported: 2018-02-28 02:18 PST by daginge
Modified: 2020-01-11 10:07 PST (History)
29 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description daginge 2018-02-28 02:18:08 PST
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.
Comment 1 Radar WebKit Bug Importer 2018-02-28 09:34:17 PST
Comment 2 Radar WebKit Bug Importer 2018-02-28 09:34:24 PST
Comment 3 youenn fablet 2018-02-28 09:47:23 PST
Hi Daginge,

This is a known limitation.
PeerConnection should work but not yet getUserMedia unfortunately.
Comment 4 daginge 2018-02-28 23:30:42 PST
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.
Comment 5 daginge 2018-05-02 05:27:56 PDT
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...
Comment 6 Ben 2018-06-01 09:27:31 PDT
@daginge can you explain how you detect in-app browser and switch to Safari?
Comment 7 daginge 2018-06-12 18:54:30 PDT
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...
Comment 8 daginge 2018-08-29 00:37:28 PDT
Any news on support in Safari in-app for the next release?
Comment 9 Raship Shah 2018-09-18 14:31:09 PDT
+1 for this feature
Comment 10 gtk2k 2018-10-04 03:49:46 PDT
Comment 11 Sebastian 2018-11-07 04:12:49 PST
Comment 12 tim 2018-11-13 08:43:42 PST
+1 for this change, we have the same problem with IOS 12 here, we don't have any WebRTC support inside in app browsers.
Comment 13 bertrand 2018-11-14 00:39:36 PST
Same here (ios 12.1), cannot make the camera work when using HTML5 manifests. It's a big problem for us as we can't distribute our app as expected. Thanks.
Comment 14 tim 2018-11-14 03:58:58 PST
just send a simple like to: https://webrtc.github.io/samples/ over hangouts for example and click in it.
None of the demo's would work.

You can also try https://appr.tc/ which won't work also (IOS 12.1).

can we get some response from the Dev team here? all examples are working in in-app Android browsers.
Comment 15 tim 2018-11-14 04:53:24 PST
it looks like turn and stun servers are failing to run onicecandidate on every WKWebView.

We even tried Chrome and Firefox for IOS but since they are both built on WKWebView, they also don't work.

We managed to get WEBrtc to work only with Safari when it is NOT an in app browser mode.
Comment 16 youenn fablet 2018-11-14 06:39:48 PST
navigator.mediaDevices.getUserMedia is not yet exposed/working in SafariViewController/Web.app and WKWebView.

RTCPeerConnection should be working though.
I am surprised that STUN/TURN servers are not working properly.
Comment 17 sampo.juustila 2018-11-15 01:06:48 PST
Comment 18 tim 2018-11-23 04:29:33 PST
(In reply to youenn fablet from comment #16)
> navigator.mediaDevices.getUserMedia is not yet exposed/working in
> SafariViewController/Web.app and WKWebView.
> RTCPeerConnection should be working though.
> I am surprised that STUN/TURN servers are not working properly.

we've tried both turn and stun servers, no matter what we do, in an in-app mode onicecandidate is never fired.

we manage to setLocalDescription and setRemoteDescription and that's it, nothing happens.

on Safari, and any other android/in app android browser it is working.
Comment 19 tim 2018-11-25 00:21:21 PST
any news regarding this from an official webkit dev?
if you all say that turn and stun should work in an in app browser we would love to see a live example, the same code that is working on Safari isn't working inside wkWebView
Comment 20 youenn fablet 2018-11-26 14:10:59 PST
(In reply to tim from comment #19)
> any news regarding this from an official webkit dev?
> if you all say that turn and stun should work in an in app browser we would
> love to see a live example, the same code that is working on Safari isn't
> working inside wkWebView

I tried loading https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ in a WKWebView using https://itunes.apple.com/us/app/webview-wkwebview-and-uiwebview-rendering/id928647773
I was able to gather a srflx candidate.

Note that by default, host candidates are not exposed.
Note also that if a connection is created using a peer reflexive candidate, there might be no srflx candidate being exposed at all.

Tim, could you create a repro case?
Comment 21 Jaroslav Bauml 2018-11-28 01:38:09 PST
Comment 22 Takahiro Ichihashi 2019-01-30 05:20:38 PST
Hello, do/can you see a chance to discuss this problem regarding next milestone (maybe Safari 13)? I noticed this compatibility issue recently and potential impact to the ecosystem seems enormous... :)
Comment 23 Dan 2019-02-18 08:18:21 PST
Comment 24 Jason DeVries 2019-03-04 17:22:00 PST
+1 On getting this finally implemented sooner rather than later. Difficult to showcase speech-to-text functionality on a website when a lot of advertising is social media based which usually results in users trying to visit the website in an in-app browser session. If it doesn't work... doesn't grab their attention in the first second, they'll likely just close it rather than reading they need to open in Safari.
Comment 25 Kara 2019-03-12 20:14:57 PDT
I would also love to know the status of this. Surprised it hasn't been prioritized higher given that a significant amount of traffic is through the in-app browser. Is there a plan to get it added in an upcoming release?
Comment 26 Stefan Sechelmann 2019-06-12 14:26:46 PDT
Comment 27 Alojz Milicevic 2019-06-25 13:45:00 PDT
Comment 28 daginge 2019-06-25 23:29:07 PDT
For everyone following this bug, I'm happy to say that Safari in-app (SFSafariViewController) now supports getUserMedia in iOS 13, which in turn means that full WebRTC support has been reached.

To feature test between old and new Safari in-app, check for the presence of RTCPeerConnection and navigator.mediaDevices.getUserMedia. If only RTCPeerConnection is present, it should be Safari in-app in iOS 12 or earlier. If both are present, you are in Safari in-app (well, Safari since at that point there's no way of distinguishing them) on iOS 13+.


(But no, still no support in WKWebView, which means Chrome/Firefox/Other browsers on iOS are still being blocked from using webcam)
Comment 29 Maciej Stachowiak 2020-01-06 21:37:33 PST
Marking this as resolved since SFSafariViewController now supports getUserMedia. Might be worth filing separate bugs for other WKWebView clients.
Comment 30 Mike 2020-01-11 10:07:21 PST
For those that were tracking this specifically for WKWebView and not SFSafariViewController, you may want to start watching #188360: