@kobit I've used some time to learn internals of Network.framework and at this point I would say it is problematic to use it by us. I was able to build a simple test app which connects to the XMPP server and even is able to do StartTLS, but there is almost no way to pass configuration data to the implementation using this framework. Almost all classes are final which makes them difficult to use and we would have to use "a map with shared state" to pass values to connection instances (at least according to the Apple engineer) but we could make that work.

The question is which way we should go?

1. Use Network.framework Problematic due to what I've state above.
2. Use our own implementation of SSL (using OpenSSL) Most likely would require some time and forwarding data between C and Swift
3. Use swift-nio Would add overhead, may reduce difficulty but would hide some Network.framework features (yes it is a wrapper for Network.framework)

I would say, it would be worth to try to support Network.framework directly - more flexible and should improve in future versions.

However, I was unable to make it work (I was unable to pass configuration in any way, so it is unusable for us).

In the end, we may keep what we have now (at least for a while) or implement SSL support with use of OpenSSL or use swift-nio (which should be the easiest as it is "netty"-like and keeps some logic out of our view.

At this point, I'm considering waiting until WWDC and in the mean time reporting feature request at Apple to add a way to pass parameters to Network.framework framer class.

Do you agree? or should I try to use one of mentioned solutions?

+1 I agree.

And as for deciding which of the 3 options to pursue, I am relying on you here. My expertise in the subject is very limited.