Swift 6.4 shipped on September 15, 2026, and the change most likely to touch your CI pipeline is buried in one sentence: Swift Build is now the default build system in Swift Package Manager. Swift.org's release post says projects now build the same way on Linux, macOS, and Windows, with no opt-out mentioned in the post itself. That's the whole pitch. Nothing in the announcement flags a compatibility risk. Two issues filed against the swiftlang project since June tell a different story, and if your CI touches remote dependencies or a Wasm target, you should read them before you bump the toolchain version.
What Swift 6.4 actually shipped
The default-build-system swap is the one change that can break a pipeline, but it isn't the only line in the release notes. Subprocess, the cross-platform subprocess library built on Swift concurrency, reaches 1.0. Optional some/any types no longer need parentheses, so (some Rocket)? can now be written as some Rocket? under SE-0521. :: module selectors, under SE-0491, let you disambiguate two identically named types pulled in from different imports. Async code inside a defer block now runs to completion and is awaited before the block exits, under SE-0493. C++20's std::span bridges to Swift's Span type without a manual conversion. And Java/Kotlin interop gets wider: async and throwing functions now work in protocol and callback wrappers, closures map automatically to Runnable, variadic parameters import cleanly, and Java record types are supported.
That last item matters beyond the release notes. Teams already weighing whether to consolidate iOS and multiplatform work under Kotlin Multiplatform instead of a pure Swift stack should watch how far Apple keeps pushing that interop surface. None of the rest of this list requires a decision. They're either genuine improvements with no migration cost or defaults you don't need to configure.
The release notes call it additive. Two real-world CI failures say otherwise
Swift.org's post frames the Swift Build default switch as a portability win, full stop. It doesn't mention a workaround, a caveat, or a single edge case. That's the framing you get from a release announcement, not from a project's own bug tracker. Everything past this point comes from issues filed against swiftlang's repositories on GitHub, not from Apple or the swift.org post, and it carries a different kind of weight: these are reproductions filed by working engineers, not a vendor's own claims about its release.
It's the same split that came up when Kotlin 2.4.20 shipped its own Wasm breaking change this release cycle: most of a release is safe to ignore, and one or two lines force an actual decision. Sort by which is which before you upgrade, not after your CI job turns red.
What breaks: two confirmed issues
-Xswiftc -warnings-as-errors fails on any project with dependencies
The stronger report is an open SwiftPM issue on warnings-as-errors propagation to dependency targets, filed June 11, 2026, and still unresolved as of this writing. A common CI pattern is passing -Xswiftc -warnings-as-errors so first-party warnings fail the build. Under the swiftbuild backend, that flag also gets applied to remote dependency targets, which already receive -suppress-warnings by default. The driver rejects the conflicting pair outright, and the build fails, even when the dependency itself has zero warnings. The native build system stripped the flag from dependency targets before compiling them; Swift Build doesn't, and the issue documents this as a regression against SE-0480's remote-targets behavior.
It isn't theoretical. Swift-nio's CI broke when the project moved to a Swift 6.4 nightly toolchain, which is about as close to a real-world confirmation as an open issue gets.
Wasm builds fail with a Darwin-style linker invocation
The other report looks like two separate issues if you only skim GitHub search results. It isn't. A project targeting wasm32-unknown-none-wasm built fine on Swift 6.3.3 and then failed on 6.4 with wasm-ld: error: unknown argument: -reproducible and a string of related linker errors. The build system was invoking the linker with Darwin-style flags, -reproducible, -filelist, -dependency_info, that wasm-ld doesn't understand.
It was filed as swift-package-manager#10543 on September 15, 2026. GitHub's own transfer redirect shows that's the same issue as the swift-build repo's tracking thread for the failure, just moved between repositories during triage, not a second independent report. A contributor confirmed the reproduction and posted the workaround on September 17, 2026: pass --build-system native to swift build. The issue closed on September 21, 2026, and it closed because of a merged swift-build pull request that stops the linker defaulting to Darwin-style flags on none-OS targets, a genuine source fix rather than a documented workaround. That fix isn't in any shipped Swift toolchain, though: Swift 6.4 shipped on September 15, 2026, six days before the pull request merged. If you're building on the released 6.4 toolchain, you still need --build-system native today, not because no fix exists, but because the fix landed after the release.
How to validate your build before and after the switch
1. Reproduce your current CI build on Swift 6.3 first
Establish a known-good baseline before you touch the toolchain version. If something fails after the upgrade, you want it attributable to Swift 6.4, not to drift that had already crept into your pipeline.
2. Run swift build --build-system swiftbuild locally before you touch CI
This forces the new default explicitly, on your current toolchain, so you see the failure mode on your own machine before a CI job surfaces it for you at a worse time.
3. Grep your CI scripts and Package.swift for -Xswiftc -warnings-as-errors and similar flags
If you find it and your project has any remote (SCM or registry) dependencies, expect the conflict described in issue #10192 until it's resolved upstream.
4. If you ship a wasm32 target, build it specifically, not just your primary platform
The linker failure only shows up on that triple. A green build on macOS or Linux tells you nothing about whether your Wasm target still links.
5. Keep --build-system native as a documented fallback in your CI config
Don't leave it as a one-off command someone remembers under pressure. Put it in the pipeline config as a named fallback until both issues covered here are resolved upstream.
If you're staffing up Swift and iOS engineering right now, put this checklist in the onboarding doc. A new hire who upgrades the toolchain without knowing about either issue will spend an afternoon debugging a linker error that has nothing to do with their code.
FAQ
Can I still use the native build system in Swift 6.4?
Yes. swift build --build-system native still works and is the documented workaround for both issues covered here.
Is the Wasm build failure fixed?
Yes, but not in the 6.4 toolchain you already have. Swift Build's merged fix for the Darwin-style linker flags on Wasm targets closed the issue on September 21, 2026, six days after Swift 6.4 shipped on September 15. Until a toolchain ships with that fix included, keep using the --build-system native workaround a contributor posted on September 17, 2026.
Does the warnings-as-errors problem affect Xcode builds too, or just CI?
The reported failures are all swift build and CLI invocations, including swift-nio's CI. The bug is in how the swiftbuild backend applies -warnings-as-errors and -suppress-warnings together on remote dependency targets, not something specific to Xcode's GUI, so any invocation that passes that flag is exposed.
What else shipped in Swift 6.4 besides the build system change?
Subprocess reaching 1.0, parenthesis-free optional some/any types, :: module selectors, async code in defer blocks, C++20's std::span bridging to Span, and expanded Java and Kotlin interop. None of it requires a migration step on its own.