3 Advantages of WebRTC Embedded in the OS

October 15, 2015

Here’s a thought. Why not get WebRTC to the operating system level and be done with it?


Today, there are different ways to get WebRTC going:

  1. Use a browser…
  2. Compile the code and link it to your own app (PC or mobile)
  3. Wrap the browser within an app (PC)
  4. Use a webview (Android)

That last option? This is the closest one to an OS level integration of WebRTC. You assume it is there and available, and use it in your app somehow.

But what if we could miraculously get the WebRTC APIs (Javascript or whatever) from he operation system itself? No compilation needed. No Cordova plugins to muck around with. Just good ol’ “system calls”?

While I don’t really expect this to happen, here’s what we’d gain from having that:

1# Smaller app sizes

Not needing to get WebRTC on a device means your app takes up less space. With the average app size on the increase, this is always a good thing.

The OpenH264 codec implementation binary alone is around 300k, depending on the platform. Assume you need 3-4 more codecs (and that number will be growing every couple of years), the other media algorithms, all the network implementation, code to integrate with device drivers, WebRTC specific wrappers, … – lots and lots of size.

And less app size means more space for other app and less app data to send over the network when intsalling the app.

2# Less variability

While the first one is obvious, and somewhat nagging – so it takes a second more to install an app – who cares?

This point has a lot more of a reason for it.

If there’s a single implementation of WebRTC, maintained by the OS itself, there’s a lot less hassle of dealing with the variance.

When people port WebRTC on their own and use it – they make changes and tweaks. They convince themselves (with or without any real reason) that they must make that small fix in that piece of algorithm in WebRTC – after all, they know their use case best.

But now, it is there, so you make do with what you have. And that piece of code gets updated magically and improves with time – you need not upgrade it manually and re-integrate all the changes you’ve made to it.

Less variability here is better.

3# Shorter TTM

Since you don’t need to muck around with the work of porting and integration – it takes less time to implement.

I’ve been working with many vendors on how to get WebRTC to work in their use case. Oftentimes, that requires that nasty app to get a WebRTC implementation into it. There’s no straightforward solution to it. Yes – it is getting easier with every passing day, but it is still work that needs to be done and taken into account.

Back to reality

This isn’t going to happen anytime soon.

Unless… it already has to some extent and in some operating systems.

Chrome is an OS – not only Chrome OS but Chrome itself. It has WebRTC built in – in newer Android versions as well, where you can open up webviews with it.

For the rest, it is unlikely to be the path this technology will be taking.


So, where exactly is WebRTC available? Check out my free WebRTC Device Cheat Sheet.

You may also like

Two years of WebRTC Insights

Two years of WebRTC Insights

Your email address will not be published. Required fields are marked

  1. Less variability: that completely depends on if the OS gets updated and if it includes all the codecs. Browsers get updated & upgraded pretty fast these days. That is the reason it works (pretty well ?).

  2. Supposing there is an independent app that is for all practical purposes a WebRTC enabled browser, but used exclusively for WebRTC sessions, not general browsing. Then when another app wants to establish a WebRTC session, it passes the required information to that independent app via a Custom URL scheme and establishes a communication session.

    Agreed that the session is not part of the app that is initiating the communication session. But so what? If we could relax the condition of integration, then much can be accomplished just as when WebRTC is embedded in the OS. Yes?

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}