Modern programming is complex. In one of my most recent mobile apps, BG Snapshot, I utilize shell scripts for low level file system tasks, Python for data munging and machine learning (ML), C++ for approximate nearest neighbors search, and Swift for building the final iOS App. The process and its organization feel clunky, messy, and my brain doesn’t appreciate the constant context switching. Wouldn’t it be nice to write complex apps and workflows end-to-end in Swift? Today I would like to talk briefly about Swift’s current ecosystem, some of the libraries and areas of support that I think are missing, and what Swift needs to become a contender as ‘the one language to rule them all’.
Preface
We, as programmers, are an eclectic bunch. Each of us looks at the field of programming through a unique lens that is shaped by our training, work experience, and areas of expertise. I come from the field of medical informatics and machine learning. I love working in scripting languages like Python and R. My favorite workflow at the moment is a text editor paired with a read-evaluate-print-loop (REPL) on the command line. I often finding myself using Python and it’s robust ecosystem as a model for comparison when I think about what I want from get-stuff-done language. Keep that in mind as I share my vision and wish list for the Swift ecosystem. It may not match your own…and that’s okay:)
The Swift Ecosystem In 2022
The Swift ecosystem as I see it is composed of Swift the language, standard and core libraries (mostly from Apple at this point), proprietary libraries (also Apple, but others as well), open-source packages, and the on-line community. There are a lot of important building blocks we have at our disposal in 2022, so let’s recap.
As of this writing Swift is in version 5.6. I’m not going to waste your time listing all of the powerful features (generics, protocols, optionals, etc.) that you have come to know and love, but let me just say one or two things. Swift’s standard library and Foundation provide a lot functionality right out-of-the box. In fact, with the recent addition of async await which addresses concurrency at the language level, I am struggling to come up with a list of major features Swift still lacks. And that’s a good thing.
In terms of cross-platform capabilities we have core language support for the three major desktop platforms: MacOS, Linux, and Windows. Of course excellent support is also provided for the rest of Apple’s fleet, which includes pads, mobile devices, watches, and TVs. Technically, you can compile and run the standard library on Android, but as I’ll discuss later, there is zero library support, so you can’t really do much at this point. But did you know that Swift has sneaked its way onto a few other platforms as well? A project called SwiftWasm allows you to compile Swift code into web assembly and run it directly in your browser. Their website includes a playground that has a graphic user interface with an API identical to SwiftUI. Check it out! For folks that like to tinker in the internet of things/microcontroller space you can run a paired down version of Swift on Arduino. While not as portable as C or Java, Swift has quickly become accessible on a wide range of platforms.
Let’s end our recap of the Swift ecosystem in 2022 with some brief highlights on libraries and package management. Open-source libraries and frameworks are the life blood of a language. They allow us to operate at high levels of abstraction, devote more resources towards solving new problems, and rapidly develop and deploy final products. The Swift Package Manager (SPM) provides a central piece of technology that promotes development of this lifeblood. It’s integrated into the build system, the expected project organization is straightforward, and the package manifest is also written and digested in Swift ,which is brilliant. Say a fond farewell to pods and cartfiles. We are one step closer to end-to-end development in Swift.
What we are missing
For a language to become ubiquitous across platforms and working domains I think we need three things:
True multi-platform support that includes tools for building out UI.
A robust catalog of open-source packages with user-friendly API’s and thorough documentation
A vibrant community of developers to provide education (via books, tutorials, blogposts, etc.), troubleshooting (via things like StackOverflow), and inspiration for devs in other languages to adopt Swift.
1. True multi-platform support
First, lets address the big elephant in the room. Apple. Swift, though open source, is developed first and for-most for Darwin devices. The fact that we can run Swift code in other places is fantastic, but what incentive is there for Apple to provide support on Android, Windows, and other non-Darwin platforms? Apple makes money on the hardware and services they sell, and I expect the company to serve its own bottom line. That being said, Apple is clearly open to the idea of running Swift on other platforms…we do have Unix and Windows builds after all. The Swift community just has to accept that a large portion of cross-platform support will have to come from its user-base and members.
There are additional challenges in the core libraries and Foundation that must also be addressed. Swift was built from the ground up to be interoperable with Objective-C. This was done intentionally so that both Apple and third-party developers (us) could continue to utilize codebases and projects written in Objective-C while we adopt Swift. I won’t pretend I understand all of the details, but this is also the source of a lot of cross-platform pain. The Objective-C runtime and Foundation libraries are only available on Apple platforms. Swift on all other platforms use different core C libraries (Darwin for Apple, Glibc for Unix, WinSDK for Windows?) and have a separate version of Foundation, whose API matches that of Apples Foundation. At a very low level, there is, to say the least, a bit of a mess. The implementation of Foundation for non-Apple platforms is incomplete, though to be fair there are a lot of key components that appear well covered (runtime entities, primitive data types, collections, etc.). My hope is people smarter than me will iron out the kinks, so the rest of us can write solid cross-platform tools. If I have to memorize platform differences in Foundation or write a mess of compiler directives it will be a deal-breaker.
Another important piece of infrastructure cross-platform Swift is missing is a suite of tools for developing user interfaces. Remember how I mentioned you can write SwiftUI code that’s compiled to web assembly and run it in your browser? That’s exactly the sort of thing we need for a platform agnostic UI framework in Swift. It makes me think about development kits like GTK and Qt. Something new and homegrown would be ideal, but Swift bindings for GTK would at least get us up and running.
2. A robust catalog of open-source packages with user-friendly API’s and thorough documentation
It’s fair to say that the vast majority of public packages available in Swift are geared towards development on Apple devices. As such, most of them are useless elsewhere, and that’s a big problem. For Swift to gain traction on other platforms we will need a robust infrastructure of cross-platform packages as well as an efficient system for package discovery.
Some of these building blocks are in the works. There is an early stage project called the Swift Package Index, that acts as a search engine for Swift packages. The index currently has metadata for more than 4,800 packages and includes useful information about project status, requirements, and compatibility. The Swift Package Index even offers hosting for DocC compatible documentation, which is really cool. I’d love to see the project grow to include a restful API and command line tools to make installing and adding packages to projects easier. Fingers crossed.
Developing a robust ecosystem of cross-platform packages in Swift will take time. Since we don’t have a GUI framework and won’t likely get one any time soon, I think focusing on scripting, command line libraries, and lower level utilities will help push growth in other areas. Scripting in Swift is something I have been exploring a bit, and there are a few key areas that need some work. In Python I can easily import packages and call functionality contained in multiple files. Neither of these things is trivial with Swift scripting. The easiest way to import libraries other than Foundation is to use the SPM, but then, you aren’t really writing a script anymore…now you are creating a tiny package with an executable. The swift-sh package may provide a solution, but I have yet to add it to my workflow. The second problem, calling code from multiple files, also has an ugly solution. You can concatenate mutliple Swift files ahead of time using the cat command and pipe the result into a call to swift. But again, this feels like a workaround and not a long-term solution. Fast and efficient scripting in Swift could be a real game changer, but I’m sticking with Python for now.
Command line applications are more of niche area, but I am guessing some of you are power users like me and feel very at home on a command prompt. The ArgumentParser package has been a welcome addition and there are a sprinkling of other packages that assist with application development, adding formatting and colors, etc., but I think we could use more. What about a version of Playgrounds that you could spin up from the command line? I think we need something for non-Apple platforms. Swift does have a REPL that includes debugger support through it’s use of LLDB, but I’d like to see something more like iPython. If you are not familiar, iPython is a REPL for Python that includes syntax highlighting, code completion with fancy menus, magic commands for looking at input history, and a ton of other neat stuff. It’s an amazing tool. I exclusively work in iPython for machine learning and data munging tasks and would love to see a comparable tool for Swift!
Lower level utility packages that sit just above or alongside things like Foundation can spawn entirely new domains for the adoption of Swift. We have already seen one example of this in the web serving space. Vapor and Kitura have opened up a whole new world where Swift is being used to serve webpages, restful APIs, and more. There are actually a number of other ongoing projects at Apple that I would include in this space…they just aren’t very well advertised. A few that were notable to me after browsing GitHub include: Collections, System, Algorithms, Atomics, and DistributedActors.
Personally, I would like to see Swift become a useful language for data scienctists. I’m not completely alone. Chris Latter, while at Google, started working on a project to bring Swift to Tensorflow. In spite of the fact that the program was shut down in 2021 I still have hope. The Numerics package is still being worked on and there has been progress on automatic differentiation for the language. Being able to get meaningful data science work done in Swift would provide additional benefits to programmers as well. CreateML, Apples tool for helping developers create ML models, only provides cookie cutter solutions. In it’s current form, if Apple doesn’t have the model you need you have to flip to python, train the model yourself, then convert it to Apple’s model format when you are done. Running the entire pipeline in Swift would be a real plus.
3. A vibrant community of developers to provide education, troubleshooting , and inspiration for devs in other languages to adopt Swift.
The last area of discussion, the development community, reminds me a lot of the old chicken-and-egg problem. You know, which came first? In this case, the problem goes like this. How can we have a strong developer community on the non-Apple platforms if developers don’t have the infrastructure they need to adopt the language in the first place? And how can developers that are working on developing that infrastructure get help if they can’t get answers from the community? Perhaps it’s a silly analogy, but I think we need explorers and pioneers. People willing to get out there on their own, struggle through challenges that have yet to be answered on Stack Overlflow, and contribute their time and code for betterment of the community.
Conclusions
In the subtitle of this post I posed a question. “Will Swift become the one language to rule them all?” Sorry, that was indeed a bit of click-bate. I think Swift does have potential as a general purpose, do everything sort of language, but we are not there yet. We need some of those key building blocks that I mentioned in this article. A framework for building GUIs, better scripting support, a playgrounds equivalent on non-Apple platforms, and additional low-level cross-platform tools that can act as scaffolding for higher levels of abstraction. I hope we get there some day. I’d love to tidy up my projects and make some of them 100% Swift.
If you have enjoyed reading this story don’t forget to mash that clap button and follow me to receive updates when I write something new.