Swift 6.4 Lands: Swift Build Goes Default, Wasm Gets 40x Faster

Swift 6.4 shipped from Apple's open source Swift project today, September 15, and the change developers will actually feel first isn't a new keyword. It's that Swift Package Manager now builds with Swift Build by default, the same engine across Linux, macOS and Windows, so swift build finally means the same thing everywhere. The release also cuts WebAssembly output up to 40 times faster in some workloads, extends interop with C++ and Java, and adds a run of new non-copying collection types. None of it needed a major version bump. It's still Swift 6, four minor releases in.

• Swift Build replaces the old per-platform build engine as SwiftPM's default, giving Linux, macOS and Windows consistent build behavior for the first time.
• WebAssembly compiled through Swift runs up to 40x faster in some workloads, per today's swift.org release notes, building on the WASI and JavaScriptKit work previewed at WWDC26 in June.
• C++20's std::span now bridges directly to Swift's Span, and Swift/Java interop gains support for async functions and callbacks.
• New memory-safe collection types, RigidArray and UniqueArray, plus a UniqueBox smart pointer, extend Swift's ownership model without reaching for an unsafe API.

What actually changed in Swift Package Manager?

Swift Build started life as the engine behind Xcode's own builds, and Apple open sourced it in 2025 so the wider Swift toolchain could eventually share it. With 6.4, that plan finishes: SwiftPM now reaches for Swift Build first on every supported platform, instead of falling back to whatever build path a given OS happened to support best. That matters more than it sounds. A team running CI on Linux and developing on macOS has historically had to account for build behavior drifting between the two. A single shared engine closes that gap by construction, not by convention. If your project ships a custom build plugin or leans on quirks of the old default, this is the release to test against before it becomes the only path.

RelatedJava 27 Ships With Post-Quantum TLS and Default G1 GC

Why is Swift suddenly 40 times faster at WebAssembly?

Swift's WebAssembly story has been building since the SwiftWasm and WASI work started showing up in Swift's toolchain a few releases back, and 6.4 is where that investment starts paying out in raw numbers. Swift.org's release notes cite performance gains of up to 40x on some workloads targeting WebAssembly, alongside continued work on JavaScriptKit, the bridge layer that lets compiled Swift call into browser JavaScript. A 40x figure on "some workloads" is not a blanket claim, and the release notes don't spell out which benchmarks produced it, so treat it as a ceiling rather than an average. Still, it's the kind of number that changes whether compiling Swift to run client-side in a browser is a curiosity or a viable option for a team that already has a Swift codebase and doesn't want to maintain a second one in JavaScript or Rust.

What's new for teams bridging Swift into C++ and Java codebases?

Two separate interop stories moved forward. On the C++ side, C++20's std::span now bridges straight into Swift's own Span type, meaning code that passes a bounded view over a C++ buffer doesn't need a hand-rolled pointer-and-count pair to cross the language boundary safely. On the Java side, the Swift-Java interop project (mentioned in Swift 6.4's WWDC26 beta preview back in June) now supports calling async functions and passing callbacks across the boundary, not just synchronous calls. Both changes target the same audience: large codebases doing an incremental migration rather than a rewrite, where the language boundary needs to disappear as much as possible for the transition to be worth doing at all.

Who should actually care about the Android and embedded changes?

The Android SDK now builds against NDK 30 and ships availability attributes, which lets Swift code targeting Android use API-level checks the same way it already does on Apple platforms, catching a call to something that doesn't exist on a device's Android version at compile time instead of at a crash log. Embedded Swift, the restricted subset built for microcontrollers and other resource-constrained targets, picks up existential type support and better error handling in the same release. Neither change is glamorous, but both close gaps that have made Swift a harder sell outside Apple's own platforms, which is the entire point of the Swift on Server and Swift Everywhere pushes the project has been running for the last few years.

RelatedRolldown 1.0 Lands in Vite 8: One Rust Bundler to Rule Them

Should you actually upgrade today?

If your project's build already leans on the newer Swift Build toolchain, or you've been waiting on faster WebAssembly output before committing to a browser target, 6.4 is worth pulling now. If you maintain a custom SwiftPM plugin, a hand-tuned CI pipeline, or anything that pokes at the build system's internals rather than going through the documented plugin API, budget time to test it against the new default before rolling it out broadly. Swift's toolchain has generally been forgiving about minor-version upgrades since the 6.0 language mode settled in, and nothing in today's notes reads as a breaking change for ordinary application code. The build-engine swap is the one place where "ordinary" stops applying.

Our take

Swift 6.4 doesn't have a single feature that makes for a punchy keynote slide, and that's arguably the point. Replacing SwiftPM's default build engine and shipping a 40x WebAssembly gain in the same release without touching the major version number is what a language does when it's confident enough to spend a cycle on infrastructure nobody asked for by name. Apple has been running this playbook since the 6.0 language mode landed: keep the surface syntax stable, keep pushing hard on the platforms Swift doesn't own by default. Server-side Swift, Android, WebAssembly and embedded targets all got something in this release, and none of them got a demo-friendly feature. That's a deliberate bet that the audience outside Apple's own platforms is worth building for on its own terms, not just as a port of what already works on iOS.

Original analysis by GenZTech. Source: Swift.org.