WebRTC on mobile is going to be different than on the desktop.
On the desktop we’ve got things covered for WebRTC: Google Chrome is there for the most part, Firefox is headed in that way, Microsoft IE and Apple’s Safari are not to be seen – at least not now. Our consumption model on desktop for WebRTC is also known – it is going to be through the web browser itself.
But what about mobile?
There’s no smartphone shipping with WebRTC support in it, and no publicly known roadmap for such support from any of the vendors. There’s Ericsson’s Bowser supporting WebRTC, but
I’d hardly call it support.
In mobile, there are 3 possible consumption modes for WebRTC:
- The native browser
- A browser app
- An app
1. The native browser
The native browser isn’t going to be ready any time soon with WebRTC.
- Apple aren’t going to make an appearance with one
- Microsoft has missed their opportunity in Windows Phone 8 – they will do WebRTC later. Probably a lot later
- Android doesn’t have it yet, and when it will, fragmentation will make sure it won’t be commonplace in quite some time
2. A browser app
We have one. It is called Bowser. From Ericsson. The last time I checked, stories about it had more retweets than it has downloads. On Android, it is 1,000-5,000 downloads. A bit less than the 73% market share that Android has in smartphones today…
What will happen when Opera adds it? Or the Dolphin browser? Or some other widely used browser?
Nothing.
Downloadable browsers aren’t that common or used today. And who in his right mind is going to ask his customers to download a specific browser for his phone in order to surf to his website?
3. An app
The most common consumption model today on mobile is the app. With over 700K applications in both Apple App Store and Google Play, this is where I see WebRTC playing. And in such a case, why should it even be WebRTC?
On mobile, WebRTC will be WebRTC and no other solution simply because it makes the lives of developers using WebRTC for their desktop app a lot easier – single interface to treat both desktop and mobile.
How will it get there?
- By telephony API platforms, in the form of an SDK. Tokbox has one. AddLive has one. You can expect Twilio and Voxeo to come up with their own SDKs as well. This might not be pure WebRTC APIs on top, but who cares?
- App developers, who will be doing the porting on their own and integrating it into their apps natively. In such a case, they will “unwrap” WebRTC in the source and just use the C++ APIs of the native library itself. I know of a few that have done just that already.
- Cross platform tools. This is where I think the interesting things will happen. When the likes of Appcelerator, and PhoneGap who offer HTML5 wrapper with native API layers come up with WebRTC support, web developers will be able of doing the same type of development for both mobile and desktop. It will also add a lot of value to these platforms and an edge over the others in their crowded space.
-
The app model will be the one that will rule mobile in the coming years. While this may change, don’t expect it to happen in 2013.
You may also like
Twilio Programmable Video is back. Twilio decided not to sunset this service. Here’s where their new focus lies and what it means to you and to the industry.
Read More
Struggling with WebRTC POC or demo development? Follow these best practices to save time and increase the success of your project.
Read More