The Blog

 

Since its first public release in 2014, the Swift programming language has become wildly popular among developers for its type-safety, functional use, and expressiveness. Despite its existence as the go-to language for iOS apps, the language is increasingly being used on the server and in the cloud.

Most notably, IBM contributed to this server-side Swift ecosystem with Kitura, an enterprise-ready REST API framework that is based on Express.js. To understand where the development of Kitura is headed, and the use of Swift on the server in general, you need to understand the history of the Swift language.

Swift: A brief history

In June 2014, the Swift programming language was introduced to the world at WWDC by Craig Federighi. Swift was intended to be a memory-safe, functional, and expressive alternative to Objective-C for iOS applications. Its announcement was hailed as a major harbinger of change for the iOS ecosystem.

Then, in 2015 at WWDC, Craig announced that Swift was going to go open-source and lean on the both community and Apple employees to grow the language. In addition to this open-source announcement, Craig announced that there was a build available for Linux. As soon as IBM learned this, we opened up conversations through partnership channels with Apple, and we began working on porting most of the major Foundation libraries in Swift to Linux.

The birth of Kitura

As libraries like Dispatch and URLSession got makeovers to work on Linux just as well as on macOS, the team began using their experience in the world of Node.js to write a framework that a developer who understood Swift could use to also write a REST API. That framework is now known as Kitura, and it was released to the public on Twitter in February 2016. Patrick Bohrer and John Ponzo spoke at WWDC in 2016 to talk about getting Swift to run on the server by demonstrating a live API running with an iOS application in the same Xcode workspace.

All of this goes to show that if you know how to write code in Swift, you are no longer limited to just writing code for your mobile phones.

Kitura 2.0 and beyond

When Swift 4 was announced, the Codable protocol was announced with it. With this protocol, Swift developers can easily encode and decode native objects to and from any external representation, such as JSON or XML. With that, the Kitura team released Kitura 2.0, with a slick new feature: Codable routing.

In Kitura 1.x, you had to respond to a GET request by parsing parameters from the request, operating appropriately, and then packing all of your response materials into an object and sending it off. It isn’t difficult to do, per se, but it requires a bit of a learning curve. In Kitura 2.0, you can instead set up a GET route that simply returns a native Swift object or an array of native Swift objects, so long as they all conform to Codable. Kitura handles the rest for you! Being able to write an API without having to worry about what goes over the wire was a nice touch.

With Kitura, you can generate an OpenAPI specification from the routes you create with an API. Kitura provides you with an API explorer that you can use to easily test and develop your API further. Being able to generate an API from a specification has existed before, but with Kitura, you can go the other way and use an explorer based on the routes you’ve already written.

Kitura comes ready out of the box to build and run in Docker with the Kitura CLI. You can also deploy to a Kubernetes cluster and use other Cloud Native Foundation tools thanks to the built-in Helm charts.

What’s next

As of right now, IBM offers 24×7 commercial support for the Swift runtime on Linux, as well as frameworks running on the Swift runtime. IBM is continuing to work with a bevy of Fortune 500 companies that are preparing to use Swift on the server in some capacity, most of which involves Kitura.

As the Swift language evolves, frameworks developed for it will evolve too. The future of Kitura is as exciting as the Swift ecosystem itself, and we’re excited to see what comes next!