I normally write WebAssembly by hand (using WAT) and interop with JavaScript directly (just for performance, manual memory management etc), so never needed anything from libc.
Additionally, you don't pay for what you use with Embedded Swift. With full optimizations unused WASI imports are removed from the final binary, so If you need only a heap allocator and nothing else, you'll technically get a WASI-less binary even with a WASI triple.
It does support browser use cases if that's what you're referring to. As you'll probably end up using JavaScript bridging for that anyway, I'd recommend checking out the corresponding JavaScriptKit tutorial.
Nice! I must have misunderstood @kateinoigakukun when they said:
You can still use wasm32-unknown-none-wasm target for that purpose, although we don't actively support it
I thought they were referring to the browser.
Thank you, @Max_Desiatov. I'll read the JS tutorial today (I need to study the WebGPU example as well).
Are you familiar with WASM-4 (the fantasy console)? I'd like to explore using Swift in a similar way, but creating a bespoke 'console' for each game (kinda like a fantasy arcade machine), using regular Web APIs to implement the various 'helper chips' (for rendering sprites, audio etc).
We don't actively support wasm32-unknown-none-wasm in a sense that you can't do much when using it without a lot of effort for the reasons stated above: you won't have classes or basic collections working without an allocator, Set and Dictionary won't work without RNG etc.
If you provide your own libc, use it at your own risk. In turn, when using that in the browser, you'll have to provide your own host imports implementation to replace existing WASI shims. At that point everything's so custom I wouldn't really recommend it. Whatever goes wrong in the process of setting it up would be much harder to debug than the existing WASI setup you get out of the box.