If you mean you'll write something in a language with a C-ish ontology (C, C++, Swift, Rust, etc.), WASM won't help you much because you can already compile these languages for both platforms and interact via bindings; WASM won't buy you anything except for mandatory interpreter overhead on iOS. If you mean a GC-ed language like JS or Java, WASM doesn't yet have native GC and likely wouldn't be much better than JavaScript as a compiler target for these languages even if/when it does.
WASM solves a totally orthogonal problem: running native-ish code in places where native code is currently unacceptable (e.g. web, other low-trust scenarios). Major mobile platforms can handle native code just fine, and WASM does precisely zero to help you write bindings for platform APIs.
I disagree. I want to dump "native" and just have a more performance engine than is JavaScript. I am assuming that more native hardware will be exposed via WASM. I want the high-level language that is compiling to WASM to isolate me from the platform differences. Perhaps is wishful thinking on my part.
What do you mean by native hardware? WASM's only goal is to expose some "hardware" in the CPU itself, all of whitch is already available to (and mostly used by) the existing JavaScript engines. Anything that goes through a driver has nothing to do with WASM; its specification explicitly does not define any APIs that WASM code can access at all.
If you want more performant code than you're getting from hand-written JavaScript, you need either (a) an improved JavaScript engine or (b) to write code in a different language. WASM isn't some magic escape hatch for high level languages.
WASM solves a totally orthogonal problem: running native-ish code in places where native code is currently unacceptable (e.g. web, other low-trust scenarios). Major mobile platforms can handle native code just fine, and WASM does precisely zero to help you write bindings for platform APIs.