[HN Gopher] A Vision for WebAssembly Support in Swift
___________________________________________________________________
A Vision for WebAssembly Support in Swift
Author : LucidLynx
Score : 160 points
Date : 2025-04-05 13:58 UTC (9 hours ago)
(HTM) web link (forums.swift.org)
(TXT) w3m dump (forums.swift.org)
| turnsout wrote:
| 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.
| solardev wrote:
| 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?
| thewebguyd wrote:
| > 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.
| wahnfrieden wrote:
| TokamakUI
|
| And https://skip.tools
| solardev wrote:
| Hmm, Tokamak seems abandoned (hasn't been touched in
| years) and skip.tools requires xCode and is Android-only
| =/
|
| Thank you though.
| wahnfrieden wrote:
| 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.
| achierius wrote:
| 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.
| dagmx wrote:
| 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.
| loic-sharma wrote:
| 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.
| jonhohle wrote:
| 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.
| jkubicek wrote:
| 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.
| turnsout wrote:
| 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).
| troupo wrote:
| > 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
| grandempire wrote:
| 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?
| yAak wrote:
| I agree with you, but sounds like a rough problem:
|
| https://danielchasehooper.com/posts/why-swift-is-slow/
| saagarjha wrote:
| The author is welcome to add type annotations if they
| want...?
| grandempire wrote:
| ?? No other language times out error checking. This is
| insanity.
| saagarjha wrote:
| Not regularly but many languages have type systems that
| are algorithmically worse, like TypeScript
| 9dev wrote:
| 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.
| cyberax wrote:
| 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?
| troupo wrote:
| > 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
| bjustin wrote:
| 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.
| cosmic_cheese wrote:
| 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.
| ben_w wrote:
| 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.
| cosmic_cheese wrote:
| 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.
| saagarjha wrote:
| > 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.
| jchw wrote:
| 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.)
| turnsout wrote:
| 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!
| [0]: https://www.swift.org/getting-started/embedded-swift/
| odyssey7 wrote:
| The rug-pull of Swift from TensorFlow came from Google rather
| than Apple.
| jchw wrote:
| Hey, I didn't say you should trust _other_ Google projects.
| The Google Graveyard meme should be enough evidence of
| that.
| saagarjha wrote:
| It came from Google because they couldn't trust Apple,
| actually. Also Chris Lattner having the focus of a
| goldfish.
| jbverschoor wrote:
| 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
| turnsout wrote:
| 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. [0]:
| https://github.com/apple/swift-argument-parser
| jbverschoor wrote:
| 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
| saagarjha wrote:
| 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).
| satvikpendem wrote:
| > _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.
| nofunsir wrote:
| Just what I've been waiting for! Now about that JVM support for
| Swift...?
| isodev wrote:
| You're mixing up the visions :) JVM support was the buzzword
| for last year's "Swift on the Server for realz".
| detourdog wrote:
| I thought that was when WebObjects switched to Java.
| isodev wrote:
| Ah, also known as Project Wonder. Good times
| zerr wrote:
| Why not Swift .NET? :)
| pjmlp wrote:
| Because we already have F# with much better tooling. :)
| watusername wrote:
| Don't forget about BEAM/Erlang interop too, now we are getting
| truly distributed... :P
| isodev wrote:
| 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".
| elpakal wrote:
| > 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?
| isodev wrote:
| 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.
| refulgentis wrote:
| 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(tm), the thing is,
| there's always been a Huge Project that's launching, but not
| landing...
| erikrothoff wrote:
| 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.
| Daedren wrote:
| 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.
| saagarjha wrote:
| 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.
| neonsunset wrote:
| .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
| pjmlp wrote:
| Tell that to Typescript and Azure teams, what can we say when
| DevDiv decides to bet elsewhere?
| neonsunset wrote:
| 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.
| syspec wrote:
| > 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/
| refulgentis wrote:
| 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)
| jagged-chisel wrote:
| > "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.
| Someone wrote:
| > Can't let the plebs bypass Xcode to develop on their
| Macs!
|
| AFAIK, they support that. https://www.swift.org/swiftly/d
| ocumentation/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):
| installer -pkg swift-x.y.z.pkg -target
| CurrentUserHomeDirectory
|
| Now run swiftly init to finish the installation:
| ~/usr/local/bin/swiftly init
|
| Swiftly will install itself and download the latest
| available Swift toolchain."_
| isodev wrote:
| 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.
| zerr wrote:
| Can we have a proper Windows support? i.e. with all the
| batteries/libraries included.
| troupo wrote:
| 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"
| WD-42 wrote:
| Is there a compelling reason to use Swift over Rust for anything
| other than Apple development in 2025?
| saagarjha wrote:
| 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.
| zozbot234 wrote:
| 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.
| saagarjha wrote:
| 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.
| pcwalton wrote:
| 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.
| singularity2001 wrote:
| 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
| cyberax wrote:
| 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.
___________________________________________________________________
(page generated 2025-04-05 23:00 UTC)