Why Swift

These days we’re spoiled for (viable) options in programming languages to the point that in some use cases you can literally throw dices or coins to determine which one to choose. Even when you exclude languages that you don’t like for some reason or another, you still end up with a handful of choices. It becomes an exercise of balancing minor tradeoffs and personal preferences.

For the most part of my work life, I have been what you would call a polyglot in programming languages. I’ve worked on or overseen the development of systems & applications in C, Python, Erlang, JavaScript/TypeScript, Ruby, Swift, Objective-C, C++, C#, Scala, Lisp, Scheme, Java, Tcl and a few more if you count technology transitions as well^[1]. It span backend and frontend, web, mobile and desktop, and everything in between. Personal and toy projects would add another handful or two.

I don’t really have a favourite language^[2], but a few default go-to languages that continued to serve well: Python, JavaScript and Swift. All of them more or less for their obvious use-cases, although the overlap in web backends does pose a choice challenge.

That said, Swift is continuing to replace everything else where appropriate and feasible, especially when starting new projects. I make exceptions for (fewer and fewer) projects that are meant to be handed over to someone else for maintenance, in which cases I will happily choose Python or JavaScript^[3].

Why Swift?

Using Swift outside of application programming for Apple platforms may cause raised eyebrows across laypersons and experts alike. The doubts range from eye-rolling (on both sides), to lack of knowledge, to lack of evidence.

Doubt 1: It’s from Apple.

Obviously the eye-roller 🙄, because the contra side will roll their eyes for merely mentioning an Apple technology and the pro side will roll their eyes as the reaction to the contra side. Haters gonna hate. Move on.

Doubt 2: It can only be used for Apple platforms.

Now we’re approaching lack of knowledge, partial truths and lack of evidence. The team within Apple and the community have created support for other platforms. The Linux port was started fairly early on, 2015 to be precise, when Swift was open-sourced^[4]. Unfortunately even Apple’s marketing pages are outdated, since they still link to Swift@IBM, which produces a neat 404 (not found)^[5]. So where are we in terms of platform support?

Linux is officially supported since Swift v2.2 and if you look closely at the version history, you’ll see that there are even patch-versions that specifically dealt with Linux (since these versions were not released for macOS). For a time IBM played a crucial role in Swift on Servers, which was and is the driving force for Linux support, but their efforts seem to have been abandoned just like their Swift web app framework Kitura. Amazon continues to invest, allowing Swift servers to run on their Amazon Linux AMI, including a Swift AWS Lambda Runtime^[6]. Since most companies, including Apple, are pretty hush-hush when it comes to disclosing their infrastructure technology, my guess is the most widely use of Swift for Linux may even be by enthusiast on a Raspberry Pi^[7].

Windows support started as an unofficial community project (driven by Saleem Abdulrasool), has been officially supported since v5.3 and Saleem is now at The Browser Company, which uses Swift for their Windows port of Arc.^{[8] [9]} I am not aware whether Apple is jumping on it to work on their Windows software, like the iCloud client or iTunes, but they probably should. Having Windows ports of all their services clients would be strong statement indeed. It’s also worth noting that Saleem since joined the Swift Core Team.

Whether all this moves Swift on Linux or Windows from experimental to production-ready, is certainly up for debate and subject to use-case.

The Android and FreeBSD ports have been unofficial community efforts in various degrees of aliveness. The challenges for all of them, including Linux and Windows, is likely the deep integration with the legacy code at Apple, namely the Objective-C runtime. While it was designed to work without it from the start, it continues to be used on Apple platforms and will so for the foreseeable future. The Swift Core Libraries and Standard Library are reasonably cross-platform, but work still continues to improve on it.

Personally, the lack of FreeBSD support is probably the biggest blow. So it’s back to the path of least resistance^[10].

Doubt 3: Apple’s priorities for Swift are overwriting

This is a doubt that virtually every technology driven by a major player faces and probably lurking in the shadows of doubt #1 and #2 as well. The priorities in development are mostly set by one entity and might not be in line with the wider community.

Granted, this can happen, as recent license changes by major contributors to open source projects have shown, but until that happens, it’s FUD. And when it happens, there is still the chance of a fork of code base with the current license, again as evidenced by the mentioned license-changing open source projects.

At this point the goals of Apple and the wider community are probably more in line with each other than it looks on the surface. You could make the argument that it is in Apple’s best business interest to push for a wide adoptability of Swift. First of all, as seen earlier, Apple has applications on Windows and also on Android. Being able to serve these from a multi-platform Swift app would make sense. Second, Apple has a huge service infrastructure, reportedly running on Linux and written in, among others, Java. I would not be surprised if there was some service somewhere still running Objective-C from the good old WebObjects days (before that was ported to Java).

Doubt 4: It can only be used for applications.

This argument often implies that Swift may not be low-level enough to be used for “hardcore” systems programming. The problem here, admittedly, is the lack evidence to the contrary, with examples few and far between and the somewhat blurry definition of what systems programming and even low-level means.

Even when it comes to Apple, we can only make assumptions based on vague statements by Apple employees and the continued efforts of Alexandre Colucci to analyse the usage of programming languages and frameworks in iOS and macOS binaries. Alexandre’s analysis has some caveats, which he points out transparently. It’s mainly used to estimate how much Apple themselves rely on Swift for creating applications, as in whether an app shipped with the operating system is mainly written in Swift, but we can draw reasonable conclusions about other parts of the system as well^[11][12].

Also thanks to Alexandre’s work this year, we can see that Swift is starting to be adopted in restricted environments like the Secure Enclave and embedded applications with Apple releasing swift-mmio.

Apart from that the Swift team continues to release open source projects aimed at low-level interaction, like Swift System and Swift Atomics.

The multitude of community projects may or may not convince someone, but for the sake of argument, I will admit that for now there is likely less low-level code produced than for example with Rust and the ecosystem is less mature.

Whether or not you count machine learning to systems or application programming is up to you, but for completeness sake, we should mention meteoric rise and ultimate abandonment of Swift for TensorFlow.^[13] When it was announced, it looked like Swift would become a serious contender, if not the language, for machine learning. Luckily Differentiable Swift is here to stay, but maybe it’s just not yet ready for primetime, otherwise this graph for Apple’s MLX would look different^[14]:

The machine learning folks and Swift’s original creator seem to have found their Mojo somewhere else. It doesn’t mean Swift is deprecated by any means, since Modular’s goals are different^[15].

One final signal that Swift is usable way beyond creating mobile and desktop apps is one from Apple. Swift is used to improve the code base of FoundationDB, with a focus on a powerful and approachable story to C++ interoperability^[16].

The mandate within Apple seems to be to go with Swift for new code wherever feasible and work with the Swift team to enable it for currently unfeasible stuff, including a sane migration story. Commendable!

More needs to be done. If you search for books on Swift, you will notice that the majority is indeed focusing on application development for various Apple platforms. So one may be excused to question the viability of Swift beyond it. If there was, publishers would have embraced it already. It’s a chicken-and-egg problem.

Why not Rust?

Probably a few were already screaming this from the sidelines. Indeed all things considered, Rust would be an excellent choice and Swift continues be inspired by the Rust ecosystem. So why not go with the original in the first place?

The momentum of Rust is strong, with even Microsoft pushing it internally and within their development tools. It’s safe to assume that Rust will become their main language for when C# on .Net isn’t low-level enough. The Linux Kernel project welcomes Rust contributions, it pops up in infrastructure, data storage and other lower-level platform projects. If you say WASM, you likely say Rust as well and the adjacent web frontend communities are adopting Rust for all kind of tooling to the point that when you do npm install, you might already install a bunch of binaries written in Rust with a JavaScript wrapper around them.

There are plenty of circumstances where even I would choose Rust over Swift. If you create an open source project, you will likely see more contribution when adopting Rust. You will also be more likely to find developers with that neat overlap of knowing the programming language and being comfortable in some area outside app development.

The question is whether any of this is a limitation for you or not. I like Rust, but I like Swift more and I’m not subject to the limitations above. But my personal preference also has some non-technical reasoning.

Swift, the dark horse

Ever since I remember, I have had what I call a dark horse mentality, even before I learned this term. I like Wikipedia’s definition most^[17]:

A dark horse is a previously lesser-known person, team or thing that emerges to prominence in a situation, especially in a competition involving multiple rivals, that in theory is unlikely to succeed but has a fighting chance, unlike the underdog who is expected to lose.

It has served me well in technology decisions and I recommended it time and again during my stints in innovation consulting as a mentality to adopt, especially if you are the expected winner in a competitive environment. The concept deserves a deeper dive, but back to Swift.

By now, unless you’re an Apple hater, you should agree that Swift is probably a dark horse in many use cases^[18], even if you know little about it.

The nice thing about dark horse technology: if your bet plays out, you may as well end up with a competitive advantage that you otherwise would not have by choosing whatever everybody else is using. Of course, the other side of the medal is that you could end up in a one-way dead-end street. Again, tradeoffs. Arguably Apple used to be a dark horse themselves, in some cases they still are, in others I would like to see more of that mentality to return.

Somewhat connected to it is this reflexive (or knee-jerk) adoption of Rust that we can see. It’s just assumed to be the best option and it might turn out to be the best option for these use-cases. For me, it rings a few alarm bells, which makes me sceptical not of Rust, but the reasons for choosing Rust. “Because ‘everybody’ is using it” has rarely been a good reason, especially if you want to move the needle.

Choosing the dark horse by definition prevents you from becoming complacent.

It will be interesting to see the Swift team’s intentions for 2024. At the time of writing there has not been a blog post in the vein of last year’s^[19]. I guess the work on Vision Pro also did impact the Swift team at Apple and their priorities.

For me personally, it means being knee-deep in various interesting open-source Swift projects, continued adoption of Swift in my playground system and many toy projects as proof-of-concepts. Whether I get involved in the community remains to be seen, since the mere thought of any kind of community involvement anywhere triggers my anxiety disorder 🤷.

There are so many potential avenues here that it’s hard to know where to start. The only project I can promise to do in the open, is to track any kind of exciting Swift usage outside of its sweet spot of programming apps for Apple platforms and revisiting this post in a year. Stay tuned for that!