Commercial offerings based on WebRTC, such as TokBox, have already established and proven that WebRTC is here to stay.
Now, we have been working on some interesting demonstrations of WebRTC, including one in iOS, using the WKWebView component, which we’ll be posting about shortly. We ended up using WKWebView, essentially embedding a web browser in our app, since it faired well with our requirements. Yet, before arriving to that solution, the question arose of what iOS native WebRTC options are currently available.
Current Panorama
After careful filtering, there are three viable options for working with WebRTC in iOS.
A “build your own framework” approach, which was first detailed in NinjaneticDesign‘s blog way back in 2013, and updated in 2014. This is a hands-on, compiling from the command-line method, meant for true code ninjas. It requires the developer to basically extract the WebRTC components from Chromium’s source code and re-compiling them along with a few other native frameworks. This option has withstood the test of time, and to date is the closest you’ll get to fully native, albeit without any support.
Check out NinjaneticDesign’s post on building a WebRTC framework for iOS:
How to get started with WebRTC and iOS without wasting 10 hours of your life
Another well-rounded approach to building a native framework by webrtcH4cKS:
Developing mobile WebRTC hybrid applications
The “hybrid” approach, using WKWebView. This option offers stability, since you’re using a component officially-built and maintained by Apple, but at the cost of having to build your own API from scratch in order to allow your WebRTC app (which is contained within the webkit web view) to interact with other native components and views.
Check out EricssonResearch’s guide on developing iOS apps using WKWebView and openwebrtc:
Developing a hybrid iOS app
Lastly, OpenTok. Hands-down, this might be the easiest of the three, offering support (by TokBox), stability and a drop-in component. OpenTok is TokBox’s SDK which comes in a multitude of flavors including iOS.
Be sure to check out OpenTok’s iOS SDK documentation:
OpenTok iOS SDK
The Future
Apple has a track record of being sneakily stealthy about releasing native implementations of promising new web standards. Point-in-case, WKWebView, which was officially announced at WWDC 14 even though it had been available in XCode since late 2013. It wasn’t until enough developers had discovered the component, and began posting about it, that Apple began working in full support for it.
Does this mean that we should expect a WebRTC component to show up any time soon without previous notice? Well, not necessarily. The fact that regular usage of WebRTC relies on an external component, what people generally call a “WebRTC server” (which is less an actual WebRTC server and more of an intermediary service which helps two clients to find each other) might muddy up things a bit.
When you see it like that, you’d expect Apple to want to offer a WebRTC channel which is fully managed by them, much like with Push Notifications, where even though you have several third-party offerings for “Push Notifications Servers”, they all rely on Apple generated certificates and verification services.
In any case, Apple (specifically the XCode team) hasn’t issued any official statements about implementing a WebRTC UI View, and there are no stealthy components showing up in any official framework which could hint to native support.
Combine that with the fact that there are three perfectly viable options for developers to implement WebRTC in iOS apps and we might just be left with the hope that Apple sees the opportunity to sieze and certify WebRTC comms much like they did with Push Notifications.
