Swift on Windows

> Nobody was talking about Android.

It matters in the current context. Developers have a much easier time targeting the latest and hottest on iOS, compared to the only other alternative.

> And the number of people still on 12 is significant.

Not for long if 14 is already 25% in less than a week, and most users upgrade to the latest versions soon enough.

I have been developing for Windows in Swift for years ️

Swift has no concept of fault tolerance. If you by mistake make an illegal array access, multiply two numbers that are too big or overflow your stack (which is limited to ridiculous 512KB on secondary threads), your app crashes and that's that. Apart from a horrible user experience (you don't even get a "nice" customised 500 error page, just a "Gateway timeout" or similar), your app is now offline for everyone.

What other backend language doesn't allow you to recover from errors? It is my understanding that even Haskell allows you to catch "error".

I developed a Swift server-side app (not with Vapor, but with Kitura - but the point still stands) for two years and this was one of the biggest issues, and despite ongoing discussions, it just has never been fixed.

Swift manages to be technically open-source while not really being true to the idea of open-source. To me, it always seems as if somebody at Apple saw that companies like Microsoft going open source was good publicity and decided that they should do it now too, without really understanding what "open source" means.

Some examples of this IMHO include:

- While Swift itself is open-source, "Foundation" (which is something of a stdlib of Swift and provides many key pieces of functionality) is not open source - at least on macOS. There is a reimplementation of Foundation for Linux which is open source but, surprise, surprise, the two sometimes have different behaviour...

- Swift releases are weirdly coupled to XCode releases, a closed-source IDE. Moreover, while technically possible, most people on macOS don't install Swift on its own, but always through XCode, and the two are quite tightly coupled (you can technically change the toolchain, but it's quite an opaque setting IMHO). This leads to a lot of "I updated XCode and now the code is not working anymore" issues, especially with more junior developers.

- Tooling outside of XCode (itself not the greatest of IDE of all times...) is extremely ... limited. For example, XCTest's (the test framework's) console output is almost unreadable and there are actually (half-abandoned) third-party tools that try to parse it and format it nicely (while introducing tons of weird bugs), something that test frameworks for other languages can just do for free. The package manager has, I think, one maintainer, and is so underpowered that most iOS developers don't really use it yet (despite it now being a couple of years old). And in terms of editor/IDE support there is now technically a LSP implementation, but last I tried, I couldn't even manage to set it up properly.

- There is no clear roadmap or even mission statement for Swift. Many other languages try to be clear about where they're headed and also what kinds of things they don't want to support, but Swift development is this weird mixture between a) a "community process" that often just leads to very different parties bringing their own very special concepts, syntax sugar, etc. into the language development without there seeming to be any overarching idea of where this all is headed, and b) some things just seemingly being implemented because it's useful for some shiny Apple feature ("function builders" which is mainly meant to support SwiftUI and which many people have been very skeptical about). Meanwhile long-standing proposals like properly fixing generics ("Generics Manifesto") are being pushed back indefinitely. It seems to me sometimes that Swift developers are willing to let the community bikeshed on trivial matters (e.g. syntax sugar), but when it comes to more important, long-term concerns (should we implement function builders or rather invest in some more generally reusable macro-like / code generation feature), are being unilaterally decided without really consulting the community.

I wrote a project about a decade ago that used WPF and was disappointed to hear later that Mono wouldn’t be implementing a clone. They actually recommended Silverlight if one wanted cross-platform WPF. But WPF is just so much better than WinForms IMO, and Silverlight was on its way out then.