Swift Download Windows 11

0 views

Skip to first unread message

Munir Junker

unread,

Aug 3, 2024, 5:02:32 PM8/3/24

to buiwhinapeer

For over a year now, there has been a significant endeavour to port Swift to Windows in conjunction with the developer community at swift.org. The Windows support is now at a point where early adopters can start using Swift to build real experiences on this platform.

Porting Swift to Windows is not about simply porting the compiler, but rather ensuring that the full ecosystem is available on the platform. This includes the compiler, the standard library, and the core libraries (dispatch, Foundation, XCTest). These libraries are part of what enables developers to write powerful applications with ease and without having to worry about many of the details of the underlying system. There are many technical details in the story of bringing Swift to a usable state on Windows, and if you are interested in them, I would recommend checking out my talk on the topic from the LLVM Developer Conference.

With these core libraries and the flexible interoperability of Swift with C, it is possible to develop applications on Windows purely in Swift while taking advantage of the existing corpus of libraries on the Windows platforms.

Although the demo application is built with CMake, Swift Package Manager support on Windows is coming along. It will soon be possible to get the application building using swift build without needing CMake or Ninja.

We at Readdle started experimenting with Swift on Windows more than a year ago, in Q2 of 2019. By that time we already released Spark for Android which uses Swift to share core code with iOS/macOS, and the opportunity to extend to one more platform was really tempting.

Despite some functionality being unready as of yet, Swift on Windows turned out to be fully satisfying our needs. In fact, some third party C/C++ dependencies gave us more headaches than Swift did itself. All business logic of Spark is located in a separate Core module. A pack of modules, actually, but we refer to them as Core. This allows us to use any UI framework on the target platform: AppKit on macOS, UIKit on iOS, native UI Toolkit on Android. So, basically, we had to port Spark Core on Windows. After all initial concepts were proved, it was mostly routine day-to-day work to bring it alive on Windows.

Another challenge was to decide how to implement the user interface. After extensive discourse we ended up with Electron as the front-end part of future Spark for Windows. That meant we not only needed to be able to build Spark Core on Windows but also use it as a loadable addon for Node.js.

Node.js addon in pure Swift? That appeared to be surprisingly easy. Swift perfectly imports N-API headers. We still need three lines of C code plus one small C header to define addon entry point, but all logic is in Swift. Due to the crossplatform nature of Node.js, we were able to use macOS as a development platform with Xcode as IDE, and then use the agility of CMake to build the same code on Windows.

Adding support for Windows to Swift is the beginning of a journey. The current support sets the first milestone where the language is usable. There is yet another even broader part of the ecosystem like lldb and the Swift Package Manager which still need more work to be as complete in their support for this different platform.

The Getting Started section has been updated with new information about using Swift on Windows! For the early adopters who are getting started and finding issues, please report them to the Swift Bug Tracker.

There are many opportunities for those interested in helping push Swift on Windows forward. One of the things that makes Swift easy to use is libraries: publishing new libraries and packages for Swift on Windows or porting existing ones is another way to get involved and help make working with Swift an ever greater delight.

For the ones interested in working on core tooling, there is plenty of work to be done to improve the debugger and to improve the Windows support in the Swift Package Manager. We invite you to check out the Swift Bug Tracker for the current issues and to send patches to the GitHub repositories. There is also a new section on the Swift forums to discuss the development of Swift on Windows. There the community can discuss issues or you can introduce yourself and let others know what area of the tooling you are focusing on. This is the perfect opportunity to become involved in the project and help it grow into a strong, vibrant, cross-platform ecosystem. We cannot wait to see what exciting things you build with Swift!

Is there a step by step guide to building a Windows Desktop App using Swift for Windows? I have looked at search engines and most come up with how to write iOS software using Swift on Windows. Which is valid but I'm specifically looking to build a Windows App using Swift.

I'm aware of the compnerd's framework. But the question is how do I use it in Windows? Is there a step by step guide somewhere that I can follow along to get all the way to just writing Swift code and compiling an app?

Student-friendly setup instructions for platforms, editors, and IDEs that support Swift. - GitHub - pwsacademy/swift-setup: Student-friendly setup instructions for platforms, editors, and IDEs that...

OK, I am not the only one who maintains a separate guide. I think this is very helpful, but we should all work helping to get the according documentation on swift.org (which is already quite good) even better (I am mostly blaming myself here). The ultimate goal should be that our own guides become superfluous. Our own guides might also become outdated fast, e.g. the repair after a Visual Studio update should not be necessary any more.

We have to either go with Visual Studio 2019 Build Tools or Visual Studio 2022 Community. I would suggest the latter, and we'd better drop hard-coded VS 2019 dependency in WinGet manifests, until the dependency selection/alternative/... feature is implemented.

Perhaps we should follow suit here. I was hoping that we could make it easier to say just install Swift.Swift and get everything, but it seems to just be causing more trouble. It would be great if we could add some notes in the install via winget so that someone searching for swift and installing it without instructions would know this is needed. Maybe I am overthinking this.

@stevapple Version 10.0.22000 seems to be the Windows 11 SDK? Will this work on Windows 10 as well? In other words, will the following command work on both Windows 10 and 11, or do we need separate commands for both platforms?

I'm sad to report that instability of Swift on Windows appears to have caused my project to drop support for Windows, despite having gotten direct support from @compnerd. In particular, about 1 in 3 CI runs on GitHub are failing, which creates too much development friction. Of course it's possible that this is a GitHub problem unrelated to Swift, but of course non-Swift Windows CI works fine on GitHub. I wonder if there's anyone out there other than @compnerd that's invested in supporting Swift on Windows? As excellent a developer as @compnerd is, we can't really call Swift on Windows supported if only one person is working on it.

a related issue for me has been the unavailability of swift-atomics on Windows. pretty much anything that involves concurrency requires atomics, which implies that anything that involves concurrency cannot support Windows.

For reference, we have not seen much in the way of instability in Windows CI for the Swift project itself, and nowadays we're running Windows CI on all pull requests alongside macOS and Linux. However, the Swift project CI is not based on GitHub's CI---its separate Windows machines coordinated by Jenkins. So it's possible that there's something different in the GitHub CI environment for Windows that's causing problems.

It's also possible that something in your code base is exposing existing bugs in Swift's support for Windows. If you're making heavy use of async, it could be issue #57976, which can manifest as a stack overflow. (We're making progress on that one, but it's tricky because Microsoft's unwinder cannot support any calling convention with mandatory tail calls).

In the issues you linked, I don't see much investigation into what's actually happening. Has anyone managed to catch the crash so we can see what's going on? Platform support is hard, especially for Windows because it's so different from Unix-like OS's, and the environment can matter in surprising ways.

If you're making heavy use of async, it could be issue #57976 , which can manifest as a stack overflow. (We're making progress on that one, but it's tricky because Microsoft's unwinder cannot support any calling convention with mandatory tail calls).

Yeah, we think we have a path forward now. We've been in touch with Microsoft, who confirmed our suspicions that we can't create a calling convention that has both mandatory tail-call optimization and structured exception handling (due to unwinder limitations on that platform), so we're trying to thread the needle here to address the bug without foreclosing on future improvements to backtrace facilities.

However, the Swift project CI is not based on GitHub's CI---its separate Windows machines coordinated by Jenkins. So it's possible that there's something different in the GitHub CI environment for Windows that's causing problems.

In addition to the issues you mention, I suspect part of the problem is that the github CI only makes available two CPU cores for CI in the free tier that most OSS projects use, whereas Apple is likely using much beefier Windows servers for your own CI. I always suspected that had a role to play in earlier reported Windows flakiness on github CI.