Thursday, July 14, 2022

An Update on Swift and Vapor

When last I wrote about the Swift programming language and the Vapor web framework, I focused on how the server-side development experience was on the cusp of becoming much, much better by the introduction of the async and await keywords. It’s been a minute, several new versions of Swift and Vapor have been released, so I think it’s time to write an update.

Swift 5.5 was officially released on September 20, 2021 and did indeed include the initial implementation of concurrency as a language-level feature, including the async and await keywords. This was followed up by the release of Swift 5.6 on March 14, 2022. Swift 5.6 was something of a smaller release, seemingly focused more on improvements to the type system. Swift 5.7 is now in the beta phase of development and builds on the concurrency and type system features of the last two versions along with a number of other features like a new regular expression engine, syntax improvements for generic typing, and more. Swift 5.7 feels like another big release and includes a number of changes that will improve the ergonomics of using Swift. Based on the pattern of recent Swift releases, version 5.7 seems destined for release sometime in September.

Vapor, too, has been updated since that last post. The async/await branch was merged into the mainline Vapor release with version 4.50.0 on October 26, 20211. I had previously feared that Vapor would be unable to adopt the async/await pattern until one of its key dependencies — SwiftNIO — did. Happily, that proved not to be the case as Vapor was able to wrap the concurrency features of the SwiftNIO library, making the Vapor API async/await compatible.

Finally, there has been a significant improvement when it comes to the code editing experience outside of Xcode. I previously reported disappointment with Swift’s canonical Language Server Protocol (LSP) implementation, SourceKit-LSP — going so far as to call it “nearly useless”. I’m thrilled to be able to say now that is absolutely no longer the case. Combined with the Swift Server Work Group’s new plugin for Visual Studio Code, working with Swift in VS Code is now much more enjoyable.2 I still wouldn’t consider SourceKit-LSP to be speedy, exactly, but it is now responsive enough to be generally very useful. I have also found it to be much more reliable, able to work without crashing and able to register locally-defined types much more readily.

As the owner of its platforms, Apple can through shear force of will ensure that Swift is a viable choice of language for development on Apple platforms.3 That isn’t true, however, of other contexts. I’ve long felt that Swift had great potential as a server-side language on non-Apple platforms but that potential wasn’t being realized. The adoption of async/await feels like a significant step forward in that regard. I haven’t written about it much in this post but Swift 5.7 also feels like a significant step forward with first-class regular expression support, simplified syntax for generic typing, updates to the concurrency features, and more. Only time will tell if Swift will see broader adoption as a server-side language but I’m finally starting to feel that there’s a good foundation now for that to happen.


  1. This release came only about a month after the release of Swift 5.5; a remarkably fast turn around. 

  2. Admittedly, though, I have not yet tried any non-Apple editors other than VS Code. 

  3. Apple’s influence notwithstanding, many early adopters of Swift did feel burned by the relatively large number of backwards-incompatible changes to Swift’s syntax prior to version 3 and Swift’s early adoption was slowed as a result. Since version 3, however, Apple has had considerably more success persuading developers for its platforms to adopt Swift.