It depends on what you're doing. Swift Foundation is cross platform for Windows/Linux/macOS and exposes apis for things like file systems, paths, process creation with the caveat that what a "Thread" is or what it means if a file is executable is a little different between platforms. If you're writing a cli tool you should be able stay mostly within the Swift stdlib and Foundation and that'll work on all platforms. As more libraries are ported to Windows (e.g. hopefully swift-nio), that should become more and more the case.
Where this isn't the case would be if performance mattered, some of Foundation system api implementations (at least, the Windows ones) can be a little inefficient since the Foundation api model and the Windows way of doing things doesn't always match and the Windows implementation has to do extra work to match the semantics.
Another would be UI wise, I haven't heard of plans for Apple to open source SwiftUI. Though since Swift can call into the native platform apis, it's quite possible to write a (perhaps not as slick) alternative.
Sounds like things have improved in the last couple years, thanks for the information. If they get to the point where a basic database-querying microservice will usually compile on all three platforms, I could imagine a lot more server-side interest in the language. Who knows?
FWIW it's already viable to use Swift in the micro-service use-case. If you're running logic inside containers it's trivial to get a Swift service up and running.
Where this isn't the case would be if performance mattered, some of Foundation system api implementations (at least, the Windows ones) can be a little inefficient since the Foundation api model and the Windows way of doing things doesn't always match and the Windows implementation has to do extra work to match the semantics.
Another would be UI wise, I haven't heard of plans for Apple to open source SwiftUI. Though since Swift can call into the native platform apis, it's quite possible to write a (perhaps not as slick) alternative.