Swift Release Notes

When your Swift program hits a breakpoint and stops so you can inspect it, the debugger’s expression evaluator has to find the exact Swift module your code was built from. Until now, that lookup wasn’t always precise. The upcoming Swift 6.4 release will include changes, begun in Swift 6.3, that address this by updating how the Swift compiler references explicitly-built Swift modules in debug info.

The majority of developers will automatically benefit from faster, more reliable debugging and smaller build products, without any modifications to their SwiftPM or Xcode projects.

For developers who maintain their own build systems using, for example, Bazel, Buck, or CMake, some adjustments may be necessary to take advantage of these changes.

This article explains how the debugger uses Swift modules. Next, it describes how Swift 6.3 changes the way modules are tracked in debug info to solve several problems with the previous representation. Finally, it shows how to adjust build systems to take advantage of the new representation and eliminate some build steps that are no longer necessary.

Swift modules and expression evaluation

LLDB’s standout feature is its powerful expression evaluator. Because LLDB embeds the Clang and Swift compilers, it can JIT-compile any valid source code and run it in the context of your application while stopped at a breakpoint. This includes not just calling code in your application, but also defining new data types, functions, and closures. Debugging features that are usually reserved for interpreted or JIT-compiled languages like JavaScript become available to ahead-of-time-compiled languages like C++ and, of course, Swift!

In order to JIT-compile user expressions that make use of data types defined in the debugged program, LLDB’s embedded Swift compiler needs to import the Swift modules defining those types. In a world before explicitly-built modules, LLDB would find the base name of the main module at the current breakpoint in the debug info and then kick off an implicit import of a module with that name. With a cold module cache this would launch an expensive compilation of that module and all its dependencies.

To illustrate this, let’s walk through a simple example:

(lldb)

p
myObj

Here myObj is just a local variable: LLDB can find its location in the debug info and resolve its type via reflection metadata. No need to bother the Swift compiler. Let’s make it more complex:

(lldb)

p
myObj.myComputedProperty

In this case, myComputedProperty is really a function call; in order to evaluate this, LLDB needs the expression evaluator to run code in the target. In order to initialize a Swift compiler instance with the state of the current module, LLDB finds the name of the current function’s Swift module in debug info. We can visualize what LLDB does using the dwarfdump utility:

$
dwarfdump Foo.o
...
DW_TAG_module
  DW_AT_name
("Foo")

Conceptually, LLDB then wraps the expression in a function that can be compiled:

(lldb)

log enable lldb
expr (
lldb
)
p myObj.myComputedProperty
...
import Foo
func lldb_expr(_ $__lldb_arg : UnsafeMutablePointer<Any>) {
let myObj : MyObject = /* some LLDB magic */
// Expression begins here:
myObj.myComputedProperty
...
}

One problem with this is that import Foo is quite imprecise: Even though the Swift language doesn’t allow multiple modules to have the same name, even the most stringently engineered application may have more than one copy of the same module. For example, there might be a private version of a module containing all of its private declarations (which would be great for LLDB) and also a Swift interface file that only contains the public interface for the module. Or there might be macOS and Mac Catalyst variants of the same module in the same process.

Swift modules, debug info, and the build system

Let’s look at where those modules are found next. In order to communicate the location of Foo.swiftmodule to LLDB, Swift build systems rely on some cooperation from the linker. On Darwin the system linker accepts an option called -add_ast_path and build systems are expected to specify this option to list every binary Swift module when linking.

# Linker invocation on macOS
ld -add_ast_path /path/to/Foo.swiftmodule Foo.o -o MyApplication

The linker translates these options into symbol table entries. The debug info linker dsymutil then collects all Swift modules and stores them in a special __swift_ast section in the dSYM bundle, where LLDB can find them by name. Alternatively, when debugging without dSYM bundles, LLDB reads the symbol table entries in the binary to collect a list of all binary Swift modules. Such an approach would not work on platforms where the linker isn’t aware of Swift. For these platforms, which include Windows, Linux, and FreeBSD, the Swift compiler provides a -modulewrap action that takes a binary Swift module and outputs an object file with a .swift_ast section holding the contents of the module. This object file can then be passed to any linker to get added to the binary, where LLDB can find it.

# Modulewrap and linker invocation on Linux
swift-frontend -modulewrap Foo.swiftmodule -o Foo.swiftmodule.o
lld Foo.o Foo.swiftmodule.o -o MyApplication

This can create scalability issues, especially for large applications:

• Module files can get large and for an entire application you can often end up with a large portion of the SDK in the resulting binary. That can be quite problematic for the binary size.
• As mentioned above, the chances of LLDB finding the right module in a Swift AST section or symbol table just by its base name diminish as the application gets more complex.
• Binary Swift modules are version-locked to the precise compiler that created them. This is at odds with the intent of dSYM bundles, which are meant for long-term archival serialization of debug info.
• If a matching explicit module cannot be found, LLDB falls back to an implicit module import which may involve recompiling parts of the SDK from source. This can be very slow.

Precise module tracking

To evaluate expressions, the debugger needs to be able to find and import Swift modules. Until now, this relied either on special linker support or additional compilation steps, with a high cost for binary size. On top of that the debugger was imprecisely locating Swift modules by name.

Starting in Swift 6.3 and continuing since, we have been making changes to the Swift compiler, the Swift driver, and LLDB that improve performance, reliability, and scalability. These changes are built on top of explicitly-built modules.

What’s new

• Explicitly-built modules track their explicit Swift dependencies: Explicitly-built binary Swift modules have always kept track of their explicitly-built Clang module dependencies. This is why LLDB can import explicit modules so much faster than implicit modules, which may need to recompile their dependencies from source. In Swift 6.3, explicitly-built binary Swift modules also keep track of their Swift module dependencies. This makes importing an explicitly-built module fast and unambiguous because no module needs to be looked up by name. This happens automatically. Users don’t need to make any changes. Users with distributed build systems will already be familiar with the Swift frontend’s path remapping options, which now also affect Swift module paths.
• Debug info stores path of object file’s own Swift module: Once LLDB finds the top-level module it can precisely import it and all of its dependencies. But how can LLDB find precisely the module that belongs to the Swift file at the current breakpoint? In Swift 6.3, the Swift compiler can store the path to it in the debug info. Because a Swift file’s own Swift module is not an input to an object file compilation, there is a new -debug-module-path compiler option to communicate the path to each object file compilation action. This path is also subject to the standard path remapping options used by users with distributed build systems.
• Swift driver passes module path to compile jobs: Users of swiftpm or Xcode do not need to think about this, because the Swift driver also knows about the new -debug-module-path option and automatically passes the path to the object file’s own Swift module to the compiler. However, users maintaining their own third-party build system to orchestrate Swift compilations with explicitly-built modules that are calling the Swift frontend directly and bypassing the Swift driver need to make sure to communicate the path to the top-level module to each object file compilation job.

What’s deprecated

Beginning in Swift 6.4, you can safely make the following changes.

• swiftc -modulewrap and ld -add_ast_path: Because the module paths are now communicated via debug info and the module headers themselves, third-party build systems doing explicit module builds can now remove all -modulewrap actions on Linux and Windows; and remove the use of the -add_ast_path linker option on Darwin (macOS, iOS, etc…).
• Binary Swift modules in dSYM bundles: As a consequence, dsymutil will no longer process binary Swift modules. This is a good thing, because binary Swift modules—which can only be parsed by the exact toolchain that produced them—were always at odds with dSYM bundles being a long-term archival format. Moreover, Swift modules often depend on Clang modules, and these Clang modules also were never included in dSYM bundles. By removing the binary Swift modules, dSYM bundles will get smaller.
  • But don’t we need them for debugging? Since Swift 1.0, binary Swift modules were included in dSYM bundles because they were needed to resolve the types of local variables. However, starting with Swift 5.6, LLDB could perform this operation by reading the reflection metadata in the binary. The absence of binary Swift modules in dSYM bundles does not affect LLDB’s ability to inspect the contents of variables or dump object descriptions with po. Binary Swift modules are still needed to evaluate complex expressions like function calls or computed getters. Expression evaluation continues to work as long as LLDB finds all binary modules in their original (or remapped) location. This is always the case when debugging a just-built binary on the same machine. If the absence of binary Swift modules in dSYM bundles creates an unforeseen problem with your workflow, please let us know, either on the Swift LLDB forum or by creating an issue on the bug tracker.

When compiling with caching enabled, all paths pointing to Swift modules and module debug info are content-addressable storage references, identified by content rather than file location, so everything described here also works transparently with compilation caching.

Coming in Swift 6.4: Faster bridging header import in LLDB

Beyond more reliable path tracking, Swift 6.4 will also speed up importing bridging headers, a step common enough across Swift projects that most developers will feel the difference.

Up to and including Swift 6.3, LLDB always compiles a bridging header from source, a step that can add noticeable time to debugging sessions that use one. In recent nightly development toolchains, LLDB can use the new precise explicit module information to import precompiled bridging headers and their explicit module dependencies directly. This makes debugging explicitly-built projects with bridging headers as fast and reliable as debugging fully modularized projects.

Summary

With these changes for explicitly-built modules:

• Binaries built with debug info on Windows and Linux, and dSYM bundles on Darwin will get dramatically smaller, since they no longer contain any binary Swift modules (6.4+)
• Contextual module imports in LLDB become more reliable due to precise tracking instead of by-name lookups
• Certain performance cliffs around module importing in LLDB are eliminated (such as SDK module dependencies in dSYMs triggering implicit imports)
• Developers maintaining their own build systems can remove support for -modulewrap actions and remove -add_ast_path from the linker flags, but may need to pass -debug-module-path to the compiler if they are not letting the Swift driver handle the frontend options
• Finally, static archives were easy to overlook: projects that didn’t use -add_ast_path when linking them often had confusing debugging issues inside those archives as a result. This entire class of issues has been designed away.

tl;dr: -modulewrap and -add_ast_path are replaced by -debug-module-path. Debug info gets smaller and more precise.

Embedded Swift is a subset of Swift that’s designed for low resource usage, making it capable of running on constrained environments like microcontrollers. Using a special compilation mode, Embedded Swift produces significantly smaller binaries than regular Swift. While a subset of the full language, the vast majority of the Swift language works exactly the same in Embedded Swift. Additional information is described in the Embedded Swift vision document.

Embedded Swift is evolving rapidly. Following our updates on Embedded Swift improvements in Swift 6.3 late last year, this post describes a number of additional improvements made in the upcoming Swift 6.4 release. You can try them out today with a Swift development snapshot.

Language improvements

Embedded Swift continues to expand its subset of the language to include more aspects of “full” Swift, making it easier than ever to bring compatibility with Embedded Swift to existing Swift code bases. Many of these features have some dynamic aspect to them, meaning that they have an impact on runtime performance (for example, due to indirect calls) and code size (due to requiring additional metadata). However, this impact only occurs where these dynamic language features are actually used: code that is highly sensitive to code size and performance can choose to avoid them, for example by enabling warnings in the PerformanceHints diagnostic group.

Generalized support for existential (any) types

Embedded Swift previously only supported existential (any) types that had an AnyObject constraint, meaning they could only be used with class instances. Now, all any types are available in Embedded Swift, including Any itself. For example:

protocol P {
  func method()
}

extension Int: P {
  func method() { print("\(self) is here") }
}

let a: any P = 17
a.method() // prints "17 is here"

The Embedded Swift generics compilation model, which requires that all generic functions and types eventually be specialized, implies some limitations on the use of any types. Specifically, a generic function cannot be called on an any type:

extension P {
  func genericMethod<T: P>(_ other: T) { ... }
}

let a: any P = 17
a.genericMethod(a) // error: cannot use generic instance method 'genericMethod' on a value of type 'any P' in Embedded Swift

Untyped throws

Embedded Swift previously only allowed throwing specific error types, like this:

func parseRecord() throws(ParsingError) -> Record { ... }

“Untyped” throws, which can throw any Error-conforming instance, was previously disallowed in Embedded Swift:

func loadImage() throws -> Image { ... } // previously disallowed in Embedded Swift

Untyped throws is equivalent to throwing a value of type any Error. With the generalization of any types, Embedded Swift now fully supports untyped throws. Throwing a value of any Error typically requires a heap allocation, so typed throws should still be preferred for code bases that want to avoid heap allocations.

Metatypes

Embedded Swift has traditionally allowed metatypes (e.g., Int.self) only in very narrow places, for example when using them to specify argument types for generic functions:

rawPointer.bindMemory(to: Value.self, capacity: 1)

Swift 6.4 introduces complete support for metatypes in Embedded Swift: one can create and use instances of metatypes, including existential types like any (DefaultInitializable.Type). For example, this is now permitted and works in the same way as full Swift:

protocol DefaultInitializable {
  init()
}

extension Int: DefaultInitializable { }

let factory: any (DefaultInitializable.Type) = Int.self
let aValue: any DefaultInitializable = factory.init()

Library improvements

Additional features in the Swift standard library and associated libraries from full Swift are now available in Embedded Swift.

Floating point parsing

Swift floating point values can be parsed from a string, like this:

let inputText: String = getInputText()
if let value = Double(inputText) {
  // value is a Double
}

As part of a reimplementation of this functionality in Swift, these floating-point parsing APIs are now available in Embedded Swift as well.

Concurrency error handling

The Embedded Swift concurrency library now supports throwing operations, such as throwing tasks and task groups. For example:

let task = Task {
  if badThing {
    throw MyError.badThingHappened
  }

  return "ok"
}

print(try await task.value)

Try it out!

Embedded Swift support is available in the Swift development snapshots. The best way to get started is through the examples in the Swift Embedded Examples repository, which contains a number of sample projects to get Embedded Swift code building and running on various hardware.

If you have questions about the improvements described here, or want to discuss your own Embedded Swift work, we encourage you to join the conversation on the Swift forums. You can ask about this post in the associated thread, and share your experiences in the Embedded Swift category.

Welcome to “What’s new in Swift,” a curated digest of releases, videos, and discussions in the Swift project and community.

June was an exciting month for Swift, featuring announcements at WWDC and community events around the globe. We invited the organizers of one of them to share with us:

Hey, it’s Mikaela and Adrian. We are organizers of CommunityKit, a community-organized conference that takes place the same week as WWDC, and iOSDevHappyHour, a monthly online meetup that keeps the community connected year-round. This is our fifth year coming out to Cupertino, and we love being able to create a place for the community to thrive, no matter where developers live.

CommunityKit brought together over 250 developers in real life to geek out over the announcements, stay for the community and vibes, see what everyone is creating, and learn from each other. Some of the highlights from this year’s event were the Indie Fair, where developers showcased their apps; the Watch Party, our annual gathering to watch the keynotes together; and Make Something, Ship Nothing, a hands-on postcard-making hangout to close the week. This year we also introduced workshops, including “Inclusive by Design” by Danielle Lewis, and for the Swift community: “Write Faster, Smarter Swift” by Paul Hudson.

We can’t wait to hear about what everyone builds and brings to next year’s Indie Fair, and hope to see you at CommunityKit and iOSDevHappyHour!

Now on to other news about Swift:

WWDC26 highlights

At its WWDC26 conference, Apple provided an update on its adoption of Swift and made a variety of new Swift-related announcements. Some highlights:

• During the Platforms State of the Union, Apple announced that parts of the core operating system kernel are being written in Swift for upcoming releases.
• What’s new in Swift featured changes in Swift since last year, including a preview of what’s coming in Swift 6.4, like up to 4x faster URL parsing and support for async code in defer blocks.
• The QUIC transport layer in Apple’s networking stack was rewritten in Swift. The project has been open sourced and is available for cross-platform use through SwiftNIO integration.
• A new Swift package, Foundation Models framework utilities, was released with tools for working with LLMs, including custom skills and context management helpers. It runs on Apple platforms and select Linux distributions.
• The Foundation Models framework itself will be open sourced in the future, meaning the same Swift APIs you use in your app could run on your server.
• Container Machine is a new tool that provides a lightweight, persistent Linux environment on a Mac. Unlike a container, which is modeled after an application, a container machine is modeled after the environment itself. Container machines share the host environment, including the home directory and configuration. It’s written in Swift and open source.

Videos to watch

• Build real-time apps and services with gRPC and Swift walks through integrating an iOS app and gRPC service using live race data from a go-karting league. See if you can spot where the track is located. 👀
• Want to learn about Swift macros with hands-on tutorials? Stewart Lynch published two videos with sample code to follow along: Swift Macros Demystified: Build a Freestanding Expression Macro, and Swift Attached Macros: Build a Real-World Member Macro from Scratch.
• A new 10-minute Embedded Swift demo uses an accelerometer and the XIAO ESP32-C6 to control a Swift bird that glides across a mini OLED screen. No soldering required!

Community highlights

• Swift Package Index joined Apple and remains open source. The team says they’re working together to build a comprehensive package registry for the Swift community.
• Yeo Kheng Meng blogged about bringing Swift to the Apple II, complete with a REPL, compiler, file browser, and editor. It’s a subset of Swift and was built with AI assistance.
• Apple shared an adoption story on the Swift blog: Migrating the TrueType Hinting Interpreter, covering how the TrueType hinting interpreter in macOS and iOS was rewritten in Swift from C. It runs 13% faster on average.
• The Swift Ecosystem Steering Group announced the creation of the Networking workgroup. This group will work on a unified networking stack for Swift, layered from low-level I/O primitives, through common protocols, to a modern HTTP client and server API.

New package releases

• New Swift bindings for the OkHttp Java library were released. If you’re using Swift on Android and looking for an HTTP client this may be useful. The project was generated with swift-java.
• Kiln is a new documentation engine written in Swift. Built to replace MkDocs-based documentation sites, it gives more options for the Swift community to render docs, in addition to the DocC project which is used for the official Swift documentation. You can see Kiln in action at the Vapor documentation.
• Version 0.4.0 of Elementary UI was released, a frontend framework for running Swift applications natively in the browser.

Swift Evolution

The Swift project adds new language features through the Swift Evolution process. These are some of the proposals currently under review or recently accepted for a future Swift release.

Under active review:

• SE-0526 withDeadline - Asynchronous operations in Swift can run indefinitely, and implementing time limits manually using task groups and clock sleep operations is verbose and error-prone. This proposal adds withDeadline, a function that executes an async operation with a composable absolute time limit specified as a clock instant, canceling the operation if it hasn’t completed in time. It also allows multiple nested operations to share the same deadline, avoiding the drift that accumulates when relative durations are passed through call layers.

Recently accepted:

• SE-0474 Yielding Accessors - When you call a mutating method on a computed property, Swift creates the illusion of in-place mutation by getting a copy, mutating it, then setting it back. This causes unnecessary copy-on-write buffer duplication for types like String, and is impossible for noncopyable types, which can’t be copied out at all. This proposal adds yielding borrow and yielding mutate, two new ways to implement computed properties and subscripts that instead lend the caller direct access to the underlying value without copying it.

Recently accepted with modifications:

• SE-0529 Add FilePath to the Standard Library - FilePath in the swift-system package parses platform-specific path syntax on the developer’s behalf, provides a normalized view of path components, and enables filesystem resolution. However, shipping in an external package means the standard library, Swift runtime, and toolchain libraries such as Foundation cannot depend on it. This proposal adds FilePath and its associated types to the Swift module, alongside essential functionality for construction, decomposition, resolution, and C interoperability.
• SE-0527 UniqueArray - Swift’s Array can’t store noncopyable elements without compromising its copy-on-write semantics or performance predictability. This proposal adds two new types to a new Containers module: RigidArray, a fixed-capacity array that traps on overflow, and UniqueArray, a dynamically growing array that enforces unique ownership by being noncopyable itself.