Stitch (May 23 2026 at 10:52): Stitch (May 23 2026 at 10:52):Hello :wave:
Since I did not found a suitable Swift wrapper for wasmtime, I built one here :
https://github.com/OpenCow42/swift-wasmtime
It vendors the official Wasmtime C API artifacts for macOS, Linux, and Windows,
and exposes a small Swift 6 API with actor-isolated runtime helpers for safer use across Swift concurrency domains.
The goal is not to mirror every Wasmtime API one-for-one, but to provide a pragmatic SwiftPM-first package that is easy to consume from Swift projects while keeping the C ownership and threading rules explicit.
I’d be happy to get feedback :thumbs_up:
gianiac (May 23 2026 at 14:14):Hi Stitch, nice work! MANIFESTO and ROADMAP are super clear, and I really like the Sendable trap snapshots + the actor/low-level split.
Two quick questions, both around packaging:
Stitch (May 25 2026 at 13:40):@gianiac Thanks! Packaging is definitely the sharp edge here.
Today the intended/default model is static linking. The macOS and Linux vendored artifacts are libwasmtime.a; Windows vendors the upstream .lib/.dll.lib/.dll set, but the SwiftPM target links wasmtime by name, so the intended path is the static wasmtime.lib. The DLL is present because it comes from the upstream C API asset, not because the Swift wrapper currently relies on app-local DLL loading.
So for shipped apps, the current default should avoid most runtime-loader work: no bundled libwasmtime.dylib/.so, no app rpath/RUNPATH, and no Windows DLL search-path setup. On macOS the Wasmtime code is part of the final linked binary, so signing/notarization is handled with the containing app/binary rather than as a separate nested dylib.
If we add a dynamic distribution mode later, I’d want that to be explicit and documented per platform: @rpath plus nested signing/notarization guidance on macOS, app-local wasmtime.dll or a controlled DLL directory on Windows, and $ORIGIN RUNPATH/system package guidance on Linux. I should probably add a Packaging section to make the current static default and future dynamic caveat clearer.
gianiac (May 25 2026 at 18:03):Thanks for the detailed breakdown, static-by-default makes a lot of sense for the current scope.
Eduard Smet (Celarye) (May 28 2026 at 12:34):Nice work! I am not a Swift developer myself but know some Swift applications that currently implement plugin systems and could maybe benefit from WASM with the Component Model. Having an accessible component model supporting runtime available now is really nice!
I saw that this currently only targets Windows, macOS and Linux and was wondering what targeting iOS/iPadOS and other Apple operating system would look like? Is there anything that might block this, or has it just not been tested yet?
Stitch (May 31 2026 at 09:58):@Eduard Smet (Celarye) You are correct, it can work in interpreter mode on iOS devices. My need was macOS but I can make it work on mobile too.
I refactored the Apple slice to work with XCFramework, and made it work for iOS. I did made a quick hello world app in the iOS simulator that worked. I cannot speak for AppStore validation tho, since there is not JIT it should work but it is outside of my control.
I updated the 45.0.0 release and it now provides the mobile support : https://github.com/OpenCow42/swift-wasmtime/releases/tag/45.0.0
Eduard Smet (Celarye) (May 31 2026 at 10:10):Great to hear, thanks for putting in the work! Apple dissalowing JIT execution on these targets is a bit unfortunate, but being able to use the component model is already a huge win.
Last updated: Jun 01 2026 at 09:49 UTC