WebRTC on Chrome, Firefox, Edge and others on iOS

Starting iOS 14.3, it’s now possible to use Chrome or an alternative WebRTC compliant browser to Safari to have audio and video calls with an iPad or an iPhone. It’s a great improvement that will help us to build Web application on mobile devices.” slug: “webrtc-chrome-ios-compatibility

Introduction

Having the possibility to use my favorite browser on my iPad to connect to my WebRTC application was really something I expected a lot. Not really for my personal usage but because it easier to let end-users connect to my Web application with the browser they like and not have to force them to use a browser they don’t really use.

I was waiting and although I was following all the WebRTC news on the Internet, I missed the announcement… It was working from several months and I were not aware of that compatibility!

That’s why, I tried to summarize what I learned from that story to that post.

Main reasons for being missed

In fact, they were 2 main reasons for that: Firstly, there was no real public announcement about that compatibility made by Apple and relayed by the community and secondly, the way I blocked my application from being used from no compliant browsers on iOS was a ‘blocked-for-ever’ strategy.

Regarding on the public announcement, I searched on the official Apple release notes but the one from iOS 14.3 was really light on that point: Nothing was announced. I found some public signals made by the community but I missed them: I didn’t pay attention to that post from Lee Martin on Twitter who mentioned it. It was then mentioned again in the latest Kranky Geek event in April’21, but I missed it again. I forgot to watch the live from Donal Toomey from Twilio: Making WebRTC on the Mobile Web Wonderful. Finally, I discovered the compatibility by testing the WebRTC API recently on my iPad and was surprised of the result…

In fact and after reading again the Webkit blog, I found the post that mentioned it. The post was related to support of the MediaRecorder API but the end of the article was dedicated to getUserMedia in WKWebView. I think I had read it before but didn’t understand the impact because there is not mention of other browsers…

Then, the second reason that explains that I was not aware was because I have chosen to block connections from any browsers except Safari on my WebRTC application when using an iPad or an iPhone. Simply because I knew that it was not working. Doing that way, I was sure to never have users with a such browser and so to control my supported list of browsers and avoid any issues in production with a browser not yet ‘qualified’: I was confident with that power. I could have chosen the other strategy which consists to check the availability of the WebRTC API and to block in case of not available. But this is complicated in our case: The getUserMedia API was available but always returns a notAllowedError error… And as there are the RTCPeerConnection API, the RTCDataChannel API, etc…, do I have to check all the WebRTC API offered by my Web application to allow or disallow some features with a fine granularity ? But using a such strategy could allow end-users to use this new compliant browser as soon as the WebRTC API are available. But again, if end-users connect to your application before you had time to qualify that new case, you can be sure that they will report issues to your support team…

WebRTC on IOS: the long tail…

On an Android device, this was never a big challenge to develop and support a WebRTC Web application on the commonly used browsers. The only exception was when using the default Android browser or WebView in system prior to 5.0. But in Android version supported today, Chrome, Firefox, Edge and a lot of other browsers are compatible with WebRTC and developing on these platforms is not so complicated.

The story is not the same on IOS.

The story started by the feat of some guys including Dr. Alex Gouillard who absolutely would like to have WebRTC in Safari. Back in 2015, they started to work on adding the support of WebRTC in a fork of Webkit (based on OpenWebRTC/GStreamer). Finally, in late 2016, Apple decided to implement WebRTC to its own port of Webkit (using Google libWebRTC).

Apple started to release a Safari version 11 compatible for MacOS 10.11 El Capitan, In fact, developers had the opportunity to test it just before with Safari Technology Preview 32.

On mobile and tablet, Apple started to introduce the support of WebRTC in the equivalent Safari version 11 linked to iOS 11 which was released in September’19 2017. Before that, there was no way to support WebRTC in any browsers on iPad and iPhone. The only possibility was to build a native iOS application that embeds the WebRTC stack.

Note: Announcing WebRTC and Media Capture

Starting iOS 11, it was possible to develop WebRTC application on Safari but it was really complicated due to the limited cases that work well and that were compatible with the other browsers.

Note: Guide to WebRTC with Safari in the Wild

Safari added the support of WebRTC through LibWebRTC. But in opposite to Google and Firefox, IOS 11 came with only one video codec available which was H.264. Note: Even if the IETF-88 meeting held in Vancouver in late 2013 failed to find an agreement, the proposal was to have 2 MTI (Mandatory to Implement) audio and video codecs: VP8 and H.264 for video and Opus and G.711 for audio. But Safari decided to propose its first version with only H.264. The reason announced was understandable: Most mobiles have hardware compliant with H.264 (decoder and encoder) but not for VP8.

Note: MTI Video Codec: a novel Proposal

Note: IETF: WebRTC Video Processing and Codec Requirements

As announced in the Webkit blog A closer look into WebRTC, RTCPeerConnection and RTCDataChannel API was available in iOS 11 in any Web View but the access to the camera and microphone was limited to Safari. That point was not understandable by developers…

That point was terrible because a lot of cases were not accessible. First, you can’t use WebRTC on iOS to develop a Web application that runs on Chrome, Firefox or any alternative browsers: Only Safari was compatible. Second, you can’t use WebRTC on iOS to develop a hybrid application using a WKWebView: getUSerMedia does not work in WKWebView-based browsers. And finally, as mentioned in that issue Support WebRTC in Safari in-app browser, it was not possible to access to a Web application from a link in an e-mail because it opens the Safari in-app version of the browser that was not compatible: getUserMedia API was not supported.

Note: Safari: A closer look into WebRTC

It was not a really good start…

With iOS 12, especially iOS 12.2, there were some improvements. Some people said that WebRTC starts to be ‘usable’ on Safari (mobile or desktop) from that version. But the same restrictions were still here regarding the browsers support. Some of the major changes were the introduction of the VP8 video codec, the work done for supporting Simulcast and the first experimental support of the screen capture API. This was resumed in that Webkit post On the Road to WebRTC 1.0, Including VP8.

We found that, on an iPhone 7 Plus in laboratory conditions, the use of H.264 on a 720p video call increases the battery life by up to an hour compared to VP8.

With iOS 13, one of the major bugs were fixed: WebRTC was now available in SFSafariViewController which means that the Safari in-app browser can now handle WebRTC request correctly.

Notes: Three Things I’m excited about In Safari 13

Other improvements that come with iOS 13 were the support of DTMF and Corporate Proxy. In the opposite, one of the most issue I encountered using Safari 13 was the lack of MediaRecorder API. Hopefully, using a shim it was possible to have something that works.

Last year, iOS 14 has been released. From my point of view, I saw that Safari little by little has closed the gap and I didn’t fear anymore to test scenario between Safari and other browsers. My personal feeling is that Safari is now at WebRTC level 1.0. And as for other browsers, adapter.js help to close the gap that persists today.

But, there is still pain points such as the following bug that mutes the existing local track when requesting a new one: iOS calling getUserMedia() again kills video display of first getUserMedia(). Bug opened since Safari 11 in nov’17.

And here we are: iOS 14.3 allows any WebRTC browsers to access the devices…

WebRTC support in Chrome, Firefox, Edge and others in iOS

The consequence of this change is that you can now use Chrome, Firefox, Edge or any WebRTC compliant browsers on an iPad or and iPhone running iOS 14.3 or higher to connect to your WebRTC application. It will work.

At that time of writing, I didn’t see issues with cases I managed. But I didn’t pass a lot of tests since I discovered that it works.

What I saw by looking at the SDP is that from Chrome/Edge or Firefox, you have 2 video codecs only: H.264 as the first rank with several profiles and then VP8. So when calling from my Chrome/Ipad to my Chrome/Mac, the codec used is H.264 while calling from my Chrome/Mac to my Chrome/Ipad results in using VP8.

By testing the WebRTC samples using Chrome on my Ipad, I discovered other things that need to be confirmed:

The good:

• Basic demos work great: RTCPeerConnection
• Authorization and enumeration are limited to input devices: getUserMedia (4K), enumerateDevices
• No issue with Data Channel: RTCDataChannel,
• DTMF are supported: RTCDTMFSender

The bad:

• Output devices can’t be selected as in Chrome desktop
• getDisplayMedia seems not to be supported
• captureStreamseems not to be supported
• TransferableStreams seems not to be supported
• I didn’t succeed to run the MediaRecorder samples due to an invalid constraint (OverConstrainedError)

Debugging WebRTC in Chrome IOS

chrome://webrtc-internals is not accessible from Chrome.

At that time of writing, the best way I found is to use chrome://inspect which display the log from any tabs directly on the iPad.

Supporting users

At that time of writing, more than 70% of iPhone users can use WebRTC with an alternative browser to Safari because they are using an up-to-date version of iOS. For iPad users, about 60% have a compliant iOS version…

But today, Safari still dominates the market share on iOS with around 90%. Less that 7% of users on iOS use Chrome.

Note:: Revealing Web Browser Market Share Statistics for 2021

So adding the support of WebRTC for alternative browsers in mid’2021 targets around 10% of users.

But in term of experience and message delivered to users, supporting any browsers on iOS is priceless.

Lessons learned

Here are my key takeaways:

• Spend more time on reading and understanding announcement: Understanding WebRTC evolution is still complicated because if technical progress are not popularized, only few people are able to understand the impact. But release notes are here, just to find time to peel them.

• I have now my own sample that checks a lot of WebRTC API. I hope this should help me to easily test new browser’s versions as well as new system and see the changes. Just to continue to improve it depending on the features I work on.

And it’s now time to open the door on iOS!