3 January 2018
The internet is removing more and more boundaries between users. It started as a content sharing system, evolved to Web 2.0, and made the first steps towards chats that connect people regardless of distance. However, ubiquitous little enemies still stand in the way of a smooth user experience. These pics with sad faces are familiar to billions.
Those are the crashed plugins. They are not altogether bad, but they have one common downside: to work well, they require most user actions to be in the pre-set acceptable range.
(data source: Kranky Geek WebRTC 2016)
The complex of technologies that enable us to talk online is called RTC, or real-time communications. The RTC solutions like Skype, Facebook video calling system and Hangouts by Google either need an installation or work with plugins. This means that their users are constantly engaged in the frustrating process of downloading, installing, and updating. The developers are not content, either: they have to spend too much corporate time and money on expensive audio and video tech.
In 2011, Google developers first implemented the standard that had to take live streaming and video chat environments to the next level. The point of WebRTC is that it enables users to make real time calls and streams without leaving the browser. It’s an open source solution that connects two browsers directly so that they can exchange audio, video, and other data. The P2P, or peer-to-peer, connection lets file transfer work without saving files to a server, which is a great opportunity to cut costs.
In 6 years, WebRTC market size has considerably grown. The standard is currently used in TokBox, Facebook Messenger, and WhatsApp.
WebRTC data channel and voice/video calls are used in corporate communications, entertainment, healthcare, education, and gaming:
as a video interviewing instrument (Plumvue);
as a place to have a voice chat with friends (Talkroom.io offers WebRTC screen sharing).
The technology can also be used by retailers (CommodiSee), agencies casting voice actors (Bodalgo), and the communities of travelers (Travefy). Some companies even offer their customers to call Santa.
WebRTC on mobile opens the road to great opportunities, but there are several factors developers need to consider before implementing these solutions.
Companies create a WebRTC video app because of the considerable savings on telephony and server-side support, high-quality video and audio, open-source code, and the ability to work on a user-friendly interface.
However, WebRTC apps for browsers are not ubiquitous yet. Safari does not support the standard, only promising to change this in the near future. Many platforms claiming that they use WebRTC in fact only use some of its components. For instance, Microsoft Edge only supports the getUserMedia API but not the PeerConnection or DataChannel.
For a developer, this limitation means that a separate native or hybrid app needs to be built for iOS. As for Android, its support of WebRTC voice call and video streaming starts from the version 4.4. There are two workarounds for this problem:
third party SDKs (OpenClove, Twilio, and Telefonica Tokbox to name only a few);
using WebView or Crosswalk in Android and Cordova plugin for iOS.
High quality of video and audio
Potential security breaches
Savings on PSTN access fees, server bandwidth
Not supported by IE and Safari
No installation/updating required
Differences in device configuration, form factor, and CPU power
Availability of APIs and SDKs
Increased battery performance
Data encryption and security
Changes in connectivity, light, and network profiling of mobile devices
Another problem arises from the differences between devices. Theoretically, you can achieve compatibility with any device. In practice, this will take a toll on developers, especially the testing part. Be prepared to deal with a variety of screen resolutions, layouts, and connectivity issues.You may need to conduct manual testing for extra reliability.
Security is a priority for WebRTC. Data encryption is mandatory, and you can only use secure protocols (which is why the services like Privatoria boast about their safety). However, there are still some vulnerabilities (covered here).
Native mobile WebRTC app development is more complicated than creating a web-based service. But it is absolutely the must if you want your iOS application to be fast. Here is the list of what you will need to go native.
This job requires reliable professionals, preferably specializing in the OS for which you are going to build. It has been observed that many native developers prefer to start from Apple and then code for Android. You will also need to find out how to choose reliable developers: losing one in the middle of a project could be catastrophic.
You will need the Audio Acceleration or other features to reduce the CPU usage.
Another absolute necessity is a careful treatment of hardware and processor difference. A WebRTC audio chat will need microphones, Bluetooth, and speakers that are implemented differently across devices. At the same time, old Android phones and iPhones that work with 3G won’t support browser-to-browser video communication.
To sum up, building a WebRTC based mobile application involves the same complications as working on web-based apps, but to a broader extent. Hopefully, it will get easier once Apple and Google implement more native APIs.
Since WebRTC is still relatively new, there are little best practices to support your experimentation. However, some practitioners have already given their feedback.
A Ninjanetic Design author described how he was able to avoid using compiled libraries. The key point was to work from the command line, first building the iOS simulator and then putting it to work.
Tim Panton once warned Google developers against duplicating PSTN functionality. WebRTC is valued for its working model and convenient interface; by building telephony-like system and charging customers in the same manner as PSTN, you will likely devalue the innovation altogether. Tim’s startup that combined PSTN and WebRTC features, phonefromhere.com, turned out to be unsuccessful.
Dan Ristic has shared his experience of treating data sharing systems in a new way. He explains that a chunking mechanism is needed for working with large files.
We are just one click away from helping you develop an amazing application! Let’s get in touch. Drop us a line in the form below, and we’ll reach out to you as soon as humanly possible.