Swift 6.4 makes Swift Build the default and speeds browser bridging

Why it matters

Swift 6.4 addresses practical barriers to using Swift outside Apple apps by standardizing package builds across operating systems and improving language boundaries, browser performance, Android support and embedded tooling.

Swift released Swift 6.4 on September 15th, making Swift Build the default build system in Swift Package Manager and extending the language further into browsers, Android, embedded devices and codebases written in C++, Java and Kotlin.

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. Borla also served as release manager for the Swift compiler, SourceKit-LSP, IndexStoreDB, Swift Syntax and Swift Stress Tester during the 6.4 cycle.

The personnel matter because Swift 6.4 is the product of a long release process spread across language design, compiler engineering, package management and platform support. According to the project's release plan, the 6.4 branch was scheduled to split from the main development branch on May 4th, followed by a tightly restricted 6.4.0 branch on August 25th.

That work produced a release whose central bet is consistency. Swift already had ambitions outside Apple's operating systems. Swift 6.4 concentrates on removing the build, interoperability and tooling friction that makes those deployments feel secondary.

One build system across Linux, macOS, and Windows

Swift Build is now the default build system in Swift Package Manager. The project says the change gives Swift projects the same underlying build behavior on Linux, macOS and Windows, reducing a source of platform-specific differences for package authors and infrastructure teams.

Swift Package Manager can also generate software bills of materials in SPDX or CycloneDX formats. That addition is less visible than a language feature, but it places dependency documentation inside the standard Swift workflow rather than leaving it to a separate compliance tool.

The Subprocess library has reached version 1.0 after an initial 0.1 release in 2025. Built around Swift concurrency, Subprocess gives command-line tools, servers and other applications a cross-platform API for launching programs, collecting output and interacting with streaming processes. Stabilizing that API fills a practical gap for developers using Swift away from conventional Apple application interfaces.

Editor support is widening through the Swift extension's availability on Open VSX, including Cursor, Antigravity and Kiro. Swiftly integration allows developers to select and manage toolchain versions from the extension.

Swift presses further into other languages

Swift 6.4 expands the boundaries where teams can introduce Swift without rewriting an existing codebase.

Swift's Span type now bridges directly to C++20's std::span, allowing values to cross the language boundary without handwritten conversion code. For C projects, the new @c and @implementation attributes let Swift functions provide implementations for C declarations while retaining safer Swift wrappers around lower-level interfaces.

The Swift and Java interoperability project adds support for async and throwing functions in protocol and callback wrappers. It also maps closures to Java's Runnable, imports variadic parameters and supports Java record types. Because the bridge works with Java and Kotlin, the changes give Android teams another route for introducing Swift modules alongside existing application code.

In its release announcement, the project says safe WebAssembly bridging through JavaScriptKit can be up to 40 times faster than the earlier dynamic approach. The release does not provide an independent comparative benchmark for that claim.

The WebAssembly SDK is now distributed through Swift.org's Swift installation page, so developers can add it to an existing installation instead of assembling a separate toolchain. The distribution change may prove as consequential as the benchmark: faster bridging has limited value if teams cannot reproduce the environment easily.

Ownership features move into ordinary code

Several Swift 6.4 additions continue the language's push to reduce copies while preserving memory safety. UniqueArray can store non-copyable elements without the copy-on-write allocation behavior of the conventional Array. The official release announcement describes UniqueBox as a smart pointer that uniquely owns a heap value, including a non-copyable value, without reference counting.

The new Iterable protocol lets code borrow elements during iteration instead of copying each value. The release describes Ref and MutableRef as first-class references for borrowing or mutating one value at a time. It also says non-copyable types can conform to Equatable, Comparable and Hashable.

According to the release announcement, Embedded Swift adds generalized existential types, including any Protocol, and richer error handling that permits throwing and catching any Error. These additions make it easier to express ordinary Swift designs on microcontrollers without abandoning the language's type system at the edge.

Everyday language changes include optional some and any types without extra parentheses, warning controls through the @diagnose attribute and module selectors for resolving APIs with conflicting names. Async functions can run inside defer blocks, while cancellation shields let cleanup operations finish after an enclosing task receives a cancellation request.

Swift began as an Apple language in 2014 and became open source on December 3rd, 2015. Swift 6.4 continues the expansion promised by that decision, with less emphasis on a single headline syntax feature and greater attention to the plumbing required for one language to work across operating systems, processors and existing codebases.

Adoption outside Apple's platforms remains the test. Swift 6.4 gives maintainers stronger build and interoperability tools; developers will determine whether those tools are enough to make Swift a routine choice for servers, browsers and embedded hardware rather than an Apple language that can also run elsewhere.