One build engine becomes the default across platforms
Swift 6.4 makes Swift Build the default build engine used by Swift Package Manager on macOS, Linux and Windows. The change replaces the previous split in default package-build paths with one engine across the three major host platforms, so the same SwiftPM project is planned and built through Swift Build whether it is being developed on an Apple machine, Linux server or Windows workstation.
This is a toolchain change rather than a promise that every package now behaves identically on every operating system. Packages can still contain platform-specific dependencies, build plugins or native code that only work on selected targets, and Swift.org does not claim universal compatibility. The material change is that SwiftPM itself now chooses the same build engine by default across those environments.
SBOM generation moves into Swift Package Manager
Swift 6.4 also implements SE-0509, adding built-in Software Bill of Materials generation to SwiftPM. Developers can ask swift build to emit CycloneDX or SPDX JSON inventories and can generate an SBOM for a package or individual product. SwiftPM can combine its resolved package graph with Swift Build's dependency graph so the result reflects dependencies actually used by a build rather than only what appears in Package.swift and Package.resolved.
The proposal documents important limits. If an SBOM is generated without the Swift Build dependency graph, SwiftPM warns that the result is based only on the package graph and may include dependencies that were not part of the built artifact. The feature inventories software components and dependency relationships; it does not by itself prove that a dependency is trustworthy, vulnerability-free or reproducibly built.
The release broadens the cross-platform runtime surface
Subprocess reaches 1.0 in the same release, giving Swift a stable cross-platform concurrency-based API for launching and interacting with child processes. Swift 6.4 also extends C++ interoperability by bridging Swift Span with C++20 std::span, expands Java and Kotlin interop, and brings Swift Build support to the Android Swift SDK path.
WebAssembly and Embedded Swift also receive substantial work. Swift.org reports that JavaScriptKit safe bridging can be up to 40 times faster than the earlier dynamic bridge, while the WebAssembly SDK is available directly through Swift.org. Embedded Swift adds broader existential-type and error-handling support. The 40-times figure is a maintainer measurement for a specific bridging path, not evidence that WebAssembly applications written in Swift are generally 40 times faster.
Why it matters and what remains to be tested
For Swift teams outside a purely Xcode-managed workflow, the release reduces build-system divergence while adding a first-party supply-chain inventory mechanism. Those two changes are especially relevant to CI, server-side Swift and organisations that need the same package tooling on developer machines and non-Apple build hosts.
The useful next evidence will come from real package estates: whether Swift Build exposes regressions in complex mixed-language projects, how stable the generated SBOMs are in continuous integration, and whether the new Android and WebAssembly paths hold up across production workloads. Swift 6.4 establishes the shipped capabilities; broad performance and compatibility conclusions still need downstream testing.