The Past, Present and Future of Swift

This article was peer reviewed by Adrian Sandu and Marc Towler. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!

I’m excited about Swift for reasons I will expand upon later, but it’s mostly the enthusiasm it has attracted. In less than six months, here are the project’s GitHub stats.

I know GitHub stats aren’t always indicative of anything, but still, these numbers are impressive.

Last week I presented a talk at the fantastic MDevCon in Amsterdam on the past, present and future of Swift. Despite some technical issues, it was well received and seemed like a good topic to turn into an article, so here it is!

I will begin by traveling back 30 years to the 1980s.

The past – Objective-C, the Legacy of Swift

Brad Cox and Tom Love were the original creators of Objective-C in the early 1980s. They wanted to add object-orientated programming concepts to C and were inspired by a popular language at the time, Smalltalk.

In 1988, NeXT decided to license Objective-C for building their advanced Operating System, NeXTSTEP.

NeXT wasn’t that successful, but their software tools were popular enough and their legacy remains in the form of their founder, Steve Jobs, and a certain other company he founded.

In 1997 Apple acquired NeXT and as part of the agreement, Steve Jobs returned as CEO, kickstarting a second life for the (then) struggling company with products such as the iMac, iPod, and of course, the iPhone.

In 2001, Apple released the first version of Mac OS X, a vast departure from the Mac OS versions that came before it. At the time, I was working in Mac support (ahh, the heady days of OS 7-9) and trust me, OS X was scary.

NeXTSTEP remnants are everywhere in OS X and the offical development language was Objective-C. Some common libraries we still use, such as Cocoa, App Kit and Foundation Kit are all from NeXTSTEP, making them 30 years old.

When iOS emerged in 2007 (Then iPhone OS) it also used Objective-C and shared some of the same libraries with OS X.

Fast forward to WWDC in 2014 and Apple announcing that after over 30 years it was time for Objective-C to be slowly retired and replaced with a new, more modern and appropriate language. That of course was Swift.

To this long term Apple user, Swift represents one of the first times that Apple listened to what people asked for, thus delivering something with far more traction than some of their other tools. Open sourcing and creating other platform versions of the language was another un-Apple step along this path. This coupled with an active community is where I think Swift’s strength lies.

The Present – What’s Possible with Swift

Linux support has been available since day 1 of the Open Sourcing of Swift, and based on my experiments, it works well.

There are no distribution packages yet, but installation is easy:

wget https://swift.org/builds/swift-2.2-branch/ubuntu1404/xxx.tar.gz
tar -xvf xxx.tar.gz
sudo apt-get install clang
export PATH=/home/vagrant/xxx/usr/bin:"${PATH}"

Replacing values with the appropriate file names and paths. Swift is constantly evolving, and so are versions and file names.

Compile and run any Swift file, for example:

swiftc helloworld.swift
./helloworld

The Linux compiler provides support for most relevant functionality (remember, this is a server, not a mobile device) and seems performant and stable so far.

Taking Server-side Swift further, two frameworks have already emerged. Perfect (already covered on SitePoint) provides simple server/client side exchange, whilst Vapor is a Rails / Laravel inspired MVC framework for Swift web applications.

Several tools have emerged to better support cross-platform Swift, these include:

• swiftenv: A Swift environment manager, like pyenv.
• swifter: A basic HTTP server written in Swift.

iOS vs Swift

It’s important to note that Swift does not equal iOS. Swift includes:

• Compiler
• Standard Library
• SDK Overlays
• Debugger

It doesn’t (and never will) include any iOS specific libraries. Firstly because they are proprietary intellectual property, but secondly because they are not relevant to a cross-platform language. iOS libraries are mostly relevant to iOS devices, and whilst I am an open source supporter, I can see why they may not be worth open-sourcing.

Swift is strongly supported by Apple, but is an external foundation and community. The swift.org website contains information, mailing lists and community guidelines for those of you interested in knowing more.

The Future

Version 3 and Beyond

The future aims of Swift focus around stability and cross-platform consistency, for version 3, this includes:

• Core library improvements
• Goodbye NS name space, an Objective-C legacy that will finally disappear.
• Improvements to the Application Binary Interface (ABI), that is the interface between libraries and host OS.
• Resilience & Portability
• Consistency and consolidation of code and standards.

And at some point in the future:

• Test modules, so developers can drop test folders into Swift projects.
• C++ Interoperability, allowing for the use of legacy and native code.
• Swift currently relies on OS level libraries for concurrent processing and needs it’s own native concurrency.

Plans and proposals for Swift features are all public, so for more details on these issues and others that may emerge, visit the Swift Evolution repository.

Windows and Android

The big question is what other platforms will Swift support? I found myself thinking that as Android has a Linux core, then it wouldn’t be too hard to run Swift applications?

The first question is a business one. What do Google, Microsoft and Apple have to gain by making Swift applications run natively on Android and Windows? I feel that Windows is more likely, as Microsoft has been surprisingly open to ideas recently.

If you’re happy to ignore the ‘native’ aspect for now, then there are options available for writing Swift once that will run on Mac OS X, Windows, iOS and Android. These are Fire / Silver from Elements Compiler, and CLion from JetBrains that supports Swift (with a plugin) and C++ / C code. These IDEs compile code to the target platform’s native language, which is never the most efficient strategy, but it’s an option that works and I have tested.

If you want to take a different approach, then Swift’s C/C++ underpinnings can help. If your platform has a C compiler (including Android NDK), then in theory it’s possible to brute force a Swift project into compiling on any platform. I came across this promising blog post that covered running Swift on Android and seemed reasonable, but the process stopped working for me about half way through. This was due to the evolving nature of NDK and Swift, but the steps follow roughly this process:

1. Compile an object file from the Swift code.
2. Link the object with the appropriate processor architecture and library definitions.
3. Create machine code from step 2.
4. Package the resulting file into an Android app, using shared libraries, NDK and C code.
5. Profit?

The same applies compiling Swift code for Windows, but the only post I could find that covered even the possibility of this was a Stack Overflow comment that says because you can run Objective-C on Windows, Swift could be possible.

All this is firmly inside Why Bother? territory, but as developers we often like to experiment and push boundaries just to see if it’s possible. Wether Windows and Android are ever ‘officially’ supported remains to be seen, but in the meantime, go crazy and see what you can get to work.

Conclusion

I hope you enjoyed this trip and stumble down memory lane to survey the current Swift landscape and look to the stormy horizon. After discussing a few edge-case topics, this is a good time to recap why I think Swift is awesome and why you should try it. Swift has an interested backer with deep pockets and an enthusiastic, responsive community. Swift is developer friendly, with modern paradigms and considerations and is partially cross-platform.

If you’re a Linux or Mac user, developing for iOS or not, visit swift.org to get started.