Swift 6.4 swaps the build engine under every SwiftPM package by default

Swift Build takes effect the first time someone runs a build with the 6.4 toolchain ^[2]. Everything else on the list waits for a source edit: the `Span` bridge to C++20's `std::span` ^[13], the new `@c` and `@implementation` attributes ^[14], the Java callback wrappers ^[15], `UniqueArray` storing non-copyable elements without copy-on-write allocation ^[20].

The project's case for the switch is consistency. It says the change gives Swift projects the same underlying build behavior on Linux, macOS and Windows, removing a source of platform-specific differences for package authors and infrastructure teams ^[3]. Joseph Heck, who works on Swift through Apple's Open Source Program Office, and Holly Borla, engineering manager for Apple's Swift language team, laid out the changes in the official release announcement ^[4]. Borla was also release manager for the compiler, SourceKit-LSP, IndexStoreDB, Swift Syntax and Swift Stress Tester through the 6.4 cycle ^[5].

Same engine on three platforms is a statement about the engine. If a build step leaned on the previous system's behavior, say a plugin's working directory or the order in which resources land in a bundle, convergence is what moves it. The announcement documents no way to select the old build system ^[21]. It does describe toolchain version management: Swiftly integration in the Swift extension lets developers select and manage toolchain versions ^[12]. The extension is now on Open VSX, including Cursor, Antigravity and Kiro ^[11]. In CI the equivalent lever is pinning the toolchain in the build image, and that decision comes before 6.4 arrives.

The project's release plan set the 6.4 branch to split from the main development branch on May 4th, with a tightly restricted 6.4.0 branch on August 25th ^[6]. That is 113 days of ordinary branch work, then 21 days from lockdown to the September 15th release ^[7][8].

The JavaScriptKit multiple shows up in a browser workload only if the JavaScript boundary sits on the hot path and the code being replaced is the dynamic bridging the project measured against ^[17]. A team that already hand-tuned its glue is comparing against a different baseline. The distribution change is easier to rely on: the WebAssembly SDK now comes from Swift.org's Swift installation page, so a build image can add it to an existing installation instead of assembling a separate toolchain ^[19].

For teams running Swift away from Apple application interfaces, Subprocess reaching 1.0 after its 0.1 release in 2025 matters more than any of it. Command-line tools and servers now have a stable cross-platform API for launching programs and reading streaming output ^[10]. Android work goes through the Java bridge, which covers Kotlin as well. It now handles async and throwing functions in protocol and callback wrappers, maps closures to `Runnable`, imports variadic parameters and supports Java record types ^[15][16]. SwiftPM will also emit SPDX or CycloneDX bills of materials ^[9].