Swift is a nice language. But unfortunately it heavily overlaps with C# making it difficult to justify picking the former anywhere besides macOS application development.
It's not a good idea to take Miguel's criticism of .NET seriously in the last couple of years, after the falling out. Give it more years and we might just hear the similar style of statements towards Swift and Apple's ecosystem now that he is promoting it.
The only thing it does is spreading the FUD further.
(I knew it was him even before opening the link, as he's the only source of vocal publicity of this kind)
I don’t know what happened but these days Miguel does seem very salty about w/e happened at his time at MS. Like you, I would take what he says with a grain of salt.
Basically after Xamarin got acquired, Xamarin.Forms got rewritten into MAUI, Mono Develop was killed in name of VSCode (after existing for a while as VS4Mac) with no comparable tooling, Mono only exists as runtime for iDevices/Android/Blazor, Mono linker got repurposed as Native AOT trimming, most of the Mono BCL was merged with .NET Core efforts.
And that was it, regarding Xamarin story in the .NET ecosystem.
I assume, like with any acquisition, what they were promised and how things went down, wasn't quite the same.
His enthusiasm for SwiftUI in particular is a bit hard to reconcile with my experience using it. It's nice on the happy path but you very easily stray into areas with baffling compiler errors and terrible UI performance.
Swift does not require a GC, which in some cases can be desirable.
I would also say that it is generally a better language feature-wise. C# suffers from having been an almost carbon copy of Java originally (with some Delphi thrown in for good measure).
We're way beyond it, but they are still stuck with some of the unfortunate early decisions for back-compat reasons. E.g. the fact that strings, arrays, and other collections are strictly reference types, or that arrays in particular are covariant despite being mutable. Swift is much more consistent in that things that are semantically values are also value types.
In that regard, given the set of gc enabled systems languages that predated both of them, I consider both had quite a few unfortunate decisions, exactly regarding value types, low level coding, and AOT compilation.
Both went with more Smalltalk and less Modula-3, even though they acknowledge influence of those languages, among others.
Collections aren't strictly reference types and with ref structs in generics feature you will be able to write a LINQ-style abstraction on top of Span<T> (though lifetime restriction still apply).
(you could already do so provided it specialized on accepting spans only with element type being a generic argument, with a new feature you could have Span<T> implement e.g. IList<T> and be passed to e.g. Reduce<T, U> where T : Span<U>, and regular struct generics existed for a very long time)
All standard BCL collections (List, Dictionary etc) are reference types. Some associated machinery like enumerators are value types, but that's beside the point here, which is that by default you end up with shared data rather than a (safer) copy. This also means that whenever you return an owned collection you either have to manually copy or wrap it in a readonly proxy to avoid accidental mutation of internal state by the caller.
In contrast, in Swift, Array, Dictionary, and Set are value types, so if you return a collection you own from a function, the caller semantically gets a copy - under the hood they do copy-on-write, so until either side decides to change its collection, they continue to share storage. Similarly for parameters neither the caller nor the callee has to worry about accidentally mutating something someone else owns. And in the rare case where pass-by-ref and its shared mutability is actually desirable, you handle that with `inout` (which is mostly equivalent to C# `ref`, including explicit marker at call site).
The same goes for strings, which in turn allows strings to be mutable like any other collection (since they aren't shared all over the place).
The CLR type system allows for all the same things in principle, yes. And if C# and the BCL were designed from scratch today, I suspect that it would make very different choices. But these are some very fundamental things that were decided 20-25 years ago, and now cannot be changed for back-compat reasons.
You can run C# on almost any device and you can do backed, front-end, desktop, games, utilities and whatnot using it. I think Swift has a lower appeal being tied to iDevices.
