Since Kotlin Native uses LLVM, then WASM support is possible. However, since WASM doesn’t yet have GC support (it’s actively being worked on, I saw the first ML commit a few hours ago) the GC Kotlin Native uses (ref count + cycle collect?) would have to be distributed as part of the runtime as well.
I believe it should not be too far off. In fact, I believe one of the Kotlin devs maintains TeaVM which can compile JVM bytecodes to WASM (experimentally) which would include Kotlin. Granted a direct Kotlin-to-(LLVM-to-)WASM compiler would probably be more efficient than going through JVM bytecode first, but not necessarily since JVM bytecode is more specific in most cases. Also, on the LLVM front, there are a good number of optimizers that can help that Kotlin native likely takes advantage of. If they did go straight from Kotlin to WASM, they could probably benefit from better DCE, inlining, etc that comes from optimizing a high level language.
TLDR: probably wait for the next WASM cycle w/ GC unless you just want to play around.
If you want to play around, get Kotlin native to compile to LLVM IR (not sure how, didn’t look), then use
s2wasm from https://github.com/WebAssembly/binaryen (pre-built bins of that+Emscripten can be found here with s2wasm in the bin folder). But you might be better off just using LLVM IR -> Emscripten since you’ll get runtime syscalls implemented in JS w/ Emscripten.
If you want to play around w/ WASM formats or see a WASM-to-JVM compiler, I wrote one in Kotlin here