Apple is Killing Swift
A great language strangled by governance
Today, we’re going to learn how modern programming languages are governed. I’ll explain how Swift’s dictatorial structure is uniquely terrible, and demonstrate to you how bad the situation has become.
Subscribe to Jacob’s Tech Tavern for free to get ludicrously in-depth articles on iOS, Swift, tech, & indie projects in your inbox every week.
Full subscribers unlock Quick Hacks, my advanced tips series, and enjoy exclusive early access to my long-form articles.
Swift was a great language, but it has fallen far from its original vision.
Pretty damn far.
Today, we’re going to learn how modern programming languages are governed. I’ll explain how Swift’s dictatorial structure is uniquely terrible, and demonstrate to you how bad the situation has become.
But first; a quick history lesson on Swift.
A Brief History of Swift
Swift was the passion project of Chris Lattner, creator of LLVM and senior director of dev tooling at Apple. Across evenings and weekends in the early 2010s, he wrote the foundations of the language we know and love today.
Apple’s senior leadership team was packed to the gills with the OG NeXT crew, all on first-name terms with Jobs, who built their careers on Objective-C. It took a lot of internal politicking to get the green-light for Swift.
In classic Apple secrecy, prior to the WWDC 2014 announcement, only 250 internal employees even knew about the project that would eventually make their codebases obsolete.
Lattner’s vision?
Simple things that compose.
Progressive disclosure.
One way to do things.
Next year, in 2015, Lattner achieved the unthinkable: convincing the world’s second-most secretive company to open-source Swift.
The open-sourced Swift language evolved over the years; driven by 3 tribes who kept each other in check:
Lattner himself, driving his core vision and keeping a lid on tech debt.
The open-source community, who fundamentally want what’s best for the language, but in aggregate behave like a trash bag full of cats.
Apple, the behemoth that pays the Swift team’s salaries, which has an unwavering commitment to profit.
In 2017, Chris buggered off to mess around with AI. Tim Cook’s MBA buddies began to wriggle their tendrils into Swift and guide it towards its next life stage.
“Swift has turned into a gigantic, super complicated bag of special cases, special syntax, special stuff…”
In 2024, we are stuck with the aforementioned 217 keywords. They are neither simple nor do they compose.
Without Lattner’s steady hand, Swift has sat uncomfortably at a pinch-point between two opposing clans: the open-source community™, and Apple Inc.
Both have their own incentives and their own imperfections, but you might guess who holds all the influence.
“Apple Inc. is the project lead and serves as the arbiter for the project. The project lead makes senior appointments to leadership.”
How to Govern a Programming Language
Every programming language is developed and maintained by somebody. This might be an individual, a team at a company, or a large distributed community.
Languages all have their own rules about how changes, features, & extensions are selected, designed, & implemented. This is critical for a sense of stability, continuity, improvement, & backwards-compatibility. For any language used by millions of developers, they need to have confidence in their livelihood.
Let’s take a look at the governance models used by the most popular and successful languages around.
Python: Benevolent Dictator For Life
Python was created by Guido van Rossum in 1990 (and named after Monty Python). Guido was the BDFL (benevolent dictator for life), a title which is rad as hell (and basically a euphemism for “lead maintainer”). Ultimately, the fiery debate over assignment expressions led to Guido’s abdication in 2018.
Today, Python is governed by a steering council of 5 engineers, who are elected annually by the hundred-ish open-source maintainers. Changes to Python are proposed via PEPs, on which the open-source community deliberates. Steerco gets the final say.
“Python development is generally evolutionary. Python makes slow and careful steps towards new features and versions. The current steering council, while being open to all sorts of language improvement ideas also has generally a very strong focus on preserving backwards compatibility.”
Rust: Community-driven open-source
Rust was initially a personal project by Graydon Hoare, which was adopted by Mozilla, his employer, and eventually became supported by the Rust Foundation — a non-profit formed by AWS, Huawei, Google, Microsoft, and Mozilla.
Changes to the Rust language are welcomed from their open-source community and discussed via an RFC process, with steering from Foundation teams such as language, compiler, and dev tools.
While this might sound utopian, the Rust community, like all open-source communities, is not without its drama.
Each major decision in Rust starts as a Request for Comments (RFC). Everyone is invited to discuss the proposal, to work toward a shared understanding of the tradeoffs. Though sometimes arduous, this community deliberation is Rust’s secret sauce for quality.
Kotlin: Corporate-backed open-source
Kotlin was created by JetBrains, the IDE company, in 2011, who hoped to sell more copies of IntelliJ and cross-sell other dev tools. In a huge coup, Google announced Kotlin support for Android in 2017.
Kotlin is governed by the Kotlin Foundation, co-created by Google and JetBrains. The foundation’s board of directors appoints the lead language designer, who is basically a high-ranking JetBrains engineer. Community members may submit a KEEP for discussion by the community, and developers may test out experimental APIs before they are finalised.
“Language design is cast in stone,
but this stone is reasonably soft,
and with some effort we can reshape it later.”
All these languages have an open-source community which proposes and discusses changes. They also have a more centralised faction which maintain and extend the language itself, and have the final say on evolution.
Incentives
Fundamentally, programming language governance is all about aligning incentives. Every programming language has 3 main constituencies:
The end-user developers who use the language day-to-day.
The community submitting (and implementing) language proposals.
The steering group with the final say.
The end-user developers just want to work with a nice language. The language is their incentive, and they vote with their keyboards. This cohort numbers in the millions, however they actually have the least amount of influence due to extremely high language switching costs: most won’t throw away their years of experience.
The community is formed of the most passionate end-user developers, alongside a collection of full-time teams directed by the steering group. This faction generally has the purest incentives; wanting to improve their favoured language. However, they are subject to a couple of other opposing forces:
Résumé-driven-development spurs engineers to take part in discussions simply to bolster their personal employability. Furthermore, hard work is hard work.
Bikeshedding is a common driver of behaviour: instead of focusing on the technical design of a proposal, it’s easy to take the path of least resistance and focus energy on trivia like syntax and naming.
Swift’s evolution forums are notorious for pages upon pages of syntactic bikeshedding.
The steering group with decision-making authority is easily the most powerful constituency, and can have drastically different incentives based on governance structure.
In some instances, such as with Python or Rust, the steering group is formed of the most influential community members, aligning their imperfect set of incentives towards something resembling “what’s best for the language”.
In other cases, such as with Kotlin, the businesses that run the language have a profit motive: selling IDEs (JetBrains) and increasing the numbers and productivity of Android developers (Google).
Fortunately, these governance incentives align nicely with the incentives of the other constituencies: creating a good language will help towards these aims.
Swift: Corporate Dictator for Life
Apple and Swift creates the worst of all worlds.
Apple is unambiguously the dictator of Swift. They pay the salaries for most of the core team, and have the power to arbitrarily appoint project leadership team members.
Apple has the purest incentive of all: maximise profit for shareholders.
There’s an extent to which this profit motive aligns them with the weak cohort of millions of iOS developers. A better language means more iOS engineers, which means more apps, which means more store revenue & device sales.
But this incentive puts them dangerously at odds with the open-source community that drives the language forwards. To a lesser extent, it puts them at odds with the Swift core team itself.
Swift 5.1 is the canonical example of Apple not giving a sh*t about the community. It introduced opaque result types with some, implicit returns, and property wrappers. It even implemented function builders in the compiler without any evolution process whatsoever!
These features together form the syntactic backbone of SwiftUI, the shiny new UI framework of the future™. Apple’s own internal timelines dictated the unilateral approval (or lack thereof) for these features, instead of giving the community a fair say.
As a result, SwiftUI looks a bit nicer than it would if we returned the View explicitly. SwiftUI is cleaner without needing to append child views onto a parent result. But these features also injected complexity and compiler magic into the whole language.
On a personal level, the Swift Concurrency Manifesto was written in 2017. But getting a hip new UI framework over the line in 2019 was, however, a much higher priority when allocating the Swift team resources*, delaying Swift Concurrency for years until 2021.
Lattner’s Legacy
Let’s re-visit Chris Lattner’s design philosophy and compare it to modern-day Swift:
Simple things that compose. (Complicated features that don’t compose)
Progressive disclosure. (Swift has 217 keywords)
One way to do things. (Result builders and macros?!)
Despite leaving Apple in 2017, Lattner remained on the Swift core team until 2021. The explanation for his departureforecasted a pessimistic outlook for Swift:
…after several discussions generating more heat than light, when my formal proposal review comments and concerns were ignored by the unilateral accepts, and the general challenges with transparency working with core team, I decided I was just wasting my time.
…several community members feel they don’t understand the real motivation for the proposal, aren’t being listened to.
Many pressures (including lofty goals, fixed schedules, deep bug queues to clear, internal folks that want to review/design things before the public has access to them, and pressures outside their team) induce odd interactions with the community.
By the time things get out to us, the plans are already very far along and sometimes the individuals are attached to the designs they’ve put a lot of energy into. This leads to a challenging dynamic for everyone involved.
This first-hand account, bleakly, aligns exactly with what we should expect from Swift’s lopsided governance structure.
Apple pays lip-service to their open-source community, ostensibly seeking their input on proposals, however they also habitually push through their own proposals — they have frameworks to ship.
Strategic priorities such as proprietary UI frameworks and cross-platform functionality which strengthens their walled garden will forever take priority. Who cares if we annoy some whinging nerds?
Tech Debt & Compilers
Chris Lattner has, on podcast appearances, spoken several times about the backlog of technical debt in the compiler. This was inevitable early on, while his tiny team successfully kept millions of devs happy as he migrated their entire development environment from Objective-C, and from Swift 2 to 3.
These days, away from the light of his influence, the compiler now has extremely silly tech debt from which it may never recover.
Modern Swift is a slave to the top-down whims of the Apple MBA cabal: who prize secrecy and sneer at community input. Unshackled from Lattner’s influence, or even the relentless drive to craftsmanship imposed from Jobs, it’s all about shipping the latest proprietary profit driver.
Apple: Bastards?
Apple isn’t behaving unreasonably with Swift given their incentive structure. We can steel-man the current situation:
It’s hard to argue that SwiftUI is pretty damn good.
From a business point of view, by 2019, it was mandatory to release a declarative UI framework to compete with the rapidly-growing cross-platform competitors React Native and Flutter.
Unifying the platforms (iOS, MacOS, watchOS, TVOS, and now VisionOS) was also a major strategic directive which strengthened the ecosystem across all Apple hardware.
Craig Federighi is not a moron — making the language more complicated was a trade-off they considered. As always, business benefits take precedence over the geeky luddites complaining about type-checking exceptions in the compiler.
Is there Hope for Swift?
Apple and the wider open-source community noticed when Chris made the dramatic step of cutting ties. While it wasn’t the only factor, it helped catalyse a shift towards a less dictatorial, more transparent, model of governance.
Swift is borrowing ideas from the Rust model — specialised steering groups and workgroups, including team members from outside Apple.
It’s a little funny that they need an entire steering group for “Contributor Experience”. Lattner really called them out where they were weakest.
The emphasis on using Swift outside Apple’s walled garden gives a glimmer of hope that Apple’s governance can start to see the forest of a great programming language through the trees of proprietary frameworks. A platforms steering group now exists to get Swift on Windows and Arduino.
Apple dogfoods Swift internally on some its own backend systems, handling millions of requests per second. While this isn’t entirely altruistic, an investment in a Swift On The Server workgroup is pretty great.
Finally, Apple is putting work into re-writing Foundation as an open-source Swift package that ports equally well to all platforms. Many new libraries such as AsyncAlgorithms are also shipped as packages rather than tied to an OS like the standard library.
Swift has strayed far from the original vision of simple things that compose; but the language may yet achieve its goal of making the world’s best general purpose programming language.
I really hope it does.
I agree with the sentiment. Swift was conceived and promoted as being simple, but it rapidly became a "Christmas tree" where everyone wants to hang something new on it.
While this might be ok for people who spend every waking moment using Swift, the constant changes and evolution make it very difficult for new people to use or part time users to keep up.
The worst thing of all is the language is no longer intuitive and the syntax resembles hieroglyphics.
Great Post