How to pick the right WebRTC mobile SDK build for your application

Most developers should just use libwebrtc that Google supplies for their WebRTC mobile SDK. Which exact release to pick and at what pace to update is a more nuanced decision one needs to make.

* I'll be using SDK and library as well as mobile WebRTC SDK and mobile WebRTC library interchangably in this article, so bear with me 😀

In the release notes of WebRTC M80 (=the changes made to WebRTC in the upcoming Chrome 80), Google added an interesting deprecation announcement:

Deprecating binary mobile libraries

The webrtc.org open source repository contains platform implementations for Windows, Mac, iOS and Android. These are primarily utilized for automated testing. Browsers and other applications that embed WebRTC often have developed their own highly optimized platform code with custom capture/render components matching the applications architecture.

We have decided to discontinue the distribution of precompiled libraries for Android and iOS. The script for creating the AAR library can be found here, the build script for iOS is located here.

Lets try to decrypt this deprecation and explain it, and then see what developers should be doing (and are doing already).

Official WebRTC precompiled libraries for Android and iOS

To understand this announcement we first need to understand what’s this WebRTC precompiled mobile libraries is exactly.

From the start, it was possible to use WebRTC on mobile. Google introduced WebRTC in Android Chrome in July 2013, less than a year after Chrome 23 was released on desktop with WebRTC support. Since that moment and on the codebase for libwebrtc (Google’s implementation of WebRTC) included support for mobile.

Up until 2016, Google never did offer any compiled binaries. Developers had to figure out the build process and handle it on their own. Several github repositories held compiled WebRTC source code for mobile and were somewhat popular.

In November 2016, Google introduced the official WebRTC precompiled libraries for Android and iOS, which they have maintained up until today.

Most of the vendors out there who are building applications or even SDKs (think CPaaS vendors such as Twilio or Nexmo) make use of libwebrtc as well for their basis of the VoIP stack implementation they run for their own clients. This was true BEFORE Google announced official WebRTC precompiled mobile SDKs and it will continue to be the case even now after Google discontinues the distribution of these mobile SDKs.

How did we get here?

Discontinuing to distribute the WebRTC mobile libraries

First off, it is important to state and understand: Google uses the same WebRTC codebase that goes into Chrome also in the Google Meet and Google Duo mobile applications running on Android and iOS.

There is no plan or incentive for Google to stop maintaining the libwebrtc codebase for mobile operating systems.

That being said, Google just stopped distribution of its WebRTC mobile libraries.

Why?

Because for all intents and purposes they were useless.

All vendors I know who run their products in production for mobile either use a third party SDK (open source or commercial) or have their own custom build of libwebrtc.

This is the case partially because the precompiled binaries from Google are somewhat useless. Here’s the official CocoaPod for Google’s WebRTC project:

The version mentioned here is 1.1.29400. What exactly does this relate to?

• The WebRTC implementation just got an internal milestone at Google for supporting 1.0 of the specification (at around the same time of the last release of this CocoaPod)
• WebRTC releases are versioned based on the Chrome release they belong to, and we’re now at 79, readying ourselves for 80
• Nowhere on this page or elsewhere is an indication when are these binaries created or from which branch of the code. There seems to be no easy way (or no way at all) to align them with the browser releases of the same codebase
• There is no explanation or release notes for any of these libraries. How do you know what was fixed, modified, deprecated or added?

This made the binaries useless without giving them any real chance in life, which led to their discontinuation.

The Google WebRTC team had two alternatives here:

1. Fix the broken part of these releases, mainly by synchronizing them with real releases of WebRTC and maintaining clear release notes for them
2. Discontinuing this effort as it causes more headaches than it was worth at its current state

They chose discontinuation. Probably because of what I’ll be sharing with you next.

What WebRTC mobile SDK should you use now?

This is the real question. It is the one developers had to deal with before, during and now after the age of Google’s official precompiled mobile libraries for WebRTC.

There are two routes to take here for any developer who needs a WebRTC SDK (I am ignoring those using higher level abstractions such as SDKs provided by CPaaS vendors):

1. Use Google’s libwebrtc project, compile and maintain it on your own
2. Go with another third party library

Between these two alternatives, the majority of the developers are choosing option (1). Why? Because let's face it - no other library today offers the same feature richness, quality and interoperability with what runs in the browser that everyone uses.

There are a multitude of alternatives to Google’s libwebrtc, but they are all lacking in at least one way (probably more):

• Commercial and cost $$$ to use
• Don’t implement any codecs. You are expected to “bring your own”
• Lack proper support for effective bandwidth estimation
• Don’t offer acoustic echo cancellation
• Not implementing peripherals support for media acquisition and/or playback (microphone, speakers, camera and display)
• Interoperability with Chrome’s WebRTC. All the time. Including support for the latest features being added to it

I am sure I’ve left a few more gaps in that list.

Ask yourself why is Edge now based on Chromium and using Google’s WebRTC almost verbatim, or why Apple is relying on Google’s libwertc in a lot of its own implementation of WebRTC in Safari.

That said, there are very good reasons for using libraries other than Google’s libwebrtc:

• Not needing a lot of what libwebrtc offers (if you need just the data channel for example)
• Requiring specialized features, such as playback from file or other sources into a WebRTC session
• Needing to run on “exotic” devices or operating systems (i.e - not classic iOS or Android mobile devices)

For the majority of the developers out there, libwebrtc is the right SDK to use on mobile.

Best practices in using Google’s libwebrtc mobile SDK

If you are going to use libwebrtc, what is it that you should be doing then?

Here are the best practices I’ve seen of companies using libwebrtc mobile SDK in production:

1. Have your own codebase for libwebrtc that you compile and integrate into your application
2. Don’t automatically upgrade to the latest libwebrtc release when that gets pushed out to a Chrome release. Doing that means releasing your application every 6-8 weeks, which is a brutal release cycle for most vendors
3. Plan and aim for 2-4 upgrades a year of your libwebrtc SDK in your mobile application. Any less and you’re in danger of breaking interoperability with Chrome or at the very least missing out on optimizations, improvements and new features
4. Think of libwebrtc as a starting point. You will have your own minor fixes and optimizations to it. Make sure they are well documented so that a future upgrade of the library doesn’t become too complex and risky a task
5. Revisit these fixes and optimizations you are making once a year. Some of them might not be needed any longer, and carrying them further might take too much effort or hurt performance
6. Try to contribute fixes you’ve made back to libwebrtc. This will be a long and frustrating process, but I suggest going through with it
7. Roll out slowly. Have it tested internally, then with a small % of your audience and then with everyone
8. Make sure you can rollback...

FAQ about WebRTC mobile SDK library

Reduce your risks with WebRTC

Looking to lower their risks and increase their time to market with that WebRTC project you’re working on?

I can help you with this; when it comes to WebRTC and communication technologies, I help my clients get the answers they need and make sure their project doesn’t get delayed.

Contact me if you are interested.