Hello, the readme said to reach out, so we're doing that. Briefly, we're looking to use Rust written WASM, interpreted in Rust runtime via something like wasm3
or wasmtime
. That's why we're looking to potentially depend on wit-bindgen
. First of all, does this make sense? Secondly, what would be the community's suggestion on the interface? (if any) we're thinking of passing a vec<u8>
to/from WASM like so:
fn handle(a: vec<u8>) -> vec<u8> {
// 1. parse, 2. do work, 3. return bin repre
}
Some loose requirements/expectations:
vec<u8>
parser/printer in mobile context, with other languages (Kotlin/Swift), not just Rustgiven the above, what resources/tech do you recommend? is wit-bindgen a good fit? it looks like the solution to us b/c interface types are not maintained now, and quite heavy (i.e. wasm-bindgen assumes a lot of JS type inter-op that we don't need). we want something fast, with small binary size, and ideally future proof (not another abandoned experiment).
if something is too vague pls lmk and i can clarify
I am not an iOS developer, but my vague understanding is that app store rules will not allow a code execution engine like wasmtime to be embedded in an app
I also distinctly remember a game that was removed because it had an embedded python interpreter
yes, that's why we're looking to use wasm3, avoiding JIT, using an interpreter instead (allowed)
If you are targeting wasm3 you probably do not want to use wit-bindgen
at this time
It could be made to work with significant effort, but if your interface is just "bytes in, bytes out" you would likely find it easier to manipulate the wasm linear memory directly from the host
in that case, are you maybe aware of a more lightweight way of generating the bindings than w/ wasm-bindgen
? we want to avoid relying on any of the JS associated baggage (https://github.com/rustwasm/wasm-bindgen/issues/5)
I am not aware of any other simple solution, but I haven't personally looked recently. What wit-bindgen
does internally - roughly - is allocate memory on the guest side and pass a pointer to that allocation to the host, which then copies the data into linear memory at that pointer
okay, then we'll try to mimic what wit-bindgen
does internally, and go from there. thanks for the rubber-ducking Lann :pray: :)
fero has marked this topic as resolved.
Lann Martin said:
I am not an iOS developer, but my vague understanding is that app store rules will not allow a code execution engine like wasmtime to be embedded in an app
This seems to have changed recently? https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_allow-jit
That is a macOS only entitlement.
There is an iOS equivalent, but it only works for local development. You can't use it in appstore apps.
And for most purposes you really have to look at app store policy rather than developer documentation to get the whole story
Does it being allowed with local development indicate that it's going to be allowed for appstore apps at some point? (if so I wonder what might be driving the change)
I don't think so. If anything I wouldn't be surprised to see it disappear entirely in the future. Basically the only system app with this entitlement is Safari (even non-apple browsers can't use it) and when using Lockdown mode Safari doesn't use it either, but falls back to a javascript interpreter.
For some clarification/context: including language runtimes is 100% allowed on iOS. See React Native (JS/V8) and Flutter (Dart) as examples of this. wasm isn't special in this regard.
The relevant iOS app store guidelines are about dynamically shipping new logic to your app _after_ it has been reviewed (i.e. when a user is running the app, new logic being presented to them that was not present in the app during review).
You should be fine as long as you both
A) don't violate local iOS security policy / guidelines (e.g. JIT compilation to ARM/native and dynamic jumps into that code segment are effectively disallowed by default, though this restriction may be loosening as per the previous reply on this thread), and
B) statically include all logic that will run when a user is using the app (excluding that run in a WebView, which can ostensibly be loaded dynamically as in a web page... which has its own subtleties to consider) .
This means that (AFAIK) Wasmtime _at the moment_ may not be the best option as it doesn't have a straightforward interpreter mode (though maybe this will change?). Straight up interpreting via something like wasm3, or compiling to statically link via something like RLBox should be fine (again, as long as the wasm source was shipped _statically_ in the app archive to install).
P.S. I'm working on a general-purpose "universal plugin" solution for mobile apps using wasm if anyone wants to talk more about the subtleties of running on iOS, Android, and beyond. I'm _very_ interested in people's usecases and where existing tooling can be improved ;).
@akesling I’m very interested in your mobile plugin solution! we’re working on a similar problem in other platforms with Extism, but mobile is definitely on the roadmap. Maybe we can collaborate?
if its only jitting code that is against the rules, and mmaping + marking as executable code that is bundled with your app is allowed, then you can still use wasmtime in AOT mode: if you disable the cranelift
feature, then you can use Module::deserialize
to load code that was emitted by Module::serialize
elsewhere
Last updated: Dec 23 2024 at 12:05 UTC