Swift is not ready for the web

Leonardo Pessoa
Leonardo Pessoa
Published in
3 min readJun 17, 2016

When I started learning Swift I was very pleased to know it shipped a compiler for Linux. Swift is a very interesting and easy language to learn (ok, I’m talking from the point of view of someone who cannot count on his fingers how many languages he knows) and being able to write code that could be shared between a front-end mobile/desktop app and a web back-end would be an enabler of great possibilities to me.

My impressions on Swift were so good I even decided to take part on the forum that discusses the evolution of the Swift language and try and contribute to it.

Running on the server-side

After taking part in this group and developing a staging server-side app I began to consider several aspects that would make it hard to develop my apps in Swift and decided it was important to share them.

  • The language is still unstable. Even Swift.org has a link describing how the many differences between Swift 2.2 (the current stable version) and Swift 3 will break apps. Even on the swift-evolution forum it is wide-known that the changes will break each and every app written in Swift so far. And it seems it has been just the same when they migrated from Swift 1. With every major change in the version of the language there would be the need to fix broken code everywhere, something iOS/macOS developers will already experience this fall and there are signs this same break will also happen when Swift 4 is out maybe next year.
  • There is no way to dynamically load/unload code. Lie, there is: NSBundle.load() and NSBundle.unload() could do the trick, if at least they had been implemented on the Linux version. One can even browse the published source code of the language and see for themselves those function bodies only have a mark that produces an error because that is not implemented. Without this feature server-side apps are unable to have their own third-party plug-ins and extensions and even writing a common application server in/for Swift is impossible; your server-side app has to have each and every feature build-in and be the server app itself (be ready to manage things like sessions and connections).
  • There is only one platform option besides macOS. Despite I’m a big fan of Ubuntu, specially as a server, I would like to be able to deploy or at least develop Swift server apps on many more different platforms like Red Hat and even Windows but there is no word on when (or even if) an official distribution for other platforms will be available. I would expect a 3.0 language to be available to a lot more platforms than just 2.

After these considerations, I decided to withdraw from my decision to work with Swift for server-side apps and go for another more stable language. I have chosen Ruby over a few options having seen it as a very stable, easy to learn and mature language and even many of its constructs are closely similar to those found in Swift - but many more are just as alien.

Of course if those aspects that were important to me and to the kind of server-side apps I was planning on developing are not relevant aspects for you and your projects, I would advise you to go ahead and give it a try if it fits your particular purpose.

EDIT on 23/06/2016: Four days ago (about two days after the current post was posted) a new merge was made into the Swift core library adding support for loading bundles using the NSBundle class. At least one of my arguments for not using Swift on the server-side has been partially addressed.

--

--

Leonardo Pessoa
Leonardo Pessoa

architecture student (5/10) · designer · developer · geek