Swift.org

Module Tracking in Swift Debug Info

2026-09-11T11:30:00-04:00

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.

What's new in Swift: August 2026 Edition

2026-09-04T12:30:00-04:00

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

Here’s an update from guest contributor Simon Leeb on Swift’s progress as a language for web scenarios:

Hi, Simon here! I am the creator of the elementary-swift project, a collection of packages born from a simple wish: I want to build web UIs in Swift and ultimately help Swift become a first-class choice for the web.

This journey began after I started using Swift for backend services. The web frontend, however, still lived in a separate ecosystem, and I really wanted it to feel as ergonomic, safe, and efficient as the Swift I was writing everywhere else.

That led to the creation of Elementary: a modern and efficient HTML rendering library with a familiar declarative API, built for the web. It integrates easily with frameworks like Vapor and Hummingbird, and has become a practical option for server-rendered web UIs.

Around that same time, years of community work in the swift-wasm project made compiling Swift to WebAssembly increasingly viable, while Embedded Swift was taking its first experimental steps. This made me wonder: “How hard can it be to use Embedded Swift and build a state-driven web UI framework that produces tiny WebAssembly binaries?” Turns out: quite hard, actually!

But it was too late. Despite my better judgment, I was in the middle of creating what is now known as ElementaryUI. Where Elementary renders HTML on the server, ElementaryUI runs in the browser itself. You can watch my talk at Swift@FOSDEM 2026 if you want to know more about the why, what, and how.

To showcase where the project is heading, I recently posted a small Full-Stack Swift on Cloudflare demo. It features Swift in the browser communicating with a Swift backend on an edge worker through shared message types. I hope it gives people a concrete sense of how much the core technologies and the surrounding tooling have advanced.

ElementaryUI is still young, with plenty left to build. Visit elementary.codes to try it, share feedback, contribute, or sponsor its development. Let’s work together and make Swift a first-class choice for the web!

Now on to other news about Swift:

Videos to watch

Saleem Abdulrasool joined the Empower Apps podcast to discuss Swift on Windows, server-side Swift, SwiftWin32, Swift’s C++ interop, and how to get started.
Building memory-safe software? Write security-sensitive code in Swift covers how Swift guarantees safety across bounds, lifetimes, types, initialization, and concurrency, with primitives like Span and non-copyable types, plus how to audit unsafe code with strict memory safety and incrementally migrate existing C modules.
Two short videos about running Embedded Swift on Raspberry Pi Pico: a video on getting started on macOS called Let it blink! and Fun with traffic lights in 60 seconds.

Community highlights

Building scalable backend apps in Swift shares an approach to structuring server-side Swift codebases, separating business logic from database and framework details so the code stays easier to test and change over time.
The Swift Package Index blog explains what a package registry actually is, how it fits alongside SwiftPM and package indexes, and walks through an example of switching a dependency managed from Git to a Swift registry.
Embedded Swift Improvements Coming in Swift 6.4 rounds up what’s ahead for Swift on microcontrollers and other constrained environments.
The Browser Company’s Swift on Windows: A year of refinement reflects on a year of work making Swift on Windows more predictable.

New package releases

Write an interface once with SwiftTUI using a declarative, state-driven syntax, then ship it as a terminal app, as a native macOS or iOS app, as an Android app, or as a WASI build for the browser.
Tired of hand-writing RawRepresentable and LosslessStringConvertible conformances? lexic generates them for you via macros, and runs the same on Linux as on Apple platforms.
StructuredQueries, Point-Free’s SQLite query builder, now has fully type-safe support for JSON and JSONB columns, including a json_each table function, so nested data can be queried and updated by key path without leaving Swift’s type system.

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:

ST-0029 Include additional issue metadata in event stream - Today, Swift Testing’s JSON event stream reports only bare-bones details when an issue occurs, making it hard to tell a thrown error apart from a manual Issue.record call. This proposal adds structured fields, including error, confirmationMiscount, exceededTimeLimit, and expression, so tools like Xcode and VS Code can show richer, more specific failure information.

Recently accepted:

SE-0544 Mutation and consumption in non-copyable type deinits - Non-copyable types that manage a resource, like a file handle or buffer, often need to run the same cleanup logic in their deinit that they use elsewhere, but until now self inside a deinit could only be borrowed, not mutated or consumed. This proposal lets a deinit mutate or consume its own stored properties directly, so existing cleanup methods can be reused instead of duplicated.
ST-0028 Revise Swift Testing’s Attachment/Encodable interop - Swift Testing lets you attach extra data, like a screenshot or JSON snapshot, to a test for inspecting after a failure, but attaching custom types previously required extra setup code and offered no way to choose the encoding format. This proposal adds new Attachment initializers that let you attach Encodable or NSSecureCoding values directly, picking the format or supplying your own encoder.

Recently accepted with modifications:

SE-0536 Package Registry Search - To use a package from a registry today, you already have to know its exact identifier, since there’s no standard way to discover packages within a registry the way other package ecosystems allow. This proposal adds an optional /search endpoint to the registry specification and a swift package-registry search subcommand, letting you find packages by name, scope, author, and other criteria, with support for qualifiers like author:"Mona Lisa Octocat" and searches that span every configured registry at once.
SE-0516 Iterable - Looping over a collection in Swift traditionally means copying out one element at a time, which doesn’t work for newer types that can’t be copied, like Span and InlineArray. This proposal introduces Iterable, a new way to loop over data without copying, and was renamed from BorrowingSequence and given support for typed throws before acceptance.
ST-0026 TaskLocal test trait - Task-local values are like settings, such as a feature flag, that apply only within a single task. Overriding one in a test previously meant writing a custom trait from scratch, but this proposal adds a .taskLocal(_:_:) trait that does it in one line, like @Suite(.taskLocal(FeatureFlags.$isEnabled, true)).

Embedded Swift Improvements Coming in Swift 6.4

2026-08-20T09:45:00-04:00

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 any) types section" href="#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.

What's new in Swift: July 2026 Edition

2026-08-07T11:30:00-04:00

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

Swift is built by contributors working on far more than the language and compiler. Alexander Sandberg reflects on what that kind of contribution looks like, and why there’s a place for you too:

Hi, I’m Alex. Four years ago I joined the Swift Website Workgroup to help care for the website you’re reading this on. I was still fairly new to the Swift community then, but I wanted to get involved somehow and make a difference.

Contributing to Swift sounds like it should involve working on the compiler or writing and reviewing language evolution proposals, but there’s a lot going on around the language itself too. What I actually spent my time doing was helping improve the site’s content and navigation, taking part in the big redesign, writing release blog posts, reviewing pull requests, and answering issues and forum posts. All of it is work anyone can learn to do, and all of it ends up in front of everyone who comes to Swift.org—which made even the smallest fixes feel worth doing.

The Website Workgroup happened to be my way in, but there are groups like it across the project—server, testing, Windows, Android, and more—each a handful of people looking after their part of the ecosystem. Whatever you’re good at or curious about, there’s probably a corner of Swift that could use your help. The community page is a good place to start looking, and the people you’ll meet are some of the friendliest I’ve come across in open source.

After four years, I’ve stepped away to focus on other things in life. Thank you to everyone I got to work with over these years! I’m leaving the workgroup, but not the community, and I’ll still be around helping push Swift forward where I can.

For more information about workgroups, the How we work page lists all workgroups. And on the Swift forums you’ll often see workgroups sharing open meetings if you’re looking to get involved!

Now on to other news about Swift:

Videos to watch

Balancing High and Low-Level Programming in Swift, presented by John McCall at PLDI 2026, digs into the ongoing work to bring explicit ownership and lifetime features to Swift for systems programming, and the tricky balance of fitting them into a language built around simple, low-friction application development without breaking source compatibility or ABI stability.
Speaking of low-level Swift: I Built a Timer for the Playdate in Swift and I Built a 3D Renderer for the Playdate (in Swift) are a fun pair of videos on building for the handheld game console in Swift.
Melbourne CocoaHeads has been uploading a great back catalog of past event talks to their YouTube channel, including Christian Mitteldorf’s 2023 talk on running Swift on the server.

Recent project changes

Google Summer of Code contributions are underway: Ege Kaya is building a Task Registry for the Swift Concurrency runtime (PR #90547), Filip Sakellariou is contributing to swift-syntax (PR #3378, PR #3390), and Padmashree S S is working in sourcekit-lsp (PR #2698, PR #2729).
Task Stealers, a new primitive in Swift Concurrency’s runtime, recently merged after generating the liveliest discussion of any PR in July. They change how work gets distributed across the cooperative thread pool, an under-the-hood change worth watching if you write concurrency-heavy code.
SwiftPM landed a reference implementation of the package registry service, along with basic auth support, a solid starting point if you’re exploring self-hosting a registry.
Small but welcome fixes landed across tooling: the VS Code extension now fails loudly when a Swift installation is broken, and gained a clean build folder command, while Swift Testing’s event stream gained an ABI.Context API that produces human-readable output for CI tooling and dashboards.

New package releases

Need to tokenize text fast? swift-gigatoken is a zero-copy tokenizer hitting up to 670 MB/s, inspired by Marcel Roed’s gigatoken, with NEON/CRC32 support and compatibility across WebAssembly and Embedded Swift.
any-error-swift takes a different approach to error handling, offering a concrete, value-semantic, Hashable type that erases any Swift error, no Foundation required, and works on every platform Swift runs on.

Swift Evolution

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

Recently accepted:

ST-0025 Tag-based Test Execution Filtering - Swift Testing lets you annotate tests with named tags, and separately lets you include or exclude tests by regex using the --filter and --skip options, but there’s no way to combine the two and filter by tag. This proposal adds a tag: prefix to those options, so you can run commands like swift test --skip tag:uiTest to selectively run or skip tests based on their tags rather than relying on a consistent naming scheme.
SE-0513 API to get the path to the current executable - There’s currently no portable, reliable way to get the path to the currently running executable in Swift. This proposal adds CommandLine.executablePath, a new property in the standard library that provides a consistent way to get this value across all platforms Swift supports.

Recently accepted with modifications:

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.

What's new in Swift: June 2026 Edition

2026-07-02T12:00:00-04:00

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.

Swift Package Index Update

2026-06-23T10:00:00-04:00

Since its launch, Swift Package Index has become an essential part of the Swift ecosystem, helping developers discover quality packages, evaluate compatibility, and make informed decisions about dependencies.

Started by Dave Verwer and Sven A. Schmidt, the project currently indexes thousands of packages and serves as a central hub for package documentation. Recently, Swift Package Index has grown alongside the Swift project’s multi-platform expansion, extending its compatibility testing to encompass Linux, Android, and WebAssembly.

Today, Swift Package Index announced that it has joined Apple and continues its mission:

Together, we’re building a comprehensive package registry to serve the Swift community’s evolving needs.

Learn more by reading the Swift Package Index announcement.

Swift at Apple: Migrating the TrueType Hinting Interpreter

2026-06-12T06:00:00-04:00

TrueType is a widely used vector font standard for rendering text in web pages, PDFs, operating systems, and applications. Familiar fonts like Helvetica, Garamond, and Monaco are all built on TrueType outlines. The format specifies a hinting interpreter intended to help outlines rasterize faithfully on low-resolution displays. Modern high-resolution displays enable beautiful typography from outlines alone, but TrueType fonts that need hinting to render legibly remain in use and we continue to support them.

Font parsers process data from untrusted sources, making the TrueType hinting interpreter a security-critical attack surface. To make the format more resilient on Apple platforms, we rewrote its hinting interpreter from C to memory-safe Swift for the Fall 2025 releases. In addition to memory safety, we also improved performance: on average, our Swift interpreter runs 13% faster than the C interpreter it replaced.

To accompany this post, we’ve also published the source code of the Swift TrueType hinting interpreter. We hope sharing our experience helps others doing similar work in Swift.

TrueType and the hinting engine

Apple developed TrueType in the late 1980s and released it with the launch of System 7 in 1991. TrueType was a major breakthrough for the time: it gave font developers enormous control over how glyphs are displayed, with an advanced grid-fitting algorithm and a sophisticated hinting engine built around a special-purpose bytecode interpreter. TrueType did all this on computers that were vastly less powerful than today’s, so it had to be extremely well-tuned for performance.

Then the internet revolutionized how fonts were used. TrueType became embeddable in PDF files in 1994 and in web pages in 2008, and it remains as relevant as ever. However, these new use cases brought additional risk: TrueType could now be exposed to untrusted fonts from anywhere on the internet.

TrueType fonts may contain programs the hinting engine runs through a bytecode interpreter. This interpreter involves input-driven control flow, complex data structures, and careful memory management—exactly the kind of code that’s hard to make perfect and where memory errors are easier to exploit. This high inherent complexity also makes correctness especially important.

Rewriting in Swift

A rewrite required a memory-safe language that could integrate into the existing codebase and provide an equivalent level of performance to the implementation it was replacing. Swift was the obvious choice for the task.

Binary compatibility was crucial for this project to succeed: existing programs had to continue to function the same as they did before, effectively unaware that a new implementation was in place. This means not just interface compatibility but pixel-identical glyph rendering as well, relative to the C implementation. Hinting can radically change the on-screen appearance of glyphs, so a small change in the interpreter’s behavior could result in substantial user-visible changes. For this project, we defined correctness to mean exact compatibility with the C implementation’s outputs.

Validating correctness

To ensure correctness, we developed two test suites. The first was a unit test suite that can target both implementations, providing exhaustive (99.7%) code coverage for both. This suite is included with the open source release of the Swift interpreter.

Then, to represent real-world workloads, we used a fuzzer to minimize a corpus of 10 million PDF files down to 4,200 without any loss of code coverage. The documents in the minimized corpus embedded 25,572 fonts with a total of 27 million glyphs that we rendered using four different transformations each, comparing the resulting bitmaps against the reference interpreter. This gave us confidence in the new interpreter’s compatibility.

By the end of the project, we wrote nearly four times as many lines of test code as we wrote for the Swift interpreter itself.

Achieving high performance

Once our new implementation passed all its tests, we turned our attention to performance. We assessed performance at a high level using PDF render time, and then iterated on improvements guided by benchmarks that rendered all of the glyphs from three different fonts. These improvements fell into four main categories.

Minimizing runtime overhead

Swift uses automatic reference counting for managing the lifetime of shared reference types, and runtime exclusivity checking for preventing overlapping access to data structures. These sources of overhead are often exacerbated by aliasing, an irreducible amount of which existed in the interpreter’s specification by design.

These sources of overhead can be eliminated by giving up the convenience of copyability, adopting ~Copyable value types (see also: struct instead of class) throughout the architecture, reserving reference types for high-level abstractions. Span, introduced in Swift 6.2 with back-deployment support all the way back to macOS 10.14.4 and iOS 12.2, allowed us to efficiently operate on sequences of these types.

Moving data around

Sometimes we want to change the “shape” of structured data when crossing language boundaries to better match the idioms on the other side. In Swift, glyph outlines are represented by a sequence of points, each of which carries a flag for whether it’s ‘on a curve’, flags for whether it’s been ‘touched’ on each axis, and three coordinate pairs: original (in the font’s base units), scaled (to the desired point size), and hinted (the interpreter program’s output).

The original C code stored these points in one struct with eight arrays. This is good from a performance perspective because it’s cache-friendly: you can operate on a dimension of many points in long runs, which is fast. But exposing the data in Swift as a collection of point elements resulted in source code that was easier to follow.

The initial cross-language bridging code we wrote prioritized expediency, safety, and simplicity by copying the glyph’s data from its C struct into Swift and then back after the program completed. Initially, those copies accounted for around 20% of the new interpreter’s runtime. In the end we wound up using projection types that provide safe access to the underlying C structure. Swift thus gives us readability without copying or otherwise transforming the underlying data structure.

Following WebKit’s Safer Swift Guidelines, the example below demonstrates how to wrap a bridged structure from C in a projection type that uses Ref for lifetime safety, brokers bounds-safe access to the underlying data, and returns idiomatic Swift types to its callers. All unsafe expressions bear // SAFETY: comments that document the safety invariants and the reasoning which guarantees that they are true.

@safe struct Zone: ~Copyable, ~Escapable {
  let _element: Ref<fnt_ElementType>

  @_lifetime(copy element)
  init(wrapping element: Ref<fnt_ElementType>) {
    // SAFETY: the `fnt_ElementType` passed by the caller must satisfy:
    // * `sp`, `ep` point at arrays of length ≥ `maxContourCount`.
    unsafe _element = element
  }

  func readContour(index: Int) -> ClosedRange<Int> {
    precondition(0..<contourCount ~= index)
    // SAFETY: `index` is bounds checked above; `_element.pointee.sp` and `_element.pointee.ep`
    // are live arrays of length `maxContourCount` per `init(wrapping:)` premises.
    return unsafe Int(_element.value.sp[index])...Int(_element.value.ep[index])
  }
}

Short-lived allocations

While runtime overhead imposes its costs in aggregate, and copying data across the language border showed up as a specific hot spot, the costs of short-lived memory allocations can show up in both ways.

Operations like filter and map allocate memory, but that allocation is only necessary if the value escapes. The Swift standard library provides .lazy.map and .lazy.filter, but they don’t work in every case. For logic that only iterates over the filter or map, it’s much more efficient to loop with continue (or use for … in … where) and transform elements into local variables as necessary.

Allocations that exist exclusively to pass results to a function’s caller can be elided too. For example, we often needed to pop the last n elements from the interpreter’s stack. The obvious implementation of this operation has to allocate space for the elements it returns (because the function simultaneously removes them) and looks something like:

mutating func pop(
  count n: Int
) -> [Element] {
  defer { items.removeLast(n) }
  return Array(items.suffix(n))
}

Optimizing this operation without compromising safety eventually led us to a continuation-passing approach where the caller passes a block that can operate on a slice of stack elements before they are removed. Swift’s compile-time exclusivity checking ensured that the stack could not be modified from inside the block, and the interface structurally eliminated any need for heap allocations or element copying.

mutating func pop<R, E: Error>(
  count n: Int,
  _ op: (borrowing Span<Element>) throws(E) -> R
) throws(E) -> R {
  defer { items.removeLast(n) }
  return try op(items.span.extracting(last: n))
}

Dynamic dispatch

Abstraction mechanisms like protocols, generics, and inheritance are very powerful, but they introduce method-call indirection that may manifest at runtime as dynamic dispatch. This overhead can often be eliminated by the optimizer, but that is not possible in all conditions. In our case, not making abstractions more generic than necessary and encouraging the toolchain to inline were sufficient for the optimizer to hoist bounds checks and specialize all of our generic contexts. When you’re profiling your code, if you see unspecialized generics or protocol witness tables in hot paths, that’s a sign that the optimizer does not have sufficient visibility to optimize the call sites and that your implementation may benefit from inlining.

Zero-cost abstractions

At this point, anyone accustomed to grinding out performance improvements in a project might reasonably expect that our optimizations could come at the cost of readability, but in reality Swift’s type system and optimizer enabled us to employ abstractions that resulted in highly legible code. For example:

FixedPoint types provided the same ergonomics as integral types, encapsulating complex rounding and shifting arithmetic.
StackElement provided access to 32-bit values with built-in conversions for all eight of its supported numeric types.
Our projection types provided safe and natural access to data that was not structured with those considerations in mind.

Swift’s type system makes it possible to define powerful and expressive abstractions. When built with optimizations, all of our abstractions added zero cost while substantially improving readability.

Memory-safe and faster than C

Our goal for this project was to make the TrueType hinting interpreter fully memory-safe, to have the same observable rendering behavior as the C implementation, and to achieve a level of performance that did not regress any user-visible benchmarks.

We met these goals. The Swift interpreter includes a small number of thoroughly verified unsafe statements at the language interop boundary; there have been no bugs reported against it since it was enabled; and it’s faster.

On average, the Swift interpreter runs 13% faster than the C interpreter it replaced. Here is a chart showing the average CPU megacycles spent per glyph in the Swift implementation versus the C implementation for all of the hinted fonts that ship on macOS, plus a sampling of non-system fonts:

● System font · ● Non-system font · below the line: Swift faster · above: C faster

Despite the overall performance improvement, we did not optimize everything! All of the new interpreter’s internal state was written in terms of noncopyable structures that were borrowed by its operations, but the top-level type itself is an @objc class that gets called across a module boundary from an Objective-C++ file. The hot paths are fast, and the cold paths are convenient.

Swift in practice

The Swift language made this project possible. Swift is memory-safe, has great ergonomics, and can be as fast as carefully written C. This makes it an excellent language for both application and systems development.

Code using noncopyable types, value types, and Span is both safe and fast by default, and module-private types can be used to collectively define an architecture at no additional cost. Together with exhaustive test coverage, these well-defined internal interface boundaries make refactoring substantially easier, which in turn accelerates the measure-and-fix optimization loop while minimizing the risk of introducing bugs.

This migration effort has deepened our Swift expertise and given us a foundation to build on. After completing the migration, we distilled what we learned into instructions for LLM coding assistants, and have since used them successfully in other projects. LLMs have improved the efficiency of our team’s work converting C/C++ to Swift, and have proven valuable in performing the kind of code transformations used in this effort.

To accompany this post, we’ve published the source code for the Swift TrueType hinting interpreter on GitHub. This is production code, intended as a reference implementation rather than an ongoing open source project. We hope seeing how these techniques work in practice helps others achieve similar results.

Announcing the Networking Workgroup

2026-06-04T06:00:00-04:00

The Swift Ecosystem Steering Group is excited to announce the creation of the Networking workgroup! Workgroups are community-led efforts, formally recognized by the project, to advance key areas of Swift.

The primary goal is to guide the evolution of networking libraries, protocols, and APIs in the Swift ecosystem, making networking in Swift excellent everywhere: high-level and safe by default, modular and interoperable, cross-platform, and observable.

Networking is one of the most common entry points for Swift developers, and the ecosystem has matured significantly over the years. Foundational libraries like SwiftNIO, AsyncHTTPClient, and swift-http-types, alongside platform stacks such as URLSession and Network.framework, power networking across apps, servers, and beyond. The workgroup will build upon these efforts and pursue the long-term directions outlined in the Networking vision, focusing on work to:

Define a unified networking stack with a coherent layered architecture, from shared I/O primitives at the foundation, through common protocol implementations, to ergonomic client and server APIs at the top.
Define currency types that let libraries interoperate without coupling to specific implementations, such as IP addresses, hostnames, ports, and HTTP requests and responses.
Evolve HTTP APIs by designing and guiding a modern, unified HTTP client and server API built on structured concurrency.
Guide the evolution of shared protocol implementations (TLS, HTTP/1.1, HTTP/2, HTTP/3, QUIC, WebSockets) so improvements benefit the entire ecosystem rather than being duplicated across libraries.

The new Networking workgroup joins a growing list of Swift workgroups, including the Android workgroup, Windows workgroup, and Build and Packaging workgroup, which were all added in the past year.

To learn more and get involved:

Discuss this announcement on the forums, and share ideas in the Networking category.
Learn more about the Networking workgroup by reading its charter.
The workgroup meets biweekly. A regular meeting time is being finalized and will be announced on the forums ahead of the first public meeting.
- Workgroup membership and meetings are open to those who wish to participate, and contributors are welcome!
- To receive an invite, send a message to @networking-workgroup on the Swift forums.

What's new in Swift: May 2026 Edition

2026-06-03T17:45:00-04:00

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

To start, we’re focusing on some of the many local meetup groups sharing Swift content:

Around the world, local meetup groups and conferences bring Swift developers together, and some even predate Swift itself! Many have YouTube channels where they share videos from their events, so you can tune in remotely. Let’s highlight a few.

In May the SF Swift meetup hosted a talk by Dan Federman, Agentify Your Swift Repo, which covers building an agent for CI and review feedback. Swift Barcelona has a dedicated YouTube presence, while some groups, like the new MLX India meetup, post event playlists, including a recent talk about using MLX Swift in iOS apps that’s worth checking out. And there’s even a community-organized Swift Community Meetups YouTube channel, which hosts meetups online and is home to a series of cross-platform Swift talks.

These groups support developers in a few ways worth calling out:

Local community: they’re building local connections among Swift developers and organizations.

Room for experimentation: by being less formal and sometimes featuring works in progress, meetups create space to share ideas, get feedback, and learn from one another.

I encourage more folks to get involved in their local Swift meetup. And if your group starts publishing content and videos, please share on the Swift Forums in the Community Showcase category.

— Dave Lester

Now on to other news about Swift:

Videos to watch

Interested in using Swift for backend server development? Mohammad Azam posted a livestream recording of Introduction to Hummingbird, a walkthrough of the web framework covering installation and development basics.
Meet the Temporal Swift SDK, from Replay 2026, introduces the SDK that brings Temporal’s durable workflows (long-running processes that survive crashes, retries, and restarts without losing state) to Swift. The SDK recently reached its 1.0.0 release.
Sébastien Stormacq shares a great introduction to what’s possible with AWS Lambda and Swift, presenting Swift, Server-side, & Serverless on the DevStandup YouTube channel.

Community highlights

Swift and WebAssembly continues to be an exciting part of the project, with regular activity shared on the Swift forums, including the most recent Swift for Wasm May 2026 Updates. And if you missed it, check out the new blog post by Goodnotes about how they brought Goodnotes to the web with Swift and WebAssembly.
The 2026 Swift Mentorship Program was announced, and there’s still time until June 15, 2026, to complete the interest survey to be a mentee. Working on contributions is a rewarding way to learn. And on that note, three Swift projects were accepted for GSoC 2026.
Training an LLM in Swift, Part 1 - Matt Gallagher takes handwritten matrix multiplication for a Swift port of llm.c from 2.8 Gflop/s to 1.1 Tflop/s, a 382x speedup, using Swift 6.2’s MutableSpan and InlineArray, Relaxed.multiplyAdd from Swift Numerics, DispatchQueue.concurrentPerform, and finally AMX and Metal. A thorough tour of performance optimization in modern Swift.
Members of the community using and contributing to the VS Code Swift Extension met in May during the Swift Extension Community Office Hours, featuring demonstrations of using Kiro and more.

New package releases

Want to build an AI agent in Swift? The Swift Bedrock Library gives you a Swift library for Amazon Bedrock foundation models.
SwiftOSC is an Open Sound Control (OSC) toolkit written in Swift which recently became cross-platform, now supporting Apple platforms, Linux, and Android. It’s music to our ears! Steffan Andrews, who developed SwiftOSC, has also released other music-related Swift packages including SwiftMIDI and SwiftTimecode.
Ordo One shipped version 1.33.0 of Benchmark, a package for creating sophisticated Swift performance benchmarks for a wide variety of metrics.

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-0532 Optional noncopyable improvements and generalizations - Swift’s Optional can wrap noncopyable types, but unwrapping with if let consumes the optional, leaving it unusable afterward. This proposal adds borrow() and mutate() to Optional, returning Ref<Wrapped>? and MutableRef<Wrapped>? to inspect or modify the payload without consuming it, and generalizes map, flatMap, and unsafelyUnwrapped to support noncopyable wrapped types.

Recently accepted:

SE-0528 Continuation Safe and Performant Async Continuations - When bridging callback-based APIs to Swift’s structured concurrency, developers today must choose between UnsafeContinuation, where misuse is silent and undefined, and CheckedContinuation, which catches mistakes at the cost of allocation and atomic operations. This proposal adds Continuation<Success, Failure>, a ~Copyable type that makes double-resume a compile-time error and a missing resume a runtime trap, with no overhead on the fast path.
SE-0519 Ref and MutableRef types for safe, first-class references - Storing a reference to part of a data structure in Swift today requires either a class, which adds heap allocation and reference-counting overhead, or UnsafePointer, which is unsafe and requires extreme care to use properly. This proposal adds Ref<T> and MutableRef<T> to the standard library: safe types that hold shared and exclusive references to a value, usable as local variables, struct members, and generic type parameters.
ST-0024 Test case repetition - Swift Testing can repeat tests for a set number of iterations, or until a specific failure/success condition is reached, which is useful for tracking down flaky failures. Currently, if any single test case triggers the condition, all tests in the target are re-run, even ones that passed. This proposal changes repetition to apply per test case and adds --maximum-repetitions and --repeat-until flags to swift test.

Bringing Goodnotes to the web with Swift and WebAssembly

2026-06-01T08:00:00-04:00

Goodnotes has been helping millions of users take handwritten notes on iPad for over a decade, earning recognition as Apple’s iPad App of the Year in 2022. Today, the same Swift code that powers our iOS app also runs seamlessly in web browsers through WebAssembly, delivering the exact same ink rendering and note-taking experience users love.

This journey demonstrates that Swift excels as a cross-platform language, running high-performance applications while sharing the same codebase. Every bug fix and improvement to Goodnotes benefits all our users simultaneously, regardless of which platform they use.

After two years of development and over two years in production at Goodnotes, we’ve shown that Swift on WebAssembly is a viable, powerful approach for building complex, performance-critical web applications.

Why we chose Swift for the web

When we decided to bring Goodnotes to the web in 2021, we faced a critical decision. After more than 10 years of development, we had accumulated millions of lines of Swift code that implemented countless refinements and optimizations for digital ink rendering, document synchronization, conflict resolution using Conflict-Free Replicated Data Types (CRDTs), and content search and document indexing.

We need to maintain more than 60 Frames Per Second (FPS) for real-time ink rendering, which makes performance critical. A JavaScript rewrite, Flutter, or Kotlin Multiplatform would all require rewriting our entire rendering engine from scratch, a substantial undertaking that would have delayed our web launch by years and inevitably introduced behavioral differences between platforms.

SwiftWasm emerged as the solution. This community-driven project allows Swift code to compile to WebAssembly, running in browsers with good performance. We started experimenting with SwiftWasm, building prototypes to validate the approach. Our first experiment focused on our handwriting component, a performance-critical part of Goodnotes that would serve as a good indicator of WebAssembly’s capabilities. The results were promising enough that we committed to this path.

The most compelling benefit wasn’t just code reuse, but the guarantee of behavioral consistency. When users draw a stroke on their iPad and later open the same document on the web, they see exactly the same curves, the same pressure sensitivity, the same ink flow. This isn’t because we carefully reimplemented the same algorithms twice: it’s because it’s literally the same Swift code running on both platforms.

Technical architecture

Goodnotes Architecture: Shared Swift code between iOS and Web platforms.

Our architecture is built around a clear separation between platform-specific UI components and shared business logic. This design enables us to maintain behavioral consistency while leveraging platform-native capabilities where appropriate.

Shared core components

The heart of our application consists of three main parts:

Content Rendering Engine: This handles the real-time rendering of notebook content and interactive ink strokes. We use a custom rendering engine built on low-level graphics APIs: Metal on iOS and WebGL on the web. The rendering logic is almost entirely shared, with only platform abstraction layers implemented separately for each platform.

Business Logic Layer: Document modeling, handwriting recognition, and document indexing are all implemented in shared Swift packages.

View Models: Core view models that handle tool interactions and user gestures are shared across platforms.

Our codebase demonstrates significant code reuse:

Total Web Swift codebase: 2.2 million lines of code
Shared Swift code: 1.47 million lines (66% of the web app, 34% of the iOS app)

While lines of code isn’t the best metric, these numbers reflect the substantial business logic and rendering engine that we successfully share between platforms.

Binary size and loading

The final WebAssembly binary is approximately 50 MB, which compresses to 12 MB with Brotli compression. We use Service Workers for efficient caching and fast load times for users.

JavaScript interoperability

We use JavaScriptKit for seamless interoperability between Swift and JavaScript. This allows us to integrate with the existing web ecosystem while keeping our core logic in Swift.

Platform compatibility considerations

When sharing code between iOS and WebAssembly targets, we encountered several important considerations:

Concurrency Model: libdispatch APIs are unavailable on WebAssembly targets. We migrated from direct libdispatch usage to Swift Concurrency’s async/await and actors, for better cross-platform compatibility.

Architecture Differences: On wasm32, Swift’s Int has a 32-bit width. Some code assumed Int only held 64-bit values, so it had to be updated to use Int64 explicitly.

Dependency Injection: Network access and other I/O operations are abstracted through dependency injection, allowing us to provide platform-specific implementations while keeping the core logic shared.

Multithreading with WASI threads

One of the most significant technical achievements was implementing true parallelism using WebAssembly System Interface (WASI) Threads with Web Workers and SharedArrayBuffer. This allows us to:

Run handwriting recognition in background Web Workers
Perform document indexing without blocking the main thread
Maintain smooth rendering at more than 60 FPS while processing complex operations

Swift Concurrency’s Custom Actor Executors (SE-0392) were crucial for managing the web platform’s constraints. JavaScript objects are isolated to their originating thread, so we needed precise control over where our Swift actors execute. JavaScriptKit provides several APIs to create a SerialExecutor for a dedicated Web Worker, enabling us to pin specific actors to specific Web Workers.

This architecture ensures that computationally-intensive tasks like handwriting recognition run in the background while UI operations stay on the main thread, while still allowing access to JavaScript objects inside background threads.

Performance Impact: This multithreading approach delivered a greater than 2x improvement in Interaction to Next Paint (INP), significantly enhancing the UI responsiveness during complex operations.

Security Considerations: Modern browser security policies require Cross-Origin Isolation to use SharedArrayBuffer. While this adds some complexity to the application, it’s a necessary trade-off for the performance benefits of true parallelism. For applications that can’t meet these requirements, single-threaded cooperative concurrent execution remains a viable option.

Development experience

One of the most significant aspects of our Swift on WebAssembly experience was the development workflow. The tooling ecosystem is mature and powerful, providing a solid development experience.

IDE support

We can develop using either Xcode or VS Code with SourceKit-LSP, providing full language server support including autocomplete, error checking, and refactoring capabilities.

Xcode doesn’t currently have WebAssembly platform support, so code completion and other features are limited for WebAssembly-specific APIs. SourceKit-LSP, however, has Swift SDK support, so by properly configuring .sourcekit-lsp/config.json, you can get code completion for WebAssembly targets as well.

Debugging and development tools

You can debug Swift code directly in Chrome DevTools: set breakpoints, inspect variables, and step through your Swift code as naturally as JavaScript. We developed a Chrome DevTools extension library that enables Swift-specific variable reflection and source-level debugging, building upon the existing WebAssembly debugging capabilities. For more details on the enhanced DWARF extension for Swift, see the Swift on WebAssembly debugging guide.

Debugging Swift code in Chrome DevTools with full source code visibility and variable inspection.

Performance profiling

The existing web ecosystem provides powerful performance profiling tools. Chrome’s Performance tab shows exactly where time is spent, down to individual Swift functions, and the Memory tab gives us good insight into memory usage patterns. For most performance optimization tasks, these standard tools are quite effective.

For more advanced cases requiring specialized memory profiling capabilities and detailed heap analysis, the growing WebAssembly ecosystem provided the foundation for building custom tools. We developed wasm-memprof for detailed heap profiling when optimizing memory usage. This tool provides insights into memory allocation patterns that aren’t easily visible through standard web profiling tools.

Performance profiling with wasm-memprof showing memory allocation patterns and optimization opportunities.

Contributing back to the community

As part of our journey, we’ve been able to contribute back to the Swift community in meaningful ways. All WebAssembly-related changes have been upstreamed, and the WebAssembly platform has been supported since Swift 6.2! This means that other teams can now benefit from the same tooling and language features that made our project successful.

Lessons learned

Our experience has shown that Swift on WebAssembly is production-ready for complex applications. The language’s safety features, performance characteristics, and modern concurrency model translate well to the web platform.

For teams considering this path, here are our key recommendations:

Start with a performance-critical component to validate the approach.
Invest in proper platform abstraction layers early.
Leverage Swift Concurrency for cross-platform compatibility.
Plan for the security requirements of SharedArrayBuffer if multithreading is needed.
Consider gradual adoption rather than complete rewrites for existing projects.

Consider using Swift for your web projects. The growing WebAssembly ecosystem and improved tooling support make this an increasingly viable option for teams looking to share code across platforms.

Get involved with Swift on WebAssembly

Swift has fulfilled its promise as a powerful, expressive language that works everywhere. From mobile devices to servers to web browsers, Swift code can run efficiently while maintaining the safety and performance characteristics that developers appreciate.

The Swift on WebAssembly ecosystem is more accessible than ever. Here’s how you can get involved:

For Developers:

Try out the Swift on WebAssembly getting started guide and build your first web application.
Explore the JavaScriptKit Hello World tutorial for hands-on learning.
Use the WebAssembly debugging guide to set up your development environment.

For SwiftWasm Contributors:

Participate in discussions with the #webassembly tag on the Swift forums.
Open issues and contribute to improve the toolchain.
Share your experiences and help build the community.

With Swift’s official WebAssembly support, we’ve entered a new era of cross-platform development. The same language that powers iOS applications can now create web experiences that are fast, safe, and maintainable.

Swift’s future is increasingly cross-platform, and we’re excited to see what the community builds next.

What's new in Swift: April 2026 Edition

2026-05-01T06:30:00-04:00

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

The 1.0 release of valkey-swift was recently announced on the Valkey blog. We’ve invited one of the authors to be this month’s guest contributor:

Hi, I’m Adam Fowler, an open source developer working in the Swift on server ecosystem. I am excited to announce the 1.0 release of valkey-swift - a production-grade Swift client for Valkey.

Valkey is a high-performance datastore commonly used as a caching layer or message broker in server applications. It is an open source fork of Redis.

Valkey-swift is a client library targeted at Valkey servers but is equally capable of working with Redis. It is built from the ground up with Swift 6 and structured concurrency. Every Valkey command returns typed responses checked at compile time, and strict concurrency checking is enabled throughout so that data races are caught by the compiler, not in production. Connections and subscriptions are all scoped through structured concurrency, so resources clean up automatically.

The client covers every standard Valkey command, auto-generated from Valkey’s own command specifications to stay in sync as the server evolves.

Previously, the de facto client library for Redis was RediStack, which was built on top of pre-concurrency concepts. Retrofitting structured concurrency would have been awkward and some of the new features in valkey-swift infeasible. Around the same time Redis changed its licensing structure and the open source fork Valkey was created. So it felt like a good time to make a clean break and build a new library.

If you’re building server-side Swift and need a fast key-value store, add valkey-swift via Swift Package Manager, and you’re ready to go. If you are using RediStack to connect with a Redis server, we have a guide to help you migrate to valkey-swift. Complete documentation is available, and contributions are welcome on GitHub.

Now on to other news about Swift:

Videos to watch

The try! Swift Tokyo 2026 conference featured not one, but two exciting talks about Embedded Swift:
- Getting started with Embedded Swift is a short and accessible introductory talk. Learn about writing Swift using embedded simulators, along with code examples to run Swift code on devices including the Game Boy Advance!
- Learn by Building: Bare-Metal Programming with Embedded Swift is a deeper look at Embedded Swift. Follow along by trying the sample code for five bare-metal Raspberry Pi Pico examples that are featured in the talk.
Want to learn more about Swift concurrency from engineers who have designed and used its features? Check out this live online Q&A on Swift concurrency.
Nil Coalescing published a new video on some of the lesser known options for working with optionals in Advanced Techniques for Working with Optionals in Swift.

New package releases

IndustrialKit is a framework for designing, programming, and controlling robotic systems that was recently discussed on the Swift forums.
swift-tar is a pure Swift library for reading, writing, and extracting TAR archives. swift-tar is cross-platform, works without requiring any system framework or Foundation, and supports GNU & PAX extensions.
Xylem is a pure Swift XML parser with zero dependencies, covering SAX, DOM, and XPath 1.0.

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-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.

Recently accepted:

Vision for Networking - Swift’s networking ecosystem is getting an overhaul. This vision document proposes three initial areas of focus: evolve HTTP APIs including new HTTP client and server implementations, define currency types to reduce duplicated effort and integration friction, and define a unified networking stack.
SE-0517 UniqueBox - Sometimes in Swift it’s necessary to manually put something on the heap that wouldn’t otherwise live there. This proposal introduces a new type in the standard library, UniqueBox, which is a smart pointer type that uniquely owns a value on the heap.
ST-0022 Custom reflection during testing - When a test fails, Swift Testing reflects the values involved to help diagnose the failure, but types have no way to customize what appears in that output. This proposal adds a customization point, CustomTestReflectable, for developers to specify exactly what should be included in test output, whether they want to simplify, obscure, extend, or reformat that information.

One more thing

Have you recently looked at the Swift.org community page? It includes updated content, plus a new How we work page that describes opportunities to get involved.

Expanding Swift's IDE Support

2026-04-08T06:00:00-04:00

You can now write Swift in a broader range of popular IDEs, including Cursor, VSCodium, AWS’s Kiro, and Google’s Antigravity. By leveraging VS Code extension compatibility, these editors tap directly into the Open VSX Registry, where the official Swift extension is now live.

Swift has long supported development using multiple IDEs including VS Code, Xcode, Neovim, and Emacs. Swift is also compatible with editors that implement the Language Server Protocol (LSP). This growing ecosystem of editor support is particularly significant as Swift continues to show its versatility across platforms and development environments, including agentic IDEs.

Swift on Open VSX

The Swift extension for VS Code is now officially available on the Open VSX Registry, the vendor-neutral, open source extension registry hosted by the Eclipse Foundation. The extension adds first-class language support for projects built with Swift Package Manager, enabling seamless cross-platform development on macOS, Linux, and Windows. This milestone brings Swift support, including code completion, refactoring, full debugging support, a test explorer, as well as DocC support, to a broader ecosystem of compatible editors and allows agentic IDEs like Cursor and Antigravity to automatically install Swift, with no manual download required. 

Swift in Cursor, powered by the Swift extension on Open VSX.

Get Started

To start using the Swift extension in any Open VSX-compatible editor, simply open the Extensions panel, search for ‘Swift’ and install the extension.

If you’re using Cursor, getting started is easier than ever. Check out our new dedicated guide: Setting up Cursor for Swift Development. It walks you through the setup, features and includes how to configure custom Swift skills for your AI workflows.

Swift now has support for a wider range of modern editors and IDEs to meet developers where they are. Download the extension, try it out in your editor of choice, and don’t forget to share your feedback!

What's new in Swift: March 2026 Edition

2026-03-31T10:30:00-04:00

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

Swift 6.3 has been released, expanding Swift into new domains and improving developer ergonomics. A highlight of its release is work to improve cross-platform build tooling. Owen Voorhees shares an update on that effort:

Hi! I’m Owen, a lead engineer on the Core Build team at Apple. Last year we shared our goal to bring Swift Build to Swift Package Manager, in an effort to deduplicate build technologies within the Swift ecosystem and deliver a consistent build experience across all platforms that Swift supports.

Since the announcement, we’ve been working in the open, landing hundreds of patches to improve Swift Build’s support across various platforms including Linux and Windows, and to integrate it deeply in Swift Package Manager. With Swift 6.3, developers have the option to enable this integration and try it out with their packages. To validate parity with the previous build system, we’ve used the package list from swiftpackageindex.com, testing thousands of open source packages with Swift Build.

Most recently, the main branch of Swift started using Swift Build as its default build system, paving the way for Swift Build to be the out-of-the-box option for Swift developers in a future Swift release.

Over the coming months, we’ll continue sharing our progress and driving down the remaining bugs to bring the build system to parity. We encourage you to give it a try and file bugs that you encounter. We’re excited by this progress, and look forward to building future tooling improvements across all platforms and project models that will benefit from this build system.

Now on to other news about Swift:

Videos to watch

Interested in Swift for systems programming? The -ization of Containerization, presented at SCaLE, covers the Containerization project and their experience adopting Swift.
Swift community meetup #8 featured two talks: real-time computer vision on NVIDIA Jetson, and a production AI data pipeline built with Vapor.
A new interview with Matt Massicotte on the Swift Academy podcast goes in-depth on Swift Concurrency.

Community highlights

How can you gradually deprecate APIs ahead of a major release? Point-Free blogged Hard Deprecations and Soft Landings with SwiftPM Traits, a clever approach to solving a common API deprecation problem.
Daniel Jilg shared TelemetryDeck’s adoption story on the Swift blog, including how they use Swift and Vapor for backend services.
The March 2026 Swift for Wasm updates are out, highlighting a new JavaScriptKit release with BridgeJS improvements, and continued work in WasmKit.

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-0522 Source-Level Control Over Compiler Warnings - Swift lets you configure warning behavior at the module level using compiler flags, but that’s an all-or-nothing approach. This proposal adds fine-grained warning control: a @warn attribute that lets you override warning behavior for a specific diagnostic group within the scope of a single declaration, with support for escalating it to an error, downgrading it to a warning, or suppressing it entirely, without affecting the rest of your module.

Recently accepted:

SE-0509 Software Bill of Materials (SBOM) Generation for Swift Package Manager - An SBOM is a standardized inventory of all the software components in a project, increasingly required for security auditing and regulatory compliance. This proposal adds native SBOM generation to SwiftPM as both a --sbom-spec flag on swift build, and a separate swift package generate-sbom subcommand, with support for the CycloneDX and SPDX formats.
ST-0021 Targeted Interoperability between Swift Testing and XCTest - When migrating from XCTest to Swift Testing, it’s common to call existing XCTest helper functions from new Swift Testing tests. Today, an XCTAssert failure inside a Swift Testing test is silently ignored. This proposal fixes that: XCTest APIs will work as expected when called in Swift Testing, and Swift Testing APIs will work as expected when called in XCTest, if XCTest already provides similar functionality.
SE-0515 Allow reduce to produce noncopyable results - Swift’s reduce currently requires its initial value to be copyable, making it incompatible with noncopyable types. This proposal updates reduce to support noncopyable initial values and results, and changes it to consume rather than borrow the initial value, eliminating an unnecessary copy even for copyable types.

Swift 6.3 Released

2026-03-24T06:00:00-04:00

Swift is designed to be the language you reach for at every layer of the software stack. Whether you’re building embedded firmware, internet-scale services, or full-featured mobile apps, Swift delivers strong safety guarantees, performance control when you need it, and expressive language features and APIs.

Swift 6.3 makes these benefits more accessible across the stack. This release expands Swift into new domains and improves developer ergonomics across the board, featuring:

More flexible C interoperability
Improvements to cross-platform build tooling
Improvements for using Swift in embedded environments
An official Swift SDK for Android

Read on for an overview of the changes and next steps to get started.

Language and Standard Library

C interoperability

Swift 6.3 introduces the @c attribute, which lets you expose Swift functions and enums to C code in your project. Annotating a function or enum with @c prompts Swift to include a corresponding declaration in the generated C header that you can include in your C/C++ files:

@c
func callFromC() { ... }

// Generated C header

void callFromC(void);

You can provide a custom name to use for the generated C declaration:

@c(MyLibrary_callFromC)
func callFromC() { ... }

// Generated C header

void MyLibrary_callFromC(void);

@c also works together with @implementation. This lets you provide a Swift implementation for a function declared in a C header:

// C header

void callFromC(void);

// Implementation written in Swift

@c @implementation
func callFromC() { ... }

When using @c together with @implementation, Swift will validate that the Swift function matches a pre-existing declaration in a C header, rather than including a C declaration in the generated header.

Module name selectors

Swift 6.3 introduces module selectors to specify which imported module Swift should look in for an API used in your code. If you import more than one module that provides API with the same name, module selectors let you disambiguate which API to use:

import ModuleA
import ModuleB

let x = ModuleA::getValue() // Call 'getValue' from ModuleA
let y = ModuleB::getValue() // Call 'getValue' from ModuleB

Swift 6.3 also enables using the Swift module name to access concurrency and String processing library APIs:

let task = Swift::Task {
  // async work
}

Performance control for library APIs

Swift 6.3 introduces new attributes that give library authors finer-grained control over compiler optimizations for clients of their APIs:

Function specialization: Provide pre-specialized implementations of a generic API for common concrete types using @specialize.
Inlining: Guarantee inlining — a compiler optimization that expands the body of a function at the call-site — for direct calls to a function with @inline(always). Use this attribute only when you’ve determined that the benefits of inlining outweigh any increase in code size.
Function implementation visibility: Expose the implementation of a function in an ABI-stable library to clients with @export(implementation). This allows the function to participate in more compiler optimizations.

For a full list of language evolution proposals in Swift 6.3, see the Swift Evolution dashboard.

Package and Build Improvements

Swift 6.3 includes a preview of Swift Build integrated into Swift Package Manager. This preview brings a unified build engine across all supported platforms for a more consistent cross-platform development experience. To learn more, check out Preview the Swift Build System Integration. We encourage you to try it in your own packages and report any issues you encounter.

Swift 6.3 also brings the following Swift Package Manager improvements:

Prebuilt Swift Syntax for shared macro libraries: Factor out shared macro implementation code into a library with support for swift-syntax prebuilt binaries in libraries that are only used by macros.
Flexible inherited documentation: Control whether inherited documentation is included in command plugins that generate symbol graphs.
Discoverable package traits: Discover the traits supported by a package using the new swift package show-traits command.

For more information on changes to Swift Package Manager, see the SwiftPM 6.3 Release Notes.

Core Library Updates

Swift Testing

Swift Testing has a number of improvements, including warning issues, test cancellation, and image attachments.

Warning issues: Specify the severity of a test issue using the new severity parameter to Issue.record. You can record an issue as a warning using Issue.record("Something suspicious happened", severity: .warning). This is reflected in the test’s results, but doesn’t mark the test as a failure.
Test cancellation: Cancel a test (and its task hierarchy) after it starts using try Test.cancel(). This is helpful for skipping individual arguments of a parameterized test, or responding to conditions during a test that indicate it shouldn’t proceed.
Image attachments: Attach common image types during a test on Apple and Windows platforms. This is exposed via several new cross-import overlay modules with UI frameworks like UIKit.

The list of Swift Testing evolution proposals included in Swift 6.3 are ST-0012, ST-0013, ST-0014, ST-0015, ST-0016, ST-0017, and ST-0020.

DocC

Swift 6.3 adds three new experimental capabilities to DocC:

Markdown output: Generate Markdown versions of your documentation pages alongside the standard rendered JSON covering symbols, articles, and tutorials. Try it out by passing --enable-experimental-markdown-output to docc convert.
Per-page static HTML content: Embed a lightweight HTML summary of each page — including title, description, availability, declarations, and discussion — directly into the index.html file within a <noscript> tag. This improves discoverability by search engines and accessibility for screen readers without requiring JavaScript. Try it out by passing --transform-for-static-hosting --experimental-transform-for-static-hosting-with-content to docc convert.
Code block annotations: Unlock new formatting annotations for code blocks, including nocopy for disabling copy-to-clipboard, highlight to highlight specific lines by number, showLineNumbers to display line numbers, and wrap to wrap long lines by column width. Specify these options in a comma-separated list after the language name on the opening fence line:
```
```swift, nocopy
let config = loadDefaultConfig()
```
```
```
 ```swift, highlight=[1, 3]
let name = "World"       // highlighted
let greeting = "Hello"
print("\(greeting), \(name)!")  // highlighted
```
```
```
```swift, showLineNumbers, wrap=80
func example() { /* ... */ }
```
```
DocC validates line indices and warns about unrecognized options. Try out the new code block annotations with --enable-experimental-code-block-annotations.

Platforms and Environments

Embedded Swift

Embedded Swift has a wide range of improvements in Swift 6.3, from enhanced C interoperability and better debugging support to meaningful steps toward a complete linkage model. For a detailed look at what’s new in embedded Swift, see Embedded Swift Improvements coming in Swift 6.3.

Android

Swift 6.3 includes the first official release of the Swift SDK for Android. With this SDK, you can start developing native Android programs in Swift, update your Swift packages to support building for Android, and use Swift Java and Swift Java JNI Core to integrate Swift code into existing Android applications written in Kotlin/Java. This is a significant milestone that opens new opportunities for cross-platform development in Swift.

To learn more and try out Swift for Android development in your own projects, see Getting Started with the Swift SDK for Android.

Thank You

Swift 6.3 reflects the contributions of many people across the Swift community — through code, proposals, forum discussions, and feedback from real-world experience. A special thank you to the Android Workgroup, whose months of effort — building on many years of grassroots community work — brought the Swift SDK for Android from nightly previews to an official release in Swift 6.3.

If you’d like to get involved in what comes next, the Swift Forums are a great place to start.

Next Steps

Try out Swift 6.3 today! You can find instructions for installing a Swift 6.3 toolchain on the Install Swift page.

Swift at scale: building the TelemetryDeck analytics service

2026-03-06T07:00:00-04:00

TelemetryDeck is an app analytics service specifically for developers, designed to manage usage analytics that are anonymized, privacy-focused, and really easy to use. TelemetryDeck is managing the data of over 16 million people every month, helping thousands of app publishers improve their products, and we’re doing it all with a Swift-based infrastructure.

The decision to go with Swift brought a lot of unexpected advantages for us. We come from a world of iOS in the frontend, Python, Node, or Ruby in the backend for server-based applications. Compared to these languages and frameworks, Swift is just as easy to use, and its compiled nature allows us to catch a lot of possible errors at compile time instead of runtime, making it ideal for a hardened, high-performance web service.

Let me share our journey and history with you.

Adopting Swift for backend services

TelemetryDeck is built on Vapor, a web framework written in Swift, for building scalable APIs and services.

Similar to other Vapor-based projects like Things, TelemetryDeck runs on containers hosted in Kubernetes. Our metadata lives in Postgres, and our analytics data is stored in Apache Druid. We use Swift-native connectors to access APIs for these services. Some of those come from the Swift community, others we’ve written ourselves and are giving back to the open source ecosystem.

In the very beginning, when TelemetryDeck was just a little exploratory hobby project, we wanted to go with Swift on the server simply because we love Swift, and we’re pretty decent at it. Vapor was new, and we figured, let’s try this out and learn a new way to apply and combine our skills.

In the end, this decision turned out to be exactly the right one and resulted in a lean architecture that is highly performant, stable, and allows us to develop and iterate quickly.

Swift’s performance characteristics are remarkable, especially in multithreading. Python’s Global Interpreter Lock has long constrained true parallelism, though recent versions have improved this. Swift doesn’t face that same challenge. Our infrastructure handles 16 million users per month with resources that would buckle other architectures. The efficiency gains aren’t just theoretical — they translate directly to lower infrastructure costs and a better user experience.

Swift’s Codable protocol

In an API-based application, you spend an enormous amount of time encoding and decoding JSON. Swift’s Codable protocol turns what’s traditionally error-prone boilerplate into straightforward, type-safe operations. When a request comes in with malformed data, Swift’s type system rejects it immediately with no manual validation required. This isn’t just convenient; it’s a security feature that prevents entire classes of vulnerabilities.

struct Notebook: Codable, Content {
    let appID: UUID
    var snapshots: [NotebookSnapshot]
    let createdAt: Date
    let title: String
}

With just these few lines, we get parsing, validation, and type safety.

Just like the postal system – which only accepts letters addressed in a specific format – the API endpoint described in the above bit of code will reject any data that doesn’t fit into this Codable.

We don’t have to check for types, additional properties, or JSON validity, something that lets us trust our APIs more when developing and sleep easy after deploying. “Just lick the stamp and send it,” as a friend of mine once encouraged me.

For a long time, TelemetryDeck offered a SwiftUI-based desktop application for interacting with analytics data, displaying dashboards, and exploring correlations. This meant we could use the same structs for encoding data on the server and decoding it on the client – these are called Data Transfer Objects or DTOs. We kept a separate package “SwiftDTOs” that was shared between both clients and the server code.

However, we ran into trouble when we updated our APIs to new versions with slightly different inputs and outputs. We always have the API version in our paths, which helps us continuously develop them while keeping compatibility with clients that take a while to update. This pattern made it hard to update Data Transfer Objects quickly because changing a struct for one API version could break another.

For our newest API version, we abandoned this approach. DTOs now live directly in their controllers as inline structs:

extension V3QueryController {
    struct QueryRequest: Codable {
        let query: QueryDefinition
        let timeRange: TimeRange
    }

    struct QueryResponse: Codable {
        let results: [QueryResult]
        let metadata: ResponseMetadata
    }
}

The lesson? Keep your DTOs close to your controllers. It’s simpler, more maintainable, and makes changes easier. Sometimes the obvious solution is the right one.

Developer experience matters

One underappreciated aspect of Swift on the server is the development experience. Swift services can be developed using your favorite IDE, including VS Code, Cursor, Xcode, and editors supporting the Language Server Protocol (LSP). We chose to develop in Xcode, our favorite IDE, with full debugging capabilities.

Under the hood, a Swift Vapor project is just a Swift Package with some dependencies. You open it in Xcode, you press Cmd+U to run the tests, you run it and set breakpoints and step through them when you’re following a bug through the stack.

Our web API services usually have a database attached to them, so when we’re developing, we can either run PostgreSQL on our machines right next to the code, or we can ask Swift Vapor’s database layer (Fluent) to use a different database for development, such as a local SQLite file.

The end result is a very comfortable experience that allows us to use an IDE specifically built for Swift development, without needing to spin up containers.

This flexibility matters when you’re building a business. We can onboard new developers quickly because the tooling is familiar. We can iterate rapidly because the feedback loop is tight. And we can maintain high code quality because Swift’s type system catches errors at compile time, not in production.

Building the ecosystem we want to use

We love the open source ecosystem around Swift on the server. There are Swift packages for external services like payment providers and transactional emails. There are tools like Imperial for Single Sign-On, and Swift Crypto for standards-compliant cryptography.

Whenever a piece of the puzzle is missing, we try to give back as much as possible. That is partly because the Swift developer community is fantastic in coming up with SDKs for various services, and we try to contribute to existing projects like StripeKit (where we added support for a lot of APIs that Stripe released) or even release our own new SDKs like BrevoKit.

Lessons learned

Building a production service teaches you things that tutorials never will. Here are some hard-won lessons from our journey:

Use the Swift Package system. A package is a fantastic way to structure and isolate code. Since our services are packages anyway, it’s natural to further subdivide them where it makes sense.

Your Swift Vapor service is almost never the bottleneck. Although profiling Swift code is easy, most slowdowns in a web service will arise from a combination of database, storage, and traffic load. You’ll migrate the way you store and access data frequently as you gain experience.

Embrace Vapor’s built-in features. Queues and jobs, migrations, and middleware. Vapor has mature solutions for common patterns. We use Fluent almost exclusively over raw SQL, and Vapor’s queue system handles everything from data processing to billing tasks.

Version your API URLs from day one. You’ll thank yourself later when you need to evolve your API without breaking existing clients.

Always set cache expiration times. It sounds obvious, but that Redis cache that “will never grow too large” absolutely will. Set reasonable TTLs on everything that you cache.

Monitor errors and performance. When you build an iPhone app, you automatically get crash logs that help you find out where things are going wrong for your users. On the server, you’ll have to collect those yourself. Before we started doing that, our customers would discover problems before we did, and that never feels good or professional.

Now we use a combination of Swift Distributed Tracing and our own analytics-based middleware to find performance bottlenecks and errors that are predictors of service crashes, and we can right the ship before most of our customers notice.

Where we are now

TelemetryDeck proves that Swift isn’t just for apps — it’s a legitimate choice for building scalable, performant backend services. We’re processing millions of events, serving thousands of developers, and doing it all with Swift and Vapor. The language that powers apps on billions of iOS devices is equally capable of powering the services behind them.

The performance gains are real: we can crunch and encode tens of thousands of data points in milliseconds. The development velocity is fantastic: we work in Xcode and write tests for behaviour and not for data parsing. And the type safety prevents entire categories of bugs that dynamically typed languages like Python or JavaScript need additional code to guard against. Perhaps most importantly, the joy of writing Swift makes the long hours of building a business more bearable.

If you’re considering Swift for your next server-side project, take it from someone who’s built an entire business on it: Swift delivers on its promise of safe, fast, and expressive code—whether that code runs on an iPhone or in a data center.

What's new in Swift: February 2026 Edition

2026-03-02T10:05:00-04:00

Welcome to this edition of “What’s New in Swift,” where we share interesting projects and updates in the Swift community that deserve visibility to a broader audience.

FOSDEM is the largest open source conference in the world, and this year Swift was featured in talks across multiple tracks and a dedicated pre-conference event. Here’s a report from the Swift community:

Hey there! Karen Chu here. 👋 I help grow and support the Swift open source community, and one of my favorite things has been increasing Swift’s participation in open source events.

As a follow-up to Swift’s presence at FOSDEM last year, this year we expanded our approach by running our own Pre-FOSDEM fringe event, which included 11 talks across multiple platforms, in addition to four Swift talks across various devroom tracks.

Though it was my first year at FOSDEM, it was delightful to meet several people who attended the Swift devroom last year and also came through again this year. With the vast array of attendee backgrounds (I met recent grads, former Swift mentees, Swift workgroup members, folks from the Swift Core Team, and more) and talks covering different platforms (embedded, server, BSD, Android, and more), that weekend showed me just how much momentum Swift has gained as a general purpose language that can benefit everyone.

I wanted to highlight Simon Leeb’s talk, Swift in the Browser with ElementaryUI, as a popular talk from the event which showed how to run Swift applications natively in the browser with WebAssembly.

FOSDEM may be over (for now), but I’m already excited about how the Swift community will show up next year!

To catch up on all the talks at the Pre-FOSDEM event, check out the YouTube playlist.

Now on to other news about Swift:

New package releases

Originally developed for searching financial databases for strings like stock tickers, FuzzyMatch brings high-performance fuzzy string matching to Swift.
Now you can expose GraphQL APIs in your applications with new Vapor and Hummingbird packages.
Using Microsoft SQL Server? SQLClient-Swift is a native client for iOS, macOS, and Linux that’s built using modern Swift concurrency.
Developers now have more options to create terminal-based Swift applications with TuiKit, a declarative, SwiftUI-like framework for building Terminal User Interfaces. TuiKit joins Noora, which provides themeable components for CLIs.

Lastly, Swift System Metrics 1.0 was announced, making the collection of process-level metrics easy.

Videos to watch

Interested in writing Swift using agents? At Swift Barcelona, a talk on Building Agentic Apps with MCP in Swift demonstrated several open source tools. And if you’re an Xcode user, check out a recent code-along covering coding intelligence in Xcode 26.
Introducing the Swift SDK for Android covered the current state of Swift on Android, how to call Java and Kotlin APIs from Swift, UI strategies, and what’s actively being worked on.
SwiftCrossUI: Swift apps, everywhere presented a UI solution for Swift applications that run on Android, Linux, and Windows, using native UI components on each platform. The project also recently published a development update in video form, covering contributions and recent changes.
Ever wanted to control microcontrollers in Swift? CoreAVR + ArduinoKit: Swift on the Arduino, the Swift way introduces ArduinoKit, which acts as the Arduino standard library for Swift, and CoreAVR, a hardware abstraction layer for AVR microcontrollers written in Swift.

Community highlights

Swift is participating in Google Summer of Code 2026! 🎉 A recent forums post announced the process and outlined key dates to learn more. This is a great opportunity if you’re a student interested in contributing to Swift!
A community member recently blogged about their experience profiling Swift applications on Windows and macOS with Tracy, covering how to visualize and analyze their application performance.

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-0514 Hashable Conformance for Dictionary.Keys, CollectionOfOne and EmptyCollection - Three standard library collection types can’t currently be used in sets or as dictionary keys. This proposal adds Hashable conformance to all three, for consistency with the rest of the standard library.
SE-0513 API to get the path to the current executable - There’s currently no portable, reliable way to get the path to the currently running executable in Swift. This proposal adds CommandLine.executablePath, a new property in the standard library that provides a consistent way to get this value across all platforms Swift supports.

Recently accepted:

SE-0506 Advanced Observation Tracking - @Observable types automatically track when their properties change. However, advanced use cases like developing middleware infrastructure or widget systems require more control and features. This proposal adds options to the existing withObservationTracking to control when/which changes are observed, and a continuous variant that re-observes automatically after coalesced events.
SE-0502 Exclude private initialized properties from memberwise initializer - When you define a struct in Swift, the compiler automatically generates an initializer that takes each property as an argument. Currently, adding a private property with a default value to a struct forces that auto-generated initializer to become private, which breaks callers outside of the type. This proposal fixes that behavior.

Have any suggestions for a future issue? Drop them in the Community Showcase on the Swift Forums. See you next time!

Announcing Swift System Metrics 1.0: Process-Level Monitoring

2026-02-20T06:00:00-04:00

We are excited to announce the 1.0 release of Swift System Metrics, a Swift package that collects process-level system metrics like CPU utilization time and memory usage. Swift System Metrics runs on both Linux and macOS, providing a common API across platforms.

Swift System Metrics visualized in Grafana, demonstrating what's possible with real-time monitoring.

Monitoring process metrics enables you to detect performance issues, optimize resource usage, and ensure your service remains reliable and cost-effective under varying loads. You can integrate Swift System Metrics into your service in just a few lines of code, making observability accessible to every developer and ensuring that even the smallest services can have production-grade visibility from day one.

Swift System Metrics is part of a larger set of packages that provide an end-to-end solution for integrating metrics into your Swift applications and services. Once system metrics are collected, they’re reported to Swift Metrics, a backend-agnostic metrics API that can work with popular backends like Prometheus and OpenTelemetry. Swift System Metrics also leverages Swift Service Lifecycle to handle process bootstrapping and resource cleanup.

With the 1.0 milestone, the API is now stable and ready for use. Note that this package was previously swift-metrics-extras, and renamed to better reflect its purpose.

Highlights

Collects and reports:
- CPU utilization time
- Virtual and resident memory usage
- Open and maximum available file descriptors
- Process start time
API-stable public interface
Support on both Linux and macOS
musl libc compatibility

The package includes an example Grafana dashboard configuration to start visualizing metrics immediately.

Get Started

Add the dependency to your Package.swift:

.package(url: "https://github.com/apple/swift-system-metrics", from: "1.0.0")

Add the library dependency to your target:

.product(name: "SystemMetrics", package: "swift-system-metrics")

Import and use in your code:

import SystemMetrics
import ServiceLifecycle
import Logging
import OTel

@main
struct Application {
  static func main() async throws {
    // Create a logger, or use one of the existing loggers
    let logger = Logger(label: "Application")

    // Setup MetricsSystem, for example using swift-otel
    var otelConfig = OTel.Configuration.default
    otelConfig.serviceName = "Application"
    let otelService = try OTel.bootstrap(configuration: otelConfig)

    // Setup your service
    let service = FooService()

    // Create the monitor
    let systemMetricsMonitor = SystemMetricsMonitor(logger: logger)

    // Create the service
    let serviceGroup = ServiceGroup(
      services: [otelService, service, systemMetricsMonitor],
      gracefulShutdownSignals: [.sigint],
      cancellationSignals: [.sigterm],
      logger: logger
    )

    try await serviceGroup.run()
  }
}

The complete documentation is available on Swift Package Index.

Get Involved

We’re looking for contributions to grow the list of process metrics collected and to expand platform support. PRs are welcome - our contribution guidelines describe how to get started.

By reaching 1.0, this project will maintain a backwards-compatible API as it continues to evolve. Thanks to everyone who contributed to this release.

What's new in Swift: January 2026 Edition

2026-01-30T11:15:00-04:00

A Reddit thread earlier this month asked about building web apps with Swift. For this edition of “What’s new in Swift,” we invited a developer to share their experience:

Hi, I’m Nick Sloan. I’m the head of engineering at Studioworks, a platform that makes it easy and fun to run your creative studio, agency or freelance business.

We chose Swift for Studioworks because of how easy it is to write safe and reliable code with great performance. Our Swift project makes use of Hummingbird 2, Soto (for its incredible DynamoDB Codable support), Hummingbird MacroRouting, and Elementary. Studioworks is a big and growing project. We are the largest Elementary codebase, and I suspect we are among the biggest projects using Hummingbird as well.

We’ve already processed millions of dollars in invoices for our customers, and after 20 years of shipping web applications, I have never seen fewer crashes and bugs make it to production. Performance has also been excellent, especially after moving our templates to Elementary. Our heaviest pages make it to the browser in less than 100ms.

We’ve been deploying web applications with PHP and Python for decades, and getting started with a Swift web project was certainly a bit slower. We had to recreate some of the build, deployment and chat tooling we had been relying on in our Python projects for years, and it took us a bit of experimenting to realize that Elementary was the best choice for templating. Once we got past those hurdles we’ve been able to build about as fast as we ever did with Python, and the quality is much better.

Swift on the web has been a resounding success for us, and I hope we’ll see this part of the community continue to grow!

— Nick Sloan

Learn more about Swift on Linux and server-based use cases by checking out our October edition, which featured highlights from the Server-Side Swift Conference. The swift.org website also has a use case page dedicated to cloud services, including a tutorial to get started.

And now for what’s new in Swift this month.

Videos to watch

On Progressive Disclosure in Swift - Doug Gregor’s must-watch talk explores how Swift lets you progressively use more language features as your experience and codebase evolves.
A new episode of NSScreencast dives into livecoding the Billion Row Challenge, with Matt Massicotte as a guest.

New package releases

Want to build 3D models with code? Cadova is a programmable alternative to traditional CAD tools, with a focus on 3D printing.
Feather Database provides a database-agnostic layer that can be shared by multiple database drivers. And it’s designed for modern Swift concurrency.
Miguel de Icaza has ported the .NET Foundation mail stack, originally created by Jeffrey Stedfast (MailKit/MimeKit), to Swift. Hello MailFoundation and MimeFoundation!

Community highlights

Introduction to Building Swift for Yocto - Check out this embedded Linux guide to using meta-swift to build Swift for a Raspberry Pi Zero 2.
Registration is open for several Swift community conferences, including SwiftCraft and try! Swift Tokyo. The Call for Proposals (CFP) is still open for try! Swift Tokyo.

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-0506 Advanced Observation Tracking - @Observable types automatically track when their properties change. However, advanced use cases like developing middleware infrastructure or widgeting systems require more control and features. This proposal adds options to the existing withObservationTracking to control when/which changes are observed, and a continuous variant that re-observes automatically after coalesced events.
SE-0507 Borrow and Mutate Accessors - When you read or write a Swift property, the code that handles that access currently either makes a copy of the value or uses coroutines, which have performance overhead. This proposal adds new borrow and mutate keywords that let properties provide direct access to their stored values and enables properties that hold values that can’t be copied.

Recently accepted:

SE-0498 Expose demangle function in Runtime module - The Swift compiler uses name mangling, turning Swift symbols into strings like $sSS7cStringSSSPys4Int8VG_tcfC which show up in backtraces and profiling tools. There are times, however, when a human-readable format is preferable. This proposal introduces a new API that allows calling out to the Swift runtime’s demangler, without leaving the process.

Announcing the Windows Workgroup

2026-01-26T08:00:00-04:00

We are excited to announce the creation of the Windows workgroup!

The primary goal is to ensure ongoing support for Swift on Windows, enabling users to develop Windows applications using the Swift programming language and its associated tools.

The new Windows workgroup joins a growing list of Swift workgroups, including the Android workgroup, Build and Packaging workgroup, and Testing workgroup which were all added in the past year. Swift workgroups are community-led efforts, formally recognized by the project, to help move forward key areas.

Windows has been an officially supported platform since 2020, and there’s been great progress since then. The VS Code extension supports Windows, and we’ve seen the community take advantage of Swift’s features on Windows, some of which are described in a 2023 blog post about Using Interoperability to Build on Windows. The workgroup will build upon these efforts and focus on work to:

Improve and maintain Windows support for the official Swift distribution.
Recommend enhancements to core Swift packages such as Foundation and Dispatch to work better with Windows idioms.
Make recommendations to the Swift Project about the direction of future Windows support in Swift.
Identify and recommend best practices for bridging between Swift and the Windows API, and for shipping Swift libraries with Windows applications.

To learn more and get involved:

Discuss this announcement on the forums, and share ideas in the Windows category.
Learn more about the Windows workgroup by reading its charter.
Join the Windows workgroup’s meetings every other Wednesday at 9:00 AM PT (Pacific Time Zone).
- Workgroup membership and meetings are open to those who wish to participate, and contributors are welcome!
- To receive an invite, send a message to @windows-workgroup on the Swift forums.

Improving the usability of C libraries in Swift

2026-01-22T08:00:00-04:00

There are many interesting, useful, and fun C libraries in the software ecosystem. While one could go and rewrite these libraries in Swift, usually there is no need, because Swift provides direct interoperability with C. With a little setup, you can directly use existing C libraries from your Swift code.

When you use a C library directly from Swift, it will look and feel similar to using it from C. That can be useful if you’re following sample code or a tutorial written in C, but it can also feel out of place. For example, here’s a small amount of code using a C API:

  var instanceDescriptor = WGPUInstanceDescriptor()
  let instance = wgpuCreateInstance(&instanceDescriptor)
  var surfaceDescriptor = WGPUSurfaceDescriptor()
  let surface = wgpuInstanceCreateSurface(instance, &surfaceDescriptor)
  if wgpuSurfacePresent(&surface) == WGPUStatus_Error {
      // report error
  }
  wgpuSurfaceRelease(surface)
  wgpuInstanceRelease(instance)

The C library here that Swift is using comes from the webgpu-headers project, which vends a C header (webgpu.h) that is used by several implementations of WebGPU. WebGPU is a technology that enables web developers to use the system’s GPU (Graphics Processing Unit) from the browser. For the purposes of this post, you don’t really need to know anything about WebGPU: I’m using it as an example of a typical C library, and the techniques described in this blog post apply to lots of other well-designed C libraries.

The Swift code above has a very “C” feel to it. It has global function calls with prefixed names like wgpuInstanceCreateSurface and global integer constants like WGPUStatus_Error. It pervasively uses unsafe pointers, some of which are managed with explicit reference counting, where the user provides calls to wpuXYZAddRef and wgpuXYZRelease functions. It works, but it doesn’t feel like Swift, and inherits various safety problems of C.

Fortunately, we can improve this situation, providing a safer and more ergonomic interface to WebGPU from Swift that feels like it belongs in Swift. More importantly, we can do so without changing the WebGPU implementation: Swift provides a suite of annotations that you can apply to C headers to improve the way in which the C APIs are expressed in Swift. These annotations describe common conventions in C that match up with Swift constructs, projecting a more Swift-friendly interface on top of the C code.

In this post, I’m going to use these annotations to improve how Swift interacts with the WebGPU C code. By the end, we’ll be able to take advantage of Swift features like argument labels, methods, enums, and automatic reference counting, like this:

  var instanceDescriptor = WGPUInstanceDescriptor()
  let instance = WGPUInstance(descriptor: &instanceDescriptor)
  var surfaceDescriptor = WGPUSurfaceDescriptor()
  let surface = instance.createSurface(descriptor: &surfaceDescriptor)
  if surface.present() == .error {
      // report error
  }
  // Swift automatically deallocates the instance and surface when we're done

These same annotations can be used for any C library to provide a safer, more ergonomic development experience in Swift without changing the C library at all.

Note: Some of what is covered in this post requires bug fixes that first became available in Swift 6.2.3.

Setup: Writing a module map

A module map is a way of layering a Swift-friendly modular structure on top of C headers. You can create a module map for the WebGPU header by writing the following to a file module.modulemap:

module WebGPU {
  header "webgpu.h"
  export *
}

The easiest thing to do is to put module.modulemap alongside the header itself. For my experiment here, I put it in the root directory of my webgpu-headers checkout. If you’re in a Swift package, put it into its own target with this layout:

├── Package.swift
└── Sources
    └── WebGPU
        ├── include
        │   ├── webgpu.h
        │   └── module.modulemap
        └── WebGPU.c (empty file)

If you reference this WebGPU target from elsewhere in the package, you can import WebGPU to get access to the C APIs.

Seeing the results

There are a few ways to see what the Swift interface for a C library looks like.

The swift-synthesize-interface tool in Swift 6.2+ prints the Swift interface to the terminal.
Xcode’s “Swift 5 interface” counterpart to the webgpu.h header will show how the header has been mapped into Swift.

Let’s do it from the command line, using swift-synthesize-interface. From the directory containing webgpu.h and module.modulemap, run:

xcrun swift-synthesize-interface -I . -module-name WebGPU -target arm64-apple-macos15 -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.0.sdk

The leading xcrun and the -sdk argument with the path is only needed on macOS; on other platforms, make sure swift-synthesize-interface is in your path. The -target operation is the triple provided if you run swiftc -print-target-info. It looks like this:

{
  "compilerVersion": "Apple Swift version 6.2 (swiftlang-6.2.2.15.4 clang-1700.3.15.2)",
  "target": {
    "triple": "arm64-apple-macosx15.0",
    "unversionedTriple": "arm64-apple-macosx",
    "moduleTriple": "arm64-apple-macos",
    "compatibilityLibraries": [ ],
    "librariesRequireRPath": false
  },
  "paths": { ... }
}

The output of swift-synthesize-interface is the Swift API for the WebGPU module, directly translated from C. For example, this code from the WebGPU header:

typedef enum WGPUAdapterType {
    WGPUAdapterType_DiscreteGPU = 0x00000001,
    WGPUAdapterType_IntegratedGPU = 0x00000002,
    WGPUAdapterType_CPU = 0x00000003,
    WGPUAdapterType_Unknown = 0x00000004,
    WGPUAdapterType_Force32 = 0x7FFFFFFF
} WGPUAdapterType WGPU_ENUM_ATTRIBUTE;

is translated into:

public struct WGPUAdapterType : Hashable, Equatable, RawRepresentable {
    public init(_ rawValue: UInt32)
    public init(rawValue: UInt32)
    public var rawValue: UInt32
}

public var WGPUAdapterType_DiscreteGPU: WGPUAdapterType { get }
public var WGPUAdapterType_IntegratedGPU: WGPUAdapterType { get }
public var WGPUAdapterType_CPU: WGPUAdapterType { get }
public var WGPUAdapterType_Unknown: WGPUAdapterType { get }
public var WGPUAdapterType_Force32: WGPUAdapterType { get }

and there are lots of global functions like this:

public func wgpuComputePipelineGetBindGroupLayout(_ computePipeline: WGPUComputePipeline!, _ groupIndex: UInt32) -> WGPUBindGroupLayout!
public func wgpuComputePipelineSetLabel(_ computePipeline: WGPUComputePipeline!, _ label: WGPUStringView)
public func wgpuComputePipelineAddRef(_ computePipeline: WGPUComputePipeline!)
public func wgpuComputePipelineRelease(_ computePipeline: WGPUComputePipeline!)

It’s a starting point! You can absolutely write Swift programs using these WebGPU APIs, and they’ll feel a lot like writing them in C. Let’s see what we can do to make it better.

Cleaning up enumeration types

C enums can be used for several things. Sometimes they really represent a choice among a number of alternatives. Sometimes they represent flags in a set of options, from which you can choose several. Sometimes they’re just a convenient way to create a bunch of named constants. Swift conservatively imports enum types as wrappers over the underlying C type used to store values of the enum (e.g., WGPUAdapterType wraps a UInt32) and makes the enumerators into global constants. It covers all of the possible use cases, but it isn’t nice.

The WGPUAdapterType enum really is a choice among one of several options, which would be best represented as an enum in Swift. If we were willing to modify the header, we could apply the enum_extensibility attribute to the enum, like this:

typedef enum __attribute__((enum_extensibility(closed))) WGPUAdapterType {
    WGPUAdapterType_DiscreteGPU = 0x00000001,
    WGPUAdapterType_IntegratedGPU = 0x00000002,
    WGPUAdapterType_CPU = 0x00000003,
    WGPUAdapterType_Unknown = 0x00000004,
    WGPUAdapterType_Force32 = 0x7FFFFFFF
} WGPUAdapterType WGPU_ENUM_ATTRIBUTE;

This works, and results in a much nicer Swift API:

@frozen public enum WGPUAdapterType : UInt32, @unchecked Sendable {
    case discreteGPU = 1
    case integratedGPU = 2
    case CPU = 3
    case unknown = 4
    case force32 = 2147483647
}

Now, we get an enum that we can switch over, and nice short case names, e.g.,

switch adapterType {
  case .discreteGPU, .integratedGPU:
    print("definitely a GPU")
  default:
    print("not so sure")
}

That’s great, but I already broke my rule: no header modifications unless I have to!

API notes

The problem of needing to layer information on top of existing C headers is not a new one. As noted earlier, Swift relies on a Clang feature called API notes to let us express this same information in a separate file, so we don’t have to edit the header. In this case, we create a file called WebGPU.apinotes (the name WebGPU matches the module name from module.modulemap), which is a YAML file describing the extra information. We’ll start with one that turns WGPUAdapterType into an enum:

---
Name: WebGPU
Tags:
- Name: WGPUAdapterType
  EnumExtensibility: closed

Tags here is a term used in the C and C++ standard to refer to enum, struct, union, or class types. Any information about those types in the API notes file will go into that section.

Put WebGPU.apinotes alongside the module.modulemap, and now WGPUAdapterType gets mapped into a Swift enum. For a package, the structure will look like this:

├── Package.swift
└── Sources
    └── WebGPU
        ├── include
        │   ├── webgpu.h
        │   ├── WebGPU.apinotes
        │   └── module.modulemap
        └── WebGPU.c (empty file)

We’ll be adding more to this API notes file as we keep digging through the interface.

Reference-counted object types

The WebGPU header has a number of “object” types that are defined like this:

typedef struct WGPUBindGroupImpl* WGPUBindGroup WGPU_OBJECT_ATTRIBUTE;

This gets imported into Swift as an alias for an opaque pointer type, which is… not great:

public typealias WGPUBindGroup = OpaquePointer

WebGPU object types are reference counted, and each object type has corresponding AddRef and Release functions to increment and decrement the reference count, like this:

WGPU_EXPORT void wgpuBindGroupAddRef(WGPUBindGroup bindGroup) WGPU_FUNCTION_ATTRIBUTE;
WGPU_EXPORT void wgpuBindGroupRelease(WGPUBindGroup bindGroup) WGPU_FUNCTION_ATTRIBUTE;

Of course, you can use these functions in Swift exactly how you do in C, making sure to balance out calls to AddRef and Release, but then it would be every bit as unsafe as C.

We can do better with SWIFT_SHARED_REFERENCE. It’s a macro (defined in the <swift/bridging> header) that can turn a reference-counted C type like the above into an automatically reference-counted class in Swift. Here’s how we would use it in the header:

typedef struct SWIFT_SHARED_REFERENCE(wgpuBindGroupAddRef, wgpuBindGroupRelease) WGPUBindGroupImpl* WGPUBindGroup WGPU_OBJECT_ATTRIBUTE;

Now, WGPUBindGroup gets imported like this:

public class WGPUBindGroupImpl { }
public typealias WGPUBindGroup = WGPUBindGroupImpl

The extra typealias is a little unexpected, but overall this is a huge improvement: Swift is treating WGPUBindGroup as a class, meaning that it automatically manages retains and releases for you! This is both an ergonomic win (less code to write) and a safety win, because it’s eliminated the possibility of mismanaging these instances.

There’s one more thing: when dealing with reference-counting APIs, you need to know whether a particular function that returns an object is expecting you to call “release” when you’re done. In the WebGPU header, this information is embedded in a comment:

/**
 * @returns
 * This value is @ref ReturnedWithOwnership.
 */
WGPU_EXPORT WGPUBindGroup wgpuDeviceCreateBindGroup(WGPUDevice device, WGPUBindGroupDescriptor const * descriptor) WGPU_FUNCTION_ATTRIBUTE;

“ReturnedWithOwnership” here means that the result of the call has already been retained one extra time, and the caller is responsible for calling “release” when they are done with it. The <swift/bridging> header has a SWIFT_RETURNS_RETAINED macro that expresses this notion. One can use it like this:

WGPU_EXPORT WGPUBindGroup wgpuDeviceCreateBindGroup(WGPUDevice device, WGPUBindGroupDescriptor const * descriptor) WGPU_FUNCTION_ATTRIBUTE SWIFT_RETURNS_RETAINED;

Now, Swift will balance out the retain that wgpuDeviceCreateBindGroup has promised to do by performing the extra release once you’re done using the object. Once these annotations are done, we’re all set with a more ergonomic and memory-safe API for this C library. There’s no need to ever call wgpuBindGroupRelease or wgpuBindGroupAddRef yourself.

We’ve hacked up our header again, so let’s undo that and move all of this out to API notes. To turn a type into a foreign reference type, we augment the Tags section of our API notes with the same information, but in YAML form:

- Name: WGPUBindGroupImpl
  SwiftImportAs: reference
  SwiftReleaseOp: wgpuBindGroupRelease
  SwiftRetainOp: wgpuBindGroupAddRef

That makes WGPUBindGroupImpl import as a class type, with the given retain and release functions. We can express the “returns retained” behavior of the wgpuDeviceCreateBindGroup function like this:

Functions:
- Name: wgpuDeviceCreateBindGroup
  SwiftReturnOwnership: retained

That’s enums and classes, so now let’s tackle… functions.

Importing functions

A typical function from webgpu.h, like this:

WGPU_EXPORT void wgpuQueueWriteBuffer(
    WGPUQueue queue, WGPUBuffer buffer, uint64_t bufferOffset, 
    void const * data, size_t size
) WGPU_FUNCTION_ATTRIBUTE;

will come into Swift like this:

public func wgpuQueueWriteBuffer(_ queue: WGPUQueue!, _ buffer: WGPUBuffer!, _ bufferOffset: UInt64, _ data: UnsafeRawPointer!, _ size: Int)

Note that _ on each parameter, which means that we won’t use argument labels for anything when we call it:

wgpuQueueWriteBuffer(myQueue, buffer, position, dataToWrite, bytesToWrite)

That matches C, but it isn’t as clear as it could be in Swift. Let’s clean this up by providing a better name in Swift that includes argument labels. We can do so using SWIFT_NAME (also in <swift/bridging>), like this:

WGPU_EXPORT void wgpuQueueWriteBuffer(
      WGPUQueue queue, WGPUBuffer buffer, uint64_t bufferOffset,
      void const * data, size_t size
  ) WGPU_FUNCTION_ATTRIBUTE 
    SWIFT_NAME("wgpuQueueWriteBuffer(_:buffer:bufferOffset:data:size:)");

Within the parentheses, we have each of the argument labels that we want (or _ meaning “no label”), each followed by a :. This is how one describes a full function name in Swift. Once we’ve made this change to the Swift name, the C function comes into Swift with argument labels, like this:

public func wgpuQueueWriteBuffer(_ queue: WGPUQueue!, buffer: WGPUBuffer!, bufferOffset: UInt64, data: UnsafeRawPointer!, size: Int)

That makes the call site more clear and self-documenting:

wgpuQueueWriteBuffer(myQueue, buffer: buffer, offset: position, data: dataToWrite, size: bytesToWrite)

Importing functions as methods

There is more usable structure in this API. Note that the wgpuQueueWriteBuffer function takes, as its first argument, an instance of WGPUQueue. Most of the C functions in WebGPU.h are like this, because these are effectively functions that operate on their first argument. In a language that has methods, they would be methods. Swift has methods, so let’s make them methods!

WGPU_EXPORT void wgpuQueueWriteBuffer(
      WGPUQueue queue, WGPUBuffer buffer, uint64_t bufferOffset, void const * data, size_t size) 
  WGPU_FUNCTION_ATTRIBUTE SWIFT_NAME("WGPUQueueImpl.writeBuffer(self:buffer:bufferOffset:data:size:)");

There are three things to notice about this SWIFT_NAME string:

It starts with WGPUQueueImpl., which tells Swift to make this function a member inside WGPUQueueImpl.
Let’s change the function name to writeBuffer, because we no longer need the wgpuQueue prefix to distinguish it from other “write buffer” operations on other types.
The name of the first argument in parentheses is self, which indicates that the self argument (in Swift) should be passed as that positional argument to the C function. The other arguments are passed in-order.

Note that this also requires WGPUQueue(Impl) to be imported as a class, as we did earlier for WGPUBindGroupImpl. Once we’ve done so, we get a much-nicer Swift API:

extension WGPUQueueImpl {
  public func writeBuffer(buffer: WGPUBuffer!, bufferOffset: UInt64, data: UnsafeRawPointer!, size: Int)
}

We’ve hacked up the header again, but didn’t have to. In WebGPU.apinotes, you can put a SwiftName attribute on any entity. For wgpuQueueWriteBuffer, it would look like this (in the Functions section):

- Name: wgpuQueueWriteBuffer
  SwiftName: WGPUQueueImpl.writeBuffer(self:buffer:bufferOffset:data:size:)

Importing functions as properties

WebGPU.h has a number of Get functions that produce information about some aspect of a type. Here are two for the WGPUQuerySet type:

WGPU_EXPORT uint32_t wgpuQuerySetGetCount(WGPUQuerySet querySet) WGPU_FUNCTION_ATTRIBUTE;
WGPU_EXPORT WGPUQueryType wgpuQuerySetGetType(WGPUQuerySet querySet) WGPU_FUNCTION_ATTRIBUTE;

With the SWIFT_NAME tricks above, we can turn these into “get” methods on WGPUQuerySet, like this:

extension WGPUQuerySetImpl {
    public func getCount() -> UInt32
    public func getType() -> WGPUQueryType
}

That’s okay, but it’s not what you’d do in Swift. Let’s go one step further and turn them into read-only computed properties. To do so, use the getter: prefix on the Swift name we define. We’ll skip ahead to the YAML form that goes into API notes:

- Name: wgpuQuerySetGetCount
  SwiftName: getter:WGPUQuerySetImpl.count(self:)
- Name: wgpuQuerySetGetType
  SwiftName: getter:WGPUQuerySetImpl.type(self:)

And now, we arrive at a nice Swift API:

extension WGPUQuerySetImpl {
    public var count: UInt32 { get }
    public var type: WGPUQueryType { get }
}

Importing functions as initializers

SWIFT_NAME can also be used to import a function that returns a new instance as a Swift initializer. For example, this function creates a new WGPUInstance (which we assume is getting imported as a class like we’ve been doing above):

/**
 * Create a WGPUInstance
 *
 * @returns
 * This value is @ref ReturnedWithOwnership.
 */
WGPU_EXPORT WGPUInstance wgpuCreateInstance(WGPU_NULLABLE WGPUInstanceDescriptor const * descriptor) WGPU_FUNCTION_ATTRIBUTE;

We can turn this into a Swift initializer, which is used to create a new object, using the same SWIFT_NAME syntax but where the method name is init. Here is the YAML form that goes into API notes:

- Name: wgpuCreateInstance
  SwiftReturnOwnership: retained
  SwiftName: WGPUInstanceImpl.init(descriptor:)

and here is the resulting Swift initializer:

extension WGPUInstanceImpl {
    /**
     * Create a WGPUInstance
     *
     * @returns
     * This value is @ref ReturnedWithOwnership.
     */
    public /*not inherited*/ init!(descriptor: UnsafePointer<WGPUInstanceDescriptor>!)
}

Now, one can create a new WGPUInstance with the normal object-creation syntax, e.g.,

let instance = WGPUInstance(descriptor: myDescriptor)

Another Boolean type?

The WebGPU header defines its own Boolean type. I wish everyone would use C99’s _Bool and be done with it, but alas, here are the definitions for WebGPUs Boolean types:

#define WGPU_TRUE (UINT32_C(1))
#define WGPU_FALSE (UINT32_C(0))
typedef uint32_t WGPUBool;

This means that WGPUBool will come in to Swift as a UInt32. The two macros aren’t available in Swift at all: they’re “too complicated” to be recognized as integral constants. Even if they were available in Swift, it still wouldn’t be great because we want to use true and false for Boolean values in Swift, not WGPU_TRUE and WGPU_FALSE.

To make WGPUBool easier to use from Swift, we’re first going to map that typedef to its own struct that stores the underlying UInt32, giving it an identity separate from UInt32. We can do this using a SwiftWrapper API note within the Typedefs section of the file, like this:

- Name: WGPUBool
  SwiftWrapper: struct

Now, we get WGPUBool imported like this:

public struct WGPUBool : Hashable, Equatable, RawRepresentable {
    public init(_ rawValue: UInt32)
    public init(rawValue: UInt32)
}

To be able to use true and false literals with this new WGPUBool, we can write a little bit of Swift code that makes this type conform to the ExpressibleByBooleanLiteral protocol, like this:

extension WGPUBool: ExpressibleByBooleanLiteral {
  init(booleanLiteral value: Bool) {
    self.init(rawValue: value ? 1 : 0)
  }
}

That’s it! Better type safety (you cannot confuse a WGPUBool with any other integer value) and the convenience of Boolean literals in Swift.

Option sets

webgpu.h describes a set of flags using a typedef of the WGPUFlags type (a 64-bit unsigned integer) along with a set of global constants for the different flag values. For example, here is the WGPUBufferUsage flag type and some of its constants:

typedef WGPUFlags WGPUBufferUsage;
static const WGPUBufferUsage WGPUBufferUsage_MapRead = 0x0000000000000001;
static const WGPUBufferUsage WGPUBufferUsage_MapWrite = 0x0000000000000002;
static const WGPUBufferUsage WGPUBufferUsage_CopySrc = 0x0000000000000004;
static const WGPUBufferUsage WGPUBufferUsage_Index = 0x0000000000000010;

Similar to what we saw with WGPUBool, WGPUBufferUsage is a typedef of a typedef of a uint64_t. There’s no type safety in this C API, and one could easily mix up these flags with, say, those of WGPUMapMode:

typedef WGPUFlags WGPUMapMode;
static const WGPUMapMode WGPUMapMode_Read = 0x0000000000000001;
static const WGPUMapMode WGPUMapMode_Write = 0x0000000000000002;

We can do better, by layering more structure for the Swift version of this API using the same SwiftWrapper approach from WGPUBool. This goes into the Typedefs section of API notes:

Typedefs:
- Name: WGPUBufferUsage
  SwiftWrapper: struct

Now, WGPUBufferUsage comes in as its own struct:

public struct WGPUBufferUsage : Hashable, Equatable, RawRepresentable {
    public init(_ rawValue: WGPUFlags)
    public init(rawValue: WGPUFlags)
}

The initializers let you create a WGPUBufferUsage from a WGPUFlags value, and there is also a rawValue property to get a WGPUFlags value out of a WGPUBufferInstance, so the raw value is always there… but the default is to be type safe. Additionally, those global constants will come in as members of WGPUBufferUsage, like this:

extension WGPUBufferUsage {
    /**
     * The buffer can be *mapped* on the CPU side in *read* mode (using @ref WGPUMapMode_Read).
     */
    public static var _MapRead: WGPUBufferUsage { get }

    /**
     * The buffer can be *mapped* on the CPU side in *write* mode (using @ref WGPUMapMode_Write).
     *
     * @note This usage is **not** required to set `mappedAtCreation` to `true` in @ref WGPUBufferDescriptor.
     */
    public static var _MapWrite: WGPUBufferUsage { get }

    /**
     * The buffer can be used as the *source* of a GPU-side copy operation.
     */
    public static var _CopySrc: WGPUBufferUsage { get }

    /**
     * The buffer can be used as the *destination* of a GPU-side copy operation.
     */
    public static var _CopyDst: WGPUBufferUsage { get }
}

This means that, if you’re passing a value of type WPUBufferUsage, you can use the shorthand “leading dot” syntax. For example:

func setBufferUsage(_ usage: WGPUBufferUsage) { ... }

setBufferUsage(._MapRead)

Swift has dropped the common WPUBufferUsage prefix from the constants when it made them into members. However, the resulting names aren’t great. We can rename them by providing a SwiftName in the API notes file within the Globals section:

Globals:
- Name: WGPUBufferUsage_MapRead
  SwiftName: WGPUBufferUsage.mapRead
- Name: WGPUBufferUsage_MapWrite
  SwiftName: WGPUBufferUsage.mapWrite

We can go one step further by making the WGPUBufferUsage type conform to Swift’s OptionSet protocol. If we revise the API notes like this:

Typedefs:
- Name: WGPUBufferUsage
  SwiftWrapper: struct
  SwiftConformsTo: Swift.OptionSet

Now, we get the nice option-set syntax we expect in Swift:

let usageFlags: WGPUBufferUsage = [.mapRead, .mapWrite]

Nullability

Throughout webgpu.h, the WGPU_NULLABLE macro is used to indicate pointers that can be NULL. The implication is that any pointer that is not marked with WGPU_NULLABLE cannot be NULL. For example, here is the definition of wgpuCreateInstance we used above:

WGPU_EXPORT WGPUInstance wgpuCreateInstance(WGPU_NULLABLE WGPUInstanceDescriptor const * descriptor) WGPU_FUNCTION_ATTRIBUTE;

The WGPU_NULLABLE indicates that it’s acceptable to pass a NULL pointer in as the descriptor parameter. Clang already has nullability specifiers to express this information. We could alter the declaration in the header to express that this parameter is nullable but the result type is never NULL, like this:

WGPU_EXPORT WGPUInstance _Nonnull wgpuCreateInstance(WGPU_NULLABLE WGPUInstanceDescriptor const * _Nullable descriptor) WGPU_FUNCTION_ATTRIBUTE;

This eliminates the implicitly-unwrapped optionals (!) from the signature of the initializer, so we end up with one that explicitly accepts a nil descriptor argument and always returns a new instance (never nil):

extension WGPUInstanceImpl {
    /**
     * Create a WGPUInstance
     *
     * @returns
     * This value is @ref ReturnedWithOwnership.
     */
    public /*not inherited*/ init(descriptor: UnsafePointer<WGPUInstanceDescriptor>?)
}

Now, I did cheat by hacking the header. Instead, we can express this with API notes on the parameters and result type by extending the entry we already have for wgpuCreateInstance like this:

- Name: wgpuCreateInstance
  SwiftReturnOwnership: retained
  SwiftName: WGPUInstanceImpl.init(descriptor:)
  Parameters:
  - Position: 0
    Nullability: O
  ResultType: "WGPUInstance _Nonnull"

To specific nullability of pointer parameters, one can identify them by position (where 0 is the first parameter to the function) and then specify whether the parameter should come into Swift as optional (O, corresponds to _Nullable), non-optional (N, corresponds to _Nonnull) or by left unspecified as an implicitly-unwrapped optional (U, corresponds to _Null_unspecified). For the result type, it’s a little different: we specified the result type along with the nullability specifier, i.e., WGPUInstance _Nonnull. The end result of these annotations is the same as the modified header, so we can layer nullability information on top of the header.

Scripting the creation of WebGPU.apinotes

webgpu.h is about 6,400 lines long, and is regenerated from a database of the API as needed. Each of the WebGPU implementations seems to augment or tweak the header a bit. So, rather than grind through and manually do annotations, I wrote a little Swift script to “parse” webgpu.h, identify its patterns, and generate WebGPU.apinotes for most of what is discussed in this post. The entirety of the script is here. It reads webgpu.h from standard input and prints WebGPU.apinotes to standard output.

Because webgpu.h is generated, it has a very regular structure that we can pick up on via regular expressions. For example:

// Enum definitions, marked by WGPU_ENUM_ATTRIBUTE.
let enumMatcher = /} (?<name>\w+?) WGPU_ENUM_ATTRIBUTE/

// Object definitions, marked by WGPU_OBJECT_ATTRIBUTE.
let objectMatcher = /typedef struct (?<implName>\w+?)\* (?<name>\w+?) WGPU_OBJECT_ATTRIBUTE;/

// Function declarations, marked by WGPU_FUNCTION_ATTRIBUTE
let functionMatcher = /WGPU_EXPORT (?<nullableResult>WGPU_NULLABLE ?)?(?<resultType>\w+?) (?<name>\w+?)\((?<parameters>.*\)?) WGPU_FUNCTION_ATTRIBUTE;/
let parameterMatcher = /(?<type>[^),]+?) (?<name>\w+?)[),]/

That’s enough to identify all of the enum types (so we can emit the EnumExtensibility: closed API notes), object types (to turn them into shared references), and functions (which get nicer names and such). The script is just a big readLine loop that applies the regexes to capture all of the various types and functions, then does some quick classification before printing out the API notes. The resulting API notes are in WebGPU.apinotes, and the generated Swift interface after these API notes are applied is here. You can run it with, e.g.,

swift -enable-bare-slash-regex webgpu_apinotes.swift < webgpu.h

This script full of regular expressions is, admittedly, a bit of a hack. A better approach for an arbitrary C header would be to use libclang to properly parse the headers. For WebGPU specifically, the webgpu-headers project contains a database from which the header is generated, and one could also generate API notes directly from that database. Regardless of how you get there, many C libraries have well-structured headers with conventions that can be leveraged to create safer, more ergonomic projections in Swift.

Swiftifying your favorite C library

The techniques described in this post can be applied to just about any C library. To do so, I recommend setting up a small package like the one described here for WebGPU, so you can iterate quickly on example code to get a feel for how the Swift projection of the C API will work. The annotations might not get you all the way to the best Swift API, but they are a lightweight way to get most of the way there. Feel free to also extend the C types to convenience APIs that make sense in Swift, like I did above to make WGPUBool conform to ExpressibleByBooleanLiteral.

A little bit of annotation work on your favorite C library can make for a safer, more ergonomic, more Swifty experience of working with that library.

Postscript: Thoughts for improving the generated webgpu.h

The regular structure of webgpu.h helped considerably when trying to expose the API nicely in Swift. That said, there are a few ways in which webgpu.h could be improved to require less annotation for this purpose:

WGPU_ENUM_ATTRIBUTE would be slightly nicer if placed on the enum itself, rather than on the typedef. If it were there, we could use
```
#define WGPU_ENUM_ATTRIBUTE __attribute__((enum_extensibility(closed)))
```
and not have to generate any API notes to bring these types in as proper enums in Swift.
WGPU_OBJECT_ATTRIBUTE could provide the names of the retain and release operations and be placed on the struct itself. If it were there, we could use
```
#define WGPU_OBJECT_ATTRIBUTE(RetainFn,ReleaseFn) SWIFT_SHARED_REFERENCE(RetainFn,ReleaseFn)
```
and not have to generate any API notes to bring these types in as classes in Swift.
WGPU_NULLABLE could be placed on the pointer itself (i.e., after the *) rather than at the beginning of the type, to match the position of Clang’s nullability attributes. If it were placed there, then
```
#define WGPU_NULLABLE _Nullable
```
would work with Clangs’ longstanding nullable-types support. Swift would then import such pointers as optional types (with ?). Moreover, if some macros WGPU_ASSUME_NONNULL_BEGIN and WGPU_ASSUME_NONNULL_END were placed at the beginning and end of the header, they could be mapped to Clang’s pragmas to assume that any pointer not marked “nullable” is always non-null:
```
#define WGPU_ASSUME_NONNULL_BEGIN #pragma clang assume_nonnull begin
#define WGPU_ASSUME_NONNULL_END #pragma clang assume_nonnull end
```
This would eliminate all of the implicitly unwrapped optionals (marked ! in the Swift interface), making it easier to use safely.

Swift.org

Module Tracking in Swift Debug Info

Swift modules and expression evaluation

Swift modules, debug info, and the build system

Precise module tracking

What’s new

What’s deprecated

Coming in Swift 6.4: Faster bridging header import in LLDB

Summary

What's new in Swift: August 2026 Edition

Videos to watch

Community highlights

New package releases

Swift Evolution

Embedded Swift Improvements Coming in Swift 6.4

Language improvements

Generalized support for existential (any) types any) types section" href="#generalized-support-for-existential-any-types">

Untyped throws

Metatypes

Library improvements

Floating point parsing

Concurrency error handling

Try it out!

What's new in Swift: July 2026 Edition

Videos to watch

Recent project changes

New package releases

Swift Evolution

What's new in Swift: June 2026 Edition

WWDC26 highlights

Videos to watch

Community highlights

New package releases

Swift Evolution

Swift Package Index Update

Swift at Apple: Migrating the TrueType Hinting Interpreter

TrueType and the hinting engine

Rewriting in Swift

Validating correctness

Achieving high performance

Minimizing runtime overhead

Moving data around

Short-lived allocations

Dynamic dispatch

Zero-cost abstractions

Memory-safe and faster than C

Swift in practice

Announcing the Networking Workgroup

What's new in Swift: May 2026 Edition

Videos to watch

Community highlights

New package releases

Swift Evolution

Bringing Goodnotes to the web with Swift and WebAssembly

Why we chose Swift for the web

Technical architecture

Shared core components

Code sharing metrics

Binary size and loading

JavaScript interoperability

Platform compatibility considerations

Multithreading with WASI threads

Development experience

IDE support

Debugging and development tools

Performance profiling

Contributing back to the community

Lessons learned

Get involved with Swift on WebAssembly

What's new in Swift: April 2026 Edition

Videos to watch

New package releases

Swift Evolution

One more thing

Expanding Swift's IDE Support

Swift on Open VSX

Get Started

What's new in Swift: March 2026 Edition

Videos to watch

Community highlights

Generalized support for existential (`any`) types any) types section" href="#generalized-support-for-existential-any-types">