Swift for Wasm September-October 2025 Updates

Max_Desiatov · October 31, 2025, 12:11pm

I'm excited to share an update on the latest progress in the Swift for WebAssembly ecosystem! Last two months of community's work were mainly focused on polishing the Swift toolchain, developing new features in our primary packages (namely JavaScriptKit and WasmKit), while also porting existing Swift libraries to Wasm.

Here’s a list of notable changes prepared with help from @kateinoigakukun, @krodak, and @scottm:

Swift Toolchain

Fixed SwiftPM passing incorrect CLI arguments to WasmKit when running swift test with Wasm Swift SDK;
Updated Swift toolchain docs/WebAssembly.md instructions for local builds of Wasm Swift SDK with a development toolchain;
Updated "Getting Started with Wasm" page on swift.org for 6.2 release;
Significant linker memory footprint and link time reduction: #84784;
@_expose(wasm) serialization crash fix cherry-picked for future 6.2 patch releases;
import WASILibc support for Embedded Swift cherry-picked for 6.2.1 patch release;
swift-cmark (a dependency of swift-markdown, swift-docc, and swift-format) had WASI build support cherry-picked for 6.2 branch, also included in the 0.7.1 SemVer tag;
Checks for swift run command with Wasm Swift SDK in swift-integration-tests.

JavaScriptKit

Most of the changes were made in the BridgeJS plugin improving interoperability between Swift and JavaScript/TypeScript:

New Features:

Added Swift -> JS protocol support #460 #456;
Added Swift -> JS default parameter value support #453;
Added Swift -> JS static/class properties & functions support #448;
Added Swift -> JS Optional support #444;

Improvements / Fixes:

Migrated to code fragment printer #442;
Switched to direct TypeSyntax initializer #445;
Fixed nested type resolution for MemberTypeSyntax #433;

WasmKit

One of our goals for WasmKit is to enable first-class Swift for Wasm debugging support when using LLDB. This is still early days, but we had some significant progress:

Added GDB Remote Protocol support with LLDB extensions;
Added breakpoint instruction to internal WasmKit VM bytecode;
Implemented qWasmCallStack debugger host command and basic breakpoints support;
Implemented basic instruction stepping support in the debugger.
Added --debugger-port CLI option to wasmkit run command when WasmDebuggingSupport package trait is enabled.

Some other relevant small improvements worth mentioning:

Implemented parsing of atomic load/store instructions from the WebAssembly multi-threading proposal;
Clarified required Swift version, list of supported platforms, and SwiftPM package usage instructions in README.md;
Added broader CI matrix for building and testing on Android, covering Swift 6.2 and main development snapshots.
Enabled Swift 6 mode and fixed all remaining Swift Concurrency warnings;
If you ever wanted to put a Wasm runtime into your Wasm runtime (e.g. for developer tooling or for implementing Wasm feature compatibility shims), WasmKit Wasm runtime now can be built for WASI and can run nested in a separate Wasm runtime;
WasmKit successfully builds on CI with SwiftPM on Swift Build when using main development snapshots.

Other Projects

DispatchAsync – New community workaround for compiling Swift that uses import Dispatch to Wasm. Provides DispatchQueue, DispatchGroup, DispatchSemaphore, DispatchTime, and DispatchTimeInterval as a drop-in replacement for Dispatch, implemented using Swift Concurrency;
swift-distributed-tracing – Introduced CI checks for WebAssembly compilation #175. Compilation fixes were merged previously in #174;
WebKit – Added WebAssembly debugging support via Remote Web Inspector.

Improvements prior to September 2025

There were a few notable improvements made that didn't end up included in the previous Q3 update, listed below for completeness:

GraphQLSwift/DataLoader – Enabled Wasm compilation #23, and integrated Wasm builds into CI #26;
vapor/sql-kit – Enabled Wasm compilation #190;
vapor/ci added Wasm CI build support to Vapor #54;
JavaScriptKit – Added Swift -> JS case / raw / namespacing / associated value enums support #436 #418 #455;
JavaScriptKit – Macro extension to define JS namespace #405;

Thank you for reading, and please feel free to add any comments or suggestions if we missed anything!

Joshua · October 31, 2025, 6:03pm

when emscripten support？

Troy_Harvey · November 1, 2025, 12:27am

Excellent work Max, Scott, Krzysztof, and Yuta. Great to see Swift WASM accelerating!

kateinoigakukun · November 1, 2025, 3:21pm

Would you mind elaborating on what you meant by "emscripten support"? Anything you want to use from the Emscripten toolchain?

ktoso · November 2, 2025, 3:07am

Pretty funny idea with DispatchAsync! Why not I guess, it’s kinda neat you can inverse it like that and this way get source compatible with libs which did use dispatch still huh

Joshua · November 2, 2025, 7:32pm

Long JMP / exceptions. The WASI implementation is not supported in most browsers.

FlorianPircher · November 5, 2025, 8:43pm

I wanted to try import WASILibc support for Embedded Swift, but the download code (Swift SDK Bundles → WebAssembly → Copy install command) on the Install Swift - macOS | Swift.org website gets me a 404:

$ swift sdk install https://download.swift.org/swift-6.2.1-release/wasm/swift-6.2.1-RELEASE/swift-6.2.1-RELEASE_wasm.artifactbundle.tar.gz --checksum 482b9f95462b87bedfafca94a092cf9ec4496671ca13b43745097122d20f18af
Downloading swift-6.2.1-RELEASE_wasm.artifactbundle.tar.gzError: badResponseStatusCode(404)

Same 404 address for the Download Wasm SDK link.

Same 404 address here: Getting Started with Swift SDKs for WebAssembly | Swift.org

Max_Desiatov · November 5, 2025, 10:43pm

The issue has been fixed, would you be able to try again? Thanks!

(The article itself is updated in a separate PR).

FlorianPircher · November 5, 2025, 10:53pm

It works, thank you!

(And with swift-6.2.1-RELEASE_wasm-embedded I can now enjoy easy access to trigonometry!)

kateinoigakukun · November 6, 2025, 2:31am

Thanks for sharing.

setjmp/longjmp is supported in recent versions of wasi-libc, and the wasi-libc bundled in our Swift SDK for Wasm includes that support in theory.
You can give it a try by passing a few extra LLVM flags to the Swift compiler: -Xllvm -wasm-enable-sjlj -lsetjmp -Xllvm -wasm-use-legacy-eh=false
More details are available here: wasi-sdk/SetjmpLongjmp.md at main · WebAssembly/wasi-sdk · GitHub

That’s true. Browsers don’t natively implement WASI (just like they don’t natively support the Emscripten system interface either).
However, there are a few WASI shim implementations available, such as:

Currently, we only rely on a few basic WASI interfaces (clock, random, and basic filesystem access), and they’re fairly straightforward.
Having a (relatively) well-defined and clean system interface like WASI has been helpful so far.
At this point, there’s not much we could directly reuse from Emscripten, but I’m definitely open to exploring that direction if it turns out to be useful.