OpenTok iOS SDK : Behind the Scenes

We’ve been working on this project for a few months and are pretty excited to showcase how it’s made and what it can be made to do. I’d like to share some stories that happened along the way.


The most interesting design requirement in this project was that the platform would work seamlessly with the rest of the OpenTok infrastructure. As it turns out, many of the tools we used to build OpenTok for browser applications had to be thrown out in exchange for open, standards-based components. Let’s take a closer look at this.

Adobe Flash Player uses the RTMP standard. RTMP offers descriptors to stream audio and video over a TCP socket, and additionally defines the Action Message Format encoding to recycle the socket for control and signaling payloads. Historically, this protocol was proprietary and when a specification was published, it was somewhat lacking in completeness. Fortunately, the collaborative engine of the open-source community was able to reverse engineer the missing pieces of the protocol, and now the media server market is peppered with viable alternative solutions.

Either way, none of this would do for a mobile client implementation. While there are a few open-source RTMP C libraries out there, licensing constraints and other technical hurdles convinced us to take a different approach. In a related stroke of providential fortune, the friendly folks at Wowza already had us covered with a media server that could perform live translation of RTMP and RTP media sessions. It was almost an accident that we had realized this feature was available to us. The discovery phase of this project taught me an important lesson in conducting research: know your prior art.

Time Bugs: The Best Bugs

The most interesting bug we encountered was caught in the eleventh hour of release preparations. To solicit feedback while design changes were still inexpensive, we invited a small number of developers to build applications on our nascent iOS SDK. One of these partners documented an issue that had an absurdly difficult to believe error state. I spent about six weeks ignoring this bug report, thinking that it had to be an environmental issue that we would have surely seen in our own testing. Eventually, I got a hold of a build of their application. Within 30 minutes, we identified an issue caused by seeding a random number generator with synchronized network time, at a laughably low level of precision. This is the kind of bug that would have haunted us for a long time, were it not for our faithful early developers.

The bug alone indicated a mildly embarrassing lapse of attention to detail. The lesson learned, however, is much bigger than RNG practices. Any of you reading this who are in software development should readily admit that It’s Always Your Fault. We’re inclined not to listen when our perception is challenged. Moreover, it can be scary to share your work in an early phase. Still, the input we got from early testing proved vital in exercising our software in ways we hadn’t considered on our own. Listen to your testers.

A quick shout out to the other unsung heroes that made this whole project possible: David Conrad and all the contributors of the gas-preprocessor; the StackOverflow community, for answering my boundless inane questions about Objective-C; Google, for indexing it; Scooba Steve, for humbly accepting the blame of everything that could possibly go wrong; and Epicenter Cafe, who allowed us to hum with a fairly consistent frequency of vibration.