Wasmer adds a Swift SDK for running sandboxed Python and Node.js on iPhone

Why it matters

Wasmer is adapting its sandbox runtime to Apple's iOS constraints by relying on WebKit rather than bundling a separate Wasm compiler. That makes local developer tools possible inside Swift apps, but iOS 27 requirements, experimental status and the unreviewed demo leave distribution and performance claims to be proven.

Wasmer released a Swift SDK on September 23rd that lets app developers embed Wasmer sandboxes in iOS and macOS apps, bringing tools including Python, Node.js, FFmpeg and Clang onto Apple devices. The launch extends Wasmer's WebAssembly runtime into native Swift apps, with founder and CEO Syrus Akbary (@syrusakbary) presenting the release as another step toward running software across platforms.

https://x.com/wasmerio/status/2102849543260029379

Akbary built Wasmer around that portability thesis. Y Combinator describes him as the creator of the GraphQL Python community and notes that he was previously CTO at uSpeak and Try.com. The Swift SDK carries the same sandbox model into apps: create a sandbox, load a package and run a command, using a Swift interface built around async/await.

The most consequential limitation is in the iOS implementation. Wasmer's blog says the iOS backend requires iOS 27 or later, is experimental, and was demonstrated in simulator screenshots. Rather than bundling its own WebAssembly compiler or interpreter for iOS, Wasmer runs its WASIX environment inside a hidden WKWebView and uses the WebAssembly engine supplied by WebKit. A bridge connects that environment to Swift for host features such as DNS, TCP networking and file access, which Wasmer says are enabled only when explicitly requested.

That architecture gives the SDK a route around the friction of shipping a JIT compiler in an iOS app, but the X post's shorthand, "No JIT required," needs qualification. Wasmer's technical post describes using WebKit's existing WebAssembly engine; its own architecture diagram labels that engine "JIT + JSPI." The claim is that developers need not ship a separate Wasm compiler or interpreter in their app, not that no JIT engine is involved anywhere in execution.

Wasmer says its example WasmerShell app can run Python and Node.js servers, frameworks including FastAPI and Next.js, and command-line tools such as FFmpeg and yt-dlp. The plain Python and Node.js server examples require no pip or npm dependencies, according to the company; framework examples require developers to install their dependencies. Wasmer's X thread also says the demo app has not yet been submitted to Apple's App Store review, while asserting that its sandboxed use of public APIs should pass review. That is the company's expectation, not an approval or a demonstrated distribution outcome.

Wasmer's announcement also groups iOS and macOS under one Swift package and shared core API, but the underlying runtimes differ. On macOS, the SDK uses Wasmer's native runtime through UniFFI, and can use Wasmer's JIT; the blog lists macOS 12 and later as supported. On iOS, the WebKit-based route is required. Wasmer cautions that optional capabilities, including terminal support, directory mounts and HTTP previews, are not necessarily available on both backends.

The company reports a score of 20,408 on the Richards JavaScript benchmark, about 5% below what it calls a native JavaScript environment on a desktop. The post does not identify the phone model or provide enough benchmark methodology to generalize that comparison to other devices or workloads. "Near-native" is therefore a company-reported result for one benchmark, not a broad performance guarantee.

The practical pitch is local execution: an app can bundle a sandboxed runtime and run tools on the device rather than sending code or files to a server. That could suit apps that need scripting, media processing or an embedded development environment. But local execution does not mean network access is impossible; Wasmer's own design includes network host services when an app explicitly enables them. The SDK gives app developers a way to mediate those capabilities, and the app's design still determines what the sandbox can reach.

The code and examples are available in the Wasmer SDK repository. For iOS developers, the release is an early route to shipping WebAssembly-backed tools within a native app, with iOS 27 compatibility, experimental status and App Store review still central to whether the demo becomes a broadly usable product.