A Trick for Making WebRTC Work on iPhone From Any Browser
Abusing URL Schemes for an Improved User Experience
User experience is everything.
If you’re a web developer building a video streaming feature that works well on mobile browsers, you’ve probably already encountered the WebRTC limitation that exists on iPhone. If not, it’s essentially this: although WebRTC is supported in all flagship browsers (and has been since 2016) on iOS, it only works in Safari.
The Problem
RTC is short for “real-time communication,” and WebRTC is the open standard that supports video, voice and generic data communication between peers on the web. In theory, the open-source project is supported by Apple, Google, Microsoft and Mozilla — but in practice, all iOS devices will show a cryptic error message if you try to use WebRTC in any browser other than Safari.
The error message even exists on streaming giant Zoom, and is no doubt the source of many users thinking, “It’s not working!”
This is because iPhone does not expose getUserMedia in WKWebview, but in a private API, inaccessible to developers. To further complicate things, Safari also doesn’t register a URL like other browsers, so while you might be able open a link in Firefox via firefox://your-url, Safari has no such method, so this trick wont work.
But you’re on the right track.
The Solution
In general, the problem isn’t that WebRTC doesn’t work on iPhone, it’s that the users preferred browser may not support it — so our solution will be to move the user to Safari, without making them do a bunch of work, like manually copying a link or opening a new browser themselves.
To accomplish this, we will use URL schemes, which allow developers to target specific apps, even from within other apps. Just as you would expect https:// to open a webpage, imovie:// will attempt to open your URL in the iMovie app and tel:// will open the phone. Although you may have only encountered a few of the more common ones like mailto://, there are hundreds of URL Scheme’s which can be used to used to manipulate apps.
We already know that you can’t target Safari directly, but comparing the schemes available on popular iPhone browsers, it becomes apparent that Safari has some unique options that no other browser understands.
Google Chrome
googlechrome://Firefox
firefox://
firefox://open-url?url=Safari
x-web-search://
ftp://LocationToFileOnFtpServer
http://WebsiteURL
https://WebsiteURLThis is important, because if Safari is the only browser that can understand a scheme, it means it is also the de facto way to open it.
The Trick
The option we want to pay attention to here is ftp://, the “file transfer protocol” which originally came into existence in the 1970’s.
FTP is an interesting technology, partly because of it’s age and relative lack of updates (the last major security extensions included the introduction of IPv6 and NATs — in 1998) and partly because of its varied capabilities. In particular, the ability to serve files, and a modern browsers ability to read them.
If you were trying to host a consumer-facing webapp from an FTP server, it probably wouldn’t make a lot of sense. Although users might be able to browse the page, there’s no way to bypass the Same Origin Policy, so form interactions, JavaScript-based uploads, and other common webapp interactions are impossible — but if you’re just trying to abuse the scheme to make Safari open, it’s perfect.
To be clear, this is a trick, a hack, a workaround.
The goal is to improve the user’s experience. Worst case scenario, users click a link in the document hosted on your FTP server that will then open the actual https://URL where the stream is taking place. However, by adding a little bit of JavaScript, you could improve this experience even further by opening a new tab automatically, facilitating a more-or-less seamless WebRTC experience on iPhone, instead of an error message.
Update 12/22/2020: New updates to iOS FTP protocol support may make this trick difficult or impossible in future versions of iOS. This is a hack.
