I just saw that @compnerd wrote an article last week about writing Swift on Windows, which I found when it was posted on lobste.rs earlier today.
7 Likes
Heh, this post already blew up on HN, which I didn't know since I don't read it, only rarely searching it for some topic I'm interested in. Looks like nobody has posted it to reddit yet.
@compnerd, have you considered submitting a post to the Swift blog about your and The Browser Company's current work, as I suggested earlier this year?
I think a Windows update post would do very well, @alexandersandberg, the Swift blog should be soliciting posts like this.
3 Likes
We do allow submissions from anyone who's interested in writing a blog post for the Swift.org blog, but we can definitely do more in terms of soliciting posts, as you mention.
I will bring it up with the SWWG. 
2 Likes
Just saw this video by Saleem's company talking about their Windows port using Swift, I like how they're openly talking about their work before it's released.
2 Likes
The Browser Company just uploaded another post on their Substack, this time about interfacing Swift with WinRT.
They've been doing a great job of blogging about their technical work, most tech blogs could learn from them, including the Swift blog. I'd love to see a blog post introducing your embedded work, @kubamracek, or a post demonstrating the new SDK bundles, @Max_Desiatov.
6 Likes
I just saw the news that the Arc browser on Windows 11 shipped, congrats to @compnerd, @Alex_L, @hjyamauchi, and others who have been upstreaming your resulting Swift toolchain patches. As the video says, this is probably by far the largest Swift codebase shipping on Windows now.
A question for the BC team, how much Swift code is in the just-shipped browser? Klocs of Swift versus C++ would be interesting, or just a percentage would suffice.
7 Likes
I would also like to congratulate the extraordinary work done by TBC team in carrying out the development of Swift applications on Windows.
In addition to the questions asked by @Finagolfin I would like to know in what proportion of the Swift business logic code was re-used from the macOS code? and the proportion of non-UI code that had to be written specifically for Windows.
To sum up, percentage of:
- C++
- Swift common with macOS
- Swift Windows-specific non-UI
- Swift Windows UI stuff
Concerning the Windows UI portion I am very intrigued in knowing the progress of an upcoming declarative level "SwiftWindowsUI" on the top of what is available now i.e. WinSDK, WinUI and Swift-WinRT.
The following video is very interesting about building Swift GUI app for Windows using TBC Swift components.
The next level to come being support for declarative development like SwiftUI. I'm eager to !!
2 Likes
I don't have exact numbers for you, but it depends on how you measure it. You could say 0% - there is the browser engine which is largely C/C++/Assembly, and that would likely dwarf everything with all the dependencies on the system. You could say ~100% - the entire shell is Swift with some C/C++ dependencies. You can portray the numbers in whatever way you like to make a point. Instead, I prefer to identify that the browser shell is entirely Swift, and the browser's functionality would not have been possible to build up at this pace without Swift, including the code and engineering sharing that it enables.
The majority of the business logic is shared code. We are using TCA, and that provides for a natural split between the business logic and UI logic. There were pieces which had to be rewritten as there were certain dependencies (e.g. SDWebImage), but they had to be rewritten as they are not purely portable Swift code.
There is some platform specific code that is not shared because there will always be platform differences and we want to integrate with those (e.g. the Windows notification center).
The Swift Windows UI "stuff" is mostly the WinUI bindings which are a separate project which we did open source. We built the shell on top of that, but that is akin to measuring AppKit or UIKit.
7 Likes
Thanks, another question I thought of: I see you've been upstreaming patches for Windows AArch64, how well is it working these days?
I ask because MS and Qualcomm plan a big push for Windows AArch64 this summer, so it would be great if Swift had a Windows AArch64 toolchain ready to go as that rolls out in the coming year.
1 Like
Windows ARM64 support is in fairly good state for the most part. While there’s no current official toolchain, there are snapshots that we are building at The Browser Company. There’s still some issues with tooling that have not been resolved, but it is usable for development and many deployment scenarios in my opinion. It is similar to the x86 story - it will require more effort and testing to truly get the desired polish.
3 Likes
This year-old blog post by a Meta engineer comparing Swift and Rust just blew up on HN and lobste.rs, starting long discussion of the two languages. He cites Saleem and TBC's work on Windows and the expansion to more platforms as a positive change.
3 Likes
i couldn’t help but notice the line
Swift is already a cross-platform, ABI-stable language
which is worded in a way that suggests Swift is ABI stable on non-Apple platforms, which is not true as far as i am aware. but other than that, it’s a great article and helps the language.
Apple has recently shown a willingness to get out of the way of cross-platform Swift, but I haven't yet seen evidence that they're throwing any significant weight behind it.
Dunno, I weigh a bit more than I should but I think I count. 
As an example, we are making improvements for Windows. A change just went in to fix a long standing bug in SwiftPM that held Windows build performance back. I'm looking for other ways to improve things there and for other platforms.
It's progress. But as always, this is an open source project, anyone can help.
12 Likes