This version adds support for bitcode. (Previously, this was only available in a beta build of the OpenTok iOS SDK.)
Note that while bitcode support increases the size of the .ipa file, the download size is smaller after the app is compiled and optimized in the App Store. Also, the app download size becomes significantly smaller due to app slicing. When installing your app, the device downloads only the architecture it requires: armv7, armv7s, or arm64 (instead of downloading all of the architectures included in the SDK). For more information on bitcode and app slicing, see https://developer.apple.com/library/tvos/documentation/IDEs/Conceptual/AppDistributionGuide/AppThinning/AppThinning.html.
You can use the OpenTok iOS SDK in apps that have bitcode enabled as well as in those that do not.
The OpenTok Media Router now includes the OpenTok scalable video feature (previously in beta). For more information, see the OpenTok Media Router documentation.
This version adds an
OTSession.capabilities property. Use this property
to check whether the client can publish streams to an OpenTok session,
based on the role assigned to the token used to connect to the session.
This version fixes issues when publishing streams on devices that use the A5 processor (including the iPhone 4S, the iPod Touch 5th generation, the iPad 2, and the iPad Mini 1st generation).
Please upgrade your apps to use the latest versions of the OpenTok server SDKs. These now use JSON web tokens (JWT) for authentication. JWT provides increased security along with standards-based encoding, decoding, and verification. The old form of authentication will expire in July 2017. Also, if you use the OpenTok REST API (instead of the server SDKs), please use JWT to authenticate calls to the OpenTok REST methods (see this topic on authentication).
This version adds support for IPv6. You will need to upgrade to this version to get your app approved in the App Store (which now requires IPv6 support in apps). For more information, see this TokBox Support FAQ.
Fixed an issue that caused clients to occasionally disconnect from sessions on poor or low-bandwidth networks.
This version fixes an audio-video synchronization issue in version 2.8.0.
Note that we have added TLS support added to OpenTok TURN servers. This fixes media streaming for clients behind network firewalls that block non-TLS traffic over port 443.
This version fixes H.264 video codec support. This was disabled in a previous version. The new version adds improved performance. The H.264 video codec is available for streaming between iOS devices only and in relayed sessions.
This version fixes multiple audio issues.
This version of the SDK uses WebRTC 49.
We have fixed the following issues:
If an app using OpenTok is running in the background when a phone call is received and the call duration is more than 10 seconds, the app sometimes crashes when the call finishes.
Distorted "robotic" audio when switching from the loudspeaker to a Bluetooth headset.
cameraFrameRate:] can take long (10 secs) to complete.
Apps using OpenTok sometimes crash when the user switches the network connection (for example, from Wi-Fi to cellular).
Setting the frame rate and resolution for a published stream using the default
camera video capturer. A new
OTPublisher initWithDelegate:name:cameraResolution:cameraFrameRate:] method
includes parameters for setting the frame rate and resolution of the stream.
New methods for getting audio and video statistics for a stream. You can now set a delegate object to monitor the following statistics for a subscriber's stream:
See the documentation for the
Fixed an issue preventing connections from working while the device is locked and app Data Protection enabled.
Fixed an issue that was causing apps to crash when disconnecting from an OpenTok session.
Fixed iOS 9 crash in the video renderer.
Fixed audio distortion issue on the iPhone 6s and 6s+ running in iOS 9.
Fixed the publisher video in the XCode iOS 9 Simulator.
properties to allow easily switching between common scaling methods without
using a custom video renderer.
[OTSession reportIssue:] method. You can call this method
when your app experiences an issue. The method sets an issue ID,
which you can use with the
or when discussing an issue with the TokBox support team.
Increased the default video resolution and frame rate for OTPublisher.
Improved audio device handling.
H264-related bug fixes and improvements (in relayed one-to-one sessions between iOS devices).
Fixed the the following issues:
Data was sent over WWAN when WiFi was available.
Audio was going to the receiver (instead of the speaker) after a phone call ended on the device.
videoDimensions property of an OTStream was incorrect.
When unpublishing a stream, audio for subscribers was dropped.
Added hardware-accelerated H.264 support for relayed one-to-one sessions between iOS devices.
Added proxy support.
Added the implementation of the
[OTPublisher initWithDelegate: name: audioTrack: videoTrack:]
method (inherited from OTPublisherKit).
Removed clang autolink feature from compilation.
Fixed broken video mirroring behavior in the publisher view.
Note that the samples directory is no longer included in the SDK bundle. The sample code is now available at the open-source opentok-ios-sdk-samples repo on GitHub. This allows us to keep it up to date and provide developers with latest version of the sample code. Feel free to clone the repo or download the source code to see the best-practice examples of OpenTok usage.
All calls to AudioUnitGetProperty were removed from the remote I/O thread (in both the SDK and in the external audio device sample app).
Previous versions of the SDK would use the mobile data connection to transmit and receive media streams when a Wi-Fi network was available. We have fixed this issue.
This version adds support for interactivity with clients using Firefox 38 in relayed OpenTok sessions (sessions that do not use the OpenTok Media Router).
Version 2.4.1 and 2.4.0 require different libraries that were required by previous versions of the OpenTok iOS SDK. When moving a project from using version 2.3.1, you need to include the VideoToolbox.framework, and you need to remove libstdc++. For complete details, see "Using the SDK" in the README.md file of the SDK.
Fixed an issue in which an app could deadlock when starting or stopping audio or receiving an incoming call.
The OpenTok iOS SDK is now available as the Pod "OpenTok", for use with CocoaPods.
This version adds support for the arm64 architecture.
This version adds support for screen sharing. When publishing a screen-sharing
stream, set the
videoType property of the OTPublisherKit object and
OTPublisherKitVideoTypeScreen (defined in the
OTPublisherKitVideoType enum). This optimizes the video encoding for screen
sharing. It is recommended to use a low frame rate (5 frames per second or
lower) with screen sharing. When using the screen video type in
a session that uses the OpenTok Media Server, you should set the
[OTPublisherKit audioFallbackEnabled] property to
NO to disable
the audio-only fallback feature, so that the video does not drop out
in subscribers. See the OpenTok Media
When a stream is created in a session, you can determine the video type
of the stream (screen or camera) by checking the
videoType property of
the OTStream object. The type of stream is defined by constants in the
To publish a screen-sharing stream, you need to implement a custom video capturer for the OTPublisherKit object. For sample code that publishes a screen-sharing stream, see the "Screen-Sharing" app in the samples directory.
You can disable the audio-only fallback feature for a published stream by
audioFallbackEnabled property of the OTPublisher object to
NO. The audio-fallback feature is available in sessions that use the
the audio-fallback feature enabled (the default), when the OpenTok
Media Router determines that a stream's quality has degraded significantly for
a specific subscriber, it disables the video in that subscriber in order to
preserve audio quality. For streams that use a have the video type set to
OTStreamVideoTypeCamera, the audio-fallback feature is enabled by default.
For streams that have the video type set to
audio-fallback feature is disabled by default.
This version adds support for armv7s and i386 architectures (in addition to armv7). You can now target the iOS Simulator. However, the Xcode iOS Simulator does not provide access to the camera. When testing in the iOS Simulator, an OTPublisher object uses a demo video instead of the camera.
This version includes a new custom audio driver API. This lets you use custom audio streams and define the audio device used to capture and render audio data. The following new classes and protocols support the custom audio driver API:
OTAudioDeviceManager -- Use this class to set the app to specify a custom audio device for use in the app.
OTAudioDevice -- Defines an audio device for use in a session.
OTAudioBus -- The audio bus marshals audio data between the network and the audio device.
OTAudioFormat -- Defines the format of the audio.
There are new delegate protocols and messages for getting the audio level of a
publisher or subscriber. See the
OTPublisherKitAudioLevelDelegate protocol, as well as the
OTSubscriberKit.audioLevelDelegate property and the
[OTSubscriberKitDelegate subscriberVideoEnabled:reason:] message is sent when
a subscriber's video stream starts (when there previously was no video) or resumes
(after video was disabled).
reason parameter has been added to the
[OTSubscriberKitDelegate subscriberVideoDisabled:reason:] message. This parameter
describes the reason why the subscriber video is being disabled.
In the previous version, this message was only sent when the video was
disabled due to changes in the stream quality (in a session that uses the
OpenTok Media Router). In version 2.3.0, the message is also sent if the
publisher stops sending a video stream or the subscriber stops subscribing to
it (and the
reason parameter value will be set accordingly).
[OTSubscriberKitDelegate subscriberVideoDisabledWarning:] message is
sent when the OpenTok Media Router determines that the stream quality has
degraded and the video will be disabled if the quality degrades more. The new
[OTSubscriberKitDelegate subscriberVideoDisabledWarningLifted:] message
is sent when the stream quality improves. This feature is only available in
sessions that use the OpenTok Media Router (sessions with the
set to routed), not in sessions with the media mode set to relayed.
This version adds support for armv7s and i386 architectures, in addition to armv7. (The SDK does not support arm64.) You can now target the iOS Simulator. However, the Xcode iOS Simulator does not provide access to the camera. When testing in the iOS Simulator, an OTPublisher object uses a demo video instead of the camera.
This version adds support for iOS 8.
This version of the OpenTok iOS SDK does not support displaying videos using Apple AirPlay.
In a session with the media mode set to relayed, only one client can subscribe to a stream published by an iOS device.
The Xcode iOS Simulator does not provide access to the camera. When testing in the iOS Simulator, an OTPublisher object uses a demo video instead of the camera.
Subscribing to screen-sharing streams (see "New features and changes - Version 2.4") is not supported in the OpenTok iOS SDK version 2.3 and older. You must upgrade to version 2.4.
If you are using a version of Xcode prior to 7.2.0, do not use the
linker flag. Instead, use the
-force_load linker flag to load specific
libraries that require it.
The OpenTok iOS SDK links to the libc++ standard library. If another library that links to the libc++ standard library was compiled in a version of Xcode older than 6.0.0, it may result in segfaults at run time when using it with the OpenTok iOS SDK. Known incompatible libraries include, but are not limited to, Firebase (versions earlier than 2.1.2 -- see https://code.google.com/p/webrtc/issues/detail?id=3992) and Google Maps (versions earlier than 1.9.0). To fix this issue, download a version of the other library that was compiled using Xcode 6.0.0 or later.
Video streaming is prevented on networks that have firewalls that use authenticated proxies. This is due to a core issue with the current underlying WebRTC implementation. (See this Chromium bug report.)
In relayed sessions, applications do not display the red bar when running in the background, if no client subscribes to your stream before the app goes into background mode.