Swift as a cross-platform language and Windows support

I have been following the latest developments in the Swift and Swift Foundation repos, and it seems Windows support is becoming a reality (thanks @compnerd, awesome job!).

Is there any plan at Apple / the Swift for TensorFlow team / other organization to hook up a Windows machine to the Swift CI infrastructure? I would love to be able to try the toolchain and follow its evolution on Windows but I don't have time/resources to build it myself (probably the same applies to many others).

10 Likes

A year has passed. What's the current status of Swift on Windows?

2 Likes

I think it would also be good to know the status of Android and Linux as well. So much work has been done so far, where are we? And what is the next focus? @compnerd @Finagolfin

Linux distros such as redhat Debian should be first to officially supported along with Ubuntu latest lts release 20.4.
Windows and Android maybe the second wave to add support.

You can compile Swift code on Windows. All the core libraries can be linked against (Foundation, FoundationNetworking, FoundationXML, Dispatch, XCTest), and also the WinSDK. But the result is still fragile at runtime. Of the tests I have started running on Windows, just under half of them crash with segmentation faults. It seems to be mostly centred around the compiler botching complicated protocol hierarchies or something, although I haven’t been able to narrow it down yet. The places I would have expected the most difficultly, because of the greatest platform differences—like FileManager and Process—are actually working flawlessly. SwiftPM is not yet functional, so you have to use CMake.

Linux has been officially supported and on par with macOS for some time now. You will just find fewer third‐party development utilities for Linux. (Not sure about variants besides Ubuntu though, if that is what you were referring to.)

Android works and some companies are using it in production. Of the core libraries, only FoundationNetworking has been giving me problems. Both SwiftPM and CMake can cross‐compile from Linux. Apparently SwiftPM can also be used to compile source natively on Android. The compiler occasionally trips for Android where it wouldn’t for macOS or Linux, resulting in the need for either #if !os(Android) or code to be refactored. (I think this too is mostly concentrated around complex protocol hierarchies.)

The main hurdles are that:

  • These platforms are still experimental and not officially supported.
  • The necessary toolchains aren’t available at the official Swift site, so to install you have to do more work collecting the pieces (and figuring out where to find them in the first place). Or else you have to build the whole toolchain from source.
  • You will need to supply a lot more build flags manually, because the compiler, CMake and SwiftPM haven’t yet been taught where to find everything either.

You can see an example of a package being tested on all platforms here. And you can search it’s source for os(Windows) or os(Android) to get a sense of some of the platform differences and what does and doesn’t work yet. The approximate number of lines in the various set‐up scripts can serve as a rough comparison of how easy it is to run tests on each platform:

Platform Build Test Notes
macOS 1 1 “swift test”
Linux 3 3 download Swift, unpack, “swift test”
Windows 40 40 configure Visual Studio; install platform module maps, Swift, and ICU; minor repairs; additions to `PATH`; run CMake; test
(This figure does not include writing the `CMakeLists.txt` files.)
Android 60 70 install official Swift, cross‐compilation toolchain, Android SDK and ICU; minor repairs; write out a destination file, “swift build”; copy libraries; install on emulator/device; execute test executable
(This figure assumes you already have the Android NDK installed.)

It won’t help you do a proper install on your own device, but if you just want to experiment, the same GitHub workflow linked above can be set up for any package with this tool. It includes the automatic generation of all the CMake pieces. (You can copy and paste instead, but you’ll then have to manually adjust pieces of it according to your particular package manifest.)

6 Likes

I can't speak much for linux, or even Android cross-compilation, as my work has been to get a Swift toolchain natively running on an Android device. The goal is to get it to the point where you can just type pkg install swift and start writing Swift packages on your Android tablet, but for now you will have to build the Swift toolchain from source, with a few simple steps. The advantage of getting everything running natively is that I can run all the tests easily and I reported last month that I was down to only 16 test failures across all the tests from the Swift compiler validation suite up through the SwiftPM and sourcekit-lsp tests.

Since then, the last test fix for Foundation has been merged, so the only failures are 11 in Swift validation, 1 in XCTest, and 3 in SwiftPM, largely inconsequential issues like some validation tests not having RUNPATH set like Android requires or some LLVM sanitizers not working on Android. Of course, I'm guessing the tests don't cover everything and there is some functionality that hasn't been implemented for Android, such as Bundle support (ironically, @pvieito, who started this thread a couple years ago, tried to fix it and then abandoned it), but I haven't looked into how much of that there is.

I tried building and testing some Swift packages on an Android device, such as SwiftyJSON, the most-starred Swift package on github that advertises linux support. While other packages worked great, with swift build; swift test just working and passing all their tests, SwiftyJSON has been broken on linux itself with Swift 5.1. It's a simple fix though, and with a couple other tweaks for the lack of Bundle support, I was able to get the same test results on both linux x86_64 and Android aarch64, around 5 test failures, will probably submit a pull with those tweaks. Another package that had problems was swift-nio, which supposedly worked at some point for cross-compiling to Android, but will require some patching to build natively.

I have not tried building an Android app like the flowkey guys or writing much of anything myself with this new Swift toolchain on Android, so I can only report test results. Jeremy has another perspective just above.

I think it might be possible to set up a native Android CI now using the new Anbox Cloud service I mentioned in my post last month. I'll reach out to them and see how it works.

6 Likes

Arch Linux is a popular choice in Linux world, however getting Swift built and run is somewhat painful. I also want to use Swift on FreeBSD (or even on NetBSD) but *BSDs are quite unsupported platforms.

Arch Linux is a popular choice in Linux world, however getting Swift built and run is somewhat painful.

Have you built it lately? I've been building Swift master on Arch Linux x86_64 occasionally since last year, and while there used to be some tweaks needed back then, I haven't had to patch it at all lately. If you try master or the 5.2 branch, it should just work.

I also want to use Swift on FreeBSD (or even on NetBSD) but *BSDs are quite unsupported platforms.

There is some support and since Darwin/macOS and Android's Bionic libc use a lot of BSD code, I doubt it would take much to get the BSDs working.

1 Like

I wanted to confirm it but ran into a weird issue compiling compiler-rt with the latest 5.2 DEVELOPMENT branch (sanitizer_platform_limits_posix.cc:1131:1: error: 'assertion_failed__1131' declared as an array with a negative size). I will file a bug.
According to this post Swift on FreeBSD FreeBSD needs a helping hand, specifically porting Foundation stuff.

1 Like

The "array declared with a negative size" is an assertion failure. Something is incorrect about the configuration.

Can't tell you what went wrong. I've been using the same build enviroment for building Swift snapshots. Ticket for this issue is opened [SR-12224] Assertion error in sanitizer: declared as an array with a negative size · Issue #54650 · apple/swift · GitHub

I think Swift should really achieve its full capabilities if & only if it start cross-platform compilation just like Go and others, in Swift 6.
Any ideas on cross-platform compilation options :thinking::thinking::thinking:

1 Like

As I understand it, it is common in this forum not to give new answers to "old" topics as everyone involved in the old topic then gets a notification, but might not be interested any more. I would recommend to then create a new topic :wink:

Good support for Windows would be great of course. Not wanting to appear negative, but there is an issue that with C# you can develop applications for MS AppStore and >also< Apple AppStore. That is unhappily not true for Swift, because MS is more restrictive here than Apple and does not allow Swift applications to be uploaded to MS AppStore.

Besides that Ximian paved the way for C# on Linux and Apple. Some company would be needed that does for Swift what Ximian did for C#.

Can you provide a link that supports this please? I haven't seen this mentioned anywhere before. What exactly is the nature of the restriction?

1 Like

Can you provide a link that supports this please? I haven't seen this mentioned anywhere before. What exactly is the nature of the restriction?

Here is some link I found on the MS homepage. So some app for MS AppStore must be written in C or C++ or some .NET language. That's how I understand it and various places on the Internet I found other people saying the same. Wished I could provide better news ...

I don't think that the link you've provided is a "policy" requirement for apps published on Windows Store. It looks more like a guidance, as in "these are the languages that we recommend to use". There are apps written in Rust already published and available on the store. What would make Rust different from Swift in this perspective?

5 Likes

Probably just that Rust has UI frameworks for Windows and we don’t?

Can you provide a confirmation that apps written in Swift aren't allowed on Windows Store because of this? Or, just plainly, a confirmation that apps written in Swift aren't allowed at all?

What I'm seeing so far doesn't confirm either of those. Certainly "only apps written in C/C++ or .NET are allowed" is not true, as shown by that app written in Rust and staying published on the store.

Something to note: the article linked by @Haddock is from 2013, before Swift was open-sourced. It wouldn't have been able to evaluate Swift as something safe to put on the MS app store.