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:
- Fix the broken part of these releases, mainly by synchronizing them with real releases of WebRTC and maintaining clear release notes for them
- 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):
- Use Google’s libwebrtc project, compile and maintain it on your own
- 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:
- Have your own codebase for libwebrtc that you compile and integrate into your application
- 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
- 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
- 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
- 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
- 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
- Roll out slowly. Have it tested internally, then with a small % of your audience and then with everyone
- Make sure you can rollback…
FAQ about WebRTC mobile SDK library
Use Google’s libwebrtc implementation. This is by far the most comprehensive and popular library for client-side WebRTC implementations. Other alternatives exist, but you need to understand what you sign up for when you opt for using them.
The best practice here is to pick something that is new but not too new. Pick on of the latest releases that is considered to be stable. Don’t upgrade immediately to the latest release as that is time consuming. Make it a point of upgrading your libwebrtc 2-4 times a year.
Yes there are. PION and GStreamer come to mind in the open source scene. I’d seriously consider the reasons for not using Google’s libwebrtc in favor of anything else though, mainly due to its feature richness and immediate interoperability with Chrome and all other browsers.
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.
So basically they are stopping to compile it for us and we need to go through the whole build procedure by ourselves?
Basically yes.
Do you think it would be worth setting up public builders for iOS/Android? There is no benefit for Google so I get why they aren’t interested, but for general public it seems like this could be a barrier of entry for people!
I would be curious to know how many people used those public builds of libwebrtc vs building locally.
That’s a very good question Sean. And like any good question, it has no simple answer.
Those who need a quick solution would be happy to use such a public build. Building libwebrtc for mobile is known to be tricky for first timers.
Automating the process would be nice, but that’s what Google did and the results haven’t proven themselves (no one used it in production as far as I can tell). You’ll need a bit of manual labor in every such release, so there’s that effort that goes into it that I don’t see people investing for the sake of others – similar attempts in the past were made and the result was a build release every couple of months.
Those that need it on mobile “a bit” will do so using a 3rd party CPaaS, outsource the effort. Those that see this as core would build it manually and invest the time in it, especially since they will be making their own modifications to the build.
The documentation always said “These libraries are compiled from the tip-of-tree and are meant for development purposes only” (for Android; the iOS there was no such warning) so I am not surprised there was no adoption.
I don’t think first-time users are really well-served with native builds, there is a good reason the cpaas platform providers exist.
Great post I was driving me crazy reviewing several post and pages. Thanks to you.
🙏
Is there any mobile libraries out there that provide access to raw (or native) audio buffers?
Xavier,
The official WebRTC library from Google comes as open source, so effectively it provides such access.
I am not aware of third party commercial SDKs that do the same, but I am certain some of them do or might have it available unofficially.
Tsahi
Thanks for the well-written and conclusive articles. Big help as we all try to orient ouselves in the WebRTC landscape.
Tsahi
It’s quite a challenge to compile webrtc as there’s no comprehensive documentation. I have written an article, just share.
https://medium.com/@abdularis/how-to-compile-native-webrtc-from-source-for-android-d0bac8e4c933
Thanks for posting this!
There seems to be a lot of great articles on Getting Started with WebRTC in the browser, but very few on getting started with WebRTC in native mobile.
I did see instructions on how to build WebRTC for iOS, but as a first-time user, I do find it challenging to get started for building WebRTC apps in native iOS (Swift).
http://webrtc.github.io/webrtc-org/native-code/ios/
For example, Google has an excellent code lab for building a sample WebRTC app with Firebase via https://webrtc.org/getting-started/firebase-rtc-codelab.
Are there similar resources for building a Swift application that uses WebRTC?
Again, it would be great to see a modern Swift demo/sample application that showcases the basics of WebRTC on native iOS.
Frankly? The Firebase getting started one isn’t that great.
To your question, I don’t know of anything similar for Swift.
Hi!
It seems that they are updating the bintray with new versions! is it right?
Not really no.
Google decided to make an updated version recently due to a security issue that got fixed in the WebRTC codebase (libsctp to be more specific) and they wanted the “official” binaries to include the fix as well. I don’t think Google is back to maintaining the binaries.
I want to build a video calling native application just like Google Duo and I am very confused, I cannot find any proper documentation, not the dependency to implement in my android app and now after reading this I don’t know what to do. I really love WebRTC and I would like to integrate it, I cannot write the webRTC lib by me.
Danish, you’ll need to learn a lot more about WebRTC to get this done.
There’s a lot of materials written in this blog and elsewhere throughout the years that you can use. There are also courses available online (such as my own webrtccourse.com).
Hi Tsahi, how do you feel about a refresh of this article? Would be good to know how the world looks 2.5 years later. Thanks!
Costin,
I believe this one has aged quite well 🙂