WebRTC Mobile to Web? Make Sure You Think at Web Speeds

Learn to run faster.

WebRTC isn’t yet standardized. It is on the way there. That said, there are already more than 800 different vendors and services out there that are making use of it – many in production, with commercial services.

There are main 3 approaches to a WebRTC-based service:

1. Browser based service, where the user interacts with the service solely through a web browser
2. App based service, where users interact with the service via WebRTC mobile apps
3. Hybrid approach, where the users can interact via a web browser or a WebRTC mobile app

That third alternative is the most challenging. The reason for the challenge isn’t a technical one, but rather one of mind set.

Fippo, who knows about the WebRTC testing service I am a part of, sends me every once in awhile issues he bumps into. This one that he shared with me recently from the webrtc-discuss group was an eye opener: someone running a native C++ app got WebRTC compiled and linked to his own app, and assuming it will work with browsers. And it did. Up until recently:

Chrome 46 started sending UDP/TLS/RTP/SAVPF in the profile field of the m-line as has been announced a while back in https://groups.google.com/forum/#!topic/discuss-webrtc/ZOjSMolpP40

Your library version has to be pretty old to be affected by this (parsing this should have been supported since mid-2014).

Here are some thoughts about this one:

• If you run WebRTC in browsers, your main concern about interoperability is around
  • Browsers changing their APIs and deprecating past capabilities
  • Working the kinks of interoperability across browser vendors
• If you wrap WebRTC in your app and use it there alone, then your concerns are minor – you live in a rather “protected” world where you control everything
• If you connect from an app to a browser with WebRTC, you’ll need to maintain the WebRTC library in your own app
  • Making sure it works with the latest browser
  • Updating and patching it as you move along

It means that mobile apps must run at the speed of the browser – whenever a new browser version gets released, you must be sure it works with your own version of WebRTC in your app. You should probably get your version updated at the same speed (that’s every 6 weeks or even less, once we’ll have 3 full browsers supporting it properly).

What are you to do if that’s your use case? Here are some suggestions:

#1 – DIY only if you can commit

Don’t put someone in your team to port WebRTC on your own.

If you do, then make sure you know this isn’t a one-time effort. You’ll need to make investments in upgrading the ported library quite frequently.

To be on the safe side, I’d suggest putting the ongoing investment (not the initial porting) at around 50% of a developer’s capacity.

Also remember you have two platforms to deal with – Android and iOS.

Can’t commit to the ongoing maintenance effort? This alternative isn’t for you.

#2 – Outsource to an independent developer with care

If you decide to use someone externally, who would take the WebRTC library, port it for you, assist you in integrating and optimizing it to your needs – make sure he will be there for the long run.

Same as you’ll need to invest internally to maintain this code, you’ll need to be able to call upon that person in the future.

Things to consider:

• Placing an exact price of future work of maintenance into the proposal – you don’t want to do the initial work just to find out the price hikes in the future when you need that contractor the most
• Make sure in your agreement with him his availability to you
• Budget appropriately these additional future work

#3 – Use an official product

The other alternative? Use an official product that gets you WebRTC as an SDK to mobile. Frozen Mountain’s IceLink comes to mind as a good solution.

You essentially outsource the headache of maintaining WebRTC’s interoperability with browsers to someone who does that for a living in a product package.

Make sure in the agreement with such vendors that you get regular updates and upgrades – and that these are guaranteed to work with the latest versions of the browsers (and even with the available beta versions of the browsers).

Check how regularly the vendor releases a new SDK and which ones are mandatory to upgrade to due to browser interoperability issues. Plan accordingly on your end.

#4 – Go for a WebRTC API Platform

Have your worries of this whole mess outsourced to someone else. Not only the mobile SDK part, but the whole real time comms platform.

You need to pick a vendor out of a very large set of potential vendors, which is why I’ve written and updated my own report on WebRTC APIs over the years.

Make sure to take a look at how well the vendor you select works with mobile and is committed to upgrading his own support for it.

It ain’t easy

Getting WebRTC to work well for the long run on mobile and web at the same time isn’t easy. It requires commitment as opposed to a one time effort. Be prepared, and make sure you take the approach that fits you best.

At least until WebRTC stabilizes (no reason for this to happen in the coming year), you’ll need to keep running at the speed of the browsers.