Swift wasm binary sizes?

Hey folks,

I had a need to delve into the world of WASM, and so I figured I'd see what Swift WASM is all about. Long story short, the environment that I'd like to deploy to is seriously memory constrained (less than 8MB). Now, thanks to the awesome work of @Max_Desiatov and others, I was able to produce a wasm binary from Swift source without too much struggle, but, it weighs in at 15 MB, well over my limit :frowning:

So, my question is, what's typical for the size of a swift wasm binary? Is there a way that I can thin mine out?

We have a separate issue on GitHub dedicated to this: build wasm file is very big??? · Issue #7 · swiftwasm/swift · GitHub

In short, wasm-strip and wasm-opt as discussed in that GitHub thread can make your binary somewhat smaller. You could also avoid using Foundation to avoid some overhead from that library.

Right now there is a minimum size of a statically linked Swift binary dictated by the size of the ICU library and the fact that Swift compiler can't strip unused protocol conformances. The dependency on ICU can't be removed completely, as it is required to make String indexing work. This is an issue for Swift on all platforms, not just Wasm.

In the meantime, if binary size is critical for you, I'd recommend using Rust, or maybe even C/C++. Rust may be especially suitable, since their no_std mode allows compiling without Rust standard library altogether.


My understanding is that Rust's standard library is basically split in 2 parts: the core library, which you can't omit and is roughly equivalent to Swift's standard library. It also includes some Unicode tables (e.g. for case-folding). The other half is the std library, which includes files, networking and more, and is closer to Foundation than the Swift standard library.

So no_std Rust is conceptually not a whole lot different to Swift without Foundation. The protocol conformances/reflection metadata/ICU issues are probably a bigger deal, would you agree?


Ok thanks for the info, it seems that I could maybe thin it to under 8MB with some of the steps mentioned in that issue thread, but I think I’ll just move to rust for the time being for this instead.

Side topic : i had no idea wasm was a realistic target for swift at the moment. Is there any guide or documentation somewhere on what the experience is and how to get started on swift on those less known swift target platforms ? (i'm especially thinking about android, and wasm)

1 Like

We're* making some progress on dropping the ICU dependency, by the way. No promises of course, but I'm quite hopeful.

*not me specifically, I'm just watching excitedly while working on other stuff


It is absolutely incredible at how well it works. I have redesigned an entire client app using Swift WASM. The team behind SwiftWASM are beyond experts.

1 Like

Interesting ! how did you deal with Foundation dependencies ?

Parts of Foundation are available when targeting Wasm (which is never written in all uppercase according to the WebAssembly spec). What isn't available through Foundation is mainly file access, locale/time zone information, and multi-threading. We're interested in supporting the latter, but currently Safari is the only browser without multi-threading support for WebAssembly. Our approach so far has been to target WebAssembly features that are available in all major browsers.

More info on Foundation support is available in the SwiftWasm book.


Thanks a lot for the answer.

Out of curiosity (and also to understand what amount of work we're talking here) : at which level do you need to work to support Foundation on Wasm ? Does Foundation rely on some kind of Posix standard, which you would need to emulate and then all its code could simply be linked against that layer ? Or are we talking about a complete rewrite ? Are you able to leverage work that has been done when porting Foundation to linux ?

Yes, it's not completely POSIX, but it's relatively close. It's called WASI.

Yes, we already leverage it, as long as it's not related to multi-threading, networking/sockets, or file access, because those features are sufficiently different from other platforms, or aren't standardized yet with WASI.

Terms of Service

Privacy Policy

Cookie Policy