Network.framework support
ferologics opened this issue · comments
Hi, how could I use this websocket on iOS client app without entire Vapor stack? I'm looking for alternative light weight SocketIO implementation
Me too
You can always use https://github.com/daltoniam/Starscream, socket.io swift client also implemented on Starscream.
Starscream is just a client but we are interesting to the server side part of the core.
NIO Transport Services are now available for iOS and other Apple platforms. In theory Vapor Websocket can run on iOS. Just need to figure out server creation.
We're working on making it easier to use Vapor on top of NIOTS. One of the issues right now is that SPM doesn't allow us to dynamically depend on https://github.com/apple/swift-nio-transport-services only on platforms where it will compile. So to get it working, we would need to hack our Package.swift files a bit or create separate packages. I'm working with the NIO team to see if we can find a better solution to the problem, you can track that here: apple/swift-nio#796
But generally, we're hoping to get to place soon where you will be able to easily opt-in to using Network.framework where supported with any of our packages built on NIO.
Hi @tanner0101 ! :)
I didn't quite understand your last message. Do you mean the problem is solved ? Is there a way to use it on iOS ?
I added it to my iOS project but I can't figure out where to go from here. I don't know how to use the WebSocket constructor. I made the init public and then I should create a class that responds to the Channel protocol right ? 🤔
I got it working thanks to the example is the tests, thanks! :)
All is working well except one aspect. When I run the app on my iOS device with a port (i.e. 8090) and then I kill the app, when I run the app again, I get the error bind(descriptor:ptr:bytes:): Address already in use (errno: 48)
Since the app is killed, I don't understand when I have the opportunity to free up the port. Did someone encounter that problem please ?
That means that whilst you might have sent a termination signal to the app, it didn't actually terminate and is still bound to the port. Another kill (or kill -9 if you can) should sort it out. Additionally make sure you're on the latest packages as there were some fixes recently for not releasing connections.
Thanks for your response! I am using the last version and the problem remains.
Unfortunately I cannot manually kill the process, I'm running it on my iOS device.
In your opinion, are sockets handled differently by the system on iOS and macOS ? I mean, should I persist or maybe this library is not suitable for iOS ?
Thanks! :)
This library should work on iOS although it certainly isn't the main platform that it's built for