Interesting proposal though it does sound a bit too general. “Improve cross compilation”… current Swift tools are barely keeping it together for the “happy path” of building for Apple devices (it’s not that happy). It would be cool to expand into wasm/wasi as long as it doesn’t come at the expense of other desperately needed improvements.
Rust, Go and others have been building WASM 0.2 support for many years, they currently have a “just works” support for WASI. It would be a long time until Swift is even remotely ready for something like this and I don’t feel there is a burning need to have “yet another wasm platform”.
> Rust, Go and others have been building WASM 0.2 support for many years, they currently have a “just works” support...
Can confirm. I was pretty stubborn and wanted to use Go to build a UI in a webview/webview using local app, but oh my, js.Value in Go is so much pain to deal with. A lot of things in the JS world don't integrate nicely with Go as a language (e.g. the difference of Go channels and JS Promises, or magical enum values _and_ URL patterns on the same properties like in the Fetch API)
Long story short, I am now around 3 months into building a WebASM bindings and components framework, and it's still a lot of work until I am on the functionality level of TSX files. [1] All those Web/DOM/Browser APIs are kinda hard to integrate into the Go world, especially if you're as stubborn as me and want to have a real typed bindings API that uses Go's native data types.
> current Swift tools are barely keeping it together for the “happy path” of building for Apple devices (it’s not that happy)
I agree, but I'm telling myself this is only a temporary pain caused by the changes for supporting Swift 6 language mode. Are you talking about something else?
Temporary but measured in years and forced on every Swift dev out there … hard to dismiss.
My comment was not about that though, I was more thinking about the super slow build times, unreliable SPM with strange limitations, Xcode still shows errors while reporting a successful build, Previews not previewing, etc.
Is this still a thing in Swift? I loved Swift 1, spent a couple of days upgrading to Swift 2, a week or more for Swift 3. At that point I just switched to React Native. I understand that iterating is generally a good thing, but the constant cykle breaking changes in the language was just too much.
It's now almost a full year since Swift 6 (concurrency) was introduced, and I've spent a lot of time rewriting, debugging and generally tweaking things to make the compiler happy... The promise of "strict concurrency" is yet to yield any meaningful benefit, despite the huge cost of having it.
I think the pursuit of some kind of semantic purity in the Swift language overshadows more practical needs and concerns. Making Swift too different from its neighbours like Kotlin and Rust also makes it harder to context switch. It now takes a lot more time and effort to get into the flow of developing native things for iOS...
Disagree about the academics point but Async Algorithms is basically an abandoned project at this point. There is someone working on it but the intention is that it evolves basically at the pace that the language does, but without the investment that the language gets. I would recommend against relying on anything going on there.
Between a dead Combine that no longer functions in Swift 6 or a severely handicapped AsyncSequence lacking basic features, where are developers supposed to turn to?
All these projects like Async Algorithms, AsyncExtensions, Asynchrone, etc. are being born out of necessity.
Deprecating Combine would be less of a problem if Sendable wasn’t a hard requirement but it is.
No, I'm talking about the latter. Combine is truly dead but the other repo is mired in an inability to make real changes, because that requires significant review effort, which is not really there. So it's just bugfixes and small tweaks.
Let's not forget the absurd insistence on "will change" semantics in onChange() instead of the far-more-useful notification "did change."
And of course the brain-dead design of withObservationTracking, which only fires on the FIRST change of a value. I mean... by what definition is that "tracking?" It's goddamned useless, unless of course you implement the clumsy workaround of re-establishing observation tracking every (first) time it fires.
Then there's the bizarre hypocrisy of evangelizing the "single source of truth" while telling everyone to prefer structs over classes in Swift. But structs are COPIED everywhere, which of course breaks the "single source of truth" on the first function call.
I wasted so much time trying to conform to these "best practices" until I finally realized that the people promoting them don't know WTF they're doing. Then I went back to classes, injected the "single source" everywhere it was needed, and got to work adding functionality.
And let's not even get into the half-assery that is SwiftUI... still, all these years later.
For context, I was saying that same thing in 2017*, because it seemed obvious, especialy given the elite consensus was it was obvious SwiftUI was being introduced to allow full cross platform development, including web.
In retrospect, I was starstruck by the people I learned programming from, and Apple Neue funds software engineering, especially developer tooling, to the point it is not actively harmful, as opposed to not painful, and very opposed to not-harmful-and-not-painful-on-not-our-platforms.
* Of course, not for Swift 6 Language Mode™, the thing is, there's always been a Huge Project that's launching, but not landing...
I'm not comfy calling out specific names, but the sort of luminary who would have been featured on Daring Fireball over the years proposed this and took umbrage to this being pointed out at the time.
I can think of 2 off the top of my head who specifically did this, one who went on about it until they saw SwiftUI x macOS 1.0 and that became their new drum to beat on. (i.e. the quality was low)
> It would be a long time until Swift is even remotely ready for something like this and I don’t feel there is a burning need to have “yet another wasm platform”.
I mean, well, it actually already exists? It's been around for a long time and works pretty great, with multithreading, access to JS objects, etc. The author of the linked thread topic is the original author of it.
I think that’s WASI Preview 1 that’s currently supported by swiftwasm (and I don’t think the spec implementation is even complete), not the current WASI 0.2. Preview 1 was the current status quo about 2 years ago.
Writing WASM in Swift so it can only be run by a Swift runtime also misses out on a huge aspect of that “bring your language” approach to wasm. It should support enough of the spec so a current wasm binary compiled from say Go can be executed in a WASI runtime powered by Swift and vis-versa. It’s a long way to get there.
Why are they framing it as a proposal if it's done? (if this comes across as Socratic, it is unintentional, I genuinely don't understand why the author would be posting a proposal when it is done)
EDIT: My naive reading of https://github.com/swiftwasm/swift/issues is there's a lot, lot, to go. TL;DR: open from 2021, stdio FILE not available in WASILibc. Long version, filed in 2020 and open: "Pointers needed on WASILibc", "Make the toolchain work without Xcode installed", "Enable libdispatch or provide stubs for it", 2022 "canImport(Dispatch) is wrongly truthy on WASI target", "wasm lacks signal support" (broke/regression in Sept. 2024, still open)
Ignore the haters—Swift is an enjoyable and productive language that gives you a lot of advanced features if you want them, but lets you ignore them and almost treat it like a scripting language. Adding first-class wasm support could help it become a more reasonable choice for development outside the Apple platform.
My only fear with Swift is Apple. The language itself seems largely fine, very interesting even, which makes me feel deeply conflicted.
While Apple has been big on pushing multi-platform Swift right now and distancing itself a bit from the Swift branding in some ways (e.g. it having its own GitHub organization) they've historically had quite an ebb and flow to this behavior. If their priorities changed, what happens to the non-Apple projects that adopted Swift? It would be better if there were multiple parties that had stake and some control in the future of Swift.
I have similar worries with Microsoft and .NET, although it's a bit different owing to the fact that Microsoft is quite a different company with different problems.
It's actually kind of bizarre that it never really felt like Google was a problem for Go, but I guess that's because unlike Apple Swift and Microsoft .NET, Go mostly targets and is almost entirely developed on platforms that Google has little control over. (Though that doesn't mean that their presence is entirely unnoticed, but even stuff like the module proxy has been more well-received than expected. It's an odd area where Google has managed to maintain some goodwill, though it could evaporate over night.)
While the efforts are laudable, it remains to be seen where it will stand against regular Python and Julia, that actually have support from card vendors directly.
I think you hit the nail on the head. By extending Go to many platforms, it doesn't feel like you're using a corporate-sponsored language (though you are). The Swift team is aware that they need to help the language thrive in other contexts, which is why they're working on projects like Embedded Swift [0]. I hope they fully embrace wasm as well!
Not sure if you're aware or not but .NET these days can (officially) target pretty much anything - not just Windows. Usage on Linux definitely picked up vs. Windows because Linux servers are cheaper. Android/iOS is there. WebAssembly is also there.
Kind of, still misses a few platforms that have had JVM support outside mainstream computing, but yeah mostly great experience for target platforms.
The IDE story is a bit complicated though, either you go for Rider, or have to delve into the internal politics of VSCode vs VS, and features that VSCode will never get because there are those VS licenses to sell.
Rust, Go, and Swift were all coming up around the same time. Rust looked ugly, Go underwhelmed me, and Swift aeemed like the best “language” at the time, with many opinions that aligned with my own.
Having now spent time in all three, swift feels the most ergonomic and has features that make me feel productive. I still feel like there isn’t much “there” in Go, and rust makes me feel like I’m solving for the compiler rather than working on whatever problem I was needing to work on.
Edit to add: SwiftUI, however, is a mess that I loathe. I may be in the minority of enjoying the IoC choices in Interface Builder and AppKit.
SwiftUI is just amazing for the first 30 minutes you use it... then you make a minor syntax error deep in some nested views and you're selectively commenting out coded blocks to hone in on the error like a caveman.
It makes print-statement debugging look cutting edge.
As an early adopter of SwiftUI, this hasn't been my experience—but I understand that a lot of people struggle with it. I think it's pretty opinionated, and if you stick to the "preferred" way of doing things, life is easier.
The biggest (and known) issue with SwiftUI is the complex error messages you get, and the fact that the type checker will give up and ask you to break up your view into "distinct sub-expressions." Really the issue is almost never the complexity of a view, but some simple syntax error (passing the wrong type to a function, etc).
Yeah. My understanding is the design of type inference is flawed and requires exponential complexity to resolve and it’s not fixable without breaking change.
Why this is not a top priority before literally anything else?
Yeah. I have a bunch of code with bog-standard linear algebra classes (vec2, vec3, mat2, ...). No generics, no nothing. Just simple classes with operator overloading.
After the recent minor XCode upgrade, Swift can't deduce the type for an expression `((v2 * scalar1) * v3)`, I have to split `let tmp1=v2*scalar1` for it to work.
As a user, I couldn’t care less about the algorithmic beauty of the type system if it works, lets me type complex things reliably, and is fast enough to stay out of my way. Does it do that by being a mess of duct table and plywood? Totally fine for me.
And yet TypeScript doesn't fail with a cryptic nonsensical error just because you have the impossible component with an unfathomable number of two nested lists, like in SwiftUI.
No, I'm saying it has a worse system than Swift's. The point I'm making is that they've designed things such that the normal case doesn't hit this, while Swift keeps adding APIs that exercise the worst of their type system.
It doesn't even have to be deep. I ran into this issue on very few quite simple components. The compiler just gives up because somehow swift's type system makes it impossible to figure out
This problem is very real. There is at least an ok way to avoid it getting too bad: make lots of View and ViewModifier structs, with each one having smallish amounts of code. Split them up to the extent that it feels silly.
As an added bonus, this is also the way to get good performance at run time. It helps minimize how many views need to get re-evaluated when something changes.
I agree about SwiftUI. It's something I want to like, but everything about it… no.
For me, SwiftUI does exactly two things better than UIKit: tables and collection views. For everything else, it's so much easier to get stuff done with UIKit*, regardless of if I'm working with Interface Builder or making UI in code (as per various projects I've dropped into).
In theory, reactive UI is good. In practice, at least in the case of SwiftUI, the "magic" data passing does sometimes fail — perhaps someone put in the wrong @ on the property — and then you've got to debug some weird magic, and if there's a sensible place to put a breakpoint for that kind of problem I have yet to learn it.
In theory, the UI is reusable across all Apple platforms. In practice, the nature of the user experience is so different that actually trying this makes it suck for everyone — you don't want finger-sized buttons on a mouse-driven UI or tiny mouse-suitable click areas for a mobile UI, and I have no idea what the user expectations are for tvOS or WatchOS despite having written apps for both because hardly anyone shares their experiences and lessons learned.
In theory, having the code be the source of truth for the WYSIWYG editor is great. In practice, the WYSIWYG editor keeps giving up because of e.g. a compiler error, and decides to stop forever until you manually resume the preview.
* I'm mostly on iOS rather than macOS, but I'd assume UIKit and AppKit have the same strengths and weaknesses.
Even outside of iOS I’m not fully convinced that declarative/reactive is “the way”. Jetpack Compose while not as bad as SwiftUI in some ways shares many of its problems, including the magic, inscrutable stack traces, and challenges in reasoning. Past a certain level of complexity imperative UI feels more manageable.
> In theory, the UI is reusable across all Apple platforms.
This is the practice (when people are lazy). The theory that Apple presented was that you are supposed to tweak your UI for each platform and share some of the common code.
This is more or less how I feel too. Writing Swift feels good, and once you make a habit of avoiding code smells that trip up SourceKit, syntax coloration and all that works well enough too. SwiftUI on the other hand gets to be a mess for anything larger than small components and collection view cells.
And so I write pure code UIKit most of the time. It’s not trendy but it’s very effective.
Wow, thanks for saying this. I had no idea it was even usable outside the Apple ecosystem. Seems like other IDEs support it too (https://www.swift.org/tools/).
I think for right now, you'd have to use the C interop and link against something like GTK or other GUI library. I don't think SwiftUI specifically would ever work well cross-platform, it has so many Apple-isms.
There's also Swift/Win32, but it's MVC. You could also use the interop and use QT as well.
I don't think any of those are necessarily good solutions, but they are there.
What sort of things are you referring to when you say "Apple-isms"? Not that I doubt your claim -- I just don't do much UI development so I don't have a good reference for what things might be 'platform specific' in that way.
Yes there’s nothing all in one yet. But these are promising directions. Tokamak isn’t abandoned, members are involved in core Swift changes that it depends on and have made progress recently with embedded Swift.
As with other languages, you’d need bindings to another UI framework. In that sense, I wish SwiftUI had a different name because it seems intrinsic to Swift when it’s really no different than UIKit.
There’s stuff like SwiftCrossUI that does multiple backend bindings
Like Flutter, this paints everything itself. It doesn’t need to bind to a UI framework directly. Instead, it needs the platform to provide primitives like a surface to draw into and input events.
The direct competitor to Swift is most likely Kotlin and I bet it'll win out as a cross platform solution of choice in a couple of years as KMP stabilizes.
It absolutely is and its a pleasant language to work with. Although it is in a kinda-symbiotic relationship with Flutter, I've found myself using it for small scripts and cli tools instead of Python because of its strong+static typing with null safety.
Relevant to the topic, Dart (and Flutter) supports targeting wasm.
Either as shebang/interpreted script, or just compile to a binary for great startup speed. I actually only recently found out you could use swift for scripting. Turns out, you can also access all the other Apple APIs :-)
#!/usr/bin/env swift
I made this small "shebang thing runner script" that either runs your script interpreted, or compiles and executes it. Depending on if you're on a TTY or not. I'm also changing it to simply check for the number of executions since last modified, and then compile. In some cases the extra time is well appreciated. You still get the convenience of interpreting, but also the performance of native.
It's basically a drop-in replacement:
#/path/to/autocompile_or_interpret_swift
Very noticeable difference.
real 0m0.212s user 0m0.159s sys 0m0.045s
vs
real 0m0.014s user 0m0.004s sys 0m0.008s
Ha, nice! I've used the Swift shebang before, but honestly once you have something that works as a "script," it's so easy to convert it to a real command line utility via Swift Argument Parser [0] that I usually spend the 5 minutes to wrap it up.
It's kind of nice to be able to access all native libraries. I usually use ruby, but having something compiled and strict is super nice. Shellscripting it one big minefield.
Compiling is a simple step ofc. But it's nice to only have the scriptfile and it's nice to not have your directory cluttered with binaries. I'll see if I can post it tomorrow. It's very small anyway
Yes, but then you have to compile it to use it, since scripts can’t use dependencies. Personally I just use getopt which sounds insane but it’s part of the standard library (imported from C).
I wish they had a vision for the language and not "we throw everything and the kitchen sink at it so that our compiler often cannot handle even the simplest SwiftUI components and takes ages to do anything"
Apple barely invest in their own platform, they sure as hell aren’t going to invest the resources required to do this. Flutter on the other hand… genuinely does a great job of cross platform and I’d argue Dart is a nicer language too.
Yes, but Dart is only a single-threaded application language, while Swift can be a proper systems language, something between C++ and Rust, in terms of usability and safety. Golang killer, when it comes to high-level systems programming.
Can we have at least SOME form of JIT compilation for iOS? The technological limitations of not being able to use it are just ridiculous at this point.
And for no real reason, except that apparently Apple's whole ecosystem can crash and burn if somebody looks at it wrongly.
Hopefully they make interface types available to the runtime. So you can read/write wasm struct properties from the host without all the usual glue code cancer
It’s a somewhat more pleasant Rust, with nicer syntax, where you get an additional option wherever you would have weird ownership semantics to just pay some extra cost to have the language solve it for you. Whether that is worth dealing with a worse toolchain is something for you to decide.
This is sort of true in theory, but in practice there's a major difference in that nearly all the libraries in Swift use a reference-counted (i.e. GC'd) shared-everything model, while in Rust nearly all the libraries use ownership and borrowing. The "normal path" of least friction in Swift is a reference-counted world, while the "normal path" in Rust is the ownership-and-borrowing world.
This is not a knock on Swift--it's really the inevitable outcome of seamless compatibility with the COM-like model of Objective-C and Core Foundation being a guiding principle of the language.
> The "normal path" of least friction in Swift is a reference-counted world, while the "normal path" in Rust is the ownership-and-borrowing world.
Of course, but the borrow checker in Rust does a lot to smooth out that potential friction; and Swift will also include comparable facilities starting from Swift 6, which will finally achieve comprehensive safety including in concurrent code.
> it's really the inevitable outcome of seamless compatibility with the COM-like model of Objective-C
There's a comparable focus in Rust of getting not-quite-seamless compatibility with the COM-like model of... well duh, COM. See Microsoft's efforts at getting low-level components rewritten in Rust into their OS's.
You can do the same in Rust of course, it just takes some boilerplate. Whether the Swift approach is genuinely "nicer" is probably a matter of personal opinion.
Niceness is an opinion but I don't think "you need more boilerplate so it is nicer" is one that many people share. When discussing aesthetics as one does here it's not very difficult to rank obvious choices like these.
Interesting proposal though it does sound a bit too general. “Improve cross compilation”… current Swift tools are barely keeping it together for the “happy path” of building for Apple devices (it’s not that happy). It would be cool to expand into wasm/wasi as long as it doesn’t come at the expense of other desperately needed improvements.
Rust, Go and others have been building WASM 0.2 support for many years, they currently have a “just works” support for WASI. It would be a long time until Swift is even remotely ready for something like this and I don’t feel there is a burning need to have “yet another wasm platform”.
> Rust, Go and others have been building WASM 0.2 support for many years, they currently have a “just works” support...
Can confirm. I was pretty stubborn and wanted to use Go to build a UI in a webview/webview using local app, but oh my, js.Value in Go is so much pain to deal with. A lot of things in the JS world don't integrate nicely with Go as a language (e.g. the difference of Go channels and JS Promises, or magical enum values _and_ URL patterns on the same properties like in the Fetch API)
Long story short, I am now around 3 months into building a WebASM bindings and components framework, and it's still a lot of work until I am on the functionality level of TSX files. [1] All those Web/DOM/Browser APIs are kinda hard to integrate into the Go world, especially if you're as stubborn as me and want to have a real typed bindings API that uses Go's native data types.
[1] https://github.com/cookiengineer/gooey
> current Swift tools are barely keeping it together for the “happy path” of building for Apple devices (it’s not that happy)
I agree, but I'm telling myself this is only a temporary pain caused by the changes for supporting Swift 6 language mode. Are you talking about something else?
Temporary but measured in years and forced on every Swift dev out there … hard to dismiss.
My comment was not about that though, I was more thinking about the super slow build times, unreliable SPM with strange limitations, Xcode still shows errors while reporting a successful build, Previews not previewing, etc.
Don’t forget our old friend “The compiler is unable to type-check this expression in reasonable time”
Is this still a thing in Swift? I loved Swift 1, spent a couple of days upgrading to Swift 2, a week or more for Swift 3. At that point I just switched to React Native. I understand that iterating is generally a good thing, but the constant cykle breaking changes in the language was just too much.
Yes. It feels like the language is being handled by academics who don't actually use it, Swift 6 really drives it down.
The lack of Sendable support for Combine and half-assed support on Async Algorithms only makes it more painful to transition at this point in time.
It's now almost a full year since Swift 6 (concurrency) was introduced, and I've spent a lot of time rewriting, debugging and generally tweaking things to make the compiler happy... The promise of "strict concurrency" is yet to yield any meaningful benefit, despite the huge cost of having it.
I think the pursuit of some kind of semantic purity in the Swift language overshadows more practical needs and concerns. Making Swift too different from its neighbours like Kotlin and Rust also makes it harder to context switch. It now takes a lot more time and effort to get into the flow of developing native things for iOS...
Disagree about the academics point but Async Algorithms is basically an abandoned project at this point. There is someone working on it but the intention is that it evolves basically at the pace that the language does, but without the investment that the language gets. I would recommend against relying on anything going on there.
Between a dead Combine that no longer functions in Swift 6 or a severely handicapped AsyncSequence lacking basic features, where are developers supposed to turn to?
All these projects like Async Algorithms, AsyncExtensions, Asynchrone, etc. are being born out of necessity.
Deprecating Combine would be less of a problem if Sendable wasn’t a hard requirement but it is.
I mostly write these things by hand when necessary which sucks but at least I know what is going on with them.
Are you talking about Combine or Async Algorithms? This has been brought up before about Combine, but AA's repo still has some recent commits.
No, I'm talking about the latter. Combine is truly dead but the other repo is mired in an inability to make real changes, because that requires significant review effort, which is not really there. So it's just bugfixes and small tweaks.
Let's not forget the absurd insistence on "will change" semantics in onChange() instead of the far-more-useful notification "did change."
And of course the brain-dead design of withObservationTracking, which only fires on the FIRST change of a value. I mean... by what definition is that "tracking?" It's goddamned useless, unless of course you implement the clumsy workaround of re-establishing observation tracking every (first) time it fires.
Then there's the bizarre hypocrisy of evangelizing the "single source of truth" while telling everyone to prefer structs over classes in Swift. But structs are COPIED everywhere, which of course breaks the "single source of truth" on the first function call.
I wasted so much time trying to conform to these "best practices" until I finally realized that the people promoting them don't know WTF they're doing. Then I went back to classes, injected the "single source" everywhere it was needed, and got to work adding functionality.
And let's not even get into the half-assery that is SwiftUI... still, all these years later.
For context, I was saying that same thing in 2017*, because it seemed obvious, especialy given the elite consensus was it was obvious SwiftUI was being introduced to allow full cross platform development, including web.
In retrospect, I was starstruck by the people I learned programming from, and Apple Neue funds software engineering, especially developer tooling, to the point it is not actively harmful, as opposed to not painful, and very opposed to not-harmful-and-not-painful-on-not-our-platforms.
* Of course, not for Swift 6 Language Mode™, the thing is, there's always been a Huge Project that's launching, but not landing...
Web was never part of SwiftUI story, where does that come from?
You're absolutely right, never made any sense.
I'm not comfy calling out specific names, but the sort of luminary who would have been featured on Daring Fireball over the years proposed this and took umbrage to this being pointed out at the time.
I can think of 2 off the top of my head who specifically did this, one who went on about it until they saw SwiftUI x macOS 1.0 and that became their new drum to beat on. (i.e. the quality was low)
Go's wasm is pretty bad. Rust's is good though.
> It would be a long time until Swift is even remotely ready for something like this and I don’t feel there is a burning need to have “yet another wasm platform”.
I mean, well, it actually already exists? It's been around for a long time and works pretty great, with multithreading, access to JS objects, etc. The author of the linked thread topic is the original author of it.
https://swiftwasm.org/
I think that’s WASI Preview 1 that’s currently supported by swiftwasm (and I don’t think the spec implementation is even complete), not the current WASI 0.2. Preview 1 was the current status quo about 2 years ago.
Writing WASM in Swift so it can only be run by a Swift runtime also misses out on a huge aspect of that “bring your language” approach to wasm. It should support enough of the spec so a current wasm binary compiled from say Go can be executed in a WASI runtime powered by Swift and vis-versa. It’s a long way to get there.
Amazing!
Why are they framing it as a proposal if it's done? (if this comes across as Socratic, it is unintentional, I genuinely don't understand why the author would be posting a proposal when it is done)
EDIT: My naive reading of https://github.com/swiftwasm/swift/issues is there's a lot, lot, to go. TL;DR: open from 2021, stdio FILE not available in WASILibc. Long version, filed in 2020 and open: "Pointers needed on WASILibc", "Make the toolchain work without Xcode installed", "Enable libdispatch or provide stubs for it", 2022 "canImport(Dispatch) is wrongly truthy on WASI target", "wasm lacks signal support" (broke/regression in Sept. 2024, still open)
> "Make the toolchain work without Xcode installed”
On macOS. Works fine on Linux.
This is such an easy ask. The only thing holding it back, imo, is Apple. Can’t let the plebs bypass Xcode to develop on their Macs!
My workaround is running a container with Linux Swift installed. Of course, I’m not targeting an Apple OS so I have the flexibility.
> Can’t let the plebs bypass Xcode to develop on their Macs!
AFAIK, they support that. https://www.swift.org/swiftly/documentation/swiftly/getting-...:
“Overview
To get started with swiftly you can download it from swift.org, and extract the package.
On macOS you can either run the pkg installer from the command-line like this or just run the package by double-clicking on it (not recommended):
Now run swiftly init to finish the installation: Swiftly will install itself and download the latest available Swift toolchain.”.NET does pretty well as far as WASM support goes, unlike Go which is abysmal :)
https://bootsharp.com/guide/llvm / https://github.com/elringus/bootsharp
Tell that to Typescript and Azure teams, what can we say when DevDiv decides to bet elsewhere?
I don't think they considered the terrible state of WASM in Go to be a challenge.
But then again, we've already concluded it was a short-sighted decision.
Ignore the haters—Swift is an enjoyable and productive language that gives you a lot of advanced features if you want them, but lets you ignore them and almost treat it like a scripting language. Adding first-class wasm support could help it become a more reasonable choice for development outside the Apple platform.
My only fear with Swift is Apple. The language itself seems largely fine, very interesting even, which makes me feel deeply conflicted.
While Apple has been big on pushing multi-platform Swift right now and distancing itself a bit from the Swift branding in some ways (e.g. it having its own GitHub organization) they've historically had quite an ebb and flow to this behavior. If their priorities changed, what happens to the non-Apple projects that adopted Swift? It would be better if there were multiple parties that had stake and some control in the future of Swift.
I have similar worries with Microsoft and .NET, although it's a bit different owing to the fact that Microsoft is quite a different company with different problems.
It's actually kind of bizarre that it never really felt like Google was a problem for Go, but I guess that's because unlike Apple Swift and Microsoft .NET, Go mostly targets and is almost entirely developed on platforms that Google has little control over. (Though that doesn't mean that their presence is entirely unnoticed, but even stuff like the module proxy has been more well-received than expected. It's an odd area where Google has managed to maintain some goodwill, though it could evaporate over night.)
The rug-pull of Swift from TensorFlow came from Google rather than Apple.
Hey, I didn't say you should trust other Google projects. The Google Graveyard meme should be enough evidence of that.
It came from Google because they couldn’t trust Apple, actually. Also Chris Lattner having the focus of a goldfish.
He has got his mojo back now.
While the efforts are laudable, it remains to be seen where it will stand against regular Python and Julia, that actually have support from card vendors directly.
I think you hit the nail on the head. By extending Go to many platforms, it doesn't feel like you're using a corporate-sponsored language (though you are). The Swift team is aware that they need to help the language thrive in other contexts, which is why they're working on projects like Embedded Swift [0]. I hope they fully embrace wasm as well!
Not sure if you're aware or not but .NET these days can (officially) target pretty much anything - not just Windows. Usage on Linux definitely picked up vs. Windows because Linux servers are cheaper. Android/iOS is there. WebAssembly is also there.
Kind of, still misses a few platforms that have had JVM support outside mainstream computing, but yeah mostly great experience for target platforms.
The IDE story is a bit complicated though, either you go for Rider, or have to delve into the internal politics of VSCode vs VS, and features that VSCode will never get because there are those VS licenses to sell.
Rust, Go, and Swift were all coming up around the same time. Rust looked ugly, Go underwhelmed me, and Swift aeemed like the best “language” at the time, with many opinions that aligned with my own.
Having now spent time in all three, swift feels the most ergonomic and has features that make me feel productive. I still feel like there isn’t much “there” in Go, and rust makes me feel like I’m solving for the compiler rather than working on whatever problem I was needing to work on.
Edit to add: SwiftUI, however, is a mess that I loathe. I may be in the minority of enjoying the IoC choices in Interface Builder and AppKit.
SwiftUI is just amazing for the first 30 minutes you use it... then you make a minor syntax error deep in some nested views and you're selectively commenting out coded blocks to hone in on the error like a caveman.
It makes print-statement debugging look cutting edge.
As an early adopter of SwiftUI, this hasn't been my experience—but I understand that a lot of people struggle with it. I think it's pretty opinionated, and if you stick to the "preferred" way of doing things, life is easier.
The biggest (and known) issue with SwiftUI is the complex error messages you get, and the fact that the type checker will give up and ask you to break up your view into "distinct sub-expressions." Really the issue is almost never the complexity of a view, but some simple syntax error (passing the wrong type to a function, etc).
> The biggest (and known) issue with
Isn't this literally what the person above is talking about?
> Really the issue is almost never the complexity of a view, but some simple syntax error (passing the wrong type to a function, etc).
The issue is that this is a big, known, common problem that cannot be solved, apparently
Yeah. My understanding is the design of type inference is flawed and requires exponential complexity to resolve and it’s not fixable without breaking change.
Why this is not a top priority before literally anything else?
Yeah. I have a bunch of code with bog-standard linear algebra classes (vec2, vec3, mat2, ...). No generics, no nothing. Just simple classes with operator overloading.
After the recent minor XCode upgrade, Swift can't deduce the type for an expression `((v2 * scalar1) * v3)`, I have to split `let tmp1=v2*scalar1` for it to work.
Like, wtf, Apple?
It’s even possible to compile on one machine and timeout on another.
I agree with you, but sounds like a rough problem:
https://danielchasehooper.com/posts/why-swift-is-slow/
The author is welcome to add type annotations if they want…?
?? No other language times out error checking. This is insanity.
Not regularly but many languages have type systems that are algorithmically worse, like TypeScript
As a user, I couldn’t care less about the algorithmic beauty of the type system if it works, lets me type complex things reliably, and is fast enough to stay out of my way. Does it do that by being a mess of duct table and plywood? Totally fine for me.
Sure, but often the duct tape and plywood makes it difficult to make things that are reliable and stay out of your way.
And yet TypeScript doesn't fail with a cryptic nonsensical error just because you have the impossible component with an unfathomable number of two nested lists, like in SwiftUI.
Algorithmically worse doesn't mean worse in practice
Can you show a common line of type script that will take exponential complexity for typescript to resolve?
I think you misunderstood my comment.
My understanding is you are saying TypeScript has a similar complexity problem in its type system as Swift.
I am wondering if you have a common example that would timeout or have problems.
If not then I struggle to see what similarity you are seeing.
(Genuine question, I am interested in what other languages do)
No, I'm saying it has a worse system than Swift's. The point I'm making is that they've designed things such that the normal case doesn't hit this, while Swift keeps adding APIs that exercise the worst of their type system.
Everyone misunderstood your reply.
Perhaps it was a pure academic reply? Because reality always trumps theory.
> Perhaps it was a pure academic reply
Yes, exactly.
> deep in some nested views
It doesn't even have to be deep. I ran into this issue on very few quite simple components. The compiler just gives up because somehow swift's type system makes it impossible to figure out
This problem is very real. There is at least an ok way to avoid it getting too bad: make lots of View and ViewModifier structs, with each one having smallish amounts of code. Split them up to the extent that it feels silly.
As an added bonus, this is also the way to get good performance at run time. It helps minimize how many views need to get re-evaluated when something changes.
I agree about SwiftUI. It's something I want to like, but everything about it… no.
For me, SwiftUI does exactly two things better than UIKit: tables and collection views. For everything else, it's so much easier to get stuff done with UIKit*, regardless of if I'm working with Interface Builder or making UI in code (as per various projects I've dropped into).
In theory, reactive UI is good. In practice, at least in the case of SwiftUI, the "magic" data passing does sometimes fail — perhaps someone put in the wrong @ on the property — and then you've got to debug some weird magic, and if there's a sensible place to put a breakpoint for that kind of problem I have yet to learn it.
In theory, the UI is reusable across all Apple platforms. In practice, the nature of the user experience is so different that actually trying this makes it suck for everyone — you don't want finger-sized buttons on a mouse-driven UI or tiny mouse-suitable click areas for a mobile UI, and I have no idea what the user expectations are for tvOS or WatchOS despite having written apps for both because hardly anyone shares their experiences and lessons learned.
In theory, having the code be the source of truth for the WYSIWYG editor is great. In practice, the WYSIWYG editor keeps giving up because of e.g. a compiler error, and decides to stop forever until you manually resume the preview.
* I'm mostly on iOS rather than macOS, but I'd assume UIKit and AppKit have the same strengths and weaknesses.
Even outside of iOS I’m not fully convinced that declarative/reactive is “the way”. Jetpack Compose while not as bad as SwiftUI in some ways shares many of its problems, including the magic, inscrutable stack traces, and challenges in reasoning. Past a certain level of complexity imperative UI feels more manageable.
> In theory, the UI is reusable across all Apple platforms.
This is the practice (when people are lazy). The theory that Apple presented was that you are supposed to tweak your UI for each platform and share some of the common code.
This is more or less how I feel too. Writing Swift feels good, and once you make a habit of avoiding code smells that trip up SourceKit, syntax coloration and all that works well enough too. SwiftUI on the other hand gets to be a mess for anything larger than small components and collection view cells.
And so I write pure code UIKit most of the time. It’s not trendy but it’s very effective.
Wow, thanks for saying this. I had no idea it was even usable outside the Apple ecosystem. Seems like other IDEs support it too (https://www.swift.org/tools/).
How would UIs work on other platforms, though?
> How would UIs work on other platforms, though?
I think for right now, you'd have to use the C interop and link against something like GTK or other GUI library. I don't think SwiftUI specifically would ever work well cross-platform, it has so many Apple-isms.
There's also Swift/Win32, but it's MVC. You could also use the interop and use QT as well.
I don't think any of those are necessarily good solutions, but they are there.
What sort of things are you referring to when you say "Apple-isms"? Not that I doubt your claim -- I just don't do much UI development so I don't have a good reference for what things might be 'platform specific' in that way.
TokamakUI
And https://skip.tools
Hmm, Tokamak seems abandoned (hasn't been touched in years) and skip.tools requires xCode and is Android-only =/
Thank you though.
Yes there’s nothing all in one yet. But these are promising directions. Tokamak isn’t abandoned, members are involved in core Swift changes that it depends on and have made progress recently with embedded Swift.
As with other languages, you’d need bindings to another UI framework. In that sense, I wish SwiftUI had a different name because it seems intrinsic to Swift when it’s really no different than UIKit.
There’s stuff like SwiftCrossUI that does multiple backend bindings
https://github.com/stackotter/swift-cross-ui
And Qt was exploring some bindings using the new C++ interoperability.
There’s also Shaft, which is Flutter ported to Swift:
https://github.com/ShaftUI/Shaft
Like Flutter, this paints everything itself. It doesn’t need to bind to a UI framework directly. Instead, it needs the platform to provide primitives like a surface to draw into and input events.
> Ignore the haters—Swift is an enjoyable and productive language
Sure, if you are on Apple devices. If you are not, better to use other languages like Rust, Go, or even Dart.
The direct competitor to Swift is most likely Kotlin and I bet it'll win out as a cross platform solution of choice in a couple of years as KMP stabilizes.
Is Dart still a thing? Genuinely interested.
It absolutely is and its a pleasant language to work with. Although it is in a kinda-symbiotic relationship with Flutter, I've found myself using it for small scripts and cli tools instead of Python because of its strong+static typing with null safety.
Relevant to the topic, Dart (and Flutter) supports targeting wasm.
Yup. It got it's second life because Flutter adopted it as it's language.
It was pretty dead for a few years (despite what the googlers will tell you...)
Not only a thing but is growing at a crazy rate. Easily my favourite language out there for the last few years.
Either as shebang/interpreted script, or just compile to a binary for great startup speed. I actually only recently found out you could use swift for scripting. Turns out, you can also access all the other Apple APIs :-)
I made this small "shebang thing runner script" that either runs your script interpreted, or compiles and executes it. Depending on if you're on a TTY or not. I'm also changing it to simply check for the number of executions since last modified, and then compile. In some cases the extra time is well appreciated. You still get the convenience of interpreting, but also the performance of native.It's basically a drop-in replacement:
Very noticeable difference.Ha, nice! I've used the Swift shebang before, but honestly once you have something that works as a "script," it's so easy to convert it to a real command line utility via Swift Argument Parser [0] that I usually spend the 5 minutes to wrap it up.
That's pretty sweet the argparser
It's kind of nice to be able to access all native libraries. I usually use ruby, but having something compiled and strict is super nice. Shellscripting it one big minefield.
Compiling is a simple step ofc. But it's nice to only have the scriptfile and it's nice to not have your directory cluttered with binaries. I'll see if I can post it tomorrow. It's very small anyway
Yes, but then you have to compile it to use it, since scripts can’t use dependencies. Personally I just use getopt which sounds insane but it’s part of the standard library (imported from C).
I wish they had a vision for the language and not "we throw everything and the kitchen sink at it so that our compiler often cannot handle even the simplest SwiftUI components and takes ages to do anything"
Can we have a proper Windows support? i.e. with all the batteries/libraries included.
Apple barely invest in their own platform, they sure as hell aren’t going to invest the resources required to do this. Flutter on the other hand… genuinely does a great job of cross platform and I’d argue Dart is a nicer language too.
Yes, but Dart is only a single-threaded application language, while Swift can be a proper systems language, something between C++ and Rust, in terms of usability and safety. Golang killer, when it comes to high-level systems programming.
Just what I've been waiting for! Now about that JVM support for Swift...?
You’re mixing up the visions :) JVM support was the buzzword for last year’s “Swift on the Server for realz”.
I thought that was when WebObjects switched to Java.
Ah, also known as Project Wonder. Good times
Don't forget about BEAM/Erlang interop too, now we are getting truly distributed... :P
Why not Swift .NET? :)
Because we already have F# with much better tooling. :)
Can we have at least SOME form of JIT compilation for iOS? The technological limitations of not being able to use it are just ridiculous at this point.
And for no real reason, except that apparently Apple's whole ecosystem can crash and burn if somebody looks at it wrongly.
Hopefully they make interface types available to the runtime. So you can read/write wasm struct properties from the host without all the usual glue code cancer
Is there a compelling reason to use Swift over Rust for anything other than Apple development in 2025?
It’s a somewhat more pleasant Rust, with nicer syntax, where you get an additional option wherever you would have weird ownership semantics to just pay some extra cost to have the language solve it for you. Whether that is worth dealing with a worse toolchain is something for you to decide.
This is sort of true in theory, but in practice there's a major difference in that nearly all the libraries in Swift use a reference-counted (i.e. GC'd) shared-everything model, while in Rust nearly all the libraries use ownership and borrowing. The "normal path" of least friction in Swift is a reference-counted world, while the "normal path" in Rust is the ownership-and-borrowing world.
This is not a knock on Swift--it's really the inevitable outcome of seamless compatibility with the COM-like model of Objective-C and Core Foundation being a guiding principle of the language.
> The "normal path" of least friction in Swift is a reference-counted world, while the "normal path" in Rust is the ownership-and-borrowing world.
Of course, but the borrow checker in Rust does a lot to smooth out that potential friction; and Swift will also include comparable facilities starting from Swift 6, which will finally achieve comprehensive safety including in concurrent code.
> it's really the inevitable outcome of seamless compatibility with the COM-like model of Objective-C
There's a comparable focus in Rust of getting not-quite-seamless compatibility with the COM-like model of... well duh, COM. See Microsoft's efforts at getting low-level components rewritten in Rust into their OS's.
You can do the same in Rust of course, it just takes some boilerplate. Whether the Swift approach is genuinely "nicer" is probably a matter of personal opinion.
Niceness is an opinion but I don't think "you need more boilerplate so it is nicer" is one that many people share. When discussing aesthetics as one does here it's not very difficult to rank obvious choices like these.
Some differences and advantages of swift are documented here: https://faultlore.com/blah/swift-abi/