Swift Tooling: Windows Edition
speakinginswift.substack.com
speakinginswift.substack.com
Though I haven't used Swift in production I have enjoyed its ergonomics in my tinkerings with it. So I'd be so glad if Swift is able to break out of its niche into broader usage.
Look no further than the Github repos for the general sentiment.
Well that was until late 2023. Then they realized nobody was writing pure Windows UI code in WinUI 3. (Probably because people were still playing catch up). So they have now have unofficially mothballed WinUI 3 and the new hotness is now MAUI - cross-platform UI! - in 2024. (But no Linux support ho-ho)
Not sure what it will be next year.
Imagine how many developers would just release to the App Store and re-release that on Android/etc to not need two codebase, and Apple would expand their 30% cut massively.
A lot of Android users would get apps from Apple’s store due to vetting/generally higher investment in App Store apps from major companies.
Apple is the iPhone company, everything else is just accessories.
The strategy Apple employed in not prioritizing C++ as a primary language, while also introducing Swift as a new language, is quite intriguing. It raises questions about the factors contributing to its success—whether it’s a result of the approach itself or despite it.
How common is it to need manual FTI bindings and if so, how hard is that? Reading https://www.swift.org/documentation/cxx-interop/ and https://forums.developer.apple.com/forums/thread/744361, I get the impression it’s fairly simple, if not often fully automated, and both Swift-to-C++ and C++-to-Swift calls look like normal calls in the respective languages.
> The strategy Apple employed in not prioritizing C++ as a primary language, while also introducing Swift as a new language, is quite intriguing.
They’re aiming to have good compatibility with existing C++ code, with all new code getting written in Swift.
AFAIK, the main factor contributing to the success of Swift in the Apple ecosystem is probably it being the replacement for Objective-C. Unlike C or C++, which required going through Objective-C or Objective-C++ to access the native platform libraries, Swift could access them directly.
That advantage does not exist on non-Apple platforms, which already have C or C++ as the most direct way to access the native platform libraries.
It's a shame, because Foundation.framework circa 1994 was a better standard library than any other language had at the time. Many have caught up since!
Swift has many virtues outside of SwiftUI -- real static typing, functional, sophisticated generics without all the gotchas of C++ templates, complete ABI, efficient exceptions, the syntax isn't so foreign to people used to C++/Java/Rust/Ruby/Python; I could go on and on.
I've written Objective-C code for 23ish years, and I like it a lot, but no one entering the workforce cares about its remaining virtues and the language has been mostly unchanged for almost two decades.
Also it’s a superset of C and C++ so you can mix all three in a single file, for better or worse.
But, in fairness, it’s a much simpler language than Swift. Which can also be a virtue.
Also Objective-C had comparably miniscule community effort in open source, the Swift on Server community is humming along, active, and businesses are using it on Linux. It's only grown in popularity... not sure Objective-C ever saw any amount of growth outside of Apple's platforms!
Secondly, yes Swift is quite relevant on Apple platforms, and that is exactly why the only ones that really care about using Swift on Linux, are mostly Apple shops writing the server side of their iDevice apps, since Apple killed OS X Server, leaving Linux distributions as the only option for server side.
This on Windows is kind of nice that it exists, but I doubt it will ever take off beyond what the folks at the Arc browser are doing.
The language is great, however the whole ecosystem speaks Apple Frameworks.
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)
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.
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 are way beyond C# 1.0 nowadays, and Valhala is still not here.
Both went with more Smalltalk and less Modula-3, even though they acknowledge influence of those languages, among others.
(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)
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.
>"Saleem Abdulrasool is the release manager for the Windows platform (@compnerd), is a prolific contributor to the Swift project and the primary instigator behind the port of Swift to Windows." Saleem's github, https://github.com/compnerd, lists swift-win32 repo, which is a "a thin wrapper over the Win32 APIs for graphics on Windows." So it's one person wrapping Win32. Not too promising yet, but it's early and there's room for Windows programmers to get involved.
Amazing work by Saleem and the team at The Browser Company to devote years to this and make it a success.
which is seemingly what the user above was talking about! I think
Windows still commands about three-quarters of desktop OS market share. If you want to leave a lot of money on the table by not targeting/developing for Windows, I suppose then there's no benefit. Not even mentioning that Windows unironically is a decent platform to develop on and develop for.
Windows also has the advantage (shared with Linux) of working on a very wide variety of desktop/laptop/workstation/server/etc hardware models from many independent vendors, while macOS is restricted to only a small number of hardware models from a single vendor.
support of cmake of swift seems good path for interop cpp(build it and codegen).
csharp did not have ideal story there.
Microsoft and Google each have languages/ecosystems with larger developer share (Google at over 6% for Dart, and Microsoft at over 27% for C#).
[1] https://survey.stackoverflow.co/2023/#technology-most-popula...
> It would be a completely new source of developers for these platforms.
I have no idea who you're referring to here. Who are the developers that are locked-in to iOS/MacOS but would consider ChromeOS or Windows if it supported Swift better? I cannot think of a single person I know that fills that bill. If anything it's the other way around, where people end up switching away because they don't have any use for Swift/AppleScript.
Opposite is not true though, there are lots of troubles you have to go through to have Swift on Android/Windows.
Very often, especially in startups, when the new app is created, it is first created for iOS and then for Android. Having proper Swift support would reduce effort for bringing apps to Android/Windows.
Apple doesn't really care about Swift outside their wallet garden. How dare other companies refrain from investing in such a wonderful creation!
Investing in Swift would to an extent canibalize Go, Dart/Flutter, TypeScript, C#. You know, the technologies which have creators that actually care and invest billions in cross-platform development.
Not to mention fragmentation.
Apple doesn't even care about Linux running in their own hardware. Their contribution towards that goal ranges from hostile to scraps, depending on who you ask.
In fact, they don't even have to do that much for Swift. They don't have to develop neither the language nor the compiler.
They need to do similar to what The Browser Company did, exposing and allowing usage of their APIs from Swift, and maintain it as their API evolves.
If The Browser Company could afford it, while developing the browser, Google and Microsoft can afford it as well.
If The Browser Company could afford it, 3 trillion USD market cap Apple can afford it as well.
Commoditizing your own product is never in a company's best interest so don't expect it to happen willingly.
Yes it can. It's just Apple can't be bothered - most of the work to do that doesn't benefit Apple - it does benefit the Swift ecosystem and community of devs, but not Apple - the venn diagram of Apple vs the Swift dev community overlaps but doesn't completely close.
Swift came out in 2014 - Windows support for the compiler came out in 2020. That's it. They haven't bothered to upgrade the tooling support in VSCode or any other app because most VSCode users aren't Apple devs. The ball is literally in Apple's court - no one elses.
Plus, honestly, moving from swift to kotlin or even dotnet is marginal. The problem is getting into the qwirks of the underlying frameworks like swiftui, the ios sdk, the android sdk, and the conventions of these platforms. Language itself is relatively marginal in that. So really I don't see the value in what you're claiming.
The future is not that far off where you can write a 100% native Android app and, minus any Android OS-specific functionality, port it over as-is to iOS and desktop.
I mean, this is just absurd logic. How is the lack of Swift support on non-Apple platforms somehow up to Google or Microsoft? The burden to support more platforms is on the language developer, not the platform dev.
I wouldn’t assume that any iOS engineer would be jumping all over the opportunity to make Android or Windows apps just because they can do it with Swift. They have their (typically pretty lucrative!) niche and are happy living in it.
AppKit is still dominant on macOS (despite the addition of Catalyst), UIKit is the chief framework on iOS/iPadOS/tvOS/visionOS, SwiftUI is native on watchOS and mostly wraps AppKit/UIKit on the other platforms. macOS is oriented around KB+mouse usage, iOS/iPadOS/watchOS are touch-dominant, tvOS is made to be remote-friendly, and visionOS is oriented around eye navigation and hand gestures.
Apple claimed they were running OSX back at the iPhone launch, but it was truly very stripped down to accommodate the underpowered hardware, and they've only made incremental, very targeted expansions in the last 16 years.