WebRTC as a Web App, Native App or Anything In-Between

Topic of the month covered by WebRTC “activists”

For this month the topic is: Web App, Native App or anything in-between. Which is best for WebRTC and in what cases?


Amir Zmora

Link: TheNewDialTone & WebRTCStandards.info (NEW)

WebRTC is being used on desktop and mobile mostly in a similar way to which users typically use services on these platforms. This means, web on desktop and native app on mobile. A few things to point out:


  • Due to current lack of support for WebRTC in IE and Safari some use a plug-in for these browsers which means it is not a pure 100% web app but this should be viewed as a gap filler
  • The more interesting case for desktop I ran into is a company that built a mission critical financial service with WebRTC. Due to the frequent version upgrades of browsers and since they can’t really control browser upgrades on PCs of their customers they decided to include WebRTC in a desktop native app so they can test and guaranty its stability


  • End goal of most companies is a native app
  • Due to priority and resource allocation many companies start with native app on iOS, browser on Android and only later build the app for Android
  • On Android some opt for a hybrid app using WebView that already has WebRTC built into it in latest version

Alan Quayle

Link: Alan Quayle

I’ve been using the Wire web app since February, app.wire.com. Its fast, slick, and elegant; I highly recommend you give it a go. The user experience is refreshing, the audio quality is amazing, and content loads fast.  WebRTC works well in this use case, its reliable and delivers nearly as good as experience as the the OS X app.  The gap has nothing to do with Wire, and everything to how web apps are presented. I loose the page, I mistakenly close the page, I mistakenly close the browser. Once web apps are presented in OS X like native applications, why would I ever want to go back to having to close applications and upgrade software? But how long until that gap is closed?

Tsahi Levent-Levi

Link: BlogGeek.me

As with anything else, it all depends on the use case.

That said, in most occurrences that I’ve noticed, the following rules of thumb apply:

  • Desktop is dominated by the web app in a “traditional” web browser
  • Mostly, that means an SPA (Single Page Application)
  • At times, a browser extension or a packaged app in the form ofChromium Embedded Framework is used. This means that the HTML5 SPA is just packaged as an executable – there is little benefit from “going fully native” with WebRTC on the desktop
  • Mobile is dominated by the app paradigm – with or without WebRTC
  • Today, most of it is native in nature, but more and more I see vendors who are trying to build cross platform HTML5 web apps and wrap them as mobile apps
  • More on approaches to mobile development in WebRTC can be found in myrecent report

Dean Bubley

Link: Disruptive Analysis

In general, WebRTC is better-surfaced as a web-app on PCs and via native app on smartphones. Tablets fall in-between, and other devices/IoT will vary case by case depending on how browsers are used anyway.

That is the key here – what is the *existing* role of the browser, and the associated user behaviour (& developer preferences). A taxi firm wanting to add a “speak to the driver” button isn’t going to re-write its entire existing native app as a webapp, just to enable feature #37. Or a user looking at a travel-booking website on a PC and big screen, or their company’s intranet, is going to be using a browser – so any real-time interaction is likely to be via the web.

Chad Hart

Link: WebRTC Hacks

All the above for most use cases. The great thing about WebRTC is that it has great development community across web and mobile, so you don’t have to worry about making the wrong choice. There are plenty of mainstream examples like Wire, Facebook Messenger, Google Hangouts that use WebRTC to support both web and native mobile.

Would mobile WebRTC be easier if it was built into native web views? Of course. At least Android 5 has it today. iOS still requires someone who really knows how to code for iOS, but if you are building a serious iOS app you probably have that anyway. I am looking forward to broader support coming for cross-platform tools like Cordova/Phone-Gap and Xamarian.

Schumann Sebastian

Link: Personal page

WebRTC as technology fits both; I’d make a distinction based on the angle we’re looking at. In both browser and native app real-time communication could be built prior to WebRTC, but with more efforts (time, money, development, licenses). WebRTC equally lowered that barrier and offers now a cheaper entry with high-quality media stacks. For “professional” developers WebRTC is just another tool for a certain problem.

What I found the most interesting so far is that for web development, the barrier is so low that for the first time, non-developers are able to build communications applications. This is fascinating hence I’d draw the line here to emphasize the benefits I’ve perceived myself. If you’re not a professional app developer WebRTC won’t be an immediate savior for building a native comm’s app, but for a non-pro web dev it is an easy enabler to start building cool apps with inbuilt high-quality audio and video communications in a few hours.


Rules of engagement for Topic of the Month: No product/company promotion. Contributors should have a wide market perspective.

If you would like to join this initiative and have your opinion published here in future posts please drop me a note.

9 replies
    • Amir Zmora says:


      WebRTC is not the target but rather the technology for creating services. When a communications island is built, its use of WebRTC or components of it maybe interesting technically but not really interesting from end user functional perspective.


        • Amir Zmora says:

          Custom URLs are used for sending information to/between the apps. This is good in some cases but why would that be something mandatory for an app to be considered as a WebRTC app? 2 different things.

  1. Aswath Rao says:

    I am afraid you are mistaken. Take a look at ciscojabber://call?address=&type=. Skype also had a call scheme, but have discontinued of late. So, just like HTTP URL scheme is used to launch a comm session in a browser, a custome URL scheme could be used to launch a comm session by the suported app. This is beneficial b/c other apps or an iOS browser can use this scheme to setup WebRTC session.

    • Amir Zmora says:


      The value of this is clear. I can see use cases where it will be great. For example, I go into a website on mobile, click on a link and it causes the app to launch and call that pre defined destination with my app identity.
      The fact this is valuable for specific use cases doesn’t mean it needs to be mandatory in WebRTC mobile apps. One great thing about WebRTC standardization is that it limits the things standardized to the minimal must required. Developers can add more on top but over standardizing will create complexity and people will just ignore those things they don’t like.


      • Aswath Rao says:

        I agree with you regarding standards demanding it. I overreached in my first statement. In my enthusiasm with my new find, I was not measured. I should have stated that this should be “best practices” and websites can dynamically change the URL scheme based on the browser type, user profile even.

  2. Sergio Garcia Murillo says:

    Regarding “On Android some opt for a hybrid app using WebView that already has WebRTC built into it in latest version” , I think this option is a bit underestimated.

    First of all, IMHO, for Android it is much better to use Project Crosswalk (from Google), that allows to embed use a full chromium webview instead of the native Android one. Why? First, it allows you to provide WebRTC support to ALL android versions, and second, it solves the fragmentation of WebViews versions.

    For iOS we have released a cordova plugin under MIT that allows you to run the same code on an iPad/iPhone: https://eface2face.com/blog/cordova-plugin-iosrtc.html

    That means that you can now create an HTML5 app that runs seamlessly on Desktop/Web, iOS and Android.


Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

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

+ 3 = 10