Swift for WebAssembly Broke Everyone's Build Scripts

Swift for WebAssembly had a bunch of updates in Q3 2025. Some are great, some will break your CI. Here's what you need to know so you don't spend your weekend debugging build failures.

The Triple Name Change That Broke Everything

Swift renamed wasm32-unknown-wasi to wasm32-unknown-wasip1. If you're using --triple anywhere in your build scripts, CI configs, or deployment tools, it's gonna break with a confusing error about unknown targets.

The rename makes it clear they're using WASI Preview 1, which is fine, but why break existing builds for naming clarity? They're preparing for WASI Preview 2 (wasip2) but that's not here yet.

If you use --swift-sdk instead of --triple, you're fine. If not, time to grep through your entire build system and update everything. Fun weekend project.

Foundation Finally Works (Mostly)

Foundation is now included in Swift SDK for WebAssembly. This is huge because before this, porting Swift apps to WASM meant rewriting all your JSON parsing, HTTP calls, and file handling from scratch.

Embedded Swift still doesn't get Foundation because they're optimizing for tiny binaries. Makes sense but sucks if you need both small size and basic libraries.

I wasted way too much time porting our API client before Foundation support existed. Still fighting some weird compilation issues but at least I didn't have to rewrite the entire thing.

CI That Actually Tests WASM

The swiftlang/github-workflows now has enable_wasm_sdk_build and enable_embedded_wasm_sdk_build flags. Finally, libraries can test WebAssembly compatibility in CI instead of discovering breakage when users complain.

Swift's core libraries are already using this. Good, because nothing's worse than a "works on my machine" library that fails to compile for WASM.

Before this, WASM support was basically "maybe it works, maybe it doesn't, try it and see." Now libraries can catch WASM breakage before shipping.

LLDB Debugging That Doesn't Suck

LLDB now supports WebAssembly debugging upstream. Finally you can set breakpoints and inspect variables instead of adding print() statements everywhere like a fucking caveman.

It'll be in Swift LLVM 21. Debugging WASM won't require guessing what went wrong based on cryptic runtime errors anymore. Same LLDB commands you already know.

Before this, debugging Swift WASM was like debugging with your eyes closed. This is probably the most useful improvement for actually getting work done.

Supporting Libraries Getting Better

WasmKit 0.1.6 added Android support but dropped Swift 5.9. If you're still on 5.9, time to upgrade or get left behind.

JavaScriptKit (0.31-0.35) got a bunch of improvements:

• Better JSClosure APIs for concurrency that actually work
• JavaScriptFoundationCompat module for bridging Foundation types
• Enhanced Embedded Swift support
• BridgeJS improvements for JS/TypeScript interop

JavaScriptKit was always a bit finicky for complex JS integration. The new versions are much more stable and less likely to crash when you need to do anything beyond basic function calls.

I wasted way too much time trying to get Swift's async/await working in WebAssembly. Three months later, after countless "this should work" moments, embedded concurrency actually makes it possible. Finally don't have to choose between Swift's concurrency model and actually shipping to WASM.

Why Regular Swift Concurrency Doesn't Work in WASM

Embedded Swift concurrency fixes the nightmare of getting Swift's actor model working in WebAssembly. Regular Swift concurrency needs a full runtime with thread pools and complex scheduling—exactly the kind of heavyweight shit that makes WASM crash and burn. The Swift concurrency manifesto explains why the standard approach is too heavy for constrained environments.

The implementation works with Swift development snapshots using swift run, but don't expect everything to work. Task.sleep is missing because the team is still figuring out how to make timers work in WASM without breaking everything. The Swift forums track which async functions actually work.

Before this, WebAssembly was basically just for math-heavy kernels. Now you can build actual apps with complex async flows instead of fighting the platform every step of the way.

JavaScript Event Loop Integration That Actually Works

The JavaScriptEventLoop integration is where this gets interesting. Our image editor was stuck in callback hell trying to coordinate GPU work with UI updates. Now Swift async/await talks directly to the browser's event loop without the constant marshaling bullshit. Still fighting some edge cases but way better than before.

What this actually means for your app:

• DOM events work properly: Click handlers don't freeze the browser while your Swift code runs. MDN's event handling docs explain why this matters.
• GPU + UI coordination: WebGPU compute shaders can update the UI smoothly instead of stuttering every frame. WebGPU examples show the visual difference.
• Streaming without blocking: Process large datasets without making the page unresponsive. Streams API integration handles backpressure correctly.
• Network requests that don't suck: Fetch API calls work with Swift async/await instead of callback hell.

Swift keeps its type safety while talking to JavaScript's event system. No more choosing between safety and actually working with the browser. JavaScriptKit documentation covers the interop details.

Why It's Actually Fast (And When It's Not)

Embedded concurrency in WASM skips most of the performance-killing overhead that makes regular threaded apps slow as shit. No context switching, no thread creation costs, no complex locks. But WebAssembly's linear memory model means you have to think differently about shared state.

The deterministic execution model makes performance more predictable, which is huge for real-time apps. Our audio processing pipeline used to have random stutters from thread scheduling; now it's way more consistent. The WebAssembly performance guide explains why single-threaded can beat multi-threaded.

Debugging Actually Works Now

The debugging integration isn't perfect but it's way better than the nothing we had before. LLDB can see task states and async call stacks without crashing half the time.

Chrome DevTools can set breakpoints in async Swift functions, which used to be impossible. Still buggy as hell but when it works, you can actually trace what's happening in your concurrent code.

Carton is Dead, Use SwiftPM Plugins

Carton was always a hack. The Q3 updates finally give us a real solution with SwiftPM plugins from JavaScriptKit.

swift package js generates ES modules and WASM files directly without external dependencies. Way more reliable for CI/CD since you don't have to mess with Node.js versions and npm's bullshit dependency resolution.

What's Still Broken

Task.sleep and timers are still missing because the team can't figure out how to make them work in WASM without breaking everything. So don't expect any timer-based code to work properly yet.

Threading support is "coming" but who knows when that'll actually land. For now, just don't expect real threading - it's single-threaded concurrency only.