I’m not convinced Swift is going to be a long-term hit in server software.
The big push I’ve heard about is from IBM. In this recent talk, Chris Bailey gives some reasons to use Swift on the server:
- It’s faster and uses less memory than some other technologies.
- It has the potential to reduce communication errors when used for both the client and the server. Chris mentions the Mars Climate Orbiter as an example of such an error.
I personally don’t find these arguments compelling.
First of all, plenty of extremely popular technologies are not the most performant technologies. You choose them because they’re easier to develop in, easier to maintain, easier to keep up and running. If we wanted the very fastest, we’d still be writing server software in C.
Second, most current server software is written in a different language, and with different libraries, than the client software it talks to. People know how to solve this problem. Hint: switching to a new language isn’t necessary.
Third, native iPhone and Mac apps are an important but not overwhelming subset of the clients a server has to talk to. The Swift advantage vanishes if we’re talking about Android or Windows or web clients.
So is Swift going to be easier to develop in, easier to maintain, and easier to keep up and running than its competitors on the server?
Making it those things for server software is certainly not Apple’s priority. Their goal is to make it work for them, which means low-level OS software, frameworks, and native application development.
IBM can try to do this work. Chris’s talk is all about the extra steps they’ve taken, the extra projects they’ve written, to do just that.
But at some point, as part of their effort, IBM is going to want something from Apple, something from the Swift development effort, which clashes with what Apple thinks is important.
Who’s going to win that clash?
Weaponized Fluff 
For what it’s worth, I think the value potential here is the ability to use shared code on both the client (mobile device) and server side of a distributed service. That game never played out well with Javascript because of the morphing and inconsistent means of handling packages and modules, but has repeatedly been the play with “isomorphic javascript”.
I haven’t worked with swift long enough to have a feel for if it will be easier to maintain software than say GoLang, Ruby, or Python. The significant breaking changes over the past year, and the planned breaking changes upcoming make me think “Well, not yet anyway…”