Apple is Killing Swift
Swift was a great language, but it has fallen far from its original vision. Pretty damn far. First; a quick history lesson. Swift was the evenings-and-weekends passion project of Chris Lattner, creator of LLVM and senior director of dev tooling at Apple. Senior leadership team was jammed to the gills with the OG NeXT crew, on first-name terms with Jobs, who built their careers on Objective-C. It took a lot of internal politicking to get Swift the green-light. In classic Apple secrecy, prior to the WWDC 2014 announcement, only 250 internal employees even knew about the project that would eventually obsolete millions of codebases.
Prior to the announcement, Chris and the Objective-C team had been playing a long game of 3D chess by quietly introducing Swift compatibility features like modules, automatic reference counting, and nullability across core frameworks. In 2015, Lattner achieved the unthinkable: convincing the world’s second-most secretive company to open-source Swift. Thus Swift evolved driven by 3 tribes who kept each other in check:
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…” Today in 2026, we are... well. 217 keywords. Not simple. No composey.
Without Lattner’s iron fist, Swift sits uncomfortably at a pinch-point between two opposing clans: the open-source community™, and Apple Incˢᵘᵖᵉʳ™. They both wage their own wars, with their own incentives, and their own imperfections. Guess who holds all the cards. “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 LanguageAll languages are maintained by an individual, a team at a company, or a large distributed community. Owners set rules for how changes, features, & extensions are selected, designed, & implemented. This is critical for a sense of stability, continuity, and improvement, and critically to maintain backwards-compatibility. Developers like to know their livelihood isn’t getting deprecated. How do the greats do it? Python: Benevolent Dictator For LifePython was created by Guido van Rossum in 1990, who was named the the BDFL (benevolent dictator for life), a title which is both 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 steerco of 5 elected engineers, picked by the 100-odd open-source maintainers. Changes are proposed by PEPs and deliberated. “Python makes slow and careful steps towards new features and versions.” Rust: Community-driven open-sourceRust was created by Graydon Hoare and adopted by Mozilla, eventually picked up by the Rust Foundation (funded by AWS, Huawei, Google, Microsoft, and all their friends). Changes to the Rust language are discussed viaRFC, steered by teams focused on language,compiler, and dev tools. While this might sound utopian, the Rust community, like all open-source communities, is not without its drama. “Everyone is invited to discuss the proposal, to work toward a shared understanding of tradeoffs. Though sometimes arduous, this community deliberation is Rust’s secret sauce for quality.” Kotlin: Corporate-backed open-sourceKotlin 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, i.e. Google & JetBrains. The board appoints the lead designer, basically a high-ranked JetBrains dev. The community submits KEEPs and devs play with experimental APIs before release. “Language design is cast in stone, Major languages have an open-source community which proposes and deliberates changes. They also have a centralised faction that has the final say on code changes. IncentivesFundamentally, language governance is about aligning incentives. Each has 3 major constituencies:
End-user devs want a nice language, and vote with their keyboards. Often in the millions, this cohort ultimately has the least sway because language switching costs equal years of experience. The community includes the most passionate end-users and usually full-timers in the pocket of the steering group. They often have pure incentives: make a good language. But also, other forces are in play:
The steering group is the most powerful by far. Their incentives depend entirely on governance structure:
Swift: Corporate Dictator for LifeApple pays most of the Swift core team’s salaries, and appoints the leadership. Apple is unambiguously the dictator of Swift. They are benevolent, to their shareholders. Incentives are good ol’ fashioned profit maximisation 🇺🇸🇺🇸🇺🇸 Incentive alignment with the developer community exists, if tenuously. A good Swift language translates, in a hand-wavey, tricky-to-put-on-a-balance-sheet way, into service revenue and device sales. But the open-source community can get f*cked. Swift 5.1 is the canonical notorious example. It added opaque result types, implicit returns, and property wrappers. Via a cheeky dictatorial backdoor, function builders were added to the compiler without any evolution process whatsoever! These features form the syntactic backbone of SwiftUI, the shiny new UI Framework of the Future™. Apple’s own internal timeline (driven by fear of React Native) dictated the unilateral approval (or lack thereof) for these features, instead of giving the community a fair say. As a result, SwiftUI looks a little bit tidier than if we had to `return` Views explicitly. SwiftUI feels easier without needing to append child views onto a parent result like in Jetpack Compose. But these features also injected complexity and compiler magic across the whole language. On a personal level, the Swift Concurrency Manifesto was published 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 LegacyLet’s re-visit the language design philosophy Latty Chris introduced and compare it to modern-day Swift:
Lattner stayed on the Swift core team until 2021, leaving on a fairly pessimistic note. The root cause of my decision to leave the core team is a toxic environment in the meetings themselves. The catalyst was a specific meeting last summer: after being insulted and yelled at over WebEx (not for the first time, and not just one core team member), I decided to take a break. After several discussions generating more heat than light, when my concerns were ignored by unilateral accepts, and general challenges with transparency working with core team, I decided I was just wasting my time… 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 bleakly reinforces exactly what we expect from Swift’s lopsided governance structure. Apple ostensibly seeks community input on proposals, however they also habitually push through their own work because they have frameworks to ship. Strategic priorities like proprietary UI frameworks that strengthen their walled garden will forever take priority. Tech Debt & CompilersChris Lattner has spoken out several times about the endless backlog of tech 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 some extremely silly tech debt from which it may never recover. Swift is a slave to the top-down whims of the Apple MBA cabal: prizing secrecy and tolerating 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 crazy given their incentive structure. We can steel-man them: SwiftUI is pretty good. From a business point of view, by 2019, they had to release a declarative UI framework to compete with cross-platform challengers, React Native and Flutter. Unifying the platforms (iOS, MacOS, watchOS, TVOS, and now VisionOS) was 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. But as always, business benefits take precedence over the whinging luddites standing in the way of progress (via tech debt tickets). Is there Hope for Swift?Apple listened when Chris dramatically cut ties. It catalysed a shift towards a less dictatorial, more transparent mode of governance. Swift is borrowing ideas from the Rust model : specialised steering groups and workgroups, including team members from outside Apple (gasp!).
The emphasis on Swift outside the Apple walled garden gives hope that Apple’s 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, Arduino, and even Android. Apple dogfoods Swift internally on 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 nice. Finally, Apple is 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 (finally). 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.
Sent from my iPhone
|
