Apple is Killing Swift
A great language strangled by governance
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.
Lattner’s vision?
Simple things that compose.
Progressive disclosure.
One way to do things.
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:
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…”
— Chris Lattner, 2024
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.”
Subscribe to Jacob’s Tech Tavern for free to join 100,000 Swift devs learning advanced concurrency, agentic iOS engineering, and Swift performance for 10 minutes a week.
How to Govern a Programming Language
All 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 Life
Python 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.”
— Guido van Rossum
Rust: Community-driven open-source
Rust 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.”
— Rust Governance
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, 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,
but this stone is reasonably soft,
and with some effort we can reshape it later.”
— Kotlin Design Team
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.
Incentives
Fundamentally, language governance is about aligning incentives. Each has 3 major constituencies:
End-user devs who use the language day-to-day.
The community submitting language proposals.
The steering group with the final say.
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:
Résumé-driven-development. I want to be the guy who implemented Borrowing because it makes me look attractive to employers.
Bikeshedding embodies the path of least resistance: devs love to focus on trivia like syntax and naming. Hey, they still helped.
The steering group is the most powerful by far. Their incentives depend entirely on governance structure:
Python and Rust steerco contains the most dedicated community members, nudging imperfect sets of incentives into something vaguely resembling “what’s good for the language”.
With Kotlin, Jetbrains and Google have a clear profit motive. Fortunately, selling IDEs and making Android devs productive align pretty well with end user devs.
Swift: Corporate Dictator for Life
Apple 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 Legacy
Let’s re-visit the language design philosophy Latty Chris introduced and compare it to modern-day Swift:
Simple things that compose -> A big bag of random complicated features
Progressive disclosure -> 217 keywords
One way to do things -> Result builders and macros(!?)
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.
— Chris Lattner
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 & Compilers
Chris 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!).
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 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.
Subscribe to Jacob’s Tech Tavern for free to join 100,000 Swift devs learning advanced concurrency, agentic iOS engineering, and Swift performance for 10 minutes a week.
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.
People seldom understand how shit things are with Swift. Looking at me talking all crazy and paranoid, but now I’ll link them this amazing post where everything is described thoroughly and adhd-free. Also them absolute goobers still want Swift on backend - I wonder who sold this genius idea in 2025…