How to Code With Swift on the Server

Final product image
What You’ll Be Creating

Since Apple first introduced Swift as the successor to Objective-C, it has revolutionized how the community codes iOS, macOS, watchOS and tvOS apps. When Swift became an open-source platform, it opened new possibilities for the language beyond mobile and client-side apps—Swift became a server language too! In this tutorial, you’ll learn what server-side Swift is and why you would want to have Swift on your back-end. 

The server-side Swift initiative is being pushed by three prominent projects—Vapor by Qutheory, IBM’s Kitura, and Perfect—with the goal of letting Swift developers create fully fledged back-end services. This, in essence, will transform such developers into full-stack developers, negating the need for reliance on Node or PHP or giving control to a BaaS platform such as Google’s Firebase. 

Objectives of This Article 

In this article, you will learn all about server-side Swift. First I’ll explain how server-side Swift works, and then I’ll show you how to get started with the Kitura, Vapor, and Perfect frameworks.

What Is Server-Side Swift?

Swift was first announced by Apple in 2014 and quickly became one of the fastest-growing programming languages. Swift draws from many of the best contemporary languages, such as Python, allowing elegance and ease of use. It frees engineers from the technical shackles of Objective-C, allowing more fluid and intuitive work. 

In December 2015, Apple made another monumental announcement and made the Swift language—along with its supporting libraries, debugger, and package manager—an open-source project under the Apache 2.0 license, opening up the platform for the public to create pull requests and contribute. The shift away from Objective-C has not only enticed the many Objective-C developers contributing to the App Store, but it has made it easier for developers of all skills and backgrounds to enter the Apple ecosystem with Swift. 

However, while Apple’s development tools have historically made it easier for developers to create visually compelling and engaging apps for the App Store, one notable bottleneck has been that projects still needed specialized back-end developers to create complex data-driven applications. So iOS and macOS developers would either need to engage the assistance of a Python, PHP or Node developer to create their back-end database or pick up the skill themselves, resulting in a significantly heavier workload to complete their project objectives. 

Although back-end-as-a-service (BaaS) has come to the rescue of iOS developers, with no-code back-end solutions such as Google’s Firebase and Apple’s very own CloudKit which alleviate the complexities of the back-end, many teams and projects demand more. This is where server-side Swift comes in, allowing you to create a fully fledged multi-threaded back-end server that is open-sourced and infinitely configurable. 

Server-side Swift lets you choose how you host your back-end server, whether with AWS, RackSpace, or your own physical servers. You can also choose how to load balance your servers (e.g. via popular server solutions such as NGINX) and how to persist your data in a database (be it NoSQL solutions such as MongoDB, or traditional databases such as Postgres, MySQL, or Oracle). Not only that, but you are never tied to one component solution—you can switch up without affecting your entire app codebase. 

The point is that by opting for an open-source server-side Swift solution such as Vapor by Qutheory, IBM’s Kitura, or Perfect, you take advantage of a vast array of plugins that allow you to configure your back end just the way you want it, making use of your existing team’s skill set in Swift to do so. 

Server-side Swift certainly sounds compelling, but which framework is right for you? Next we take a look at each one in turn, starting with Kitura.

Getting Started With Kitura


Starting with Kitura, you have a platform that was initially released in February 2016 and gained prominence later that year at Apple’s WWDC, representing IBM’s foray into supporting server-side web with Swift, which was then set to transition from Apple’s hands to open source. 

Generally speaking, Kitura is focused on convention over configuration: it builds your initial project out with stubs, before you opt for the specific frameworks and libraries you are looking to build. Kitura’s authentication mechanism is supported by its very own Kitura-Credentials middleware framework, allowing you to choose from a smorgasbord of authentication mechanisms, from the traditional username/password to social-media login and federated authentication, using OpenID which handles JSON Web Tokens (JWT).

Kitura’s database ORM solution is powered by Kuery to obfuscate the complexities of dealing with SQL directly, supporting common relational databases such as MySQL, SQLite and PostgreSQL natively, as well as other database solutions, including NoSQL databases, through the various other compatible plugins. 

Kitura also provides other useful plugins for things such as HTML templating, using popular plugins such as Stencil and Markdown. Coming from IBM, the server-side framework also benefits from intimate connectivity with IBM Watson APIs as well as providing native macOS support for integrating directly into their Bluemix cloud platform. This provides an additional option at your disposal, along with your other traditional deployment options across Linux/Unix and macOS servers. 

While the platform certainly does provide a unique set of features—from Kuery to the ability to integrate with the various IBM API libraries—it doesn’t have the community clout that Vapor has. Adopting Kitura requires appreciating and embracing its own non-conventional ways of doing things, from how Kuery operates to its authentication mechanisms. However, given that it is backed by a large company with a focus on the enterprise, there are some future-proofing assurances built in. 

Kitura documentation page

Installing and Running Kitura

The quickest way to get started is by using Kitura’s command-line interface (CLI), supported on both macOS and Linux. Using the popular package management utility Homebrew, install Kitura and Kitura CLI by entering the following:

Within an empty folder that you will use as your project, run the following to initialize your project:

When it’s done generating your skeleton application, you will notice a new project called HelloKitura.xcodeproject. You can learn more about project generation by referring to Kitura’s official documentation. You can open the newly generated project in Xcode and edit the primary application class, Application.swift, to handle all calls to your server’s root http://localhost:8080/ URL:

The code snippet above responds by returning the classic Hello, World!. Before you can finally run the project, change your Xcode scheme to point to HelloKitura (your active project), and kick off your project by pressing CommandR. While your server is running, in a browser of your choice, go to http://localhost:8080 and you should see the hello world text in your browser. 

Further Information

Check out the following links for more information about Kitura.

  • Kitura packages/plug-ins
  • Kitura Help

Getting Started With Vapor


Released a few months later than Kitura, in September 2016, Vapor by Qutheory is widely considered the most popular in terms of community size and number of plugins. It’s built on top of Apple’s Swift-nio framework, making it a true performance powerhouse. Unlike Kitura and other platforms, which aren’t built purely in Swift but rather on Node.js or other intermediary parsers, Vapor decouples itself from any of those dependencies to deliver a Swift parser and provide clear and readable APIs.

Vapor documentation page

Vapor provides comprehensive support of databases for SQL vendors such as MySQL and PostgreSQL, as well as NoSQL vendors such as Redis and MongoDB, like Kitura. Whereas Kitura has its own Kuery ORM solution, Vapor leverages Fluent ORM to support the databases I just mentioned, making it relatively easy to extend the ORM to other third-party database providers. Vapor separates itself from the other frameworks in natively supporting Apple’s Push Notification Service, as well as supporting SMTP for pushing email notifications. 

Whereas Kitura implements its own authentication framework, Vapor has Stormpath’s Turnstile authentication library baked in natively. Like Kitura, the platform also supports the Mustache and Markdown templates, as well as its own Swift-native expressive templating language, Leaf. Vapor also comes with its own CLI engine like the other server-side Swift frameworks, with the ability to extend the application command-line arguments with custom flags. 

Installing and Running

To get started with Vapor, you start by installing the Vapor toolbox, which consists of all the library dependencies and the CLI toolkit. Install it with Homebrew by entering the following in the terminal:

When installation has completed, you can confirm Vapor has installed successfully by typing vapor —help. To create a project, type in the following, substituting with your own project name:

The Vapor engine will build a folder structure resembling the following:

To actually create an Xcode project, you will also need to explicitly enter the following command, from within the project folder: 

Finally, to build and run your project, from Xcode select the Run scheme as well as the deployment target device of My Mac, and then press the Run button as you would do for any other Xcode project. Provided your Xcode project doesn’t encounter any errors, you should see the following confirmation message in the terminal:

Go ahead and enter that URL in your browser of choice, and you should see your application running. 

Further Information

Check out the following links for more information.

  • official Vapor documentation
  • Vapor GitHub repository

Getting Started With Perfect


Finally, we take a look at Perfect by PerfectlySoft, a feature-rich server-side platform like Vapor and Kitura. Perfect includes the same standard bells and whistles you would find on the previous vendors, from templating with Mustache or Markdown to networking with web sockets, as well as Apple Push Notification and SMTP.

Perfect documentation page

Like the other server-side platforms, Perfect has its own ORM implementation, the StORM platform (Perfect StORM), which provides native support for MySQL, PostgreSQL and other prominent relational databases, as well as MongoDB, Redis, and other NoSQL solutions. One notable omission from Perfect is a CLI, but the framework makes up for this with a native macOS app.

Like Vapor, Perfect also has Turnstile baked in to power its authentication mechanism, extended to interact with StORM more intimately. Another distinction that this solution has over the others is in many of the native utility libraries it supports, including their very own cURL wrapper as well as tools for working with files and folders. Perfect’s developer base is the second largest, almost on par with Vapor’s, meaning you have a strong community to back this platform, along with a rich set of educational resources to give you confidence if you choose it.

Installing and Running

Getting up and running with Perfect is really straightforward. First, clone the PerfectlySoft repo, by entering the following:

From within the cloned folder, build the project:

Finally, run the project, which will run a local server on address

You can also run your project on Xcode by first generating a new project, as follows:

Within Xcode, ensure your executable target is pointed at My Mac, before building and running the project.

Further Information 

Check out the following links for more information about the Perfect framework.

  • official Perfect documentation
  • StORM documentation


The release of Swift to the open-source community has instigated a push for Swift solutions beyond client apps, with back-end server frameworks becoming the next frontier. Pushed by three prominent projects—Vapor by Qutheory, IBM’s Kitura, and Perfect—server-side Swift has enabled iOS (and macOS) engineers to become full-stack developers. This can negate the dependence on Node.js, PHP or .NET back-end engineers. Server-side Swift also gives teams the ability to control their back-end without having to rely on mobile back-end-as-a-service solutions like Firebase or CloudKit.

Server-side Swift isn’t for everyone: you have to decide on how much control you need for your back-end, and whether it does make sense for you to roll your own. Also, I didn’t try to tell you which server-side Swift solution is best. Developers are certainly spoiled for choice, and all three provide a unique and mature take and are worth experimenting with. I would encourage you to play around with each of the sample codes, evaluate the syntax, and engage with their respective communities to see which solution fits you best.

Powered by WPeMatico

Leave a Comment

Scroll to Top