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.
Did I just see that Chrome is now supporting a WebRTC compliant browser that works in in some version of Android? Does this mean number 1 might be moving faster than you anticipated? Good quality video conferencing (VP8 is good enough for some use cases but not for others) that works natively in a browser on an android or iOS device is really big deal for some use cases versus having to download an app.
I will be the first one to be happy about being wrong, but there’s still a way to go here.
This is in Chrome Beta, when Chrome itself isn’t part of what is being provided as part of the Android OS and is rather a downloadable browser in most cases. I assume it will change with time, but when and how will it be provided and on which handsets and tablets – that’s yet to be seen.
VoIP is basically a stack of protocols namely SIP,RTP,STUN,ICE, and so on. Now WebRTC replaces most of the previously mentioned protocols except SIP, where we can use SIP or XMPP or our custom one for signalling to complete the new WebRTC based VoIP stack.
Ok, now WebRTC is lightweight because it is written in js and more advanced than previous solutions, what benefit it is going to give for a native app in mobile(iOS), because here WebRTC is not reducing any redundancy or overhead of plugins as it do in WebBrowsers as long as native mobile VoIP app don’t wanna communicate with desktop web interfaces?
Please throw some light if my assumptions are wrong?
Building an app still requires you to use a media engine. Best one in town is the one you find in WebRTC. I know of several companies who have used it for that purpose.
While you might need an app on a phone, you may still want to run on the desktop, and there, the ability to use the web is helpful – so having the same approach on both mobile and desktop when it comes to the media system and the signalig makes perfect sense.
There are apps who use HTML5 for cross development. What happens when PhoneGap, Appcelertor or any other cross platform development solution for mobile starts offering WebRTC JS APIs?