SDKs for iOS, macOS and tvOS Updated

We recently released version 2.1.0 of our SDKs for iOS, macOS and tvOS. This version introduces some important changes:

• You now have again control on the maximum number of concurrent sessions on the same Server. This feature was part of SDKs version 1.x, but couldn’t be included in version 2.0.x.
• You now have again a connection event specific for authentication challenges. This feature too was part of SDKs version 1.x, but couldn’t be included in version 2.0.x.
• Minimum OS requirements have been raised to 10.9 for macOS and 8.0 for iOS. Thanks to this, we could remove the use of NSURLConnection and all HTTP networking is now done through NSURLSession, reducing the use of threads.
• The SDKs are now packaged as frameworks, no more as static libraries. Thanks to this, the download size has been reduced and they cohabit better with other libraries when imported via CocoaPods (in particular for projects developed with Swift).

See below for more details.

Note: if you need download and example pointers, jump directly to the end of the post (“Get the SDKs”).

Importing the Client Library

Since SDKs are now packaged as a framework, there are some minor changes to take into account when updating your project.

Importing the Library via CocoaPods

Use the following pod names for version 2.1.0:

• For iOS: Lightstreamer_iOS_Client
• For macOS: Lightstreamer_macOS_Client ⚠️
• For tvOS: Lightstreamer_tvOS_Client

Note: the macOS pod name now correctly references macOS, no more OS X. The previous pod, Lightstreamer_OS_X_Client, has been deprecated.

Once the pod has been installed in your project, add the import statement appropriate for your platform in your code or bridging header (for Swift). Since header files are now part of the framework, the import statement now requires that the name of the framework is prefixed. E.g.:

#import <Lightstreamer_iOS_Client/Lightstreamer_iOS_Client.h> ✅

The previous import statement would now fail:

#import <LightstreamerClientAll.h> ❌

Importing the Library Traditionally

To import the library traditionally proceed as follows:

• Download the client library’s distribution and documentation (see “Get the SDKs” at the end of the post).
• Unzip the library’s distribution and copy the framework inside your project.
• In your project’s Build Phases page, add the client library’s framework in the Link Binary With Libraries section.
• Still in the Link Binary With Libraries section, add also the following system frameworks: Security.framework and SystemConfiguration.framework.
• Finally, add the import statement appropriate for your platform in your code or bridging header (for Swift).

Similarly to CocoaPods, since header files are now part of the framework, the import statement now requires that the name of the framework is prefixed. E.g.:

#import <Lightstreamer_macOS_Client/Lightstreamer_macOS_Client.h> ✅

The previous import statement would now fail:

#import <LightstreamerClientAll.h> ❌

Controlling the Maximum Number of Concurrent Sessions

The LSConnectionOptions class now provides a class property called maxConcurrentSessionsPerServer.

The default values for this property are:

• 2 for iOS and tvOS;
• 3 for macOS.

This leaves some connections free for subscription requests and message sending. Maximum values are:

• 4 for iOS and tvOS;
• 6 for macOS.

Trying to set a value higher than these maximums will have no effect. Additionally to the class property, there is also an instance property called maxConcurrentSessionsPerServerExceededPolicy where you can set the policy to adopt in case the maximum number of sessions is exceeded.
Recall that these limits ensure that requests are actually executed by the system. With higher values the system would timeout without even trying (more information here). If your operating conditions require a higher number of concurrent sessions, the appropriate thing to do is to provide multiple Server end-points.

Responding to Authentication Challenges

The LSClientDelegate protocol now provides an event called client:willSendRequestForAuthenticationChallenge:. 
This event is called directly from the connection thread when the corresponding event is received by the network transport implementation. If implemented, it must respond quickly and without blocking: any necessary information must have been collected and cached in advance.
Once it has been verified, the implementation must call one of the following methods on the challenge object:

• useCredential:forAuthenticationChallenge:
• continueWithoutCredentialForAuthenticationChallenge:
• cancelAuthenticationChallenge:
• performDefaultHandlingForAuthenticationChallenge:
• rejectProtectionSpaceAndContinueWithChallenge:

If not implemented, the network transport implementation automatically calls performDefaultHandlingForAuthenticationChallenge:. 

Conclusion

This version reintegrates back little but important features of 1.x, repackaging also the library in a compact format now supported also by iOS and tvOS. But most of all, it is a step further in the process of stabilization, improvement and completion of the second major version of our client library for Apple platforms.

The update is suggested to all our customers.