Today, we are excited to announce that version 2.3.0 of the OpenTok iOS SDK is available to our developers.
In addition to support for iOS 8 and Xcode 6, we also want to share details about additional new mobile features which we’ve outlined below.
- Build Voice-optimized experiences: Audio Levels API and UI best practice example. See more.
- Audio Driver API: implement custom Audio I/O in your app.
- Support for the armv7s architecture.
- Support for the iOS Simulator.
- Intelligent Quality Control features:
- Video recovery from audio-only fallback.
- Connection Quality API: a warning callback to notify that audio-only fallback is eminent.
- Audio-only fallback redesign.
Learn more about OpenTok iOS SDK 2.3.0 here.
Last night TokBox released patches to the OpenTok iOS and Android SDKs to resolve a recently identified OpenSSL vulnerability that affects the majority of web service providers.
In early June, a security advisory was issued by OpenSSL, quoting the following:
‘An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server.’
OpenTok Mobile SDKs, Revision 2: The Video Driver
In the latest versions of the OpenTok SDKs for iOS and Android, everything is new. We found an opportunity to learn from the lessons of the past two years, and seized it to conduct an overhaul of the architecture of the client. The 2.2.0 release of the iOS and Android SDKs marks the second major revision of the implementation of the OpenTok Mobile SDKs. This post highlights one of the many new features of the 2.2.0 SDKs, about which we are feeling particularly excited: the “Video Driver”. Although the feature exists with parity in both platforms, today we’ll focus on the iOS-variant of the new API.
Nearly 7 months ago, we publicly announced that the OpenTok API would extend its reach to native mobile application developers by publishing the OpenTok iOS SDK. In the time since, we have tightened the performance of the SDK runtime for iOS devices and spent a good deal of time learning about how best to deliver video to the mobile platform. While iOS commands a large portion of the mobile app market, it is intuitive that we should build similar SDKs for other popular platforms outside of the browser. It is a pleasure to announce that we are developing the OpenTok Android SDK, to allow native Android developers to bring live video chat to their apps.
Several partners have been asking us about the options around getting access to media streams as they come and go from an iOS device. While more robust media access features are further off, I wanted to take some time to explore the options an iOS developer can play with today.
The UIKit view hierarchy integrates with a fairly simple animation and compositing API. Every instance of UIView is backed by an animation layer (CALayer), which can be accessed (and manipulated) without much complexity. A neat thing about CALayer is that you render its contents at any time using the
renderInContext: method. Most often, your render target is the window, which is managed by the UIKit view hierarchy, so none of this knowledge is particularly compelling. Unless of course, you wanted to render the contents of the animation layer to a bitmap in memory to perform, say, facial recognition with the iOS 5 CIDetector.