around 2015-17 - Swift could have easily dethroned Python.
it was simple enough - very fast - could plug into the C/C++ ecosystem. Hence all the numeric stuff people were doing in Python powered by C++ libraries could've been done with Swift.
the server ecosystem was starting to come to life, even supported by IBM.
I think the letdown was on the Apple side - they didn't bring in the community fast enough whether on marketing, or messaging - unfortunately Swift has remained largely an Apple ecosystem thing - with complexity now chasing C++.
It's a nice lang for sure, but this will never be true with the way things are. Such wasted opportunity by Apple.
Why did this take so long to be added? Such strange priorities. Adding an entire C++ compiler for C++ interoperability before adding... C exports. Bizarre.
Reminds me of "In case you forgot, Swift has 217 keywords now" https://x.com/jacobtechtavern/status/1841251621004538183
While the Flash guys had to use a native development environment and compile their stuff, I could just edit JavaScript in a plain text file and hit reload.
20 years later, and some of the same friends now swear by Swift. And have to use a native development environment and compile their stuff. While I still prefer to just edit JavaScript in a plain text file and hit reload.
I do, though, think Swift had/has(?) a chance to dethrone Rust. Rust is incredibly powerful but sometimes you don't really need that complexity, you just need something that can compile cross-platform and maintain great performance. Before now I've written Rust projects that heavily use Rc<> just so I don't have to spend forever thinking about lifetimes, when I do that I think "I wish I could just use Swift for this" sometimes.
You're right, though, that Swift remains Apple's language and they don't have a lot of interest in non-Apple uses of it. They're much happier to bend the language in weird ways to create things like SwiftUI.
In 2015-2017 you could interop with C, C++ support wasn't added until very recently.
I do agree with you though and I am not sure what the exact reasoning is, but Swift is definitely an Apple ecosystem language despite the random efforts to gain traction elsewhere.
Just IMO, but... no. To me a "could have easily" requires n-1 things to have happened, and 1 thing not happening. Like, we "could have easily" had a nuclear exchange with the USSR, were it not for the ONE Russian guy who decided to wait for more evidence. https://en.wikipedia.org/wiki/1983_Soviet_nuclear_false_alar...
But even in '15-'17, there were too many people doing too many things with Python (the big shift to data orientation started in the mid/late 90's which paved the way to ML and massive python usage) by then.
The 'n' was large, and not nearly of the 'n' things were in Swift's favor then.
Again, IMO.
Another problem is the Apache Software Foundation don't seem to have any Swift maintainers, which means there really aren't any good pure Swift libraries for Arrow or Parquet.
There are some really good open-source libraries from Apple like Swift Collections or Swift Binary Parsing.
[0] https://swiftpackageindex.com/search?query=platform%3Alinux
Why could it?
> it was simple enough - very fast - could plug into the C/C++ ecosystem. Hence all the numeric stuff people were doing in Python powered by C++ libraries could've been done with Swift.
Half a dozen languages fit this description.
> the server ecosystem was starting to come to life, even supported by IBM.
No, not at all. Kitura, Vapor (a fitting name) were just a toys that no serious player ever touched.
Swift for TensorFlow was a cool idea in that time …
No way something that compiles as slowly as Swift dethrones Python.
Edit: Plus Swift goes directly against the Zen of Python
> Explicit is better than implicit.
> Namespaces are one honking great idea -- let's do more of those!
coupled with shitty LSP support (even to this day) makes code even harder to understand than when you `import *` in Python.
Edit 2: To expand a little on how shitty the LSP support is for those who don't work with Swift: any trivial iOS or macOS project that builds fine in Xcode can have a bunch of SourceKit-LSP (the official Swift LSP) errors because it fails to resolve frameworks/libraries. The only sane way to work with Swift in VS Code or derivatives I've found is to turn off SourceKit diagnostics altogether and only keep swiftc diagnostics. And I have the swift-lsp plugin in Claude Code, there's a routine baseline of SourceKit errors ignored. So you have symbols without explicit namespaces, and the LSP simply can't resolve lots of them, so no lookup for you. Good luck.
Swift was feeling pretty exciting around ~v3. It was small and easy to learn, felt modern, and had solid interop with ObjC/C++.
...but then absolutely exploded in complexity. New features and syntax thrown in make it feel like C++. 10 ways of doing the same thing. I wish they'd kept the language simple and lean, and wrapped additional complexity as optional packages. It just feels like such a small amount of what the Swift language does actually needs to be part of the language.
I wrote an eBook on Swift several ago but rarely update that book anymore. Count me as one of the many developers who for a while thought Swift would take over the world. At least Swift is a fun language to use, and now with LLM coding tools writing macOS/iOS/iPadOS apps is fairly easy.
But I don't know why I'd pick Swift on the server when Rust is better in almost every dimension, with a thriving and more community-driven ecosystem.
Once enums, ownership rules, and nullability cross that boundary, the generated header stops looking like a neat bridge and starts looking like one more place for ABI bugs to hide. Closures make it weirder fast, because now your error handling and calling conventions can drift just enough to produce the kind of bug that wastes a whole afernoon.
https://youtu.be/ovYbgbrQ-v8?si=tAko6n88PmpWrzvO&t=1400
--- start quote ---
Swift has turned into a gigantic super complicated bag of special cases, special syntax, special stuff...
We had a ton of users, it had a ton of iternal technical debt... the whole team was behind, and instead of fixing the core, what the team did is they started adding all these special cases.
--- end quote ---
That's funny. To me magic is implicit by definition and Python strikes me as a very magical language compared to something like Java that is way more explicit.
This must have pushed Chris Lattner towards making Mojo both interpreted and compiled at the same time.
The Zen of Python is how we got crap like argparse where arguments are placed in the namespace instead of a dict.
And then if that's the case, how were they not ready to solve the many problems that a big organization would run into? And all the schedule constraints that come with it?
I've been using C# since the first release in 2003/4 timeline?
Aside from a few high profile language features like LINQ, generics, `async/await`, the syntax has grown, but the key additions have made the language simpler to use and more terse. Tuples and destructuring for example. Spread operators for collections. Switch expressions and pattern matching. These are mostly syntactic affordances.
You don't have to use any of them; you can write C# exactly as you wrote it in 2003...if you want to. But I'm not sure why one would forgo the improved terseness of modern C#.
Next big language addition will be discriminated unions and even that is really "opt-in" if you want to use it.
* If you're in a team (or reading code in a third-party repo) then you need to know whatever features are used in that code, even if they're not in "your" subset of the language.
* Different codebases using different subsets of the language can feel quite different, which is annoying even if you know all the features used in them.
* Even if you're writing code entirely on your own, you still end up needing to learn about more language features than you need to for your code in order that you can make an informed decision about what goes in "your" subset.
To answer your question: I would immediately get rid of guard.
Also, I think the complexity and interplay of structs, classes, enums, protocols and now actors is staggering.
I would remove the distinction between value types and reference types at the type level. This has caused so many bugs in my code. This distinction should be made where the types are used not where they are defined.
I would remove everything related to concurrency from the language itself. The idea to let code execute on random threads without any explicit hint at the call site is ridiculous. It's far too complicated and error prone, which is why Swift designers had to radically change the defaults between Swift 6.0 and 6.2 and it's still a mess.
I would remove properties that are really functions (and of course property wrappers). I want to see at the call site whether I'm calling a function or accessing a variable.
I would probably remove async/await as well, but this is a broader debate beyond Swift.
And yes you absolutely do have to know and use all features that a language has, especially if it's a corporate language where features are introduced in order to support platform APIs.
Swift Caching Compiler - https://github.com/jrz/tools
Is it gonna be what you primarily use if you wanna write an Android app? Probably not.
Is it gonna displace react Native? Probably not. Is it gonna reach the levels of flutter? Maybe.
2. On top of that many of the features in the language exist not because they were carefully designed, but because they were rushed: https://news.ycombinator.com/item?id=47529006
Im curious how is this used?
The improvements in embedded Swift have definitely made it one of the most enjoyable/productive languages to work on the OS. I feel like I can build useful abstractions that wrap raw memory access and make the userland code feel very neat.
On the other hand, the compilation times are SO bad, that I'm really focusing on the Nim port anyway.
It's also strange because before I learned Swift, I heard about how beautiful it is but I find it much noisier than Rust.
Focusing on the keywords rather than the macros, I think the rest of them have legitimate use cases, though they're often misused, especially fileprivate.
It's a shame but it for sure needs BigTech for it to be used anywhere else.
E.g. ClearSurgery[0] is written fully in Swift, including the real-time components running on the Linux boxes.
I'm not 100% sure but I think the swift doc you linked is missing at least a dozen keywords so the truth probably lies in the middle
For Windows there's a 5 year old blog post: https://www.swift.org/blog/swift-on-windows/
For Linux there's a guide for GNOME: https://www.swift.org/blog/adwaita-swift/
It would be really nice if instead we could just do one style of development and then ship a set of libraries as used to work for OpenSTEP (which was why it had "OPEN" in the name).
However, I suspect that we may not be too far off, from LLMs being the true cross-platform system. You feed the same requirements, with different targets, and it generates full native apps.
Same with Swift, but I'd call that more of a wasted opportunity because Apple, unlike Rust Foundation, has a mountain of money to make it happen, and yet they don't seem to care.
With a simple tooling. No ugly script. Everything is naturally integrated.
https://docs.instruqt.com/tracks/challenges/using-markdown-e...
This used to be the case around Swift 4, but since then they've added so many features and keywords to the language. Now the simplicity and elegance is gone.
Also it seems like there was a marked change in the culture of Swift. It somehow attracted a lot of the "ackchyually" crowd which resulted in a lot of massively complicated features. I liked to occasionally browse the evolution docs and they got more and more complex over time.
Never. It won’t even reach Compose level, Flutter level DX is unattainable for any framework outside Flutter.
March 24, 2026

Swift is designed to be the language you reach for at every layer of the software stack. Whether you’re building embedded firmware, internet-scale services, or full-featured mobile apps, Swift delivers strong safety guarantees, performance control when you need it, and expressive language features and APIs.
Swift 6.3 makes these benefits more accessible across the stack. This release expands Swift into new domains and improves developer ergonomics across the board, featuring:
Read on for an overview of the changes and next steps to get started.
Swift 6.3 introduces the @c attribute, which lets you expose Swift functions and enums to C code in your project. Annotating a function or enum with @c prompts Swift to include a corresponding declaration in the generated C header that you can include in your C/C++ files:
@c
func callFromC() { ... }
// Generated C header
void callFromC(void);
You can provide a custom name to use for the generated C declaration:
@c(MyLibrary_callFromC)
func callFromC() { ... }
// Generated C header
void MyLibrary_callFromC(void);
@c also works together with @implementation. This lets you provide a Swift implementation for a function declared in a C header:
// C header
void callFromC(void);
// Implementation written in Swift
@c @implementation
func callFromC() { ... }
When using @c together with @implementation, Swift will validate that the Swift function matches a pre-existing declaration in a C header, rather than including a C declaration in the generated header.
Swift 6.3 introduces module selectors to specify which imported module Swift should look in for an API used in your code. If you import more than one module that provides API with the same name, module selectors let you disambiguate which API to use:
import ModuleA
import ModuleB
let x = ModuleA::getValue() // Call 'getValue' from ModuleA
let y = ModuleB::getValue() // Call 'getValue' from ModuleB
Swift 6.3 also enables using the Swift module name to access concurrency and String processing library APIs:
let task = Swift::Task {
// async work
}
Swift 6.3 introduces new attributes that give library authors finer-grained control over compiler optimizations for clients of their APIs:
@specialize.@inline(always). Use this attribute only when you’ve determined that the benefits of inlining outweigh any increase in code size.@export(implementation). This allows the function to participate in more compiler optimizations.For a full list of language evolution proposals in Swift 6.3, see the Swift Evolution dashboard.
Swift 6.3 includes a preview of Swift Build integrated into Swift Package Manager. This preview brings a unified build engine across all supported platforms for a more consistent cross-platform development experience. To learn more, check out Preview the Swift Build System Integration. We encourage you to try it in your own packages and report any issues you encounter.
Swift 6.3 also brings the following Swift Package Manager improvements:
swift package show-traits command.For more information on changes to Swift Package Manager, see the SwiftPM 6.3 Release Notes.
Swift Testing has a number of improvements, including warning issues, test cancellation, and image attachments.
severity parameter to Issue.record. You can record an issue as a warning using Issue.record("Something suspicious happened", severity: .warning). This is reflected in the test’s results, but doesn’t mark the test as a failure.try Test.cancel(). This is helpful for skipping individual arguments of a parameterized test, or responding to conditions during a test that indicate it shouldn’t proceed.The list of Swift Testing evolution proposals included in Swift 6.3 are ST-0012, ST-0013, ST-0014, ST-0015, ST-0016, ST-0017, and ST-0020.
Swift 6.3 adds three new experimental capabilities to DocC:
Markdown output: Generate Markdown versions of your documentation pages alongside the standard rendered JSON covering symbols, articles, and tutorials. Try it out by passing --enable-experimental-markdown-output to docc convert.
Per-page static HTML content: Embed a lightweight HTML summary of each page — including title, description, availability, declarations, and discussion — directly into the index.html file within a <noscript> tag. This improves discoverability by search engines and accessibility for screen readers without requiring JavaScript. Try it out by passing --transform-for-static-hosting --experimental-transform-for-static-hosting-with-content to docc convert.
Code block annotations: Unlock new formatting annotations for code blocks, including nocopy for disabling copy-to-clipboard, highlight to highlight specific lines by number, showLineNumbers to display line numbers, and wrap to wrap long lines by column width. Specify these options in a comma-separated list after the language name on the opening fence line:
```swift, nocopy
let config = loadDefaultConfig()
```
```swift, highlight=[1, 3]
let name = "World" // highlighted
let greeting = "Hello"
print("\(greeting), \(name)!") // highlighted
```
```swift, showLineNumbers, wrap=80
func example() { /* ... */ }
```
DocC validates line indices and warns about unrecognized options. Try out the new code block annotations with --enable-experimental-code-block-annotations.
Embedded Swift has a wide range of improvements in Swift 6.3, from enhanced C interoperability and better debugging support to meaningful steps toward a complete linkage model. For a detailed look at what’s new in embedded Swift, see Embedded Swift Improvements coming in Swift 6.3.
Swift 6.3 includes the first official release of the Swift SDK for Android. With this SDK, you can start developing native Android programs in Swift, update your Swift packages to support building for Android, and use Swift Java and Swift Java JNI Core to integrate Swift code into existing Android applications written in Kotlin/Java. This is a significant milestone that opens new opportunities for cross-platform development in Swift.
To learn more and try out Swift for Android development in your own projects, see Getting Started with the Swift SDK for Android.
Swift 6.3 reflects the contributions of many people across the Swift community — through code, proposals, forum discussions, and feedback from real-world experience. A special thank you to the Android Workgroup, whose months of effort — building on many years of grassroots community work — brought the Swift SDK for Android from nightly previews to an official release in Swift 6.3.
If you’d like to get involved in what comes next, the Swift Forums are a great place to start.
Try out Swift 6.3 today! You can find instructions for installing a Swift 6.3 toolchain on the Install Swift page.
Holly Borla is a member of the Swift Core Team and Language Steering Group, and the engineering manager of the Swift language team at Apple.
Joe Heck works on Swift as part of the Open Source Program Office at Apple.
March 6, 2026
TelemetryDeck is an app analytics service specifically for developers, designe..
I'd pick it over Swift if targeting Android since it can build and run in the JVM as well as natively -- and has Swift/ObjC interop. Its also very usable on the server if you wanted to, since you can use it in place of Java and tap into the very mature JVM ecosystem. If that's what you're into.
And I have a lot more faith in JetBrains being good stewards of the language rather than Apple, who have a weird collection of priorities.
Fully agree. I have zero Swift knowledge and currently use LLM to write a native app. I'm well aware of the SDKs and concepts in iOS development, so even if something's wrong I got intuition where to look and how to make the LLM fix it.
What’s that supposed to mean?
You're commenting on a post about an update... that they apparently don't do? What?
I don’t believe that’s true. Things are moving constantly, and in the right direction. Then again it would help if you cited particular grievances, because being a regular (cross-platform/cross-target) Swift user I am not sure what you are talking about…
I did not choose ClearSurgery’s example randomly. I was at a conference recently where the CTO was here, and he explicitly told us they were moving fast thanks to the Swift ecosystem. (I am not working there personally, nor am I affiliated.)
ForEach(vm.sorted(by: \.name)) { user in
row(for: user)
}
\. looks like a syntax error to me, wtf. Also, "in" instead of -> ??? .padding(.vertical, 4)
I also really dislike how you can leave off the type name, meaning you never actually know what that Type is unless you literally inspect the signature of the caller. func sorted(by keyPath: KeyPath<User, String>) -> [User] {
users.sorted { $0[keyPath: keyPath] < $1[keyPath: keyPath] }
}
???Yeah I fully accept it's just a me problem. But I hate it haha.
Nim really is clean and simple.
I tried to use Vapor with Swift recently and struggled to get something working because the documentation looked comprehensive, but had a lot of gaps. I ended up throwing it out because I didn't have the time to dig through the source to understand how to do something, when I could use a mature framework in any other language instead.
The promise is there but I'm just not ready to invest. My youthful days of unbounded curiosity are coming to an end and these days I just want to get something done without much faff.
Which GUI toolkit(s) does that install support?
It would certainly be quite profitable. Money tends to drive progress.
Hah! I'll use that argument if I ever get PIP'd.
No but seriously, constantly moving doesn't mean fast enough. Swift took took long to have cross-platform support.
And it is still uberslow to compile. To the point of language servers giving up on analyzing it and timeout.
if they really want me to use this lang for everything, they'd have to 1. massively improve compilation speed, 2. get the ecosystem going (what's the correct way to spin up an http server like with express?) and 3. get rid of roughly 150 of the 200 keywords there are
especially w.r.t. the last one, of course everyone frets at huge breaking changes like this, so it won't happen, so people won't use it
Plus Swift is arguably too unnecessarily complex now.
And there's Rust/Zig so why use Swift for low level?
I lost immediately any interest on it
However, the Kotlin community is fundamentally all about open source, whereas Apple & iOS Devs have an allergy to it. The quality and quantity is already miles above the vast majority of what's in the Swift ecosystem. https://klibs.io has all the native compatible libs. And if you're targeting a platform where the JVM is available then yeah, it's massive. Compose makes UI tolerable compared to JWT too. Even large projects like Spring are Kotlin first nowadays.
I don't understand this point. Could you explain?
The new keywords enable new language features (ex: async/await, any, actor), and these features are opt-in. If you don't want to use them, you don't have to.
What are they keywords you think should be removed?
At least 6 years old.
Coming from C++ and JavaScript, there aren't many languages that can claim to have "simpler" tooling than Go.
Using a language is more than just writing it with a pre-established knowledge of what subset of features you think is worth the tradeoffs. More keywords/features means when you try to figure out how to do something new, there may be 15 different ways and you need to analyze and figure out which is the best one for this scenario, which ones are nonstarters, etc.
That's was more or less the whole design goal of Go. It was made by C++ programmers who were fed up with how many features were in the language, so they kept the feature set limited. Even the formatting is decided by the language. You may not agree with every decision, but what matters is decisions were made and they're standardized, so everyone is on the same page. You can read anyone else's code, and you know exactly what's going on.