The open source VoIP engine and standards initiative, known as WebRTC, is finally starting to get some traction. Earlier this month, Slack followed Facebook Messenger’s lead and launched its voice calling feature based on WebRTC. Though exciting, this launch is limited — it only works within Slack’s desktop apps and Chrome.
We can presume it’s just in MVP mode and that Firefox support will come soon, given the minimal incremental effort to support that platform. Internet Explorer and Edge, its WebRTC-supporting upgrade, are likely a non-factor for Slack users. That leaves support for Apple’s Safari browser next on the list.
Does it matter that Safari does not support WebRTC? Safari has been lagging on the web for a while — does Apple even care?
Does WebRTC need Apple?
Safari has been a perennial thorn in WebRTC’s side. As a loyal Apple user and a WebRTC fan, I’ve been somewhat disappointed that the two are not growing closer. Depending on who is counting, Safari has roughly a 10-15 percent share of the total browser market across desktop and mobile. The stats don’t indicate that changing much over time. A flat 10-15 percent is not insignificant, but it’s not really big enough to get initial priority when developing a new web app. Does that change when your user base grows and you can afford to provide broader support?
Facebook certainly doesn’t seem to care. Try to make a call through the Messenger interface on the web with Safari and you’ll get this:
They don’t even attempt to hide the call buttons to prevent users from trying to make calls on Safari. They keep the phone and video call buttons there, enticing you to click so they can try to convince you to use another browser. If Facebook doesn’t care about supporting Safari for its 800-plus million Messenger users, it’s hard to make a case that anyone else should, too.
However, Safari is not a WebRTC developer’s biggest problem: Apple’s iOS policy is. Apple requires that you use its web-rendering engine. It doesn’t matter if you’re a small startup or Google with its Chrome browser: If you want to build an app that renders a web page, you need to use Apple’s WebView API.
Apple can monetize apps via the app store; it can’t monetize web visits through a browser.
There is no such thing as WebRTC on the mobile web for iOS. This means that Google and other developers can’t support WebRTC on iOS devices unless it’s built into a native iOS app. That is a serious blow to web advocates’ vision of a ubiquitous world wide web for all devices. From the App Store review guidelines: “Apps that browse the web must use the iOS WebKit framework and WebKit Javascript.”
Does Apple need WebRTC?
Apple has its own VoIP app that it puts on all its devices — FaceTime. The FaceTime app works just fine on Apple devices without WebRTC. Steve Jobs mentioned in 2010 that Apple would move to make FaceTime an open standard. This could have mitigated the need for the WebRTC standard in the first place. Then, in 2012, Apple was sued by a patent troll around this tech and lost. Since then, Apple has kept quiet about opening FaceTime, and there is no reason to think that will change.
Apple’s web renderer policy on iOS has the effect of forcing WebRTC developers to create iOS apps for their devices. Apple can monetize apps via the app store; it can’t monetize web visits through a browser.
WebRTC is not the only casualty of Apple’s policy (see the full list versus Firefox here). Despite the low market risk in supporting many modern web features, Safari is way behind. Apple certainly has the resources to do whatever it wants. Its huge and growing backlog is certainly an indicator that the web hasn’t been a big priority. Even if this suddenly changed, WebRTC would be just one of many features competing for internal attention.
Apple being Apple, we will never really know what is going on until they are ready to announce something.
Historically, the world’s most valuable company has not had much incentive to do anything different. If Apple can survive by ignoring web, why would it care about a single web standard like WebRTC?
Can Apple buck the status quo forever?
The short answer is “no.” Apple’s strategy of dragging down the web, and making developers’ lives more difficult, cannot be sustained indefinitely. If it pushes too much against the status quo of the rest of the market, it risks alienating its constituents rather than endearing them.
Thanks to WebRTC, VoIP calling has moved from being a magical, technical feat that few could master, to an easy-to-add feature to any app. If Safari won’t support WebRTC, developers will likely direct those customers to something other than Safari, just as Facebook has done. Apple may not have ambitions of creating the No. 1 browser, but I’m sure they would still like Safari to be competitive. With Google, Amazon, Snapchat and now Slack providing WebRTC as a feature, we’re at the point where many developers want to do the same.
Apple also has pressure on the iOS app-development front. Building WebRTC for iOS from the source repositories is a lot easier than it used to be, but it’s still not as simple as using the web APIs. To get there, WebRTC really needs to be added to iOS’s native web view, just like it is in Android with Google.
Of course, there are always third-party libraries to help in the interim, but third party and commercial is never as attractive as free and native to developers. Hopefully Apple will understand the strategic need to address WebRTC. Retaining a faithful user and developer base is at stake, and I’m not the only one considering making the switch to Android.
Does Apple want to change?
Guess what? Apple has been spotted advertising WebRTC developer roles for WebKit (its web rendering engine).
It seems Apple really is feeling the pressure. This is certainly good news for web and WebRTC advocates. Community efforts like webrtcinwebkit.org should make it much easier for Apple’s new WebRTC engineers when they are hired.
Apple being Apple, we will never really know what is going on until they are ready to announce something. Still, it seems WebRTC’s initial vision of universal browser support will be a reality at some point in the near future. It just goes to show, you can’t ignore your customers’ demands forever.