Gotta hand it to The Browser Company for doing so much for Swift lang.
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.
WinRT was abandoned by Microsoft. They said the new hotness is now WinUI 3.
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)
I hope Microsoft would settle for one UI library instead of pushing a new one every five years. WinUI 3 is their most recent invention. Application developers can't keep up with the changing standards.
With all the mismanagement around WinRT, only the Windows team themselves and companies with sunken cost into UWP looking into a migration path, still care about WinUI 3.
Look no further than the Github repos for the general sentiment.
A properly motivated Apple would have been pushing cross platform Swift/SwiftUI and launched an App Store on both Android and Windows.
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.
Nope - that would be a massive undertaking. Someone tried reimplementing SwiftUI but it was abandoned quickly after realising how much work it would entail: https://github.com/Cosmo/OpenSwiftUI
What potential roles could Swift fulfill within the Windows ecosystem? Is there a specific segment they aim to serve? One might inquire about the feasibility of developing GUI applications using Swift on Windows, particularly regarding the necessity for manual FFI bindings, given the current state of Windows-specific tooling which is largely GUI-centric.
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.
> It raises questions about the factors contributing to its success—whether it’s a result of the approach itself or despite it.
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.
> One might inquire about the feasibility of developing GUI applications using Swift on Windows, particularly regarding the necessity for manual FFI bindings,
Swift was a play by Apple to make application developers (and I suppose their own internal developers) more productive. Swift absolutely became successful because it had a strong reason for developers to learn it. That said, it probably also made Apple more successful in some way as well as you cannot undercut the value of productivity.
Looking at the application landscape (and quality) in the early years of Mac OS X with Objective-C and later on with Swift, I‘m not so sure about that. Even worse when you look at Cocoa vs SwiftUI.
It seems like a better fit for high-end apps that want to adopt the native framework for Windows and macOS. Developers of these apps will often accept some of the quirks with manual bindings to get the performance they need while trying to maximize code sharing and minimizing divergence for as much of the shared code as possible. This is not going to be accepted by most developers on the Windows platform, but they seem out of sorts with their current options anyway.
On this WWDC '24 it will be 10th anniversary of Swift. Great milestone for language. There is so much work going on improving it. However From outside it does look like it still is few years away from being general purpose outside Apple ecosystem.
This isn't the first Swift implementation ported to Windows. RemObjects Silver has had swift on windows (as in, develop and build/run on Windows) for at least a few years now, though it's not open source. https://www.remobjects.com/elements/silver/everywhere/
Perhaps more importantly for many, it's not free, either. RemObjects does some very interesting stuff, but $1K for a single developer license is rather insane in the current dev tooling market.
Opinionation Incoming! Objective-C is completely irrelevant outside of Apple because Interface Builder was the killer app for Objective-C and there was never a version that worked well with anything except AppKit -- even UIKit has always been painful to use with it. iOS developers had to tolerate Objective-C, but no one else bothered.
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.
Not OP, but it compiles orders of magnitude quicker than Swift. It also doesn’t tend to grind Xcode to a halt as the language server tries to work out what’s going on.
But, in fairness, it’s a much simpler language than Swift. Which can also be a virtue.
If you need to be nitpicky about squeezing every last bit of performance out, then Objective-C is still useful, especially given you can just drop down to C in the same source files. I've become a big "C is bad and C lovers should feel bad" guy in recent years, but I can't ignore the "simplicity" (for some experience level definiton of simplicity) and speed of the old tools.
You'd consider wrong. Given iOS and macOS are exponentially more popular than when Objective-C was the primary language for both OSX/iOS, Swift is far more relevant than Objective-C ever was.
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!
First of all, Objective-C was opensourced during NeXT days, that is also when GNUStep effort started. Steve Jobs famously wasn't that happy about the GCC license forcing NeXT to do so, years before Apple came into play.
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.
Swift is a nice language. But unfortunately it heavily overlaps with C# making it difficult to justify picking the former anywhere besides macOS application development.
It's not a good idea to take Miguel's criticism of .NET seriously in the last couple of years, after the falling out. Give it more years and we might just hear the similar style of statements towards Swift and Apple's ecosystem now that he is promoting it.
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)
I don’t know what happened but these days Miguel does seem very salty about w/e happened at his time at MS. Like you, I would take what he says with a grain of salt.
Basically after Xamarin got acquired, Xamarin.Forms got rewritten into MAUI, Mono Develop was killed in name of VSCode (after existing for a while as VS4Mac) with no comparable tooling, Mono only exists as runtime for iDevices/Android/Blazor, Mono linker got repurposed as Native AOT trimming, most of the Mono BCL was merged with .NET Core efforts.
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.
His enthusiasm for SwiftUI in particular is a bit hard to reconcile with my experience using it. It's nice on the happy path but you very easily stray into areas with baffling compiler errors and terrible UI performance.
Swift does not require a GC, which in some cases can be desirable.
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're way beyond it, but they are still stuck with some of the unfortunate early decisions for back-compat reasons. E.g. the fact that strings, arrays, and other collections are strictly reference types, or that arrays in particular are covariant despite being mutable. Swift is much more consistent in that things that are semantically values are also value types.
In that regard, given the set of gc enabled systems languages that predated both of them, I consider both had quite a few unfortunate decisions, exactly regarding value types, low level coding, and AOT compilation.
Both went with more Smalltalk and less Modula-3, even though they acknowledge influence of those languages, among others.
Collections aren't strictly reference types and with ref structs in generics feature you will be able to write a LINQ-style abstraction on top of Span<T> (though lifetime restriction still apply).
(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)
All standard BCL collections (List, Dictionary etc) are reference types. Some associated machinery like enumerators are value types, but that's beside the point here, which is that by default you end up with shared data rather than a (safer) copy. This also means that whenever you return an owned collection you either have to manually copy or wrap it in a readonly proxy to avoid accidental mutation of internal state by the caller.
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.
You can run C# on almost any device and you can do backed, front-end, desktop, games, utilities and whatnot using it. I think Swift has a lower appeal being tied to iDevices.
>"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.
Is that how they are handling any of the Swift UI work for Arc (their browser)? I think they are 100% focused on bringing the Swift compiler etc. over and leaving all UX to the Windows UI (WinUI lib?) so that they have a native experience on macOS and Windows.
You have Swift-NIO for cross platform form networking, OpenCombine as an open source implementation of Combine, and I’m not sure what you mean by file system but you can read/write files without needing any library other than the cross platform Foundation implementation
> I guess I don’t see the benefit of using Windows for anything.
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 still commands about three-quarters of desktop OS market share.
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.
I've worked with Xcode for ~2 years of professional work spread across ~10 years of other work, and honestly, I don't fully get the criticism.
It's not great, but for an IDE (not a text-editor with plugins), I've always found it miles better than the Intellij suite. I preferred Visual Studio when I was working on Windows, but that's a much bigger project, so perhaps not a fully fair comparison.
Xcode from ~2021 onwards, with Swift package support, has been a significant improvement too. Now you can avoid much of the IDE configuration and just work with source code more, something I prefer. There was also a period of a few years where it crashed all the time (Swift 1-4?) but those days seem to be long gone now.
The source control integration has always sucked and I steer clear, but I was always doing the same in Intellij/etc or Visual Studio anyway.
Perhaps today VSCode is sufficiently IDE-like with enough packages, and perhaps it's fast enough, but I still feel like there's a difference, and even though I can do Swift in it I prefer to use Xcode. Changing Xcode's shortcuts to something more reasonable made a huge usability difference too.
I'm interested to hear what you think is so terrible about Xcode. Perhaps I'm missing something!
To me the thing is that there is usually a major problem of some sort with Xcode and it can take up to a year to resolve (when they release the next major version). For example in Xcode 14.1 there was a bug that would make it crash when trying to open a project. It would crash over and over and over until it finally opened. That was finally fixed in 14.3. 15 was great then with 15.3 a bug was introduced where any time you change branches the package cache became invalidated and you had to close Xcode and reopen it. Of course it’s still not fixed in 15.4. 16 might be solid but I can guarantee some extremely annoying bug will be introduced in a point update and won’t be fixed until the next major. It has been this way since I started using Xcode 9.
I’d rather deal with a slow and cumbersome IDE than one that moves things around with every major update and introduces major bugs that don’t get addressed in in a timely manner because the IDE updates are tied to iOS releases for some god forsaken reason.
I was a fan of AppCode until JetBrains dropped it.
Having worked with it since it was still known as Project Builder I think it’s fine too. The only part that’s really bad is the XIB/storyboard editor, which was actually pretty good when it was its own independent program (Interface Builder) but has been awful ever since it got merged into Xcode. That’s easy enough to avoid though, with UIKit being pleasant and practical to write in pure code, as I’ve been doing for the past several years.
Beyond that, there are some things that can make SourceKit (provider of syntax coloration, autocomplete, etc) grumpy, but those are almost all code smells that should be avoided anyway like pyramids of doom built of closures or way-too-long optional chains.
The GUI building was always pretty bad, true. I managed to skip most of that and either did UIKit mostly via code, or more recently SwiftUI (which is mostly pretty good) and server-side stuff.
I think SourceKit was the source of many crashes a few years ago, more recently it seems to have transitioned to fewer crashes and more cases where it just gets "grumpy" as you said, and in the last few years I've even found most of those cases have ceased.
Yeah things have been pretty smooth in recent years, especially after being able to drop CocoaPods in favor of Swift Package Manager. On average I find myself “fighting” the IntelliJ-based Android Studio more frequently than I do Xcode.
Xcode's UI is miles better than the IntelliJ suite, or any other IDE I've used, but functionally it's a decade behind them, especially with Swift. Its autocomplete is extremely basic, its debugger barely works with Swift, and its refactoring system is very limited. It doesn't really support plugins, so the community can no longer patch these holes.
It scales poorly, shitting itself every time you open files larger than a megabyte (DB dumps as JSON hang it).
Xcode 15.3/15.4 shipped a really stupid bug where, when it detects certain changes to the file system, it just deletes the Package.resolved file, breaking your build. So you have to close the project just to do a git pull.
Speaking of closing, its overall launch and opening performance is very poor. Opening old style storyboards can hang the UI for multiple seconds. It abuses the main queue like none other.
Its UI can't handle large scale testing. It even added support for repeated tests in the UI, but viewing the results of thousands of test runs hangs the UI. When I do my manual test repetitions in the millions, I can wait literal minutes for the UI to render the result list. And I have to do those million test runs manually because the support they added for repeating tests in the UI run much more slowly its magnitudes slower.
Its syntax highlighting, like much of its tooling, breaks constantly, and yet is extremely inflexible. It has no customizable formatting capability, nor a Swift formatter or linter built in. It can't format on save, nor does it have any configuration available there.
Did I mention it has no real extensibility? Years ago there was a thriving third party plugin ecosystem, with a plugin manager called Alcatraz. It could manage plugins, snippets, editor themes, and project blueprints, all from within Xcode. Apple killed it by locking down the plugin API it used and replaced it with APIs that are a tenth as capable, barely work, and haven't been touched since.
So what's so terrible about Xcode? It's a death by a thousand paper cuts (and the occasional missing finger).
The plugin system was literally an internship project, and in that context putting together a working proof of concept for out-of-process plugins which can perform simple tasks is a great success. They just never bothering scheduling anyone to work on making the other 90% of a useful plugin API, which makes me wonder if they even realized that they shipped a basic prototype as a headline feature.
>Xcode 15.3/15.4 shipped a really stupid bug where, when it detects certain changes to the file system, it just deletes the Package.resolved file, breaking your build. So you have to close the project just to do a git pull.
Oh, so that's why my builds have broken from time to time and have required me to use File → Packages → Resolve Package Versions to fix it.
The broken debugger and language server issues strongly suggest type inference problems in your project. Load a core dump into lldb manually without Xcode to verify.
You can fix this by fewer chained calls to high-order functions or explicitly declaring returned variable types. Whatever it takes to reduce the search space to resolve your types.
> Xcode's UI is miles better than the IntelliJ suite, or any other IDE I've used, but functionally it's a decade behind them
Their live preview when you're building a swiftui, apart from that I'm not sure what's better in their UI. Managing windows is clunkier, the rest is very standard ide stuff?
It's not that Xcode's UI is great, it's just that the others are so bad. Xcode usually stays away from the unlabeled button mess that IntelliJ IDEs have become and is overall more Mac native. Of course, some of that is that it's lacking the features that drive complexity in other IDEs, so it's entirely possible it would be worse if it was more full featured.
One really embarrassing problem of Xcode is cold start time. It takes around 15..20 seconds on my M1 MBP for Xcode to start into a project. Followup starts are faster (about 3..5 seconds), but come on, on such a machine it should start instantly, and it's a really bad look when a "bloated Electron app" like VSCode starts in a second.
The next problem is that some important areas seem to be abandondend. For instance the debugger variable view panel is so extremely bare bones compared to a "proper" IDE to be hardly usable, and nothing has been done about in at least a decade.
Next we have that weird 'scheme model' for setting build target options. No idea how any software engineer could come up with such an awkward and unintuitive system when there have been plenty of examples around how to do it better when Xcode was created.
Hadn't heard about this either. Chris claims he left the Swift language committee because of toxic behavior claiming he got yelled at on a conference call.
Very impressive, when TBC said they were implementing their app in swift for Windows I wrote it off as vaporware that would never ship, as the goal seemed too audacious and unnecessary, but they did it and continued to push forward!
Just curious, how is Swift as a language in 2024? What are the interesting developments, shortcomings? How does that compare to modern C# and Kotlin for example?
I’m likely biased since I’ve been writing Swift for about twice as long as I’ve been writing Kotlin, but between the two I prefer Swift by a good margin. In comparison it feels less idiosyncratic/fussy and more flexible/ergonomic, and it’s nice not having to contend with the likes of Gradle and Proguard.
I feel like Swift is a big miss from Google/Microsoft.
If they supported Swift on their systems (properly supported), they would immediately open up their platforms to lots of Swift developers, and I think the benefit would be more than they would need to invest into supporting Swift.
It's not a zero-sum game, they don't have to reduce support for other languages.
It would be a completely new source of developers for these platforms. Better 1% than 0%, and I would say that effort for that would not outweigh the possible benefits and income from new devs/apps.
It's not Microsoft and Google's job to write Apple's software for them. It's like complaining that Apple doesn't write a good Dotnet runtime; of course they don't. It's not their job, and they don't want to anyways.
> 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.
Is that survey actually scientific? I have been doing Ruby and Swift for years and never completed that survey. That survey is of reasonably active users to Stack Overflow — there is a selection bias. There isn’t a lot of great Swift content on SO, so that’s going to attract fewer developers to answer the survey.
Those languages are already well supported on Apple platforms from the language makers themselves, there is not much Apple can do to "support them" better.
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.
We've had Kotlin Multiplatform for a while now, so a developer writing an Android app in Kotlin could bring it over to iOS and desktop platforms today with reduced effort. Compose Multiplatform aims to take this a step further by allowing UI code sharing instead of just business logic.
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.
"open themselves to have more developers supporting theirs?" -- Thats exactly what is missing from Google/Microsoft.
Apple is already supporting Swift on other platforms, however, developer experience is not as good as on macOS and I don't think that can/will be solved by Apple.
It is exactly where other players missing out, by making their dev experience as good or better, they could help developers write apps for their platforms.
> Apple is already supporting Swift on other platforms, however, developer experience is not as good as on macOS and I don't think that can/will be solved by Apple
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.
.net and kotlin work on Mac. Why would MS or Google subjugate themselves to an ecosystem driven by Apple?
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.
If anything they care about keeping it inside their wall. Just think, if Swift apps were a button click away from running on Android. Suddenly the best iOS apps become multi platform at no additional effort, dependence on Apple becomes a little less.
It's not about Apple. Google/MS would invest for their own sake, so that it would translate into more apps (earlier, not as a second class citizen) on their platform, which in the end would bring money as well.
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.
For an Apple\Google owned ecosystem it is. If leaving the walled garden is a button click away, what app would be Apple or Google exclusive? Suddenly an iPhone Owner's favorite apps are on the other platform too, so when upgrade time rolls around why buy an iPhone (and vice versa for Android)?
Commoditizing your own product is never in a company's best interest so don't expect it to happen willingly.
> 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.
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.
There are very few “Swift developers” out there. Much more common are “iOS developers who write in Swift”.
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.
They don't have to jump though, many iOS developers also do watchOS/macOS apps but they are still "iOS developers".
If they can bring one more platform under their belt with little effort, I would say that many of them would consider 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.
macOS is far more complex and flexible than the iOS family of OSes (which are really all just iOS, including iPadOS).
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.
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.