SwiftNIO and transport service: current state?


(Mickaël Rémond) #1

Hello,

I am working on client library (a new XMPP library) that aims at supporting both iOS (that's the first goal), but also MacOS and Linux.

After a prototype on SwiftNIO, I decided to use directly Network.framework as iOS support was my primarily goal.

Now, I am in the process of merging my SwiftNIO prototype with my Network.framework transport implementation, making my code use the right transport based on the compile target.

Watching the just release Try Swift talk about SwiftNIO and Transport Service, it seems wise to assume that Transport Service for SwiftNIO seems to be “mature” (= a safe bet to be future proof) and that I should rely (and possibly contribute if needed) to that effort instead of writing dual backend inside my lib.

Am I right to assume I can reach my goal that way and should built SwiftNIO + TransportService to target iOS 12+, MacOS and Linux (using Network.framework when available, falling back to BSD socket when needed) ?

Any gotcha I should be aware of ?

Thanks !


(Cory Benfield) #2

You are correct. :+1:

In general, if you are on a sufficiently new macOS/iOS, you can use NIOTransportServices, otherwise you can fall back to regular NIO instead. This will work well, and it'll let you write all your code to be agnostic of the deployment platform, which is really nice.

If you encounter problems, please do let us know, we love contributions of all kinds.