Native WebRTC Mobile App Development: Tools and Tips

Native WebRTC Mobile App Development: Tools and Tips

WebRTC is an out-and-out browser based technology. When we talk about WebRTC, perhaps the most imaginative might picture some technology on a mobile or at best a native application instead of a browser-based one, however most would imagine nothing but browsers and some story around it.

Now WebRTC has gone stronger and its implementations have crossed many boundaries. WebRTC on mobile apps is no longer a fantasy. As we discussed in our previous post WebRTC is awesome and it is touted as the future of internet based communication. Here at Algoworks we have successfully created functioning mobile apps using it and they are performing better than predicted. By mobile apps we mean cross-platform compatible native WebRTC mobile apps that are capable of challenging the traditional VoIP based apps like Skype or VooDoo.

However implementing WebRTC on Mobile Platform is not as simple as it might seem at first.

Challenges in using WebRTC for Mobile

WebRTC is directly NOT dependent on any platform or device. It is a browser based API created to work in browser FOR browser based applications. Seeing the first problem here?

First, even if we focus on developing a browser based WebRTC app, not all mobile browsers supported WebRTC features like PeerConnection or MediaStream API. This is the case especially so for iOS browsers.

Second, since we have to create native WebRTC applications and not web-based ones, we would kind of need to create our own browser and then run the WebRTC API’s on them. Since not all devices support all web browsers, and not all web browser support WebRTC, clashes are bound to occur.

But apart from these obvious browser-based challenges, there are some serious device-based ones as well which are as follows:

Audio Hardware: Different devices, even in the same Operating system family, have different implementation for the microphone, speaker, and Bluetooth builds. These require some special handling from developer point of view.

Processor Limitations: WebRTC is a processor intensive API. Also most WebRTC internal APIs are supposed to be supported by at least ARMv7 CPU architecture with its NEON extension. Though Audio can be processed in CPU with NEON, video cannot. Since the old Android devices, iPhone 3G and other previous devices do not have ARMv7 CPU architecture, WebRTC’s reach becomes limited. This is the main reason why we don’t have lots of WebRTC apps lining up. But as more and more people switch to latest devices, this limitation will disappear.

Battery Problems: Once again since iPhone is a CPU-intensive application, it drains a lot of battery. Advancement in technology will also eventually remove these limitations, for example Audio Acceleration feature remarkably cuts on a lot of CPU processing and thus saves a lot of battery.

Tools to implement WebRTC on mobile

These challenges are not insurmountable. With some tinkering you can overcome most of these except the ones relating to CPU architecture. However the biggest challenge is the fact that Apple does not support WebRTC on its own. You would need to create your own custom SDK for iOS support or you can use third party SDKs and significantly reduce your app development time. Here are some the most popular third part WebRTC SDKs that provide iOS as well as Android support.

Telefonica Tokbox

Tokbox and its API platform OpenTok are currently among the most used WebRTC SDKs. OpenTok itself is used by 80,000 users for communications where Tokbox is used by major brands like Bridgestone Golf, Major League Baseball’s website MLB.com, and Universal Music Group. The platform is robust, full of features, and most importantly comes with plug-ins to make it compatible with internet explorer(the bane of web developers). We used Tokbox for developing new webRTC application and were hugely impressed by its performance.

Addlive WebRTC Platform

Awarded the best WebRTC tool award in 2013 at the WebRTC expo, AddLive is a very powerful voice and video communication API. Used by over 5000 business, AddLive provides support for native iOS WebRTC application development. However the API supports only Apple 5 and above CPUs, i.e. only iPhone 4 and above and iPad 2 and above. In May 2014 AddLive was acquired by Snapchat.

HookFlash

Hookflash was the only WebRTC SDK that first provided support for iOS app development, which was followed by Android and JavaScript support.

Hookflash flips the order of WebRTC SDK offerings, first supporting iOS via its Open Peer SDK with Android and JavaScript SDKs and reference apps coming later. The company offers a service level agreement (SLA) for premium accounts and commercial pricing at one tenth of one cent per API call for high quality messaging, voice and video chat for developers and enterprise customers.

Bistri

Bistri’s Android SDK is currently in beta, so you have to contact them to get it directly while an iOS SDK is “coming soon”, according to the company’s website. The company already has its mobile app available for both iOS and Android, so an iOS SDK should definitely be more than a vaporware promise.

Open Clove

OpenClove offers two options for WebRTC support, with a large number of demos and sample code with the pay option. FreeMAD offers free source code for two-way communications & peer-to-peer communications, with video the default voice and messaging options are available by adjusting flags in the template. Access to OpenClove’s pay platform includes support for multi-party conferencing, recording, streaming, and other advanced features.

Twilio

“Make every device a phone” is Twilio’s motto — since “phone” is such a limiting concept these days, I’m not sure I truly get the idea behind the assertion, but the company provides WebRTC SDKs for both Android and iOS. Twilio lists Airbnb, the Democratic National Committee, eBay, Intuit, and Hulu among its users.

WebRTC is still a growing field

WebRTC is one of the most worked upon technology. It is still a growing field and we are going to see a lot of improvement in it in coming days. However the technology is viable even in the present scenario. So if you are thinking about using WebRTC for your communication solution, you are going in the right direction.

The following two tabs change content below.
Rachit Agarwal

Rachit Agarwal

Director and Co-Founder at Algoworks Technologies
Rachit is leading the mobility business development function, mobility strategy and consulting practice at Algoworks. He is an expert of all mobile technologies and has experience in managing teams involved in the development of custom iPhone/iPad/Android apps.
Rachit Agarwal

Latest posts by Rachit Agarwal (see all)

Rachit AgarwalNative WebRTC Mobile App Development: Tools and Tips
  • Pingback: Native WebRTC Mobile App Development: Tools and...()

  • Pingback: Native WebRTC Mobile App Development: Tools and...()

  • ravindra pai

    Great Article, But WebRTC apps on mobile has several limiting factors,

    1) Use of VP8 and opus are computationally intensive, on mobile which becomes kind of limiting factor.

    2) Webrtc can’t make use of h264 hardware encoders in iOS devices, where h264 codec adoption is still slow across browser.

    3) ARM64 support for ios devices is not yet stable.

    WebRTC sdk providers still need to cover lot of grounds. We at 1click.io provide SDK for iOS free addressing above issue.

  • Algoworks1

    Agreed, Mobile WebRTC has a long way to go. Thanks for the reference to 1click.io, we shall surely check it out from a developer’s perspective.

  • John Parr

    Acision also has a complete WebRTC mobile SDK solution – see forge.acision.com

  • Alex Frfegha

    Would you say Tokblox is expensive?

  • http://percevio.com Percevio

    How about WebRTC Web application with responsive design? It can be a mobile web application. Check our work at: http://percevio.com

  • AlgoworksTech

    We used TokBox for one our projects. We first started with opensource version OpenTok but switched to TokBox because it greatly reduced our development time. So in the end the expensive point depends on the time scale of your project. You can do the same in both Tokbox and OpenTok but the latter would require some custom coding and would increase your development time.