Importing Lightstreamer with Swift Package Manager

[boris@ig]

As you might heard Xcode 11 now allows us to use Swift Package Manager for iOS projects. This allows us move away from CocoaPods or Carthage. I am already converted our Lightstreamer internal wrapper into Swift Package but I was unable to build it. I am getting errors when trying to import the framework:

error: no such module 'Lightstreamer_iOS_Client'
import Lightstreamer_iOS_Client

I have also tried to wrap lightstreamer into its own SPM project and I am able to build it, but even if my package depends on it, it produces same error.

Quick research showed me that Swift packages do not support binary frameworks, however I think it is worked in Xcode beta 5, now I am using Xcode beta 6 and it doesn't work any more.

Ideally we would have Swift.package file into Lightstreamer client and this would allow us to import it, the code has to be open. Thank you.

[gianluca.bertani]

Hello,

we are investigating the problem. If it will be possible to wrap our client library in a Swift Package, we will surely do. Anyway, consider that we will wait for Xcode 11 to be GM before finalizing such wrapper. Don't hold your breath.

[gianluca.bertani]

Hello again,

we investigated the matter, and I’m afraid we have bad news. As reported even at the very beginning of the official documentation, a Swift package can't contain binaries.

We could publish our source code (in fact, our client SDKs are just reference implementations of our TLCP public protocol, there’s nothing to hide), but our build is currently based on a Java to Obj-C transpilation process (discussed in this blog post) that requires multiple libraries from an external project (Google’s J2ObjC). Those libraries could not be included, since they are binaries, and they are not available in turn as a Swift package.

This rules out the possibility to wrap our iOS client SDK, as is, in a Swift package, at least for now. The day J2ObjC should release their libraries as a Swift package, or if we should ever embark on a full rewrite of the client in Swift, we will re-evaluate the opportunity. Until then, you will have to continue with more traditional ways to add our client to your projects.

Thanks anyway for bringing this matter to our attention.

[dehesa]

Yes, indeed SPM doesn't yet support precompiled binaries. It seems they are on the pitching stage for this feature. For more information check:
- Pitch: https://forums.swift.org/t/pitch-sup...ndencies/27620
- SPM support for binary distribution discussion: https://forums.swift.org/t/spm-suppo...ribution/25549
- SPM bundles & resources support discussion: https://forums.swift.org/t/swift-pm-...esources/13981

It is quite interesting to realize you are transpiling Java to Obj-C. It seem to work well for my usage, which is mainly desktop bounded (https://github.com/dehesa/IG). I do wonder however how well does it play with URLSession including this year's changes (low data mode, etc). I had to do a MQTT library wrapping for Apple systems some years ago and using C and Posix implied not using URLSession, which work as intended on WiFi, but on Cell stop working altogether.

[gianluca.bertani]

Our client library uses only native components for networking: NSURLSession on HTTPS transport, and CFStream on WebSocket transport.

The mechanism we use is a simple dependency injection pattern:

• The Java engine wraps all the services it needs for connecting, receiving messages, sending messages etc., behind a Java interface.
• The Java desktop and Android clients implement this interface with Java classes that use Netty as networking component.
• The transpilation process scraps the interface implementations, leaving just the bare interface, which then becomes an Obj-C protocol on the iOS client.
• Finally, the protocol is then implemented with a Obj-C classes that provide the same services using NSURLSession or CFStream as required.

So, our client is actually well aligned with the latest features of NSURLSession. We don't circumvent them using BSD sockets or similar expedients. Our client is, and has always been, a good iOS citizen regarding networking.

[dehesa]

Thanks for the details, Gianluca! and congratulations on achieving a multi-platform working architecture (I know it is not easy).

[gianluca.bertani]

Thank you very much. It's a team effort of course, I'll forward your words to the other people of the team.

[boris@ig]

Hello again,

we investigated the matter, and I’m afraid we have bad news. As reported even at the very beginning of the official documentation, a Swift package can't contain binaries.

Hi, thanks for your answer. I understand the limitation.

Xcode 11 supports distributing binary libraries with new XCFrameworks format. https://developer.apple.com/videos/play/wwdc2019/416/
Just out of curiosity, I have tried to run

cd lightstreameriosclientxcodebuild
-create-xcframework -framework Lightstreamer_iOS_Client.framework -output lightstreamer.xcframework

And I am getting error:
error: binaries with multiple platforms are not supported

Is this because your binary contains Java? Only Swift and "C based code" is supported.

If you decide to rewrite your client in Swift — XCFrameworks is wonderful tool for distribution with official support. It's great alternative to SPM if you don't want to go open source. I wish you all the best.

[gianluca.bertani]

Hello,

no, Java is surely not the culprit. In fact, our client library does not contain or incapsulate Java code, nor a Java Virtual Machine, by any means. It contains only pure Obj-C code transpiled from Java code, the meaning of this being: Obj-C source code automatically produced by a tool to be functionally equivalent to its corresponding Java code. Plus a number of support libraries (which are still pure Obj-C).

The error you see is due to our binaries supporting multiple architectures: different iPhone/iPad ARM code segments, plus the x64 code segment for the simulator. An XCFramework could be built starting from separate code segments, i.e. multiple single-architecture frameworks instead a single multiple-architecture framework.

I will check out the added support for binaries and keep this thread updated. Thanks for the heads up.

[dehesa]

Hi Gianluca,

The Swift Package Manager has now implemented all the requirements needed to distribute LightStreamer through SPM. You can see the new features in the Swift Evolution status page. Specifically:
- SE-273: Package Manager conditional target dependencies.
- SE-272: Package Manager binary dependencies.
- SE-271: Package Manager resources.
- SE-278: Package Manager localized resources.

These features are already implemented and can be accessed in the Swift development snapshots. They will be released to the broad public with Swift 5.3. Supporting SPM would definitely help me out managing dependencies and updating libraries. Please consider supporting SPM as soon as you can (SPM better than XCFramework).

In that same vein, boris@ig, IG could also update its Lightstreamer requirements. It seems it has been frozen in time.