Swift.org

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.

What's new in Swift: December 2025 Edition

2025-12-19T12:00:00-04:00

Welcome to the latest digest of news from the Swift project.

Each edition, we share updates that we hope will be useful to you whether you’re writing code with Swift or contributing to the language as a whole, and we start with an introduction from this edition’s guest contributor:

As we near the end of the year, it’s a time for reflection and gratitude. We’re profoundly grateful for the energy, creativity, and dedication of our community: the hundreds of contributors who submit code to improve Swift, those who create and steward ecosystem packages with thoughtfulness, and the developers building remarkable things with this language.

Indeed, it has been a monumental twelve months for Swift as an open source project.

From its relatively humble roots as an open source project, starting with a simple blog post ten years ago this month, the Swift project now comprises over 70 repositories, with hundreds of contributors every week bringing fresh perspectives, performance improvements, and tooling enhancements to the ecosystem.

The release of Swift 6.2 brings more approachable concurrency with defaults that align with a philosophy of progressive disclosure: making advanced features available when you need them, but keeping them out of your way when you don’t. Swift 6.2 also adds WebAssembly support, deep C++ interoperability, and improved memory safety features.

This year proved that Swift truly runs everywhere, across a variety of platforms and use cases:

Embedded: Embedded Swift is rapidly evolving, moving from experimental to practical use cases, with significant updates targeted for the upcoming 6.3 release.

Android: The workgroup is making strides with daily snapshot builds and end-to-end demos, bringing native Swift development closer to reality on Android devices.

Windows: Support is maturing fast, with richer tooling via the VS Code extension and a growing library of packages that support Windows out of the box.

BSD: The preview of Swift on FreeBSD support is now available for FreeBSD 14.3 and later, and will be featured in a FOSDEM 2026 talk about Porting Swift to FreeBSD.

AI: The ecosystem is evolving quickly, with MLX providing a Swift-friendly API for machine learning on Apple Silicon, and numerous packages from Hugging Face for Swift development.

Server: Backend development remains a major growth area. At the recent AWS re:Invent conference, Amazon announced integrated support for Swift in Amazon Linux and adoption of the AWS Lambda Runtime, signaling that the cloud is ready for Swift’s memory safety and speed.

And of course, Swift remains the unrivaled language of choice for building apps across all Apple platforms, whether you’re building an app or a game for iPhone, iPad, Mac, Apple Watch, Apple TV, or Apple Vision Pro!

So thank you, once more, on behalf of all of us working on Swift: there would be no Swift community without you!

— Tim Sneath

To end this milestone year, let’s take a look at some of the things that caught our attention this month.

Swift at FOSDEM 2026

Get ready for FOSDEM, the world’s largest independently run open source conference, taking place in Brussels in late January / early February. The Swift community will be there, with a Pre-FOSDEM Community Event. The Call for Proposals is open for short talk submissions through January 5th, 2026 (23:59 CET).

Outside of the pre-conference event, Swift talks will appear in several FOSDEM devrooms including Containers, BSD, LLVM, and SBOMs. Hope to see you there!

Talks worth watching

Beyond Web Services: Swift for Low-Level Container infrastructure - Eric Ernst introduces us to Apple’s Containerization and Container open source projects, built entirely in Swift.
Separate code from configuration with Swift Configuration - Swift Configuration provides a unified approach to handling configuration in your Swift applications. For more information, also check out the Swift Configuration 1.0 announcement from last week.
Getting started with gRPC Swift - A deep dive into the Swift package for gRPC, a key building block of performant cloud services.

Behind the scenes interviews

Running Swift in AWS Lambda | Serverless Office Hours - Sebastien Stormacq answered developer questions and was live coding with Swift on AWS Lambda. Also check out the related Swift AWS Lambda Runtime package.
Observability in Server Side Swift, with Moritz Lang - Dev Conversations #16 - This interview covers all things distributed tracing and Swift OTel.
Code-along: Start building with Swift and SwiftUI - Originally live streamed, a developer code-along that walks you through building a complete iOS interface using Swift and SwiftUI, followed by a Q&A session to answer developer questions.

Swift blog highlights

In case you missed it, here are several recent blog posts you’ll want to check out:

Exploring the Swift SDK for Android - Common questions about Swift on Android are answered by the Android workgroup, and new Swift 6.3 SDK nightly previews were announced.
Temporal Swift SDK introduced - Temporal has also blogged about using Swift with Temporal.
2025 Google Summer of Code contributors had posts featuring work related to several Swift-related projects, everything from Bringing Swiftly support to VS Code, Extending Swift-Java Interoperability, Improved code completion for Swift, and Improved console output for Swift Testing.

Swift everywhere

As this month’s guest contribution shared, Swift continues to expand to new platforms. Here are a few recent examples from the community:

Using Swift SDKs with Raspberry Pi - Did you know Swift can run on a Raspberry Pi? This blog post does a deep dive, it’s time to open your terminal and follow along!
Swift for Wasm December 2025 updates - An update on progress related to Swift for Wasm. In December the community also had an online meetup including talks.
AWS blog post about AWS Lambda runtime - The Swift AWS Lambda Runtime moved to the official AWS Labs GitHub organization, delivering a vendor-supported approach to running Swift on AWS Lambda.
Swift on a Pebble watch - A fun example of how a developer used Swift’s embedded support to build a “hello world” example on a 10-year-old Pebble Time Round watch.

Swift Evolution

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

Under Active Review:

SE-0501 HTML Coverage Report - This proposal adds HTML coverage report generation to Swift Package Manager’s swift test command. Currently, SwiftPM only generates JSON coverage reports, which are useful for automated tools but difficult for developers to read directly. The new --coverage-format option would allow generating HTML reports alongside or instead of JSON, enabling visual inspection in CI systems and faster feedback during development.

Recently completed:

SE-0497 Controlling function definition visibility in clients - The @inlinable attribute in Swift allows function definitions to be visible to callers, enabling optimizations like specialization and inlining. This proposal introduces explicit control over whether a function generates a callable symbol and makes its definition available for optimization purposes.
SE-0493 Support async calls in defer bodies - Swift’s defer statements provide scope-based cleanup but currently cannot perform asynchronous work, forcing developers to either manually insert cleanup on every exit path or spawn detached tasks. This proposal allows await calls within defer bodies when the enclosing context is async, with the defer statements implicitly awaited at scope exit to ensure proper cleanup completion.

Editor Note: With this update, we’re going to take a break from the blog for the next couple of weeks. Wishing everyone a restful end to 2025!

Exploring the Swift SDK for Android

2025-12-18T06:00:00-04:00

Since the announcement of the preview Swift SDK for Android, the Android workgroup has seen a lot of interest in how it works and what’s next. Please read on for some answers to common questions about the technology and its future, and try out the new Swift 6.3 SDK nightly previews.

How Swift works on Android

Swift compiles directly to native machine code on Android, the same way it does on most other platforms. This approach produces similar performance to C and C++ code built using the Android Native Development Kit (NDK), while achieving a happier balance between performance, safety, and usability. To make this possible, Swift apps on Android bundle a native runtime that implements many of its features, including its standard library and core libraries, like Dispatch and Foundation.

However, since most Android APIs are only made available through Java and Kotlin, Swift must call into the Android Runtime (ART); that’s where the Java interoperability project’s jextract and wrap-java tools come in. These tools automatically create bindings that enable you to call Swift from Java or go the other way using the Java Native Interface (JNI), which allows Swift to seamlessly integrate with the Android platform.

The jextract tool gained a JNI mode this summer: you can watch its author Mads Odgaard’s Server-Side Swift Conference talk and try out the example weather app he submitted in the Android examples repository.

Swift on Android in production

While work is still ongoing on official Java interoperability, Android apps built using Swift have been in production for many years employing homegrown Java interop, with these apps collectively downloaded millions of times. Here are some notable examples:

Spark - A popular email client using Swift to share code between mobile iOS/Android and desktop macOS/Windows versions
flowkey - An interactive piano learning app built with Swift for Android for almost a decade
MediQuo - A healthcare app leveraging Swift for cross-platform development
Naturitas - An organic products marketplace running Swift in production

Ongoing work

Grassroots community efforts to run Swift on Android began as soon as the language source was opened in 2015, and continue to this day. The Android project board lists areas the workgroup determines important, such as easy debugging, now a high priority for us. While it may work for small examples, we need to expand and test it more and make it easy to configure and access. That will likely mean tying the debugger and Swift Language Server Protocol tool, sourcekit-lsp, into Integrated Development Environments (IDEs) like Visual Studio Code and Android Studio, another issue on our board.

An Android workflow was added to the official Swift workflows for GitHub months ago, allowing you to easily try building your Swift packages with the Swift SDK for Android, and work is underway to let you run your tests in an Android emulator too.

We are looking to onboard more contributors and have set up a video call this weekend to discuss getting started. We hope to make these contributor calls a recurring event moving forward, as more people pitch in to improve these Swift tools themselves.

Swift allows you to target many platforms with the same business logic, and Swift on Android expands that much more. As we shared in our draft vision document, a prominent use case we’re focused on is sharing core business logic, algorithms, and data models across applications. The workgroup is not providing a single GUI solution, however a number of nascent community projects have approached the challenge in different ways.

Our recent post in the Swift forums lists a handful of popular and in-progress options. While the workgroup has not validated the claims on individual projects, we plan to add more info on using compatible GUI tools with the Swift SDK for Android in the coming months.

Android API versioning

Until recently, Swift on Android did not support targeting multiple Android API levels in the same app, but recent preview releases bring the familiar @available attribute and #available runtime check that you know from Apple platforms to Android:

#if canImport(Android)
import Android
import Dispatch
#endif

@available(Android 33, *)
func backtrace() {
    withUnsafeTemporaryAllocation(of: UnsafeMutableRawPointer.self, capacity: 1) { address in
        _ = backtrace(address.baseAddress!, 1)
    }
}

@main
struct ExecutableDemo {
    static func main() {
        #if os(Android)
          print("Hello from Android API 28 or later")
          if #available(Android 33, *) {
            // The following code is only run on Android 33+ devices.
            backtrace()
            print("Hello from Android API 33+")
          }
        #endif
    }
}

Try this new feature on Android and let us know how it works for you.

Learn from the community

Those using Swift on Android for many years have been sharing their experiences, as founding contributors like Readdle and flowkey have written about their work for the last decade.

The Left Bit’s Pierluigi Cifani recently wrote about their experiences, gave a great talk at NSSpain 2025 a couple months ago, and was interviewed by Swift Toolkit last month.

A community member recently contributed an example app that builds C++ using CMake and links it with Swift, using Swift’s automated JNI bridging to Java instead.

Swift 6.3 SDK nightly previews

Finally, we are happy to announce that an official Swift 6.3 SDK CI has been set up, and it is producing nightly preview releases of the Swift 6.3 SDK for Android. Please follow the Getting Started guide to install and use it.

Swift on Android has been a community effort for the last decade, growing from that initial patch to apps in production and an active group of developers. Try out the new preview releases of the Swift 6.3 SDK for Android and help us make it even better!

Swift Configuration 1.0 released

2025-12-11T06:00:00-04:00

Every application has configuration: in environment variables, configuration files, values from remote services, command-line flags, or repositories for stored secrets like API keys. But until now, Swift developers have had to wire up each source individually, with scattered parsing logic and application code that is tightly coupled to specific configuration providers.

Swift Configuration brings a unified, type-safe approach to this problem for Swift applications and libraries. What makes this compelling isn’t just that it reads configuration files: plenty of libraries do that. It’s the clean abstraction that it introduces between how your code accesses configuration and where that configuration comes from. This separation unlocks something powerful: libraries can now accept configuration without dictating the source, making them genuinely composable across different deployment environments.

With the release of Swift Configuration 1.0, the library is production-ready to serve as a common API for reading configuration across the Swift ecosystem. Since the initial release announcement in October 2025 over 40 pull requests have been merged, and its API stability provides a foundation to unlock community integrations.

Why it exists

Configuration management has long been a challenge across different sources and environments. Previously, configuration in Swift had to be manually stitched together from environment variables, command-line arguments, JSON files, and external systems. Swift Configuration creates a common interface for configuration, enabling you to:

Read configuration the same way across your codebase using a single configuration reader API that’s usable from both applications and libraries.
Quickly get started with a few lines of code using simple built-in providers for environment variables, command-line arguments, JSON and YAML files. Later, when your configuration needs require a more sophisticated provider, swap it in easily, without refactoring your existing code.
Build and share custom configuration providers using a public ConfigProvider protocol that anyone can implement and share. This allows domain experts to create integrations with external systems like secret stores and feature flagging services.

Swift Configuration excels in the Swift server ecosystem, where configuration is often read from multiple systems and tools. The library is equally useful in command-line tools, GUI applications, and libraries wherever flexible configuration management is needed.

For a step-by-step evolution of an example service, from hardcoded values all the way to a flexible provider hierarchy, check out the video of my talk from the ServerSide.swift conference in London.

Getting started

After adding a package dependency to your project, reading configuration values requires just a couple of lines of code. For example:

import Configuration

let config = ConfigReader(provider: EnvironmentVariablesProvider())
let timeout = config.int(forKey: "http.timeout", default: 60)

However, Swift Configuration’s core strength is its ability to combine multiple configuration providers into a clear, predictable hierarchy, allowing you to establish sensible defaults while providing clean override mechanisms for different deployment scenarios.

For example, if you have default configuration in JSON:

{
  "http": {
    "timeout": 30
  }
}

And want to be able to provide an override using an environment variable:

# Environment variables:
HTTP_TIMEOUT=15

Then what we have are two Swift Configuration “providers”, and we can layer them:

let config = ConfigReader(providers: [
    EnvironmentVariablesProvider(),
    try await FileProvider<JSONSnapshot>(filePath: "/etc/config.json")
])
let timeout = config.int(forKey: "http.timeout", default: 60)
print(timeout) // 15

Providers are checked in the order you specify: earlier providers override later ones, followed by your fallback defaults. This removes ambiguity about which configuration source is actually being used.

Advanced capabilities

Beyond basic lookups, the library includes features for production environments:

Multiple access patterns – choose between the synchronous, asynchronous, and watching patterns.
Hot reloading – apply configuration updates without restarting your service.
Namespacing and scoped readers – organize configuration values through nesting.
Access logging – easily debug configuration issues through detailed observability.
Secret redaction – avoid accidental exposure of sensitive configuration values.

The documentation covers these features in detail.

Community adoption

With 1.0, the API is now stable. Projects can depend on Swift Configuration knowing only backward-compatible changes are expected going forward. API stability allows libraries and tools to rely on Swift Configuration as a common integration point for reading configuration.

Prior to the 1.0 release, a number of ecosystem projects have begun experimenting with and adopting Swift Configuration. Here are some examples of efforts in progress:

In libraries: Expose configuration entry points built on ConfigReader, making your library easier to integrate. Projects experimenting with Swift Configuration include:
In applications: Instantiate a ConfigReader and pass it to your dependencies. Use any combination of ConfigProvider types - JSON/YAML files, environment variables, or remote systems.
- Peekaboo
- swiftodon
By implementing custom providers: Extend the ecosystem with new formats or external sources by implementing a ConfigProvider. Examples of experimental providers:

Next steps

With a stable foundation in place, libraries and applications can begin finalizing their own integrations and releasing API-stable versions built on Swift Configuration.

Try integrating Swift Configuration into your applications, tools, and libraries, check out the project’s documentation, and continue sharing feedback from your real-world experience on the GitHub repository through issues, pull requests, or Swift Forums discussions.

Happy configuring! ⚙️

Embedded Swift Improvements Coming in Swift 6.3

2025-11-17T08:00: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. This post describes a number of improvements made in the last few months, covering everything from improved C interoperability to better debugging and steps toward a complete linkage model for Embedded Swift. These features and bug fixes are included in the upcoming Swift 6.3 release, and you can try them out today with a Swift development snapshot.

Libraries and Diagnostics

Printing floating point numbers

Previously, the description and debugDescription properties for floating-point types (Float, Double, etc.) were not available in the Embedded Swift standard library. With a new all-Swift implementation, you can now use these with Embedded Swift.

Embedded restriction diagnostics

There is a new opt-in set of warnings in the EmbeddedRestrictions diagnostic group that diagnoses language constructs that aren’t available in Embedded Swift, such as uses of untyped throws or calling generic functions on existential values. These diagnostics are enabled by default when building Embedded Swift, and can also be enabled in non-Embedded Swift using the compiler flag -Wwarning EmbeddedRestrictions or in the package manifest with:

swiftSettings: [
    .treatWarning("EmbeddedRestrictions", as: .warning),
]

Read the full details at EmbeddedRestrictions.

Swift MMIO 0.1.x

The 0.1.x release of Swift MMIO, a package for memory-mapped I/O, includes many bug fixes and quality-of-life improvements, plus newly written comprehensive documentation on the Swift Package Index.

The biggest addition is code generation support. There’s now an svd2swift tool and corresponding SwiftPM plugin that generates Swift MMIO interfaces directly from CMSIS System View Description (SVD) files. You can run it manually from the command line, or configure the plugin to handle everything automatically at build time.

Debugging also got a nice upgrade with SVD2LLDB. This LLDB plugin lets you work with device registers using their actual names instead of fumbling with the raw memory addresses. It even includes visual decoding support to help you make sense of register values. For example, here’s what it looks like when you decode a hypothetical timer control register:

(lldb) svd decode TIMER0.CR 0x0123_4567 --visual
TIMER0.CR: 0x0123_4567

                      ╭╴CNTSRC  ╭╴RST
  ╭╴S   ╭╴RELOAD╭╴CAPEDGE  ╭╴MODE
  ┴     ┴─      ┴─    ┴─── ┴──  ┴
0b00000001001000110100010101100111
      ┬─    ┬─    ┬───    ┬   ┬─ ┬
      ╰╴IDR ╰╴TRGEXT      ╰╴PSC  ╰╴EN
                  ╰╴CAPSRC    ╰╴CNT

[31:31] S       0x0 (STOP)
[27:26] IDR     0x0 (KEEP)
[25:24] RELOAD  0x1 (RELOAD1)
[21:20] TRGEXT  0x2 (DMA2)
[17:16] CAPEDGE 0x3
[15:12] CAPSRC  0x4 (GPIOA_3)
[11:8]  CNTSRC  0x5 (CAP_SRC_div32)
[7:7]   PSC     0x0 (Disabled)
[6:4]   MODE    0x6
[3:2]   CNT     0x1 (Count_DOWN)
[1:1]   RST     0x1 (Reset_Timer)
[0:0]   EN      0x1 (Enable)

C Interoperability

`@c` functions and enums @c functions and enums section" href="#c-functions-and-enums">

The Swift evolution proposal SE-0495 provides support for defining C-compatible functions and enums with the @c attribute. For example, the following declaration defines a function that is callable from C with the name MyLib_initialize:

@c(MyLib_initialize)
public func initialize() { ... }

The Swift generated header from the above example, which can be included in any C/C++ code, contains a declaration of this C function:

void MyLib_initialize(void); 

This feature also works with the @implementation attribute introduced in SE-0436. If you have a pre-existing C header that documents a C interface, you can implement that C interface with a Swift function such as:

@c @implementation
public func MyLib_initialize() { ... }

The Swift compiler ensures that the signature of the Swift function matches that of the C header. This allows you to replace an existing C library with a Swift implementation without affecting C clients.

The @c attribute formalizes the @_cdecl attribute, fixing a number of corner cases in the process.

Improved tolerance of mismatching C signatures

The Swift compiler has historically required precise consistency between the Swift types for C functions imported from headers or declared in Swift with @c (formerly @_cdecl) or @_extern(c). For example, if you declared a C function without nullability annotations in a header:

void takePointer(const double *);

And then separately defined in Swift with, for example:

@c func takePointer(_ values: UnsafePointer<Double>) { ... }

The compiler could fail to compile when it noticed the mismatch, often with a hard-to-understand “deserialization” failure. The compiler now keeps the different views on the underlying C declaration separate, diagnosing problems when the underlying C declarations themselves are inconsistent. This allows subtle differences such as nullability or sendability annotations to occur in C signatures without failing to compile.

Debugging

Debugger printing of values

LLDB’s support for printing the values of Swift types in Embedded Swift has been improved. In addition, the memory read command now supports an optional Swift type name, so that you can take an arbitrary address and render it as a value of that named Swift type. The following example shows interpreting the address as the type MyMessage:

(lldb) memory read -t MyMessage 0x000000016fdfe970
(MessageLib.MyMessage) 0x16fdfe970 = {
  id = 15
  timestamp = 793219406
  payload = "hello"
  ...
}

More data types inspectable in core dumps

LLDB needs access to type layout information so it can display variables. Since Embedded Swift doesn’t contain reflection metadata, the Swift compiler emits all the type layout information as DWARF debug info. There have been several improvements to the Swift compiler’s debug info output, such as support for type declarations nested inside an extension. At the same time, LLDB added support for nested generic type aliases in Embedded Swift. These two improvements together make it possible to inspect many common standard library data types, such as Dictionary and Array, in Embedded Swift core dumps. Previously these data types were only accessible via the expression evaluator, which requires a live process.

LLDB also has native support for the new InlineArray data type.

Debugger armv7m exception frames unwinding

LLDB’s support for producing backtraces after taking exceptions in armv7m has been greatly improved. Previously after taking an exception, you would be presented with a back trace like the following:

(lldb) bt
* thread 1
  * frame #0: 0x0020392c NeoPixelRainbow`NeoPixelRainbow.swift_UsageFault_Handler() -> () + 28
    frame #1: 0x00203910 NeoPixelRainbow`UsageFault_Handler + 8
    frame #2: 0xfffffff8
    frame #3: 0x00202a86 NeoPixelRainbow`NeoPixelRainbow_main + 8
    frame #4: 0x00200256 NeoPixelRainbow`cinit_ctor_loop_end at startup.S:98
    frame #5: 0x00200210 NeoPixelRainbow`Reset_Handler at startup.S:33

However this back trace would often be missing one or more frames before the start of the exception frame (UsageFault_Handler above).

Now, LLDB is able to walk back through exception frames into the standard program frames and produce a backtrace that contains the missing frames.

(lldb) bt
* thread #1
  * frame #0: 0x0020392c NeoPixelRainbow`swift_UsageFault_Handler() + 28
    frame #1: 0x00203910 NeoPixelRainbow`swift_UsageFault_Handler()
    frame #2: 0x00203366 NeoPixelRainbow`static Application.main() + 2270 // Real exception location
    frame #3: 0x00202a86 NeoPixelRainbow`NeoPixelRainbow_main + 8
    frame #4: 0x00200256 NeoPixelRainbow`cinit_ctor_loop_end + 18
    frame #5: 0x00200210 NeoPixelRainbow`Reset_Handler + 16

Linking

`@section` and `@used` attributes @section and `@used` attributes section" href="#section-and-used-attributes">

The Swift evolution proposal SE-0492 introduced two new attributes that are useful in Embedded Swift. The @section attribute specifies that a particular global variable should be emitted into the named section:

@section("__DATA,mysection")
@used
let myLinkerSetEntry: Int = 42

Also included is an objectFormat check that can be used within #if to conditionalize code on the various object formats (ELF, COFF, MachO, Wasm), that you can use to provide different section names:

#if objectFormat(ELF)
@section("mysection")
#elseif objectFormat(MachO)
@section("__DATA,mysection")
#endif
var global = ...

The @used attribute lets the compiler know that the entity it’s attached to should always be emitted, even if it appears unused.

Progress on the Embedded Swift linkage model

Embedded Swift uses a different compilation model from regular Swift that delays code generation to later in the compilation process. This compilation model has not been fully defined and has various practical problems. One such issue involves duplicate symbols: if you have four Embedded Swift libraries whose dependencies form a diamond, like this:

  A
 / \
B   C
 \ /
  D

Then symbols from A that are used in both B and C would cause duplicate definition errors when linking both into D. The Swift compiler now emits symbols from imported modules using weak definitions, so the linker can de-duplicate them. This eliminates the need for flags like -mergeable-symbols and -emit-empty-object-file that provided partial workarounds.

Another step along the path to formalizing the Embedded Swift linkage model is SE-0497, which defines a new @export attribute that controls how a function is visible to clients. The spelling @export(implementation) makes the implementation available for clients to emit, specialize, or inline, subsuming the longstanding but unofficial @_alwaysEmitIntoClient attribute. The spelling @export(interface) ensures that only the interface and not the definition of the function is made available to clients by emitting a callable symbol, allowing library developers to fully hide the implementation of a function even in Embedded Swift.

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.

GSoC 2025 Showcase: Improved Console Output for Swift Testing

2025-11-14T13:15:00-04:00

The Swift community participated in Google Summer of Code 2025, and we’ve recently been showcasing all of the projects and work accomplished here on the Swift blog. You can learn more by following these convenient links:

Bringing Swiftly support to VS Code
Extending Swift-Java Interoperability
Improved code completion for Swift
Improved console output for Swift Testing (this post)

Each GSoC contributor has shared a writeup about their project and experience in the program. The fourth and last post in this year’s series, contributed by Kelvin Bui, improved the console output that is printed when running tests implemented with Swift Testing.

To learn more, you can read the full post on the Swift forums.

Improved Console Output for Swift Testing

Hello everyone! My name is Kelvin Bui, and I’m excited to share my GSoC 2025 project, where I worked on improving the console output for the Swift Testing framework with my mentor, Stuart Montgomery.

Overview

This summer, as part of Google Summer of Code 2025, I had the incredible opportunity to work on improving the console output for the Swift Testing framework. The primary goal was to transform the existing static log into a modern, clear, and highly useful tool for developers. The main achievement of this project is the design and implementation of a new, two-phase console reporter, with a primary focus on delivering a comprehensive Hierarchical Summary and Detailed Failure Report. It also leverages serialization to allow emitting output from a separate supervisor process, in alignment with future project directions.

Problem & Motivation

The default console output for swift test was functional but presented several challenges for developers working on large and complex projects:

Difficulty Locating Failures: In large test suites, critical failure messages were often lost in a long stream of success outputs, making it hard to quickly assess the health of a test run.
Lack of Structure: The flat log format made it difficult to understand the relationship between tests and their parent suites, especially in projects with many nested modules.

Our vision was to solve these problems by creating an advanced console reporter that is both informative and intuitive.

Key Technical Achievements

Hierarchical Test Display:

A clear, indented tree structure that visualizes the relationship between suites and tests.
An “issues as sub-nodes” model for displaying rich failure context directly within the hierarchy.
An “out-dented” suite summary line that cleanly concludes each suite’s output.

Serialization-Based Architecture:

A future-proof design that processes ABI.EncodedEvent objects, preparing the reporter for an out-of-process harness architecture.
Logic to build an in-memory representation of the test plan by consuming initial test discovery events and then looking up test details by ID for subsequent events.

Rich Failure Reporting:

A dedicated FAILED TEST DETAILS section that provides comprehensive information for each failure, including the fully qualified test name, a detailed error message, and the exact source location (file:line).

Visuals: Before & After

The Advanced Console Output Recorder fundamentally transforms how developers interact with test results. By introducing a visual hierarchy and detailed contextual information, it elevates the diagnostic experience from a flat, hard-to-parse log into a structured, scannable report.

Current Console Output:

Prior to this project, the default swift test output presented a linear, undifferentiated stream of events. While functional, this format lacked visual cues, making it challenging to quickly identify test relationships, pinpoint failures within large suites, or understand the overall structure of a test run. The absence of clear demarcation between test suites and individual tests often led to slower debugging cycles and increased cognitive load for developers.

New Hierarchical Summary:

The new recorder introduces a rich, hierarchical display that immediately brings order and clarity to test output. Using Unicode box-drawing characters (with ASCII fallback), it clearly visualizes the nested structure of test modules, suites, and individual tests. This not only makes the test results significantly easier to read and navigate but also provides crucial context around failed tests, displaying detailed issue descriptions directly within their respective hierarchical nodes. This transformation dramatically improves the developer experience by offering instant insights into test organization and failure points.

Challenges & Lessons Learned

Technical lessons:

Designing for serialization & ABI: Refactoring to consume ABI.EncodedEvent taught me the value of decoupling - moving from in-process object graphs to a serialized event stream increases robustness and enables harness-style execution. It also exposed careful trade-offs: serialization simplifies process boundaries but requires stable encoding contracts and more explicit discovery/lookup logic for test metadata.
Building a thread-safe collector for results required balancing lock granularity and throughput. The adopted strategy (a single lock per event bucket, plus careful mutation patterns) simplifies correctness while keeping contention low for typical test workloads.
Cross-platform fallbacks: Supporting ASCII fallback for line-drawing characters taught me to design for the weakest terminal capability first, then progressively enhance for modern terminals. Testing across Windows/Linux/macOS terminals and non-interactive CI runners uncovered many small but critical edge cases (line-wrapping, width detection fallbacks).
Deciding what to show inline vs. in a details section is a UX trade-off; too much inline detail makes the tree noisy, and too little hides useful context. The two-tier approach (short inline message + full details section) balances these needs.

Collaboration & process lessons:

Presenting to the workgroup matters: Early live presentation to the Swift Testing workgroup exposed design assumptions quickly and gave direction that influenced major architectural choices.
Iterative, small PRs win: Breaking work into digestible PRs (skeleton → ABI pivot → UI features) made reviews actionable and reduced reviewer fatigue.
Incorporating targeted reviewer comments (e.g., ABI pivot) showed the importance of documenting design decisions (why we choose serialization, how the tree is constructed), which speeds later onboarding and review cycles.

Personal growth:

I learned how to accept and act on high-quality feedback from senior engineers, and how to reframe technical trade-offs as testable hypotheses. The project sharpened my ability to move from mockups to production code while keeping maintainability and cross-platform compatibility as first-class concerns.

Acknowledgements

I’d like to express my deepest gratitude to my mentor, Stuart Montgomery, for his exceptional guidance, patience, and technical insights throughout this entire project. His mentorship has been invaluable.

I’d also like to thank Jonathan Grynspan for his crucial, in-depth architectural feedback, which significantly improved the project’s long-term viability. Thank you as well to Swift Testing Workgroup, and all the other members of the Swift community who provided thoughtful feedback on the forums. This project would not have been possible without your collective expertise and support.

GSoC 2025 Showcase: Improved Code completion for Swift

2025-11-12T13:05:00-04:00

Our blog post series showcasing the Swift community’s participation in Google Summer of Code 2025 continues with our third update. Learn more about the projects and work accomplished:

Bringing Swiftly support to VS Code
Extending Swift-Java Interoperability
Improved code completion for Swift (this post)
Improved console output for Swift Testing

Each GSoC contributor has shared a writeup about their project and experience in the program on the forums. Today’s featured project improved how documentation is displayed during code completion in IDEs, contributed by Ahmed Elrefaey.

To learn more, you can read the full post on the Swift Forums!

The project enhances SourceKit-LSP, an implementation of the Language Server Protocol (LSP) for Swift and C-based languages. Now you can see full documentation during code completion instead of just brief summaries, as well as what arguments are available to pass when calling functions.

Editors that support the Language Server Protocol all benefit from these improvements to SourceKit-LSP, bringing these features to editors like VS Code, Neovim, IntelliJ IDEA, Vim, and more.

This work has landed in the SourceKit-LSP project, and will be included in a future Swift toolchain release.

Improve the display of documentation during code completion in SourceKit-LSP

Hi everyone!

This is Ahmed Elrefaey. I’m excited to share with you an update on my GSoC project which improved the display of documentation during code completion for Swift. I worked on improvements to SourceKit-LSP, which is an implementation of the Language Server Protocol (LSP) for Swift and C-based languages. My GSoC project was mentored by Hamish Knight.

Project Goals

The aim of this project is to enhance how documentation is displayed in SourceKit-LSP during code completion by:

Showing the full documentation for a code completion item instead of the first paragraph only, which we call “brief documentation”.
Implementing Language Server Protocol’s signature help request showing the user which overloads are available, along with their corresponding documentation.

Progress

During this summer, we have made great progress on this project that I want to share with you.

We have successfully implemented full documentation comment retrieval for completion items by lazily retrieving the full documentation comment upon request to avoid having to fetch all documentation comments at once.

Here’s what SourceKit-LSP currently provides in VS Code (brief documentation):

And here’s how it looks with full documentation:

We have also implemented a large portion of signature help support, showing the available overloads and their corresponding documentation while editing. We reused the existing argument completion logic to determine the overloads and refactored the code completion item description implementation to reuse it in signature help.

Here’s a quick demo of signature help in VS Code.

To try this out in VS Code for yourself, you can download a main development snapshot from swift.org. If using Swiftly you can run swiftly install main-snapshot. Then, in VS Code you can pick “Select Toolchain” from the Command Palette and select the newly downloaded toolchain.

Closing Thoughts

I’m incredibly grateful for this opportunity to contribute to the Swift project, and I really learned a lot from this experience. I’d like to thank my mentor, Hamish Knight, for his unwavering support and guidance throughout this summer. I’d also like to thank Alex Hoppen, Rintaro Ishizaki, and Ben Barham for their valuable feedback during code review.

Introducing Temporal Swift SDK: Building durable and reliable workflows

2025-11-10T09:40:00-04:00

The Temporal Swift SDK is now available as an open source project.

Building reliable distributed systems requires handling failures gracefully, coordinating complex actions across multiple services, and ensuring long-running processes complete successfully. Rather than develop these resiliency features into every application or service you develop, an alternative approach is to use workflows. Workflows encapsulate your code so it runs durably and handles many common failure scenarios.

Temporal is widely used for workflow orchestration across many languages. With the release of the SDK, Temporal is now available for Swift developers building production cloud services.

An announcement post is also available on the Temporal blog with more information for their developer community.

Writing durable workflows in Swift

Durable workflows run to completion even when infrastructure fails. If your server crashes mid-execution, Temporal automatically resumes the workflow from where it left off with no lost state or manual intervention required. By bringing this capability to the Swift ecosystem, developers can focus on application logic while Temporal handles state management, retries, and recovery.

The SDK provides a seamless Swift developer experience by:

Using familiar async/await patterns and structured concurrency to build maintainable workflow code.
Leveraging Swift’s strong type system to catch errors at build time rather than runtime.
Providing macros to reduce boilerplate when authoring workflows.

Temporal workflows are particularly valuable for handling multi-step coordination in applications that must survive failures, such as data pipelines, business automation, payment processing, and operational tasks.

What is Temporal and why does it matter?

Temporal is an open source platform for building reliable distributed applications. At its core is the concept of durable execution, your code runs to completion even in the face of infrastructure failures. When a worker crashes or restarts, Temporal automatically resumes your workflow from where it left off, without requiring you to write complex retry logic or state management code. This is achieved through Temporal’s architecture, which separates workflow orchestration from actual work execution:

Workflows define the overall business logic and coordination. They describe the sequence of steps, decision points, and error handling for a process. Workflows must be deterministic. Given the same inputs and history, they must always make the same decisions.
Activities perform the actual work, such as calling external APIs, processing data, or interacting with databases. Activities should be idempotent, meaning they can be safely retried without causing unintended side effects.

Modern distributed systems face common challenges: coordinating multiple services, handling partial failures, ensuring consistency across operations, and managing long-running processes. Traditional approaches require building custom retry logic, state machines, and coordination mechanisms. Temporal provides a platform that handles these concerns, allowing you to focus on your business logic.

Getting started

To get started with the Temporal Swift SDK, explore its documentation which provides detailed guides for implementing workflows and activities. The repository also includes a rich collection of example projects, demonstrating the SDK’s capabilities across different use cases from simple task orchestration to complex multi-step business processes.

For a deeper understanding of Temporal’s core concepts and architectural patterns, check out the general Temporal documentation, which provides valuable context for building robust distributed systems. For a video introduction, watch this conference presentation from Server-Side Swift 2025 where the project was announced.

Community and feedback

Temporal Swift SDK is an open source project and we’re eager to hear from the Swift community. Whether you’re building microservices, coordinating long-running processes, or simply curious about durable execution, we’d love to know how the Temporal Swift SDK works for you.

The project is actively developed and we welcome contributions, bug reports, and feature requests. Ready to start building reliable distributed systems? Visit the Temporal Swift SDK repository to get started.

GSoC 2025 Showcase: Extending Swift-Java Interoperability

2025-11-07T06:00:00-04:00

This is the second post in our series showcasing the Swift community’s participation in Google Summer of Code 2025. Learn more about the projects and work accomplished:

Bringing Swiftly support to VS Code
Extending Swift-Java Interoperability (this post)
Improved code completion for Swift
Improved console output for Swift Testing

Each GSoC contributor has shared a writeup about their project and experience in the program on the Swift forums. Today’s featured project improved interoperability between Swift and Java, contributed by Mads Odgaard. Mads recently presented on this project at the Server-Side Swift conference: Expanding Swift/Java Interoperability, and you may have noticed it in action in the recent Swift.org blog post: Announcing the Swift SDK for Android!

To learn more, you can read the full post on the Swift forums.

JNI mode for SwiftJava interoperability jextract tool

My name is Mads and I am excited to share with you what I have been working on for Swift/Java interoperability over the summer with my mentor Konrad Malawski for Google Summer of Code 2025.

Overview

The swift-java interoperability library provides the swift-java jextract tool, which automatically generates Java sources that are used to call Swift code from Java. Previously, this tool only worked using the Foreign Function and Memory API (FFM), which requires JDK 22+, making it unavailable on platforms such as Android. The goal of this project was to extend the jextract tool, such that it is able to generate Java sources using JNI instead of FFM and thereby allowing more platforms to utilize Swift/Java interoperability.

I am very glad to report that we have succeeded in that goal, supporting even more features than initially planned! Our initial goal was to achieve feature parity with the FFM mode, but the new JNI mode also supports additional Swift language features such as enums and protocols!

With the outcome of this project, you can now run the following command to automatically generate Java wrappers for your Swift library using JNI, therefore opening up the possibility of using it on platforms such as Android.

swift-java jextract --swift-module MySwiftLibrary \
  --mode jni \
  --input-swift Sources/MySwiftLibrary \
  --output-java out/java \
  --output-swift out/swift   

How does it work?

Each Swift class/struct is extracted as a single Java class. Functions and variables are generated as Java methods, that internally calls down to a native method that is implemented in Swift using @_cdecl. Take a look at the following example:

public class MySwiftClass {
  public let x: Int64
  public init(x: Int64) {
    self.x = x
  }

  public func printMe() {
    print(“\(self.x)”);
  }
}

It is roughly generated to the equivalent Java class:

public final class MySwiftClass implements JNISwiftInstance {
  public static  MySwiftClass init(long x, long y, SwiftArena swiftArena$) {
    return MySwiftClass.wrapMemoryAddressUnsafe(MySwiftClass.$init(x, y), swiftArena$);
  }
  
  public  long getX() {
    return MySwiftClass.$getX(this.$memoryAddress());
  }

  public  void printMe() {
    MySwiftClass.$printMe(this.$memoryAddress());
  }

  private static native long $init(long x, long y);
  private static native long $getX(long self);
  private static native void $printMe(long self);
}

We also generate additional Swift thunks that actually implement the native methods and call the underlying Swift methods.

You can learn more about how the memory allocation and management works in the full version of this post on the Swift forums!

An interesting aspect of an interoperability library such as swift-java is the memory management between the two sides, in this case the JVM and Swift. The FFM mode uses the FFM APIs around MemorySegment to allocate and manage native memory. We are not so lucky in JNI. In older Java versions there are different ways of allocating memory, such as Unsafe or ByteBuffer.allocateDirect(). We could have decided to use these and allocate memory on the Java side, like FFM, but instead we decided to move the responsibility to Swift, which allocates the memory instead. This had some nice upsides, as we did not have to handle the complexity of witness tables like FFM mode does.

For more info on memory in FFM, I strongly recommend watching Konrad’s talk try! Swift Tokyo 2025 - Foreign Function and Memory APIs and Swift/Java interoperability

The most obvious place we need to allocate memory is when we initialize a wrapped Swift class. Take a look at the following generated code for a Swift initializer:

public static  MySwiftClass init(SwiftArena swiftArena$) {
  return MySwiftClass.wrapMemoryAddressUnsafe(MySwiftClass.$init(), swiftArena$);
}
private static native long $init();

Here we see that we are calling a native method $init which returns a long. This value is a pointer to the Swift instance in the memory space of Swift. It is passed to wrapMemoryAddressUnsafe, which is basically just storing the pointer in a local field and registering the wrapper to the SwiftArena.

SwiftArena is a type that is used to ensure we eventually deallocate the memory when the Java wrapper is no longer needed. There exists two implements of this:

SwiftArena.ofConfined(): returns a confined arena which is used with try-with-resource, to deallocate all instances at the end of some scope.
SwiftArena.ofAuto(): returns an arena that deallocates instances once the garbage-collector has decided to do so.

This concept also exists in the FFM mode, and I recommend watching Konrad’s talk at try! Swift Tokyo 2025 to learn more!

If we take a look at the native implementation of $init in Swift, we see how we allocate and initialize the memory:

// Generated code, not something you would write

@_cdecl("Java_com_example_swift_MySwiftClass__00024init__JJ")
func Java_com_example_swift_MySwiftClass__00024init__JJ(environment: UnsafeMutablePointer<JNIEnv?>!, thisClass: jclass, x: jlong, y: jlong) -> jlong {
  let result$ = UnsafeMutablePointer<MySwiftClass>.allocate(capacity: 1)
  result$.initialize(to: MySwiftClass.init(x: Int64(fromJNI: x, in: environment!), y: Int64(fromJNI: y, in: environment!)))
  let resultBits$ = Int64(Int(bitPattern: result$))
  return resultBits$.getJNIValue(in: environment!)
}

We are basically allocating memory for a single instance of MySwiftClass, initializing it to a new instance and returning the memory address of the pointer. It is the same approach for struct as well!

My experience with GSoC

Google Summer of Code was an awesome experience for me! I got to work with my favorite language on a library that is very relevant! A HUGE thanks to my mentor Konrad Malawski, who provided invaluable guidance, was always available for questions and allowed me to experiment and take ownership of the work!

I would definitely recommend GSoC to anyone interested, it is a great way to engage with the open-source community, develop your skills and work with some talented people! My number one advice would be to never be afraid of asking what might seem to be embarrassing questions, they might actually turn out to be great questions and lead to useful discussions and solutions.

GSoC 2025 Showcase: Swiftly support in VS Code

2025-11-05T13:00:00-04:00

Another successful year of Swift participation in Google Summer of Code recently came to an end, and we’d like to shine some light on the projects and work accomplished!

Summer of Code is an annual program, organized by Google, which provides hands-on experience for newcomers contributing to open source projects.

In this series of four blog posts, we’ll highlight each of the Summer of Code contributors and their projects. You can navigate between the posts using these convenient links:

Bringing Swiftly support to VS Code (this post)
Extending Swift-Java Interoperability
Improved code completion for Swift
Improved console output for Swift Testing

Each GSoC contributor has shared a writeup about their project and experience in the program on the forums. The first project we’re featuring on the blog brought Swiftly support to Visual Studio Code, contributed by Priyambada Roul. To learn more, you can read the full post on the Swift forums.

Bringing Swiftly support to VS Code

I am Priyambada Roul. I’m incredibly excited to share what I’ve been working on over the past three months as part of Google Summer of Code 2025 with Swift.org, alongside my mentors, Chris McGee and Matthew Bastien.

My project focused on integrating Swiftly (Swift’s toolchain manager) into the VS Code Swift extension.

The Problem We Solved

We’ve made switching toolchains easier with Swiftly, allowing you to install and switch between Swift versions without leaving VS Code. Developers can now:

Switch Swift versions with a single click
Install new toolchains without leaving VS Code
See real-time progress during installations
Automatically sync with project-specific Swift versions

What’s New for Swift Developers

Swiftly VS Code Integration

The VS Code extension now provides an entirely seamless toolchain management experience:

We now support macOS too!
See your current Swift version in the VS Code status bar
Click the version to switch between installed toolchains instantly
Install any Swift version directly from VS Code with real-time progress
Automatic detection of .swift-version files with prompts to switch

Enhanced Swiftly CLI

Swiftly now supports a machine-readable JSON output format
Swiftly now reports toolchain installation progress updates in JSONL format
We have polished error reporting

This experience is already shipping in the latest update of the VS Code extension, so you can try it yourself now!

Things I learnt

Making a VS Code extension. While I have experience with TypeScript from web development, the VS Code extension API and its development workflow are different from what I’m used to.
I understood the structure and distribution of Swift toolchains, as well as how different versions can coexist on the same system using symlinks, environment variables, and PATH manipulation, across both macOS and Linux.
The extension spawns Swiftly processes and reads their JSON output streams in real-time. This involved learning about IPC mechanisms, stdin/stdout buffering and process lifecycle management.

Want to see what we built? Check out the repositories:

VS Code Swift Extension: github.com/swiftlang/vscode-swift
Swiftly CLI: github.com/swiftlang/swiftly

I have linked all pull requests and technical details in my detailed project report, which provides an in-depth look into the specific changes.

This GSoC experience has been transformative. I came in as someone intimidated by large codebases, and I’m leaving with the confidence to tackle complex, multi-tool integrations. I’m excited to continue contributing to Swift community!

What's new in Swift: October 2025 Edition

2025-10-31T12:15:00-04:00

Editor Note: This is the first of a new series, What’s new in Swift, a regular digest featuring what’s new in the Swift project and ecosystem, with insights and perspectives from across the Swift world. This October edition covers highlights from the Server Side Swift conference, major package releases, and the latest Swift Evolution proposals.

Thanks to Joe Heck for sharing his conference experience and insights as our inaugural guest contributor.

Guest contributor highlights

At the beginning of October, I attended the Server Side Swift conference, my second year attending. I love that it focuses on using Swift both with and beyond Apple devices. This makes the conference a bit different from others you’ll see talked about by the community.

The keynote, by Ben Cohen, talked about language performance and the balancing act of the advances and continued work on the Swift language to enable you to reach for extremely high code performance. Having developed server and infrastructure apps in the past myself, I highly value the combination of the ease of developing in Swift and its impressive safety guarantees while also being able to drive out that “goes brrr” code performance.

In addition to low-level code performance, the conference had a great talk Observability in Server-Side Swift on how to keep an eye on the performance of your service as part of a bigger system. I’ve long been a fan of distributed tracing, and the 1.0 release of swift-otel enables server apps to provide logs, metrics, and traces using the OpenTelemetry standard to system observability tools. The 1.29.0 release of async-http-client just makes that process even easier, and I’ll briefly note that the new Valkey client for Swift also now includes full support for distributed tracing.

— Joe Heck

Joe’s conference experience highlights some of the exciting developments we’re seeing across the Swift ecosystem. Let’s dive into the broader picture of what’s been happening in the Swift community this month.

October 2025 updates

Featured community projects

Swift SDK for Android - The Android workgroup announced in the blog a preview release of an SDK supporting Android, and a dedicated Android platforms category in the Forums.
The Swift Extension of VS Code - Useful for developing server apps in Swift, the Swift Extension of VS Code is rapidly evolving and just released v2.12.0 featuring swiftly integration and a new walkthrough for first-time users.
Swift Build and Packaging Workgroup - A new workgroup under the ecosystem steering group with a focus on the tools used to build and package Swift code.
Swift Package Manager documentation - The documentation for the Package Manager is refreshed and now published, including the API references, on docs.swift.org.

Talks and presentations

Talks from the Server-Side Swift conference, hosted in London at the beginning of October, are now being published online. The following are two talks that stood out to me, which I’d like to share to encourage you to investigate the Server-Side Swift playlist of talks.

Unlock Generative AI for Swift Server-Side Development - Mona walked through using a library she helped create that uses large language models with her server side code.
Building Networking Libraries with Span and Concurrency - Joannis talks about how Swift concurrency can support network libraries for heavily concurrent data flows and the new Span feature from Swift 6.2 to provide efficient access for network buffers.

The Swift package ecosystem

Swift OTel - recent update 1.0.1 : An Open Telemetry exporter for a service to publish logs, metrics, and tracing to an OTel collector.
Swift Configuration - new release 0.2.0 : A new package, using the same pattern as swift-log and swift-metrics, to load configuration that supports a variety of loaders including JSON, YAML, and environment variables.
Swift Profile Recorder - new release 0.3.8 : An in-process profiler to help you capture what your code is spending time doing, so you can optimize its performance.
Swift Collections - recent update 1.3 : Among other updates, this adds UniqueArray to the collections provided - a high-performance collection type that takes advantage of the Swift’s performance advances with the types Span, InlineArray, and non-copyable types in Swift.
swiftly - recent update 1.1.0 : This adds deeper integration to help with developing Swift using VS Code.

Swift Evolution

Under active review:

SE-0497 Controlling function definition visibility in clients - The @inlinable attribute in Swift allows function definitions to be visible to callers, enabling optimizations like specialization and inlining. This proposal introduces explicit control over whether a function generates a callable symbol and makes its definition available for optimization purposes.

Recently completed:

SE-0495 C compatible functions and enums (accepted) - This proposal introduces the @c attribute to mark Swift functions and enums as callable and representable in C, respectively. It aims to formalize and extend the experimental @_cdecl attribute.
SE-0496 @inline(always) attribute (accepted) - The Swift compiler uses inlining to optimize code by expanding function bodies into callers, but it may not always inline functions due to size concerns. The @inline(always) attribute allows developers to force inlining for specific functions.

If you’re making something available that you’d like to highlight, create a thread on the Swift Forums Community Showcase. Please also nominate packages that you find interesting for potential inclusion into the Package Showcase hosted on Swift.org

Announcing the Swift SDK for Android

2025-10-24T06:00:00-04:00

Swift has matured significantly over the past decade — extending from cloud services to Windows applications, browser apps, and microcontrollers. Swift powers apps and services of all kinds, and thanks to its great interoperability, you can share code across platforms.

The Android workgroup is an open group, free for anyone to join, that aims to expand Swift to Android. Today, we are pleased to announce nightly preview releases of the Swift SDK for Android.

This milestone reflects months of effort by the Android workgroup, building on many years of grassroots community effort. With the SDK, developers can begin developing Android applications in Swift, opening new avenues for cross-platform development and accelerating innovation across the mobile ecosystem.

The Swift SDK for Android is available today, bundled with the Windows installer or downloadable separately for use on Linux or macOS.

Getting Started

We’ve published a Getting Started guide to help you set up your first native Swift code on an Android device. The Swift for Android Examples help demonstrate end‑to‑end application workflows on Android.

With the Swift SDK for Android, you can now start porting your Swift packages to Android. Over 25% of packages in the Swift Package Index already build for Android, and the Community Showcase now indicates Android compatibility.

The swift-java project enables you to interoperate between Java and Swift. It is both a library and a code generator, enabling you to integrate Swift and Java in both directions by automatically generating safe and performant bindings. To learn about generating bindings to bring your business logic to Android, check out the recent Swift Server Side meetup talk by Mads Odgaard.

Next Steps

This preview release opens many new opportunities to continue improving these tools. We encourage you to share your experiences, ideas, tools and apps on the Swift forums. This post has been published on an associated thread for discussion, and new posts can be shared in the Android category.

The Android workgroup is drafting a vision document, currently under review, for directing future work regarding Swift on Android. This vision will outline priority areas and guide community efforts to maximize impact across the ecosystem. In addition, we maintain a project board that tracks the status of major efforts, as well as official CI for the Swift SDK for Android.

If you’re as excited as we are, join us and help make this ecosystem even better!

Introducing Swift Profile Recorder: Identifying Performance Bottlenecks in Production

2025-10-06T06:00:00-04:00

Swift Profile Recorder, an in-process sampling profiler for Swift services, is now available as an open source project.

Profiling is a powerful technique for understanding the performance, resource usage, and behavior of your applications. With Swift Profile Recorder, profiling can now be added to your Swift services by simply adding a package dependency and no additional setup. Swift Profile Recorder enables you to:

Adopt profiling without extra privileges or system dependencies, allowing you to add profiling across a variety of compute environments with constrained permissions.
Collect samples using curl, allowing you to easily read profiler output via an HTTP endpoint without needing to learn specific tooling like perf, sample, DTrace, or eBPF (bpftrace).
Integrate with existing tools for visualization and analysis by supporting multiple industry-standard formats, including Linux perf script format, both the pprof file format as well as the /debug/pprof/profile endpoints, and also the collapsed format as used by the original FlameGraphs.

Apple has used Swift Profile Recorder at scale for several years as a tool for operating and debugging Swift services in production. Alongside the recent announcement of swift-parca, the Swift server ecosystem now has multiple profiling tools and approaches.

What is profiling and why does it matter?

Profiling enables you to understand where your Swift application spends its time — whether it’s computing, waiting for a lock acquisition, or blocked in file I/O. Profiling is achieved by collecting samples of activity, which provide insight into how it’s being used.

Modern operating systems have tooling available to profile your applications or even the whole system. Examples include Apple’s Instruments, sample, and Linux’s perf. Furthermore, there are kernel systems like DTrace or eBPF that can be used to profile your applications.

The community recently contributed swift-parca, which plugs into Parca Agent, leveraging Parca Agent and eBPF on Linux to profile your application continuously. These samples are then aggregated on a centralized Parca server. This is a great tool which we hope many deployments can leverage today. But there are a few constraints which may impact wider adoption:

Special privileges are required to attach to another process or load an eBPF/DTrace program into the kernel
Linux distributions may require additional components to enable this functionality
The available profiling technologies differ significantly between operating systems

To enable more teams to profile their applications, Swift Profile Recorder takes a different approach — it runs from within your process, implemented as a Swift Package. This means it can profile your code even in environments where external profiling tools can’t operate. You also won’t need to install other system components, you won’t need extra privileges, and the approach can work on different operating systems — right now Swift Profile Recorder supports macOS and Linux.

Profiling Swift services at Apple

Apple extensively uses Swift on server to build distributed systems providing storage and compute at a huge scale. These systems power the build and test infrastructure for the development of Apple’s operating systems. Our client workloads are latency-sensitive, so we soon found a need to further instrument the code to understand performance bottlenecks.

This infrastructure runs in a sandboxed environment where we don’t have access to tools such as eBPF. Additionally, components of our infrastructure run atop macOS. So we built Swift Profile Recorder to give better insights into non-optimal code.

We use Swift Profile Recorder in two ways for the above infrastructure use case:

To safely diagnose specific and isolated instances of performance regressions
To gather a large number of samples across all of our infrastructure to identify common patterns, also known as Continuous Profiling

Getting started

Adding Swift Profile Recorder to your application requires minimal setup:

// In your Package.swift
.package(url: "https://github.com/apple/swift-profile-recorder.git", .upToNextMinor(from: "0.3.0"))

// In your target dependencies
.product(name: "ProfileRecorderServer", package: "swift-profile-recorder")

Then, in your application’s main function:

import ProfileRecorderServer

@main
struct YourApp {
    func run() async throws {
        // Start the profiling server in the background
        async let _ = ProfileRecorderServer(configuration: .parseFromEnvironment()).runIgnoringFailures(logger: logger)

        // Your application code continues here
    }
}

Enable profiling through environment variables:

Assuming you specified configuration: .parseFromEnvironment() you will have to set an environment variable to activate the profiling server:

PROFILE_RECORDER_SERVER_URL_PATTERN=unix:///tmp/my-app-samples-{PID}.sock ./my-app

Collect samples with a simple curl command:

curl --unix-socket /tmp/my-app-samples-12345.sock \
     -sd '{"numberOfSamples":1000,"timeInterval":"10ms"}' \
     http://localhost/sample | swift demangle --compact > samples.perf

Visualization and Integration

The generated profiles work seamlessly with popular visualization tools:

Speedscope (speedscope.app): Drag and drop your .perf file for instant flame graph visualization
Firefox Profiler (profiler.firefox.com): Upload your profile for detailed timeline analysis (example profile)
Traditional FlameGraph tools: Use Brendan Gregg’s original FlameGraph scripts for custom visualizations
Many other tools compatible with the common .perf, .pprof or stack collapsed formats

An example running Hummingbird’s hello example on macOS visualized in Speedscope can be seen below

Swift Profile Recorder can also be used a source to send samples to Parca as well as Pyroscope. If your production environment allows you to install system-wide profiling using eBPF, we would recommend to use Parca Agent together with swift-parca.

Community and feedback

Swift Profile Recorder is an open source project and we’re eager to hear from the Swift community. Whether you’re running Swift applications in Kubernetes, investigating performance issues, or simply curious about where your application spends its time, we’d love to know how Swift Profile Recorder works for you. For example, it should be possible to integrate Swift Profile Recorder into a lambda function. We look forward to hearing how you use the profiler.

The project is actively developed and we welcome contributions, bug reports, and feature requests. As with any profiling tool, different applications and environments present unique challenges, and community feedback is essential for improving the profiler’s effectiveness across diverse Swift codebases.

Ready to start profiling? Visit the Swift Profile Recorder repository to get started. We also encourage you to discuss the project on the Swift forums, including asking questions about this post on the associated thread, and sharing your experiences in the Swift Profile Recorder category.

Swift.org

What's new in Swift: March 2026 Edition

Videos to watch

Community highlights

Swift Evolution

Swift 6.3 Released

Language and Standard Library

C interoperability

Module name selectors

Performance control for library APIs

Package and Build Improvements

Core Library Updates

Swift Testing

DocC

Platforms and Environments

Embedded Swift

Android

Thank You

Next Steps

Swift at scale: building the TelemetryDeck analytics service

Adopting Swift for backend services

Swift’s Codable protocol

Sharing Data Transfer Objects between Client and Server

Developer experience matters

Building the ecosystem we want to use

Lessons learned

Where we are now

What's new in Swift: February 2026 Edition

New package releases

Videos to watch

Community highlights

Swift Evolution

Announcing Swift System Metrics 1.0: Process-Level Monitoring

Highlights

Get Started

Get Involved

What's new in Swift: January 2026 Edition

Videos to watch

New package releases

Community highlights

Swift Evolution

Announcing the Windows Workgroup

Improving the usability of C libraries in Swift

Setup: Writing a module map

Seeing the results

Cleaning up enumeration types

API notes

Reference-counted object types

Importing functions

Importing functions as methods

Importing functions as properties

Importing functions as initializers

Another Boolean type?

Option sets

Nullability

Scripting the creation of WebGPU.apinotes

Swiftifying your favorite C library

Postscript: Thoughts for improving the generated webgpu.h

What's new in Swift: December 2025 Edition

Swift at FOSDEM 2026

Talks worth watching

Behind the scenes interviews

Swift blog highlights

Swift everywhere

Swift Evolution

Exploring the Swift SDK for Android

How Swift works on Android

Swift on Android in production

Ongoing work

Sharing Swift across platforms: logic vs UI

Android API versioning

Learn from the community

Swift 6.3 SDK nightly previews

Swift Configuration 1.0 released

Why it exists

Getting started

Advanced capabilities

Community adoption

Next steps

Embedded Swift Improvements Coming in Swift 6.3

`@c` functions and enums @c functions and enums section" href="#c-functions-and-enums">

`@section` and `@used` attributes @section and `@used` attributes section" href="#section-and-used-attributes">