Wednesday, February 26, 2014

WebRTC - Current state of afairs - Native App vs HTML/Web - iOS / Android / MacOS / Windows

I received an email with an inquiry about how to approach WebRTC development in an app, and this is my experiences based on some of the functionality that we have implemented.

Depending on what your requirements are the easiest way is to do web only, but then you are currently ruling out iOS support.

In Google Chrome it works on Windows, Linux, MacOS and Android.  We have tested cross browser on Windows and it works between Chrome, Firefox (and Opera).

It is important to note that this is the full Chrome app/application not the development component "webview". I have not been able to find a webview that supports webrtc, and the new one in KitKat (Android 4.4) does not either (even though it is built on Chrome rather than the original native Android browser)

Chrome for Android supports a few features which aren't enabled in the WebView, including:
  • WebGL 3D canvas
  • WebRTC
  • WebAudio
  • Fullscreen API
  • Form validation

So it is possible to create a web-based WebRTC application that will work across Android, Windows, Linux and MacOS and at least on Windows it works across Chrome, Firefox and Opera.

IE is currently no go, although

Some people also report that IE supports WebRTC when using

It works pretty well across both fixed network connections like ADSL/ADSL, 3G/ADSL, 3G/3G networks but occasionally you run into some paranoid system admin that has the firewall locked down so tight that neither incoming or outgoing connections work and then you will face problems. This can occur at a higher level (i.e. ISP). ICE, STUN and TURN can only do so much.

What about native app development and support?

My thoughts on how to do this can be found at the following blog posting

I/we am working on both an Android and iOS solution and it will be developed on Github and everyone is free to contribute. Currently we am facing some problems on the Android version as can be seen here. The iOS version is a bit technically harder than the Android version due to Google/the WebRTC team already doing most of the hard work in their Java demo app.

So all in all web is the most doable way at the moment, but there are people that have this working on iOS using objective C and on Android using native Java.

Wanting a cross device code base and thus creating it in C#/MVVMCross makes it harder, since you have to take mono/native (dalvik/iOS) communication into account, and may run into restrictions in the Xamarin supported API for low level native API's.

There are not many people on the internet that seem to have the skills to pull this off especially if you are aiming for both across web and native.

The skillset to pull this off involves one or more of the following depending on the signaling system you end up using and your requirements to functionality

All in all the complexity still shines through the WebRTC proposal, not because it is bad, but because it is such a diverse runtime enviroment - and it is such an amazingly complex topic. On top of this, the users perception is but this is just like a phone call this shold just work 100% of the cases. They do not see or understand that there might be a difference calling from the same device if you move from WIFI to 3G network. This is plumbing and it should just work - always - on all devices - everywhere. Auch!!! That is a pretty high expectation to fulfill.

This is still bleeding edge, I am not even sure this is out of alpha/beta stages yet - at least officially, so there are reference  implementation (Chromium i.e. Google Chrome) bugs that might bite you.

This is a super exciting area, but at the moment web seems to me the most approachable.

Another option is to buy one of the cloud based offerings that have both Java and iOS components that make this easier. They are shielding you from some of this complexity, but comes at a cost.

Neither web or native is without pitfalls, but certainly doable, if you have the skills.

No comments: