My personal opinion is because Swift has turned into an "us too" language. There's a large rush for all popular language ecosystems to rush to whatever trendy development exists in language design now days to retain the momentum of community. I write/maintain a decent amount of code in Swift these days. I'm proficient in some parts of it, clueless in others. Like Kotlin, and Javascript, and even Python to some degree (I do a lot of Kotlin and Python too), these multi paradigm languages are sort of a "use it however you want." There's no unifying simplicity in them. So it becomes a race to the bottom of utility. Why use Swift, when it looks and feels like so many other languages, and when it's clear the rate of the changes in it will primarily benefit Apple?

To be clear, I don't hate Swift at all, I like some bits of it, it's just that there's no real draw for me to play with out side of the Apple eco system. If Apple made it so that I could use it write Android apps with it (kinda like Dart is supposed to be), I would be much more excited about. If Swift was dedicated to a small set of unifying principles (kinda like Elixir), I could get more excited about it.

There’s a few reasons, but mostly is due to economics and the way Apple builds its own software.

Swift came out of the iOS side of the company, and was sponsored to make writing iOS apps easier. It was therefore constrained to fit into a particular shape; in particular, Objective-C compatibility was a must have. Many of the frameworks and libraries on iOS/macOS are implemented in Objective-C including “std” libraries like Foundation.

When building Swift for Linux/Windows, there isn’t an Objective-C ecosystem, and rather than introduce one, instead the language just doesn’t have support for that. As a result, the “std” libraries are a complete rewrite of the libraries available on macOS. Even being able to include Posix basics used a different library name; Darwin vs GlibC. [There was a long battle to try and get a meta import of LibC which would import the right one on different platforms.]

So there are really two dialects of the language: Apple Swift and Linux/Windows Swift. They share the same overall feel but is like the difference between Diesel and Petrol/Gas. Same overall outcome, different completely under the hood.

Two other reasons exist; firstly, the internal builds are a fork of the open source project, so when a new feature lands on an iOS device, code and libraries are written to support that (eg SwiftUI) and nothing related to that fork lands until after Apple have announced it. What that means is you get giant blobs of diffs on an annual basis; in some cases, reverting bugs that have been fixed already in the open source world (because the internal version was forked six months previously).

The other reason is that Swift depends on a forked version of llvm/clang, to the extent where you have to install those to be able to compile Swift programs. Many upstream distributions already ship their own clang, which is essentially incompatible with Swift, but they want to follow their philosophy of only one version of a library (and don’t want to replace their own version with a Swift specific one).

So, Swift on iOS is a primary platform, and if you are writing iOS apps is the standard way. Every other platform is a second class citizen and software project management at Apple is not well suited to an open source workflow; since the iOS team are calling the shots on swift (and paying for most of it, to be fair) then the language evolves for their benefit primarily and then others as a side effect.

Even though it was obviously beta, there was a lot of early churn in the language and libraries. Some substantive, some trivial. And even in later versions, they like doing October surprises with language features, despite being open in development (SwiftUI and all it’s crazy dsl support came outta nowhere)

But the Linux story was garbage through v5, with half the standard library being unimplemented, and you getting to find out only at runtime.

Also, swift on Linux was (is) still just “here’s a tarball, dump it somewhere” or build from source.

That and the fact that static binaries aren’t a thing without a lot of work, if at all, means you have to ship a 2gb runtime to do anything — which sucks for casual tools.

I love the language but it feels like a bad time anywhere but on Darwin

Perhaps because everything else that Apple does screams "WALLED GARDEN" so the world is now wary af.

There are so many languages to choose from that don't take off outside their niche, why would Swift be different?

From an outsider's perspective, Swift is an attempt to replace ObjC as the "macOS/iOS platform language" with something that feels a bit more '21st century' (for better or worse), so it plays the same role as Kotlin on the Android platform.

IMHO a better solution would have been to provide more "language-interop-friendly" C-API wrappers for high level macOS framework APIs, so that it's easier to write macOS and iOS applications in all sorts of languages (the same applies to Android btw). But the NIH seems to be strong at Apple, so Swift it was instead.

I wish I could use it in more places. It checks most of my boxes and I feel reasonably proficient in it, so I would love if I could it in place of say C# on Windows or in place of C++ or Rust for cross platform desktop development.

Swift is also the bulk of what I write for my day job, and it's always nice to not have to allocate mental resources to the differences between languages when trying to work on personal projects in one's off-time. It's so nice to just sit down and just start writing code without having to spend a ton of time googling "how to do X in Y language".

I would imagine the churn is a big killer and lack of decent documentation on the current version. Apple cannot even keep their example code for their platform up to date. If you are on the Apple platform you have to deal with it, but there are other, stronger ecosystems for other language on other platforms.

I feel like the lengthy focus on the Swift for Tensorflow project by some of the key Swift figureheads (including Chris Lattner himself) slowed Swift done a lot. SFT was eventually scrapped, and I can’t help but wonder where the language would have been if those minds would have focused on things like landing async/await & ABI stability earlier and working on other new language features.

Unless you're making iphone apps there are much better languages for nearly every use case that are already heavily adopted

Why would you learn it if you aren't targeting apple users.

The same reason as Objective-C did not took off outside NeXT/Apple, you just get the bare bones compiler without the ecosystem.

When Swift was released, it was not open source. At the moment it was open sourced, Swift was not in the news anymore and I remember thinking "ok, whatever".

I wonder if this late open sourcing contributed to this.

And yes, from the outside, it seems very Apple oriented. For any use case outside Apple there seems to be a (more?) suitable language.

Last time I looked, it didn't have a stable way to export a C-compatible ABI for FFI. Unless the majority of your project is in Swift, or there is are bridges for the project's other languages, interop with existing code can awkward or expensive.