I ship an Apple app (currently in TestFlight, demonstrated at HOPE 2026 conference a last month) that runs untrusted .wasm guests on Apple TV 4K (A10X), iPhone XS (A12), and Apple Watch SE2/6 (S4, technically A14 efficiency CPU cores and slightly cut-down GPU). we currently integrated WAMR, and are evaluating TinyWasm. Our target is currently wasm32-wasip2 components on WASI 0.2.6; native capabilities are statically linked—we do not need dynamically loaded WASI modules. Most of our WASI/WIT is W3C API shaped, and I'm attributing each in-tree request to the specific module that currently works under the WAMR integration.
I agree with the direction in #62: keep component handling, canonical ABI, resource tables, and custom WASI/WIT modules out of TinyWasm. It decouples maintenance overhead from a shifting standard, and lets crazy people like me innovate :D WASIp1-only users should only see negligible code-size and call-path impact that doesn't affect their low-end embedded deployment scenarios.
The concrete integration needs I can see right now are:
- Preview 2: checked canonical-ABI memory access,
realloc/post-return, and resource ownership.
- custom WASI modules
compression-streams passes list<u8> chunks and stream resources
w3c:file-system-access/read-only-file-picker returns a selected-file resource backed by wasi:io/streams.input-streamw3c:web-audio/realtime-render adds short-lived WASM worklet workers and resource cleanup across threads
- Untrusted guests: bounded parse work and memory/resource accounting across worker restarts, including pathological compressed inputs. We will try existing allocator/limiter APIs first and bring small failing fixtures for any missing core seam.
- Preview 3: async functions, futures, and streams
- replace the current
wasi:io/pollevent-queue pattern in w3c:web-speech/speech-recognition, shape-detection-camera/live-camera-detection, and WebAudio worker notifications. Polling is a not great for Apple Watch performance or battery life on any mobile device.
- An opt-in host-call suspend/wake/cancel seam may be needed; realtime audio callbacks must not block to avoid regressing the audio glitching/skipping I worked hard to eliminate on my real devices.
- General: A stable component-to-core handle seam
- Exported functions and memories are accessible today, but ordered instantiation is marked unstable and internal by-index access is gated for debugging.
- If a valid component cannot express its selected memory, realloc, or post-return function through the stable export APIs, I'd request (or can contribute) the smallest store-checked handle API that allows this to durably work end-to-end
Which core APIs would you prefer an external layer to rely on (eg they'll be reasonably stable)? I can contribute narrow, independently tested changes when a concrete fixture demonstrates a gap we can't solve out of tree, but is there a specific place you'd like me to start?
I ship an Apple app (currently in TestFlight, demonstrated at HOPE 2026 conference a last month) that runs untrusted
.wasmguests on Apple TV 4K (A10X), iPhone XS (A12), and Apple Watch SE2/6 (S4, technically A14 efficiency CPU cores and slightly cut-down GPU). we currently integrated WAMR, and are evaluating TinyWasm. Our target is currentlywasm32-wasip2components on WASI 0.2.6; native capabilities are statically linked—we do not need dynamically loaded WASI modules. Most of our WASI/WIT is W3C API shaped, and I'm attributing each in-tree request to the specific module that currently works under the WAMR integration.I agree with the direction in #62: keep component handling, canonical ABI, resource tables, and custom WASI/WIT modules out of TinyWasm. It decouples maintenance overhead from a shifting standard, and lets crazy people like me innovate :D WASIp1-only users should only see negligible code-size and call-path impact that doesn't affect their low-end embedded deployment scenarios.
The concrete integration needs I can see right now are:
realloc/post-return, and resource ownership.compression-streamspasseslist<u8>chunks and stream resourcesw3c:file-system-access/read-only-file-pickerreturns a selected-file resource backed bywasi:io/streams.input-streamw3c:web-audio/realtime-renderadds short-lived WASM worklet workers and resource cleanup across threadswasi:io/pollevent-queue pattern inw3c:web-speech/speech-recognition,shape-detection-camera/live-camera-detection, and WebAudio worker notifications. Polling is a not great for Apple Watch performance or battery life on any mobile device.Which core APIs would you prefer an external layer to rely on (eg they'll be reasonably stable)? I can contribute narrow, independently tested changes when a concrete fixture demonstrates a gap we can't solve out of tree, but is there a specific place you'd like me to start?