Keeping It Realtime

Starting today, SimpleWebRTC users will have access to a sample app based on our widely used video collaboration tool, Talky.

This means if you're building a new WebRTC app, using Talky as a starting point means you've now got a much more complete and battle-tested user experience out of the box.

Talky was first released in February 2013 (under its original name, Conversat.io). It started as a demo app showcasing the first version of SimpleWebRTC. Since that time, our team has made a lot of revisions—both to Talky and to SimpleWebRTC itself.

We've had a six year journey of iteratively building upon and improving our platform, which has ultimately become SimpleWebRTC. Since that time, we've served many clients, helping them integrate WebRTC into their applications. And beginning last year, developers have been doing so themselves as they integrated the heart of what we've built with Talky into their applications using SimpleWebRTC.

The original SimpleWebRTC was one of the first Javascript libraries for WebRTC out there; the first public version was released more than five years ago. It offered a simple API that allowed JavaScript developers to prototype stuff quickly without having to understand the intricacies of the WebRTC APIs. “You can build cool stuff with WebRTC in five minutes” was true. Taking it to production at scale remains a bit more difficult.

Under the hood, SimpleWebRTC consisted of a bunch of Javascript modules that let you access the camera, microphone, screen content, a wrapper for the RTCPeerConnection API, and something to keep track of your peers and do all of the signaling. It came with a very simple NodeJS signaling server called signalmaster. Socket.io was used for signaling.

This simplicity came at a cost. SimpleWebRTC was designed for a single use-case: multiparty video chat using direct peer-to-peer connection between the participants. For the more complex problems we had to solve, we needed something better. Which is why we rewrote SimpleWebRTC almost from scratch, taking into account what we had learned in the last five years.

Hey guess what? Today is SimpleWebRTC beta release day! We know how difficult using WebRTC can be, so we decided to make it simple (see the play on words there?).

SimpleWebRTC allows you to add video, voice, text chat, and screen-sharing to your app with easy to use React components. And as of today, you can try it out for free.

Very soon we’ll be shipping a brand new version of SimpleWebRTC, and everything about it is different.

What’s different?

The biggest feature of the soon-to-be-released version of SimpleWebRTC is that it will just be a bunch of flexible React components.

These components will make it so that anyone with a basic understanding of React can build advanced WebRTC applications. No need to understand anything about how connections are set up, no need to set up signaling or STUN/TURN servers, and it gets even better than that.

To the thousands of people who made Talky calls on February 14, 2017, Talky didn’t seem much different. There were some icon and button color changes, but nothing to write home about. However, it was a very big day in our world.

For the past couple of years, we've been transitioning Talky from AmpersandJS to React. The reason for the transition is an article on its own, but to put it simply, I only need one word. Components, heard of 'em?

During the rewrite, we moved the core functionality of Talky into its own library of super slick React components which... [SPOILER ALERT] we'll very soon be making available to anyone who wants to build an app using them. This very simple webrtc react library enables us to build robust video chat features in very little time at all, and we're excited to say we'll be sharing it with the world in the coming months. 🎉

While Talky on the web was receiving consistent upgrades, our Talky iOS application hadn't been updated in quite some time, and it really needed an overhaul to take advantage of some backend upgrades. When trying to figure out what to do about our iOS application we had two options:

Open road

I began my adventure working at &yet in January of 2018, and one of my first experiences was when suddenly, traffic on Talky plummeted. This was particularly jarring to me since one of the reasons I was hired was to be Talky’s product manager. How could traffic drop so quickly, and why didn’t it recover?

Initially, this felt like a fluke. Perhaps there was an issue with our usage monitoring, or maybe not all of our traffic was being reported? Because we don't gather data from our users, we didn't have regional information at our fingertips. Luckily, our support emails began coming in and we were able to diagnose the issue. All of the missing traffic had been coming from one particular country, The United Arab Emirates (UAE), and their government had banned our app.

Let’s Talky ‘bout UAE

At the end of 2015, we teamed up with AT&T to write a blog series on UX and WebRTC. We’re excited about the future of communication on the web and hope these posts will help teams get started in creating enjoyable user experiences with WebRTC. Check them out!

Post #1: Getting started with UX and WebRTC
An introduction to WebRTC featuring reasons to include it in your application, a handful of questions to consider during the initial stages of planning, and the importance of consistency and seamless implementation.

Post #2: UX considerations for initiating and joining calls
The first major interaction a user will have with WebRTC is initiating or joining a call. This post covers questions to ask and decisions to consider when designing this part of the flow. How do things like buttons, text, and user expectations affect the experience?

Post #3: UX patterns for transparent voice and video calls
Next, here are some useful patterns and techniques for the voice or video call itself. What information or context could help the user during the call? The theme here is clarity and transparency.

tl;dr: with adapter.js you can write WebRTC code that is spec-compliant and works in all supported browsers. That is the web we want.

We have come a long way since WebRTC was first enabled by default in Nightly back in February 2013 after interoperability had been achieved earlier that month. Since then a lot has happened.

One of the bigger updates to the specifications was the addition of a Promise-based version of the API instead of callback-based API in December 2014. Firefox has supported the Promise-based versions of the getUserMedia and the RTCPeerConnection APIs for quite a while now. Yay!

That means you can write code like this:

Back in June, Apple introduced bitcode as a part of their app thinning strategy, which allows them to implement some optimizations in the future without developers having to resubmit their apps. Unfortunately, bitcode must be enabled for the whole app, including third-party libraries. This is a problem if you use WebRTC as it does not currently have a build option to enable bitcode.

Because the Talky iOS app uses WebRTC, I decided to investigate what it would take to enable bitcode when building WebRTC. For this post, I assume that you're building a Release build of WebRTC with the steps outlined at http://www.webrtc.org/native-code/ios.

Step 1: Get the code

If you haven't already downloaded the WebRTC source, open a terminal window and follow the steps for "Getting the code".

We’ve talked before about the revolutionary importance of WebRTC, because it brings the principles of the open web to voice, video, screensharing, and other applications that were traditionally closed off to fast innovation. This revolution has been led not by old-style telcos but by web and mobile companies, especially the developers of the Google Chrome and Mozilla Firefox browsers.

Until recently, both Microsoft and Apple have been standing on the sidelines as this revolution unfolded. Thankfully that’s starting to change, as Microsoft adds these capabilities to its upcoming Edge browser. (Apple, however, is still late to the party.)

There’s a twist to this story, though, because Edge supports an object-oriented flavor of WebRTC called ORTC, which most observers expect will eventually become WebRTC 1.1 or 2.0 or something. :-)

Thus we have a conundrum: in video conferencing apps like our Talky service, cross-browser calls work fine right now because both Chrome and Firefox support WebRTC. But adding Edge to the mix doesn’t automatically result in cross-browser calls to Edge users, since the signaling methods involved have different syntax even though the semantics are the same.