Swift Has 217 Keywords Now. Nobody Agrees on What It's For.

Imagine your favorite restaurant. The one you discovered when it was a tiny Italian trattoria with twelve seats, a handwritten menu, and the best cacio e pepe you’d ever tasted.

Then one year they added sushi. Okay, sure. Then tacos. Then a Thai section. Then a raw bar. Now the menu is 47 pages, the pasta tastes different, the original chef left, and the new management keeps telling you the food is actually better than ever.

That’s Swift in 2026.

The Number That Started a War

217 keywords. That’s how many reserved words Swift currently has.

For context, Go has 25. Rust has about 50. Python sits around 35. Even C++, the language developers love to complain about, managed to accumulate its keyword count over four decades. Swift did it in twelve years.

Jacob Bartlett’s widely-shared piece about Apple’s stewardship of Swift dropped this number like a grenade into the developer community, and the resulting discussion hasn’t really stopped. The piece reverberated across Hacker News, Reddit, and every iOS developer Slack channel I’m in.

The core argument isn’t that Swift is bad. It’s that Swift doesn’t know what it wants to be anymore.

Three Promises, Twelve Years Ago

When Chris Lattner introduced Swift in 2014, the language was built on three principles: simple things that compose, progressive disclosure, and one obvious way to do things.

That last one is beautiful. It means a junior developer and a senior developer should look at the same problem and reach for roughly the same tools. You don’t need to know about five competing patterns to write a for-loop.

Fast-forward to today. Want to write concurrent code in Swift? You need to understand async/await, Task, TaskGroup, actors, @Sendable, @MainActor, nonisolated, ~Copyable, isolation boundaries, and a half-dozen compiler attributes that changed meaning between Swift 5.5, 6.0, and 6.2. Oh, and the rules about which of these actually matter got completely rewritten last month.

Progressive disclosure? More like progressive confusion.

The Concurrency Saga Tells the Whole Story

The Swift Concurrency manifesto was published in 2017. The actual implementation didn’t ship until 2021. Why the four-year gap? Because Apple needed SwiftUI ready for 2019, and the compiler team was redirected.

Then Swift 6.0 arrived in 2024 with strict concurrency enforcement turned on by default. The idea was right — catch data races at compile time. The execution was… ambitious. Suddenly, codebases that had worked fine for years were drowning in compiler errors about Sendable conformance and actor isolation.

The community pushed back hard. Blazej Sleboda’s “Swift Concurrency is a Mess in 2026” post captured what a lot of developers were feeling — the constant model changes were eroding trust.

So Apple course-corrected with Swift 6.2. @MainActor everywhere by default. The new @concurrent attribute to opt into concurrent execution. Same safety guarantees, dramatically less boilerplate.

It’s a good fix. But the fact that it was needed — that the language team essentially reversed course on a flagship feature after two years — tells you something about how Swift is being designed. Features ship, the community struggles, the features get revised, repeat. It’s not a confidence-inspiring cycle.

Who’s Actually Driving This Thing?

Here’s the governance problem nobody wants to talk about directly.

Swift is technically open-source. There’s a Swift Evolution process. Proposals get discussed. Votes happen. But Apple appoints the language’s leadership and pays the core team’s salaries. As Swift.org itself states, Apple serves as the project’s arbiter.

That’s not necessarily evil. Someone has to make decisions. But it creates a specific dynamic: when Apple has a strategic priority — say, shipping SwiftUI on time, or pushing the concurrency model that makes Apple Intelligence work better — that priority tends to override community concerns.

Chris Lattner, Swift’s original creator, left the core team in 2021. In a 2024 interview, he was blunt about what the language had become. He described it as something that had evolved away from the simplicity he originally intended.

The counterargument is fair: languages grow. Rust has a borrow checker that makes new developers cry. TypeScript’s type system has become its own Turing-complete language. Complexity isn’t automatically bad.

But most of those languages have governance models where the community has genuine power. Python has its elected steering committee. Rust has focused teams with real authority. Swift has… Apple.

The Cross-Platform Identity Question

Meanwhile, Swift is trying to become something beyond an Apple language.

Swift 6.3 brought official Android support. There are workgroups for Windows, Arduino, and WebAssembly. Apple’s rewriting the Foundation framework as a standalone open-source package. These are real investments.

But they create a tension. Is Swift a language for Apple platforms that happens to run elsewhere? Or is Swift trying to be a general-purpose systems language that competes with Rust and Go?

The 217 keywords suggest Apple is trying to make it both. Simple enough for beginners, powerful enough for systems programming, safe enough for concurrent server code, elegant enough for UI declarations, and cross-platform enough to run on Android.

That’s a lot of identities for one language. And historically, languages that try to be everything end up being nothing in particular.

The Counter-Argument: Swift Has Never Been Better

I should be fair here, because the doom narrative isn’t the whole picture.

SwiftUI — the reason a lot of that complexity exists — is genuinely excellent in 2026. Building interfaces with it feels faster and more natural than almost any other framework on any platform. If you’re taking our SwiftUI courses, you’ve seen how far the framework has come from its shaky 2019 debut.

Swift 6.2’s concurrency model, the revised one, is actually pretty clean. The compiler catches real bugs. The performance is excellent. The developer experience, once you learn the (new) rules, is better than before.

And the cross-platform expansion is legitimately exciting. Running Swift on Android isn’t just a party trick — it means shared business logic between iOS and Android apps. That’s a real architectural win.

The problem isn’t that Swift is bad. It’s that Swift is complicated in ways that feel accidental rather than intentional. It’s 217 keywords not because someone sat down and designed a 217-keyword language, but because twelve years of competing priorities left features stacked on features like geological layers.

What WWDC Needs to Answer

WWDC 2026 is 19 days away. Every year, the Swift team presents their vision for the language’s future. This year, the community isn’t just looking for new features. They’re looking for a philosophy.

Three questions that need answers:

1. What is Swift’s complexity budget? Every language has one. Will Apple commit to removing or simplifying features, not just adding new ones? The best thing Swift 7 could announce is that it’s smaller than Swift 6.

2. What does governance reform look like? The current model works when Apple’s priorities align with the community’s. But when they don’t — and concurrency proved they sometimes don’t — there’s no check on Apple’s power. Is that going to change?

3. Is Swift one language or three? An Apple UI language, a cross-platform systems language, and a server-side language have different needs. Pretending they don’t is how you get 217 keywords.

The Restaurant Still Makes Good Pasta

Look, I still write Swift every day. I still think it’s the best language for building iOS apps. The tooling is solid, the community is passionate, and the course material we’ve built around SwiftUI proves you can learn it and build real things with it.

But loving a language doesn’t mean ignoring its problems. Swift’s biggest risk in 2026 isn’t competition from Kotlin or Rust. It’s that the language is trying to be so many things at once that newcomers bounce off the complexity wall before they ever get to the good parts.

The little Italian trattoria is still in there somewhere. I just hope someone at Apple remembers the original recipe.