Current Features & Benefits of the Top Server-Side Swift Frameworks

19 min readMar 29, 2017

While Server-Side Swift is production ready in my eyes, I know that it can be difficult to recognize where to start or what will fit your needs. Based on my own research and experiences, here is an overview of each of the popular frameworks.

I have mentioned this in past talks, but it is definitely worth repeating here: You should try all the frameworks and see what works best for you. I have even done benchmarks in the past, but really you should never pick a framework on speed alone, or any other single metric. Give them all a try.

The top Server-Side Swift frameworks at this time are Vapor, Perfect, Kitura, and Zewo. Each one is a bit different, and having developed in all of them, I hope to offer you some insight here. I’ve listed them below in order of the number of features, smallest to largest.

If you are reading this, you should also note that this information is current for March 2017 and could have changed by the time you got here.

Let’s Start with Zewo

Zewo takes inspiration from Go, and strives to use Go-style concurrency while avoiding callbacks. It is licensed with the MIT open-source license and is maintained on GitHub by private individuals as far as I know.

Zewo is certainly fast enough to use and has all the basic features you might expect from a server-side framework. This includes things like HTTP request/response, url routing, TLS (SSL), Websockets, templating (Mustache), and structured data (JSON/XML). It also allows the use of middleware (filters).

Zewo supports the Turnstile authentication framework, and thus logins and sessions. It also has support for JSON Web Tokens though its own native package. Zewo has some connectors available for MySQL, PostgreSQL, Redis, and RethinkDB, as well as an ORM for use with Postgre.

For deployment options, Zewo has Docker images and supports all native Swift platforms (macOS or Ubuntu 14/16).

When looking at educational materials, Zewo includes a basic project sample, an example for ToDo that shows the use of the server, as well as the PostgreSQL connector. They also have examples for using websockets & graphQL. Zewo’s documentation is currently limited to a getting start guide.

Where Zewo Shines: If you’re looking for Go-style concurrency and avoiding callbacks, Zewo is where you will find that. Though quite fast, that does not actually make it quite the fastest available, but some developers may find the Go-style approach in line with their own preferences. Zewo is also the only framework that has an active graphQL example, but (to be clear) that does not make it the only framework that can support it, as GraphQL is a third-party Swift package that works on its own. What Zewo does have all to itself is ZeroMQ and Lua script packages. Thus, Zewo is very useful on projects that require running Lua, Connecting to RethinkDB, or dealing with ZeroMQ, as these features are unique to this framework.

Where it Falls Short: Zewo is not as big of a community as the other three frameworks in this article. This means that support is somewhat limited overall, and documentation is very far behind the others. Documentation is currently no more than a getting started guide (March 2017). If you want to learn the ins and outs, you will be reading a lot of code and you will need to be very active on their Slack, because there are very few code examples posted. Smaller community also means that development has been slower and while Zewo has a minimum feature set, it does not go as far as the other frameworks, which you will see more detail on below.

Zewo Overall: If you’re after Go-style concurrency with without callbacks or you are in the market for a Swift framework that has native support for ZeroMQ, Lua, or RethinkDB, Zewo is your framework. If you need extensive documentation, you are looking for a lot of tutorials, or a feature set that goes a bit beyond the basics — you may not find what you are looking for here. This does, however, present a distinct opportunity to anyone who is looking to heavily contribute features to a framework or is interested in developing documentation, as this is where Zewo needs the most community driven help.

Next is Kitura

Kitura is developed and supported by the might of IBM and probably got its start in the enterprise partnership between IBM & Apple announced in 2014. It is Apache 2.0 Licensed.

When looking at Kitura, you will find the standard feature set that you would expect from any server-side framework similar to Zewo above, as well as a few more advanced features that go a little further. One notable difference, though, is that Kitura currently lacks support for structured data outside of JSON natively. If you need XML, you will have to look for Swift Packages elsewhere or borrow from one of the other frameworks. Kitura also has support for Aphid MqTT (Internet of Things/IoT Messaging).

Authentication wise, your Kitura projects rely on Kitura-Credentials. Kitura also has pre-built middleware for both CORS and CSRF, as well as third party login wrappers for Google, Facebook, and Github authentication. Native support for JSON Web Tokens has not yet been implemented.

Kitura is very unique in its approach to databases. For SQL database types, Kitura uses a SQL database abstraction layer called Kuery (pronounced as “Query”) that unifies the subtle differences in them into a single API. Though Kuery, they have support for MySQL, SQLite, and PostgreSQL. Kuery is not meant to be a full ORM per-se, but rather an abstraction to SQL to make native SQL queries more Swift-y. Kitura also has support for Redis, CouchDB, Apache Cassandra, and ScyllaDB, but through native packages that are not related to Kuery.

Kitura goes further by having not only templating for not only Mustache, but also for Markdown and Stencil. Additionally, they include support for FastGCI, allowing data streaming through current server setups with Apache. Diving a bit deeper, they have a native connector for Watson API Services including Weather Analytics, as well as an HTML5 entity escaping library that can come in real handy.

Deployment with Kitura is, of course, compatible with native Swift environments in at least macOS and Ubuntu 14/16. But this is also where we diverge a bit from the other frameworks, as being a part of IBM gives you a native macOS App that integrates directly into their Bluemix platform. If you already use Bluemix for your hosting needs or your employer does, this has some obvious benefits.

If you are looking to learn Kitura, educational resources are not in short supply. Kitura’s website has a great getting started guide, as well as full breakdown of the functions included in their API, an organized section on their website for tutorials, and additional guides for building, testing, & deploying.

Where Kitura Shines: The obvious answer here is that if you already use Bluemix, Kitura is going to rock your Swift world. But digging a little deeper, some of their unique features like IBM’s Watson APIs, Apache Cassandra, ScyllaDB, and Stencil templating are going to make Kitura essential for any project that requires them. This makes Kitura great for projects that need a connection to a system that has one of the databases that are unique to this framework (Cassandra & Scylla), or relies on any IBM service, such as Watson or Bluemix.

Where Kitura Falls Short: In community size, Kitura still ranks number 3 out of 4 on Slack members. While it has more members than Zewo, it is still not the most active of the four, though I can personally attest to the helpfulness of the staff at IBM and the rest of the community on their Slack. If you want to use database handling inside Kitura for SQL, you will be stuck in Kuery, and you will be using its syntax. Since the syntax is similar to native queries, it’s not a large leap, but it does have a small learning curve. If you want to use Turnstile for authentication, you will need to look elsewhere. While it does have its own robust and native authentication package, Kitura is the only framework with no support for Turnstile.

Kitura Overall: Kitura is shaping up to be a fine framework backed by the mighty IBM giant. They are not likely to disappear anytime soon, and development will surely continue at a decent pace. They are not the biggest community and they certainly do not have the largest feature set, but the basics that most developers need are in place. Some of their unique features may be very attractive to you if your project depends on them, and some you may find require a bit of getting used to (Kuery). You also may find that certain IBM platforms have their own attraction, such as Watson or Bluemix. Kitura is great for projects that need to integrate with other IBM services or projects that are intended for deployment on Bluemix.

Onwards to Vapor:

There are two things you will notice about Vapor immediately: They have an enormous and very active community, and they have a very simple syntax. Vapor is also the only framework to focus on being written purely in Swift. Vapor is owned and run by the startup Qutheory, LLC and uses the MIT License.

Swift exclusivity makes Vapor a little different from the start. First, it does sacrifice a little speed (it is important to note here that speed is not the only, or even the most important factor in choosing a framework, which is partially why this article exists). What Vapor gains from being Swift-only is a very readable and understandable API, as well as removing dependence on a lot of third parties. i.e. Where other frameworks may choose to implement things like Node.js’s HTTP parser, Vapor has its own Swift parser. This also allows them to focus on keeping their APIs simple, readable, and keeping their naming and other conventions (with lots of protocols) in line with the language. Much in the same way that Zewo is very passionate about Go-Style Concurrency, Vapor is very proud to be exclusively written in Swift.

Vapor also has a great core set of features, along with some of their own. The only basic features notably absent in comparison to Kitura and Zewo is native XML, CSRF middleware, and FastCGI support. However, they also expand on many features that Kitura and Zewo have yet to, such as support for Apple’s Push Notification Service and SMTP for sending emails, both of which come in very handy.

Vapor’s database support is very thorough. They not only have native connectors for SQL languages like MySQL, Sqlite, and PostgreSQL, but also include native support for Redis and MongoDB. In addition, they also have the Fluent ORM system with support for SQLite, MySQL, PostgreSQL, and MongoDB. Since they are also entirely focused on a well done Swift API, Fluent’s drivers are protocol-oriented and that makes it relatively easy to add your own if you know your way around Swift plus whatever database you choose.

Turnstile, the popular authentication framework for Server-Side Swift is baked into Vapor. You can use it without having to add it in as a dependency. They also have an entire crypto library as a separate, native repository for you to make use of. This is all in addition to native frameworks for things like authentication and sessions, which also have pre-built Fluent ORM handlers for database storage. CORS support is also available as pre-written middleware.

Having a very active community comes with very active development. After officially releasing Vapor 1.0 in September, 2016, the team has been hard at work and is currently rolling out Alpha tests of Vapor 2.0, often at the rate of multiple times per day.

A number of features that are exclusive to Vapor exist. First, they have their own templating engine in addition to supporting Mustache and Markdown. Their own templating system is called Leaf, and it’s native to Vapor. Leaf has the advantages of being natively Swift and being designed to integrate in a way that works well with Vapor’s engine, the underlying system that deals with requests and responses. Also quite unique is Vapor’s route type-validation system, meaning that you can have routes that will only work when passed a certain type, such as an Int. Another exclusive is SwiftyBeaver integration, which was actually developed by the creators of the SwiftyBeaver logging system. Vapor also has a suite of command line tools for creating and manipulating projects, which is installable through shell or though their own homebrew tap. They also have a library of tools that help to create command line applications in Swift, including useful items like progress indicators. Vapor also includes a command line interface, which is a very unique feature to their platform. They even have a console protocol for easily extending your applications command line arguments with custom flags.

Deployment with Vapor, like everything else Swift is compatible natively with macOS and Ubuntu 14/16. Vapor also has Docker containers, as well as helpers in their ‘Toolbox’ command line utility to help run Vapor on Heroku or to build a Docker container.

Widely available educational resources are an additional standout of Vapor. Their documentation is well organized and easy to use, though not quite exhaustive just yet (if you are looking for things like native MySQL, you will have to look in the GitHub repositories for instructions and code). A very distinct and beneficial item that Vapor has is their own video library found at http://vapor.university. Here you will find a collection of Video tutorials and presentations about Vapor, including many from the popular tutorial maker Ray Wenderlich. Example projects are also avialable on Vapor’s GitHub including Leaf Templating, SQLite, Authentication, ToDo, The Vapor University Website Itself, Chat, Fluent ORM, a Dashboard, Pokedex, and a Slack Bot. They even have started minimal documentation in Chinese.

Where Vapor Shines: Vapor clearly has the cleanest and easiest syntax to learn and the largest community. This makes Vapor great for beginners. Those new to Swift will find the educational resources, simple syntax, and extremely active Slack community of great value. If you are in search of a Swift-only Server-Side Framework, this is also the only option for you, as the others include at least one C library. Users of SwiftyBeaver may find that the native connector is also a plus. Another huge plus is the route-type validation system, push notification support, wide use of protocols, SMTP mailer, and the very complete feel to their database support.

Where Vapor Falls Short: They sacrifice a little bit of speed and performance in favor of being pure Swift, so if you need a speed demon that will handle a ridiculous volume of traffic, you may find that another framework may suit your needs (or server budget) a little better when scaling. That does not mean it is slow, it is just not the fastest available. While they have a ton of education, the documentation could be more complete, especially for some of the native databases (pull requests are appreciated if documentation is your forte).

Vapor Overall: Vapor is well suited to beginners and veterans who prefer a simple syntax or a pure-Swift library with a great feature set. They have a very vibrant and active community that produces a lot of quick releases and fixes, as well as quick support on Slack. Vapor is great for projects that need to be very concise and readable, implemented quickly, and those within the scope of its feature set.

Finally, Perfect:

Perfect is big, powerful, fast, and absolutely jam-packed with features. Perfect is run by a Canadian startup, PerfectlySoft, which is well capitalized by seed funding and well supported by an established agency. Also striking about Perfect is the entangled history its team has with Apple, most notably that some team members come from the original Lasso language team, a programming language that Apple once included in their lineup. This team has been developing server-side technologies for many years, and strategically chose to move their careers to Swift. Perfect is licensed under Apache 2.0.

The first thing to take note of in Perfect is that there are an enormous amount of repositories. So many, in fact, that they have divided them into different GitHub teams based on purpose:

https://github.com/PerfectlySoft contains the main repositories for the Framework and Engine
https://github.com/PerfectExamples contains all of their example projects
https://github.com/SwiftORM contains the StORM ORM and its database connectors
https://github.com/PerfectServers which contains complete, pre-written apps that are immediately configurable and deployable

This is probably because the code library would be difficult to manage in any other way. It also means that they have a very large feature and example set.

Perfect does have all the basic features you would expect, including things like routing, websockets, TLS (SSL), logging, Mustache, Markdown, JSON, etc… It also has some extras that are also found in other frameworks, such as XML, Apple Push Notifications, MqTT, and SMTP for emailing. You will have a hard time finding basic features that Perfect lacks. The only notable feature missing is native route type validation. As far as gaps in specialized features go, they are mostly lacking in proprietary areas you would expect to be missing like IBM services and support for formats like Vapor’s Leaf. Perfect also does not have any command line tools, though they do have a native Mac app.

The Perfect community, like Vapor, is also very large and very active. It is the second largest community of the four, coming in a little shy of Vapor, but also growing very quickly.

Perfect has a wide variety of database support. They have native connectors for SQL languages like MySQL, SQLite, PostgreSQL, and MariaDB. They also support MongoDB, Redis, CouchDB, and even FileMaker. Perfect also has a partial implementation of Microsoft’s ODBC under development, which is sort of a low-level API for accessing multiple database types thorugh one interface. Think of it like an ORM, but low-level C. Speaking of ORMs, as mentioned above, Perfect has the StORM ORM, complete with implementations for PostgreSQL, MySQL, CouchDB, Mongo, and SQLite.

First in the security and authentication is Turnstile. This is a popular third party framework from Stormpath, and there is a vendor implemented library on Stormpath’s GitHub. There are also Perfect implemented Turnstile versions that extend the vendor implementation and include things like pre-made StORM providers for immediate database-based authentication without the need for a custom implementation. You can find those here. Perfect, like Vapor, also has it’s own crypto library for your use, as well as SPNEGO/Kerebos, LDAP, and Active Directory support. They also have a native OAuth2 library, which provides pre-written implementations of popular third party logins like Facebook, Google, GitHub, LinkedIn, Slack, and more. Perfect is also notable for supporting basic HTTP authentication. Perfect also provides their own custom implementation of sessions. Finally, they offer pre-written middleware packages for both CORS and CSRF.

Perfect has quite a few unique features that are not found in the other three frameworks. This is certainly where they put a lot of their effort and take a great deal of pride. One of the many distinctive features is a native cURL wrapper, that allows you to use libcurl inside of Perfect. Another notable feature set involves deep interaction with directories, files, and zip. They have robust support for working with files (create, read, write, & delete), directories (create, list, delete), and zip (both zip and unzip). They are also the only framework with support for MariaDB, ODBC, and FileMaker.

Additionally, Perfect exclusively has an OAuth2 flow wrapper, and they are the only framework to have their entire docs, plus a majority of repository READMEs fully translated into Chinese. They are also the only framework offering pre-written applications meant for immediate deployment and the only place I have seen an implementation of BSON (Binary JSON). They also exclusively support SPNEGO/Kerberos, LDAP, Active Directory, and Big Data (GridFS/Hadoop, etc…).

Perfect also developed a native Mac App meant to manage not just Perfect projects, but any Swift Package Manager based project, called Perfect Assistant. Perfect Assistant is integrated with Docker for testing Linux, as well as AWS & Google Cloud Platform for automated project deployments. It includes the ability to create new projects that are empty SPM packages, based off the Perfect Template, based off one of several examples, or as a clone from an existing git repository. When managing a project, it allows you to build for macOS or Linux (through Docker), clean the build, generate an Xcode Project, integrate and Xcode Project (which means that it adds a shell script that runs the Linux build through Docker each time Xcode builds — handy if you plan to deploy on Ubuntu), run tests, and more. It is also a dependency manager, and can fully manage your Package.swift in a drag-and-drop style. The pre-arranged package dependencies are heavily geared towards Perfect, but there is also a button to add from any existing remote repo.

In addition to their own native Mac App, Perfect is also integrated with a specialized IDE called SCADE. Scade is an IDE that allows you to use Swift to develop cross-platform, native mobile applications for both iOS and Android (as well as Perfect Projects). SCADE accomplishes this feat by having their own SDK that compiles source code native to both platforms on the backend. For the curious, SCADE is currently in private beta, and the only way to get an invite is to join the #swift-android-ios on Perfect’s Slack Channel (Slack links are at the end of the article).

Perfect has a wide variety of deployment options. As with the other frameworks it is compatible anywhere Swift is (macOS & Ubuntu 14/16). Perfect also has Docker containers that can be used to deploy in other environments, as well as a FastCGI connector for Apache and a Heroku Buildpack. Deployment can also be managed for AWS or Google Cloud Tools through Perfect Assistant, the macOS App noted above. Aside from comprehensive deployment options, Perfect has a very unique repository of pre-written applications that are ready to use with minor configuration including applications like SwiftSlack, a Swift port of Slackin, designed to quickly get new users invites to your Slack Team.

There is no shortage of educational resources for Perfect. As noted earlier, there is an entire GitHub organization with nearly two full pages of example projects on a wide variety of topics. Perfect has a set of instructional documentation and API documentation. If you speak Chinese, you are also in luck, because their documentation has been translated, as well as the READMEs on most of their repositories. If you are looking for video tutorials, there are plenty out in the wild from sources like The Perfect Team, Ray Wenderlich, myself, and others, though they are not aggregated anywhere yet. There are also no shortage of articles. Like the other frameworks, Perfect has a comprehensive getting started guide.

Where Perfect Shines: Perfect has a very robust feature set that includes a lot of things that no one else has. They also have a ton of examples to go with those features. Both of those things make Perfect a good choice for anything complicated. If you are in search of a framework that works tightly with things like cURL, Filemaker, Kerberos, Active Directory, BSON, Hadoop, GridFS, OAuth2, or ODBC, you are not going to find that anywhere else. Likewise, Perfect is the only framework that directly supports MariaDB, working with directories natively, and zipping/unzipping directories, so if those are on your list of desires, Perfect is a good place to start. Perfect is also incredibly well organized due to their use of separate GitHub organizations for different purposes. Despite Zewo modeling after the notoriously fast concurrent model for Go, Perfect still comes out the fastest of all the Server-Side Swift frameworks.

Where Perfect Falls Short: Perfect does not have the easiest (or shortest) syntax. Perfect is very technically oriented and it is not as well suited to developers with little experience with building from scratch. Given the initial focus on performance, many of the technical feats and features they have come at the cost of some syntactic sugar, a fact which they have ackowledged, but has yet to be remedied by the community. Perfect also has no central location for their tutorial videos and articles, many of which are user provided, which makes them more difficult to locate vs. something like Vapor University’s clean aggregated feed.

Perfect Overall: The robust feature set makes Perfect great for complex projects because it simply does more than any of the others. Perfect’s large set of examples, extensive documentation, tutorials, and community also make it attractive for larger projects because there is simply more to draw from. Given it’s speed and capabilities, Perfect is great for any application that manipulates files or directories or works with a large data set, as well as for projects that need to integrate with a system like FileMaker or Active Directory. It is also well suited to projects that scale to a size where you need to worry about having the fastest request/response. Perfect is also has the deepest hooks of the frameworks, meaning that something like Vapor or Kitura could be built using Perfect.

Overall

While all of the frameworks tend to do the same thing, they are very different when it comes to their capabilities and resources. Each framework has something unique to offer. Choosing what works best for you needs to be a good blend of requirements, what you like, and how fast you need it to be done. I recommend testing each framework and deciding for yourself what works best for your needs.

There are some features that no one has yet, that would be incredibly useful. These include things like two factor authentication, a robust permissions system for authenticated users, or a robust library to draw server stats from, native CSV handling, etc… For those of you inclined to make pull requests, now is a great time to get involved in the community.

The Swift Package Manger is a wonderful thing. It means that you can mix and match dependencies that you want. This also means that you are welcome to use things outside of the frameworks. Here is a list of repositories that I often add to my projects, which are not part of any of the frameworks:

https://github.com/yaslab/CSV.swift (for working with CSV files)
https://github.com/iamjono/SwiftString (a lot of convenient methods for working with strings)
https://github.com/iamjono/SwiftRandom (easy ways to generate random things directly in the type you need them)
https://github.com/stormpath/Turnstile (authentication)

I also have a few of my own under development:

https://github.com/rymcol/SwiftSQL (Right now it basically converts dates to and from common SQL formats, but I plan to expand it to more SQL types in the future)
https://github.com/rymcol/SwiftCron (Scheduled and repeating functions in macOS, sorry, no Ubuntu support yet because it relies on the Objective-C Runtime) (an example is also posted here)

I think the future for Swift on the server is very bright. I use these frameworks in production on personal and client projects. I have never been happier with a server-side language. I also never want to see a semicolon ever again, though I am sure I will continue to type a them by the hundreds until WebAssembly lets me get rid of Javascript on the frontend. As time moves on, I am sure that we will only see more features and more improvements from everyone.

Get Involved

If you are interested in Server-Side Swift, now is the time to get involved! There is still a lot of work to be done on the frameworks, their documentation, tutorials, as well as public applications, open or closed source. You can learn more about each framework and get involved here:

Get in Touch

If you want to connect, you can reach out to me @rymcol on Twitter. I also recommend following me here for future updates.

Disclosures: I’m on github teams for both Vapor & Perfect because I contribute to them. I am not an employee of either, nor do my opinions reflect theirs. PerfectlySoft Inc. agreed to fund the research behind this article for me, to better understand the state of all the current server-side frameworks and help themselves to build a better roadmap. I’ve done my absolute best to remain completely impartial, as I develop in all four platforms, and I’m heavily involved in the Server-Side Swift community.