What’s New in Swift 6.4?

Library Updates

XCTest interoperability

Apple introduced Swift Testing at WWDC 2024 to take advantage of Swift’s rich type system and concurrency model. This allowed for better integration with Swift’s language features and enabled more expressive and efficient testing patterns. But let’s be honest — most codebases still have years of XCTest helpers and assertions they’re not about to rewrite overnight. One of the main obstacles to adopting Swift Testing in existing projects has been that it never quite played nice with XCTest. This made it challenging for developers to gradually migrate their existing XCTest-based test suites to Swift Testing without significant refactoring. For example, consider the following tests:

func assertUsername(_ name: String) {
  XCTAssertFalse(name.isEmpty)
}

@Test func testUsername() {
  // ✅ Pass unexpectedly
  assertUsername("")
}

class UserTests: XCTestCase {
  // ❌ Fails as expected
  func testUsername() {
    assertUsername("")
  }
}

XCTest assertions called from inside a Swift Testing test don’t always report failures correctly. In other words, an assertion could silently fail to fail. Swift 6.4 fixes that interop, so you can actually migrate a test suite over gradually instead of doing it all in one risky pass.

ProgressManager

If you’ve ever hand-rolled a progress bar across many async steps, you know it gets messy fast. Swift Foundation’s new ProgressManager fixes that. This new class gives you a way to manage and report progress in asynchronous Swift code that improves on the traditional Progress / NSProgress approach. Three pieces are involved:

• ProgressManager owns and advances progress, including weighted child work.
• Subprogress transfers a parent-assigned portion to a worker. The worker consumes it to start a child manager and reports completed units on that manager.
• ProgressReporter exposes read-only, observable progress for a UI or observer.

Say you’re building a game that downloads a level pack, unzips it, and then installs the assets. Each step contributes differently to the overall progress. You might decide that downloading accounts for 50% of the work, while unzipping contributes 30% and copying the assets accounts for the remaining 20%. You can use ProgressManager to track progress across all three tasks, assigning each its own weight:

func downloadLevelPack(manager: ProgressManager) async throws {
  try await download(subprogress: manager.subprogress(assigningCount: 50))
  try await unzip(subprogress: manager.subprogress(assigningCount: 30))
  try await copyAssets(subprogress: manager.subprogress(assigningCount: 20))
}

Now, each subprogress is assigned a weight, reflecting its contribution to the overall progress. The parent ProgressManager takes care of aggregating and reporting the progress from each subprogress. You can use manager.fractionCompleted to get the overall progress as a fraction between 0.0 and 1.0. Each subprogress also tracks its own progress independently. For example, if the download step consists of 10 chunks, you can report progress for each chunk downloaded:

func download(subprogress: consuming Subprogress) async throws {
  let manager = subprogress.start(totalCount: 10)
  for _ in 0..<10 {
    // The sample simulates a downloaded chunk with a short delay.
    try await Task.sleep(for: .milliseconds(150))
    manager.complete(count: 1)
  }
}

There's more to ProgressManager — custom units, cancellation, hooking it up to a SwiftUI progress view — but that's a full article on its own.

Standardized build system

Apple has invested in standardizing the build system for Swift. The result is Swift Build, a consistent, reliable way to build Swift projects across platforms. Before Swift Build, Xcode and Swift Package Manager had different ways of handling builds, which could lead to inconsistencies and platform-specific issues. Swift Build unifies the process, so builds behave the same way regardless of which tool triggered them.

Apple also added Software Bill of Materials (SBOM) support to Swift Build and SwiftPM, with CycloneDX and SPDX as the supported formats. SBOM gives developers and security teams a way to track their dependencies. That makes it easier to spot vulnerable dependencies or faulty releases quickly and apply patches before they cause bigger problems.

Other improvements

• Now you can use more natural optional any and some types, such as any Foo? and some Foo? instead of (any Foo)? and (some Foo)?.
• Apple officially released swift-subprocess 1.0.0. This library provides a Swift-native way to manage subprocesses, making it easier to run and interact with external commands from Swift code.
• Swift/Java interoperability has improved, including work that helps make Swift usable for Android development.
• C and C++ interoperability continues to improve.

Where to Start, and Where to go From Here?

None of this is revolutionary, and that's kind of the point — Swift 6.4 is a "fix the rough edges" release. Syntax gets a little easier, concurrency gets a little safer, and testing migration gets a little less painful.

If you're deciding what to actually adopt first, start with anyAppleOS and the memberwise initializer change. Both are drop-in with little risk. Reach for defer with await and cancellation shields the next time you cleanup code. And if you're straddling XCTest and Swift Testing, the interop fix alone is worth the upgrade.

The official release notes have the full list of changes. You can get details on every proposal that shipped in this release on the Swift Evolution dashboard for further reads.

Finally. here are some resources you should check:

• Moving from XCTest to Swift Testing
• WWDC26: What's new in Swift
• Migrate to Swift Testing