Swift.org

Announcing Swift Homomorphic Encryption

2024-07-30T06:00:00-04:00

We’re excited to announce a new open source Swift package for homomorphic encryption in Swift: swift-homomorphic-encryption.

Homomorphic encryption (HE) is a cryptographic technique that enables computation on encrypted data without revealing the underlying unencrypted data to the operating process. It provides a means for clients to send encrypted data to a server, which operates on that encrypted data and returns a result that the client can decrypt. During the execution of the request, the server itself never decrypts the original data or even has access to the decryption key. Such an approach presents new opportunities for cloud services to operate while protecting the privacy and security of a user’s data, which is obviously highly attractive for many scenarios.

At Apple, we’re using homomorphic encryption in our own work; we’re therefore delighted to share this Swift implementation in the community for others to use and contribute to.

One example of how we’re using this implementation in iOS 18, is the new Live Caller ID Lookup feature, which provides caller ID and spam blocking services. Live Caller ID Lookup uses homomorphic encryption to send an encrypted query to a server that can provide information about a phone number without the server knowing the specific phone number in the request. To demonstrate this, we are also sharing live-caller-id-lookup-example, which provides a functional example backend to test the Live Caller ID Lookup feature using homomorphic encryption.

These two packages take full advantage of features such as:

Swift on Server, including the Hummingbird HTTP framework and cross-platform support
easy benchmarking with the Benchmark library
performant low-level cryptography primitives in Swift Crypto.

Private Information Retrieval (PIR)

Live Caller ID Lookup relies on Private Information Retrieval (PIR), a form of private key-value database lookup. In the PIR setting, a client has a private keyword (such as a phone number) and wants to retrieve the associated value from a server. Because the keyword is private, the client wants to perform this lookup without the server learning the keyword.

A trivial implementation of PIR is to have the server send the entire database to the client for local processing. While this does prevent the server from knowing what queries are being made, it is only feasible for small databases with infrequent updates.

In contrast, our PIR implementation, which relies on homomorphic encryption, only needs to sync a small amount of database metadata with the client. This metadata changes infrequently, which allows efficient handling of very large databases with a high volume of updates.

Homomorphic Encryption

As mentioned above, homomorphic encryption enables computation on encrypted data without decryption or access to the decryption key.

A typical workflow for homomorphic encryption might be as follows:

The client encrypts its sensitive data and sends the result to the server.
The server performs computation on the ciphertext (perhaps incorporating its own plaintext inputs), without learning what any ciphertext decrypts to.
The server sends the resulting ciphertext response to the client.
The client decrypts the resulting response.

The Swift implementation of homomorphic encryption implements the Brakerski-Fan-Vercauteren (BFV) HE scheme (https://eprint.iacr.org/2012/078, https://eprint.iacr.org/2012/144). BFV is based on the ring learning with errors (RLWE) hardness problem, which is quantum resistant.

The Live Caller ID Lookup feature requires BFV parameters with post-quantum 128-bit security, to provide strong security against both classical and potential future quantum attacks, previously explained in https://security.apple.com/blog/imessage-pq3/.

Using Homomorphic Encryption

We believe developers will find homomorphic encryption useful for a wide variety of standalone privacy-preserving applications both inside and outside the Apple ecosystem, including private set intersection, secure aggregation, and machine learning.

Below is a basic example for how to use Swift Homomorphic Encryption.

import HomomorphicEncryption

// We start by choosing some encryption parameters for the Bfv<UInt64> scheme.
// *These encryption parameters are insecure, suitable for testing only.*
let encryptParams =
    try EncryptionParameters<Bfv<UInt64>>(from: .insecure_n_8_logq_5x18_logt_5)
// Perform pre-computation for HE computation with these parameters.
let context = try Context(encryptionParameters: encryptParams)

// We encode N values using coefficient encoding.
let values: [UInt64] = [8, 5, 12, 12, 15, 0, 8, 5]
let plaintext: Bfv<UInt64>.CoeffPlaintext = try context.encode(
    values: values,
    format: .coefficient)

// We generate a secret key and use it to encrypt the plaintext.
let secretKey = try context.generateSecretKey()
let ciphertext = try plaintext.encrypt(using: secretKey)

// Decrypting the plaintext yields the original values.
let decrypted = try ciphertext.decrypt(using: secretKey)
let decoded: [UInt64] = try decrypted.decode(format: .coefficient)
precondition(decoded == values)

We look forward to working with others to enhance this package: you can read more about contributing at the repositories on GitHub. We also encourage you to file issues to swift-homomorphic-encryption and live-caller-id-lookup-examples if you encounter any problems or have suggestions for improvements.

We’re excited to see how homomorphic encryption can empower developers and researchers in the Swift community to enable new use cases!

Plotting a Path to a Package Ecosystem without Data Race Errors

2024-07-01T05:00:00-04:00

Swift 6 introduces compile-time data race safety checking for any code that opts in to use the Swift 6 language mode. While individual modules can adopt this mode incrementally and independently of their dependencies, the full benefit of runtime data race safety is only realized when all modules have opted in. Therefore, the quick adoption of Swift 6 language mode across the ecosystem of open-source packages will play a key role in advancing data race safety across the entire Swift ecosystem.

Data races can lead to crashes, inconsistent behaviour, and performance issues in apps so the sooner apps and their dependencies can adopt the Swift 6 language mode and opt in to these checks, the better!

Tracking Swift 6 Readiness and Progress

The Swift Package Index’s new Ready for Swift 6 page tracks progress toward data race safety across the entire package ecosystem. While packages can opt in to Swift 6 language mode at their convenience, this page shows the number of packages that would pass those checks if all strict concurrency checks were enabled for all packages.

The Swift Package Index has been running these checks using Swift 6 nightly toolchains since early May, and there has already been a steady reduction in the number of packages with data race errors. For the past week, the Swift Package Index build machines have been running fresh builds with the advantage of platform SDKs with more Sendable conformance, bringing the total percentage of packages with zero data race errors to over 43%! That’s a really great start for being only one week into the Swift 6 beta process.

Over time, successful adoption of Swift 6 language mode in the package ecosystem will come from two directions. First, as more packages opt into these checks, package authors will fix potential data races highlighted by the compiler, increasing compatibility and reducing errors. Second, compiler iterations will refine data race checking and consolidate error diagnostics.

Data Race Safety Indicators

When evaluating a package, it is helpful to know if that package has any reported data race safety issues. To assist with this, the Swift Package Index now displays a “Safe from data races” label alongside other package metadata when packages compile with zero errors using complete strict concurrency checks.

Compatibility vs Data Race Safety

During the transition to Swift 6, you will likely see packages that show a green checkmark against Swift 6 in Swift Package Index’s platform and Swift version compatibility matrix while also showing that the package has data race safety errors:

When compiling packages to check compatibility with Swift 6, the Swift Package Index uses whichever language mode the package author specifies. A package can be compatible with Swift 6 before it adopts the Swift 6 language mode and strict concurrency checks and the matrix only ever shows compatibility. Whether you adopt a package with potential data race safety issues is yours to make, but if the compatibility matrix shows a green checkmark, you can.

Call to Action: Adopt the Swift 6 Language Mode

Compile-time data race safety is a major advance for the Swift language, eliminating an entire class of potential concurrency bugs and elevating your code’s safety and maintainability. Every module that migrates to Swift 6 contributes to the community-wide transition to bring data race safety to the Swift software ecosystem. You can help by updating your own packages, and you can follow the broader ecosystem’s progress on the Ready for Swift 6 page on the Swift Package Index.

New GitHub Organization for the Swift Project

2024-06-10T06:00:00-04:00

Today, we are announcing an exciting development for the Swift programming language: its migration to a dedicated GitHub organization at GitHub.com/swiftlang.

This migration reflects the growth and maturity of the Swift community and highlights Swift’s versatility beyond Apple’s own ecosystems. Over the last decade, many inspiring individuals’ hard and creative work has elevated Swift into various creative and practical applications. With a GitHub organization dedicated to Swift, we are creating an even more conducive environment for collaboration and innovation. This change will allow Swift to expand its reach to more platforms and use cases, sparking fresh possibilities and broadening Swift’s impact across the technology landscape.

Timeline and Initial Scope

The migration to the swiftlang organization will be phased over the coming weeks and months, striking a balance between minimizing disruption and ensuring a deliberate completion. Initially, the swiftlang organization will include foundational elements of the Swift project, such as:

Compiler and core tools
Standard libraries and core APIs
Samples
The Swift.org website
Official clients, drivers, and other packages (coming soon)

As we move forward, we will address several key governance aspects:

Methods for integrating new projects into the organization and guiding them through a successful maturity cycle
Utilization of GitHub teams and other tools to expand our contributor base and clearly define roles for commiters
Extend and augment continuous integration (CI) support to ensure Swift and all of its components is a well-tested, production-ready programming language for all use cases

A Community Journey

Various groups within our community will spearhead this migration, including the Core Team, the Contributor Experience Workgroup, the Swift Server Workgroup, and the Website Workgroup. This initiative represents a community-wide effort, with full transparency as changes progressively unfold.

As a first step, we will move the swift-evolution repository today, with other repositories transitioning over the coming weeks. We will post updates to the accompanying forum posts as the migration unfurls.

On behalf of the core team, I want to express our deep gratitude to everyone who has contributed to the Swift dream, from its inception a decade ago to today. Together, we are building the pathways for the next chapter of Swift!

Onward!

Ted (and the Swift Core Team)

Get Started with Embedded Swift on ARM and RISC-V Microcontrollers

2024-04-03T06:00:00-04:00

We’re pleased to introduce a repository of example projects that demonstrate how Embedded Swift can be used to develop software on a range of microcontrollers.

Swift is a scalable language, great for writing desktop and mobile apps, server backends, and system software. And as you may have seen, thanks to a new, experimental compilation mode, you can use Swift to target embedded environments like ARM and RISC-V microcontrollers as well, popular for building professional and hobbyist electronics projects such as IoT devices.

Microcontrollers are constrained environments where not all of Swift’s features are appropriate. The new Embedded Swift compilation mode turns off certain language features like runtime reflection, ABI stability, and existentials, to produce standalone binaries suitable for firmware. Despite turning off some language features, the Embedded Swift subset still feels very close to the “full” Swift that developers love, and makes it easy to continue writing idiomatic, easy-to-read Swift code. You can dive into the details in the formally accepted Embedded Swift Vision Document, and try it out in the nightly downloadable toolchains.

The Swift community has already started publishing several fascinating projects built with this language mode, and we thought it would be useful to publish a collection of sample projects at swift-embedded-examples.

Swift on STM32F746, Raspberry Pi Pico, nRF52840, and ESP32C6

This repository is meant to be a showcase of the wide applicability of Embedded Swift. The examples are targeting different microcontrollers where Swift can be easily used, including STM32 boards, the Raspberry Pi Pico, Nordic Semiconductor boards, and even RISC-V ESP32 boards. The examples also cover different build systems and integration options, such as building fully standalone Swift code and bridging existing SDKs from board vendors to Swift.

We encourage anyone interested to try out the examples and help us grow the repository. We are looking for community contributions to cover more microcontroller boards, different build systems, and usage of simple peripherals.

Try It Out

If you’d like to try out the existing example projects, visit the repository at swift-embedded-examples. It contains a catalog of examples along with instructions on how to build and run each of them.

To use these examples, be sure to install the latest development snapshot toolchain. As an experimental mode, Embedded Swift is not yet available in release versions of Swift.

If you have any questions or want to share your experiences and ideas, please reach out on the Swift Forums. Your feedback will help bring Embedded Swift into a future release.

SSWG 2024 Annual Update

2024-03-28T10:30:00-04:00

In this annual post, the Swift Server WorkGroup (SSWG) reflects on the community, ecosystem-wide accomplishments and the workgroup’s focus areas for the year ahead.

Since our previous update, Swift on the Server has continued to grow in many ways. Let’s start with a look at the progress made in 2023, then look ahead and next steps for 2024.

2023 in Review

Server Community Survey

For the first time ever, the SSWG ran a developer community survey aimed at collecting feedback and information about the shape and breadth of the Swift server ecosystem. We received a great response, and we’d like to thank everyone who participated!

We’ve analyzed the responses to help direct the workgroup’s efforts, as well as provide visibility into how the ecosystem is doing. For example, while the majority of respondents already use Swift Concurrency, there remain challenges in some areas with adoption. We also learned that there is a lot of interest in standardized tooling such as swift-format and sourcekit-lsp, and interest in building out support for various IDEs.

You can read the full SSWG Community Survey 2024 Report over on the Swift forums.

Continued Focus on Growing the Ecosystem

The SSWG has continued to focus on growing the ecosystem by incubating packages and providing guidance to package authors. We’ve seen a lot of new, in-development, and improved packages in the last year.

By participating in the Google Summer of Code, we were able to provide swift-memcache-gsoc, which makes it easier to communicate with Memcached servers. The wire protocol and higher-level connection APIs are done, with connection pools and key sharding on the roadmap.

Adoption of Structured Concurrency

We’ve seen a lot of progress on the adoption of Structured Concurrency. Most new libraries are adopting it, and we’re working on a guide to help existing libraries adopt it as well.

Two big drivers of Structured Concurrency in the ecosystem have been SwiftNIO’s introduction of NIOAsyncChannel and the ServiceGroup in the rewritten ServiceLifecycle package. Together they are foundational pieces for higher-level libraries like Hummingbird and gRPC to build logic using Structured Concurrency.

Tooling Improvements

Tooling has seen some tremendous improvements in 2023 with the introduction of Swiftly, Dependabot for Swift, and Chiseled Containers.

In addition, thanks to the introduction of Package Plugins, we’ve seen the OpenAPI Generator make an entry. This plugin allows you to generate Swift boilerplate code from an OpenAPI specification. This is a great way to build both HTTP clients and servers.

New Members

Since our update post of 2023, Sven A. Schmidt has joined the workgroup. Sven has already been involved with the documentation workgroup and is known for his work on the Swift Package Index.

Ecosystem

Last year, we saw seven new packages enter the SSWG incubation process. A tremendous amount of work has been done on these packages, showing how rapidly the ecosystem is expanding:

Swift Distributed Actors (Cluster) was accepted in January 2023. This package enables writing peer-to-peer clusters in Swift using distributed actors.
Cassandra Client was accepted in February 2023, providing a Swift client for Apache Cassandra.
SQLiteNIO was accepted in September 2023. This package provides an SQLite driver for Swift, and is commonly used through Vapor’s Fluent ORM.
Swift Service Context and Swift Distributed Tracing were accepted in October 2023. These packages enable distributed tracing for Swift, rounding out the “three pillars of observability”.
DiscordBM was accepted in October 2023. DiscordBM is a Swift client for Discord’s Bot API, and is the foundation of Vapor’s Penny bot.
Swift OpenAPI Generator was also accepted in October 2023, providing a Swift code generator for OpenAPI specifications, enabling generating both servers and clients.

In addition, MongoKitten was pitched and approved at the start of 2024. MongoKitten is a popular MongoDB driver for Swift.

Goals for 2024

Preparing for Swift 6

In preparation for Swift 6, we’ll be looking at the impact of strict concurrency checking across the server ecosystem. We are planning to enable strict checking on every incubated package and make each package compile warning-free under the strict checking rules.

Adoption of Structured Concurrency

Adoption of Structured Concurrency has been going strong but the journey isn’t finished. In the coming year, we’ll be focusing on adopting Structured Concurrency in even more libraries, with the goal of making SwiftNIO an implementation detail of more and more libraries.

In addition to working on libraries, we are also planning work on more guides for developers of libraries and applications, describing how to adopt Structured Concurrency and the benefits it brings.

Standardized HTTP Server and Middleware

In 2023, we’ve extensively prepared for a standardized HTTP server and middleware. The in-progress, Hummingbird rewrite is already taking advantage of the new HTTP types. The goal for 2024 is to produce a low-level, general-purpose HTTP server package.

Marketing Swift on the Server

Marketing Swift on the Server is a big focus area for 2024. With the introduction of the redesigned navigation of the Swift.org website, we’ll be better able to showcase Swift on the Server.

We’re looking to create more content for the ecosystem, such as integrated example projects and showcases of existing server-focused projects.

In addition, we’re looking to connect developers by organizing online user group meetings. We’re currently planning the first Swift Server User Group meeting, with a goal of 3-4 meetings per year.

Finally, we’re excited to see the return of the ServerSide.swift conference in 2024, hosted in London.

Writing GNOME Apps with Swift

2024-03-25T06:00:00-04:00

Swift is well-suited for creating user interfaces thanks to the clean syntax, static typing, and special features making code easier to write. Result builders, combined with Swift’s closure expression syntax, can significantly enhance code readability.

Adwaita for Swift leverages these Swift features to provide an intuitive interface for developing applications for the GNOME platform. GNOME is a popular, open source desktop environment for Linux, known for its emphasis on simplicity and accessibility. It offers an intuitive user interface, with a vast app ecosystem built using its modern Adwaita design language. Explore a collection of great apps under Apps for GNOME.

Let’s look at a code example of using Adwaita for Swift. The following code snippet defines a view, which represents a part of the user interface inside a window.

struct Counter: View {

    @State private var count = 0

    var view: Body {
        HStack {
            Button(icon: .default(icon: .goPrevious)) {
                count -= 1
            }
            Text("\(count)")
                .style("title-1")
                .frame(minWidth: 100)
            Button(icon: .default(icon: .goNext)) {
                count += 1
            }
        }
    }

}

A view can be nested within other views or added as the child of a window.

Its content can be modified from outside that view and is influenced by its position in the view hierarchy. This makes it easier to compose views to produce different results. The screenshot shows one simple possibility.

Motivation

The primary motivation for this package is to enable the use of Swift when writing GNOME apps, for all the reasons outlined above. But there are a few additional reasons:

Declarative

While there are already libadwaita and GTK bindings for numerous modern programming languages, including Rust, Python, and JavaScript, all official bindings follow an imperative coding style. This can be verbose and harder to follow than a declarative style as user interfaces are constructed using a series of commands. The following Python code serves as an illustration of this.

class Counter(Gtk.Box):

    def __init__(self):
        Gtk.Box.__init__(self, orientation=Gtk.Orientation.HORIZONTAL, spacing=6)
        self.count = 0

        button_prev = Gtk.Button.new_from_icon_name("go-previous", Gtk.IconSize.BUTTON)
        button_prev.connect("clicked", self.on_prev_clicked)
        self.pack_start(button_prev, True, True, 0)

        self.label = Gtk.Label(label=str(self.count))
        self.label.set_name("title-1")
        self.pack_start(self.label, True, True, 0)

        button_next = Gtk.Button.new_from_icon_name("go-next", Gtk.IconSize.BUTTON)
        button_next.connect("clicked", self.on_next_clicked)
        self.pack_start(button_next, True, True, 0)

    def on_prev_clicked(self, button):
        self.count -= 1
        self.label.set_text(str(self.count))

    def on_next_clicked(self, button):
        self.count += 1
        self.label.set_text(str(self.count))

This Python code uses the PyGObject library and produces the same user interface as the Swift code above.

Ease of Use

As you can see, Adwaita for Swift is built around data. For example, changing the variable count when pressing one of the buttons in the sample app will automatically update the user interface. Traditional bindings require you to call a function on the object holding a widget that should update its content once a value changes.

If you decide to store the value on the disk so that it persists between startups of the app, you would have to add a lot of complexity to your code using traditional bindings. Adwaita for Swift enables you to simply add a unique identifier to the variable that should be stored, and will take care of the rest.

@State("count") private var count = 0

There is also a simple and safe approach for localization with the Localized package.

Readability

The simplicity coming with the data-centric approach has a positive impact on readability.

Another point is the declarative definition of the user interface itself. You can focus on what the app should look like and how it should behave rather than how to achieve those results.

While there are other solutions available, such as defining the UI with XML and Blueprint, they require the user interface and actual code to be written in different files. Also, updating the user interface has to be done manually whenever data changes. This makes it more difficult to follow the logic as a reader.

As the user interface is written in Swift, you can use convenient Swift syntax directly in your user interface definition.

var view: Body {
    if count == 0 {
        Text("😍")
    } else {
        Text("\(count)")
    }
}

Cross-Platform App Development

Adwaita for Swift is useful in a number of ways:

You can write apps that run on Linux, macOS and Windows with a single codebase.
You can share backend Swift code between SwiftUI apps and GNOME apps.
You can create entirely new GNOME apps using Swift, achieving great code readability and memory safety.

Publish Apps

In addition to traditional distribution packages, Adwaita for Swift works great with Flathub. Flathub is an app store powered by Flatpak which simplifies the installation and publishing of apps for desktop Linux.

There is the Freedesktop SDK Extension for Swift 5 which adds support for Swift, and a tool to convert Swift Package Manager dependencies into Flatpak sources.

Learn how to publish your apps in the Adwaita for Swift documentation.

Get Involved

Each contribution to this project is highly appreciated.

You can:

Create an app! Use the template repository as a starting point and refer to the tutorial. Feel free to showcase your project in the discussions. Note that libadwaita works best on Linux. If you’re on a newer Mac and interested in Linux, check out Asahi Linux.
Open issues if you find any problems or if you have an idea, or participate in the dicussions by asking questions, dicussing ideas, or informing others about your work.
Write documentation to help others understand Adwaita for Swift.
Simply star the repository to improve its discoverability.
Take a look at the Memorize app. It is the first app on Flathub built using Adwaita for Swift.

Thanks for your participation ❤️

Introducing the Benchmark Package: Complementing Unit Tests with Performance Checks

2024-03-20T06:00:00-04:00

In the world of software development, the old adage “make it work, make it right, make it fast” serves as a guiding principle for creating robust, efficient applications. This journey starts with ensuring that our code functions as intended, a task where unit and integration testing have proven indispensable. However, ensuring functionality is only part of the equation. The true measure of an application’s excellence extends into its performance - how fast and efficiently it operates under various conditions. Herein lies the critical but often overlooked third step: making it fast.

In the realm of professional trading software, the role of a comprehensive benchmarking framework integrated with Continuous Integration (CI) parallels the importance of unit and integration testing. Just as unit and integration tests are essential for ensuring the functional correctness of software, benchmarking within a CI pipeline is crucial for continuously validating the non-functional aspects, such as high throughput, low latency, predictable performance and consistent resource usage. This is vital for maintaining the competitive edge in a fast-paced financial environment where the extreme market data rates and performance requirements means that even small variations in response time - on the scale of microseconds - can significantly impact trade outcomes.

Performance is an important part of the overall product regardless of the application domain, no end user wants to wait on a computer or other electronic device, instant response to user operations truly helps provide a delightful end user experience.

After examining the existing infrastructure within the Swift ecosystem, we concluded that there were no existing solutions meeting our needs for multi-platform and rich metrics support, CI integration, and developer-friendliness. Therefore, we decided to develop a Benchmark package and open source it, believing it could help advance performance for the Swift community and benefit all of us.

The Role Of Benchmarks

Have you ever encountered a performance problem that slipped through to end users which resulted in a bug report? Do you systematically measure and validate performance metrics when making changes to your Swift package?

Swift aims for performance that rivals C-based languages, emphasizing predictable and consistent execution. Achieving this involves optimizing the use of constrained resources like CPU, memory, and network bandwidth, which significantly influence application workloads across server-side, desktop, and mobile environments. Key performance metrics include CPU usage, memory allocation and management, network I/O, and system calls, among others. These metrics are essential for foundational software, where controlling resource usage and minimizing footprint are as critical as maintaining runtime performance. The Benchmark package readily supports these metrics, along with OS-specific ones for Linux and macOS, providing a comprehensive toolkit for Swift developers to monitor and enhance their applications’ efficiency.

Constructing a set of benchmarks and consistently running them provides an indication when something is not performing as expected, just as a unit test flags if some functional expectation is broken. Then complementary tools (e.g. Instruments, DTrace, Heaptrack, Leaks, Sample, …) are used to for root-cause analysis to analyze and fix the underlying problem.

This is analogous to unit tests, where a failed test indicates that something is wrong, and other more specialized tools are used to fix the problem (e.g., a debugger, TSAN/ASAN, adding asserts, debug printouts, …).

Benchmarking Infrastructure

The open-source Benchmark package helps you automate performance testing and makes it easy for individual developers to run a quick performance validation locally before pushing changes.

The Benchmark package is implemented as a SwiftPM command plugin and adds a dedicated command to interact with benchmarks:

swift package benchmark

Introductory getting started information is available both on the package GitHub page as well as in the Swift Package Index DocC documentation.

A minimalistic benchmark measuring the performance of Date would simply be:

import Benchmark
import Foundation

let benchmarks = {
    Benchmark("Foundation-Date") { benchmark in
        for _ in benchmark.scaledIterations {
            blackHole(Foundation.Date())
        }
    } 
}

It is suitable both for microbenchmarks mostly concerned with CPU usage as well as for more complex long-running benchmarks and supports measuring a wide range of samples over a long time thanks to using the HDR Histogram package.

Benchmark provides support for an extensive set of built-in metrics:

cpuUser - CPU user space time spent for running the test
cpuSystem - CPU system time spent for running the test
cpuTotal - CPU total time spent for running the test (system + user)
wallClock - Wall clock time for running the test
throughput - The throughput in operations / second
peakMemoryResident - The resident memory usage - sampled during runtime
peakMemoryResidentDelta - The resident memory usage - sampled during runtime (excluding start of benchmark baseline)
peakMemoryVirtual - The virtual memory usage - sampled during runtime
mallocCountSmall - The number of small malloc calls according to jemalloc
mallocCountLarge - The number of large malloc calls according to jemalloc
mallocCountTotal - The total number of mallocs according to jemalloc
allocatedResidentMemory - The amount of allocated resident memory by the application (not including allocator metadata overhead etc) according to jemalloc
memoryLeaked - The number of small+large mallocs - small+large frees in resident memory (just a possible leak)
syscalls - The number of syscalls made during the test – macOS only
contextSwitches - The number of context switches made during the test – macOS only
threads - The maximum number of threads in the process under the test (not exact, sampled)
threadsRunning - The number of threads actually running under the test (not exact, sampled) – macOS only
readSyscalls - The number of I/O read syscalls performed e.g. read(2) / pread(2) – Linux only
writeSyscalls - The number of I/O write syscalls performed e.g. write(2) / pwrite(2) – Linux only
readBytesLogical - The number of bytes read from storage (may be from pagecache!) – Linux only
writeBytesLogical - The number bytes written to storage (may be cached) – Linux only
readBytesPhysical - The number of bytes physically read from a block device – Linux only
writeBytesPhysical - The number of bytes physically written to a block device – Linux only
retainCount - The number of retain calls (ARC)
releaseCount - The number of release calls (ARC)
retainReleaseDelta - abs(retainCount - releaseCount) - if this is non-zero, it would typically mean the benchmark has a retain cycle (use Memory Graph Debugger to troubleshoot)

Custom metrics are supported as well for application-specific measurements (e.g. cache hit/miss statistics).

Writing Benchmarks

There’s an introduction to writing benchmarks as well as a sample repository.

A slightly more complicated benchmark measuring a part of the Histogram package:

import Benchmark
import Foundation
import Histogram

let benchmarks = {
    // Minimal benchmark with default settings
    Benchmark("Foundation-Date") { benchmark in
        for _ in benchmark.scaledIterations {
            blackHole(Foundation.Date())
        }
    } 

    // Slightly more complex with some customization
    let customBenchmarkConfiguration: Benchmark.Configuration = .init(
        metrics: [
            .wallClock,
            .throughput,
            .syscalls,
            .threads,
            .peakMemoryResident
        ],
        scalingFactor: .kilo
    )

    Benchmark("ValueAtPercentile", configuration: customBenchmarkConfiguration) { benchmark in
        let maxValue: UInt64 = 1_000_000

        var histogram = Histogram<UInt64>(highestTrackableValue: maxValue, 
                                          numberOfSignificantValueDigits: .three)

        for _ in 0 ..< 10_000 {
            blackHole(histogram.record(UInt64.random(in: 10 ... 1_000)))
        }

        let percentiles = [0.0, 25.0, 50.0, 75.0, 80.0, 90.0, 99.0, 100.0]

        benchmark.startMeasurement() // don't measure the setup cost above

        for i in benchmark.scaledIterations {
            blackHole(histogram.valueAtPercentile(percentiles[i % percentiles.count]))
        }

        benchmark.stopMeasurement()
    }
}

Benchmark Output And Analytics

The default output is in a table format for human readability, but the package supports a range of different output formats with output suitable for analysis with other visualization tools.

Sample default output when running benchmarks:

Key Benchmark Workflows Are Supported

Automated Pull Request performance regression checks by comparing the performance metrics of a pull request with the main branch and having the PR workflow check fail if there is a regression according to absolute or relative thresholds specified per benchmark
Automated Pull Request check vs. a pre-recorded absolute baseline p90 threshold (see e.g., Swift Certificates for such a workflow with related Docker files), suitable for e.g., malloc regression tests
Manual comparison of multiple performance baselines for iterative or A/B performance work by an individual developer
Export of benchmark results in several formats for analysis or visualization
Running the Instruments profiler on the benchmark suite executable directly from Xcode

Closing Thoughts

The Swift community, including major public projects like Swift Foundation, SwiftPM, SwiftNIO, and Google Flatbuffers, has recently embraced the Benchmark package to focus on performance optimization.

Discover how to leverage this tool for your own Swift applications by exploring the extensive documentation and join the conversation on the Swift forums to share insights and get answers to your questions. Or why not provide a PR to your favourite open source package that lacks performance tests?

Take the first step to improve your software today, by adding its first benchmark to check performance!

Byte-sized Swift: Building Tiny Games for the Playdate

2024-03-12T06:00:00-04:00

I’m excited to share swift-playdate-examples, a technical demonstration of using Swift to build games for Playdate, a handheld game system by Panic.

Why Swift?

Swift is widely known as the modern language for app development on Apple devices. However, over the course of its first decade, it has grown into a versatile, multi-platform language targeting use cases where you’d otherwise find C or C++.

Personally, I have come to appreciate Swift’s emphasis on memory safety and great ergonomics, and want these traits for embedded systems where reliability and security are critically important.

But embedded systems are not only found in mission-critical applications. Some are actually all fun and games.

Playdate by Panic

Over the holiday season, I read about building Playdate games in C and became curious if the same was possible in Swift. For those unfamiliar with Playdate, it is a tiny handheld game system built by Panic, creators of popular apps and games like “Transmit,” “Nova,” “Firewatch,” “Untitled Goose Game,” and more. It houses a Cortex M7 processor, a 400 by 240 1-bit display, and has a small runtime for hosting games. Additionally, Panic provides an SDK for building games in both C and Lua.

While most Playdate games are written in Lua for ease of development, they can run into performance problems that necessitate the added complexity of using C. Swift’s combination of high-level ergonomics with low-level performance, as well as its strong support for interoperating with C, make it seem like a good match for the Playdate. However, the typical Swift application and runtime exceed the device’s tight resource constraints.

Regardless, I still wanted to create a game in Swift and I had a good idea for the approach.

The Embedded Language Mode

Recently, the Swift project began developing a new embedded language mode to support highly constrained platforms. This mode utilizes generic specialization, inlining, and dead code stripping to produce tiny binaries, while retaining the core features of Swift.

Note: The embedded language mode is actively evolving and is helping drive the development of language features such as: non-copyable types, typed throws, etc. It is available now in nightly toolchains and if you’re curious to learn more, check out the Vision for Embedded Swift.

These defining characteristics make the embedded language mode a great solution for shrinking Swift to fit the Playdate’s constraints.

With the embedded Swift language mode in hand, I got to work.

The Games

I wrote two small games in Swift for the Playdate. The first game is a port of the Playdate SDK sample of Conway’s Game of Life into Swift:

This game is one Swift file that builds directly against the Playdate C API and does not require dynamic memory allocation. The packaged game clocks in at 788 bytes, slightly smaller than the C example, which is 904 bytes.

$ wc -c < $REPO_ROOT/Examples/Life/Life.pdx/pdex.bin
     788

$ wc -c < $HOME/Developer/PlaydateSDK/C_API/Examples/GameOfLife.pdx/pdex.bin
     904

Note: Both versions could likely be made smaller, but I did not try to optimize code size.

The second game is a paddle-and-ball style game named “Swift Break.”

Swift Break uses the same high-level language features you’d find in desktop and server applications, such as enums with associated values, generic types and functions, and automatic memory management to simplify game development while retaining C-level performance.

For example, here’s the core game logic for handling ball bounces:

sprite.moveWithCollisions(goalX: newX, goalY: newY) { _, _, collisions in
  for collision in collisions {
    let otherSprite = Sprite(borrowing: collision.other)

    // If we hit a visible brick, remove it.
    if otherSprite.tag == .brick, otherSprite.isVisible {
      otherSprite.removeSprite()
      activeGame.bricksRemaining -= 1
    }

    var normal = Vector(collision.normal)

    if otherSprite.tag == .paddle {
      // Compute deflection angle (radians) for the normal in domain
      // -pi/6 to pi/6.
      let placement = placement(of: collision, along: otherSprite)
      let deflectionAngle = placement * (.pi / 6)
      normal.rotate(by: deflectionAngle)
    }

    activeGame.ballVelocity.reflect(along: normal)
  }
}

It calls a moveWithCollisions method to move the ball, iterating through a collection of objects the ball bounced off of while moving.

Swift Break features a splash screen, a pause menu, paddle-location-based bounce physics, infinite levels, a game over screen, and allows you to control the paddle with either the D-Pad or the Crank!

Try it Out

If you’re eager to use Swift on your Playdate, the swift-playdate-examples repository has you covered. It contains the above ready-to-use examples that demonstrate how to build Swift games for the Playdate, both for the simulator and the hardware.

Additionally, the repository includes detailed documentation to guide you through the setup process. Whether you’re a seasoned developer or just starting, you’ll find the necessary resources to bring your ideas to life.

But if you’re up for a deep dive into the technical details of what it takes to bring Swift to a new platform, read on!

Deep Dive: Bringing Swift to the Playdate

Bringing up a new platform is always fraught with challenges and infuriating bugs. Everything is broken with numerous false starts, until you clear the last bug, and then it all comes together. Getting Swift games running on the Playdate was no different.

My general approach was to leverage Swift’s interoperability to build on top of the Playdate C SDK. The good news is that the Swift toolchain already had all the features I needed to get this working. I just had to figure out how to put them together. Here’s an overview of the path I took:

Building object files for the Playdate Simulator
Importing the Playdate C API
Running on the Simulator
Running on the Hardware
Improving the API with Swift
Completing Swift Break

Without further ado, let’s get started.

Building object files for the Playdate Simulator

Note: The commands mentioned below were run with a Swift nightly toolchain installed and have the TOOLCHAINS environment variable set to the name of the toolchain.

My first step was compiling an object file for the Playdate Simulator. The simulator works by dynamically loading host libraries, so I needed to build the object files for the host’s platform and architecture (the so-called triple in compiler-speak), which swiftc does by default. The only additional flags I needed were for enabling embedded Swift and code optimizations.

$ cat test.swift
let value = 1

$ mkdir build

$ swiftc -c test.swift -o build/test.o \
    -Osize -wmo -enable-experimental-feature Embedded

$ file build/test.o
test.o: Mach-O 64-bit object arm64

Importing the Playdate C API

The next step was compiling against the Playdate C API from Swift. This was straightforward due to the structure of the Playdate C header files and Swift’s native support for interoperating with C.

I started by locating the Playdate C header files:

$ ls $HOME/Developer/PlaydateSDK/C_API/
Examples     buildsupport pd_api       pd_api.h

$ ls $HOME/Developer/PlaydateSDK/C_API/pd_api
pd_api_display.h     pd_api_gfx.h         pd_api_lua.h         pd_api_sound.h       pd_api_sys.h
pd_api_file.h        pd_api_json.h        pd_api_scoreboards.h pd_api_sprite.h

And used an “include search path” (-I) to tell the Swift compiler’s C interoperability feature where to find them. I additionally needed to pass a “define” (-D) to tell the compiler how to parse the header files:

$ swiftc ... -Xcc -I -Xcc $HOME/Developer/PlaydateSDK/C_API/ -Xcc -DTARGET_EXTENSION

Next, I created a module map file to wrap the headers into an importable module from Swift:

$ cat $HOME/Developer/PlaydateSDK/C_API/module.modulemap
module CPlaydate [system] {
  umbrella header "pd_api.h"
  export *
}

And used an “import search path” (-I) to tell the Swift compiler where to find the CPlaydate module:

$ swiftc ... -I $HOME/Developer/PlaydateSDK/C_API/

Lastly, I made a minimal “library” using the Playdate C API from Swift and compiled using the flags above:

$ cat test.swift
import CPlaydate
let pd: UnsafePointer<PlaydateAPI>? = nil

$ mkdir build

$ swiftc \
    -c test.swift \
    -o build/test.o \
    -Osize -wmo -enable-experimental-feature Embedded \
    -Xcc -I -Xcc $HOME/Developer/PlaydateSDK/C_API/ \
    -Xcc -DTARGET_EXTENSION \
    -I $HOME/Developer/PlaydateSDK/C_API/

$ file build/test.o
test.o: Mach-O 64-bit object arm64

Running on the Simulator

Once I was able to use the Playdate C API from Swift, I ported the Conway’s Game of Life example included in the Playdate SDK to Swift, referencing Inside Playdate with C frequently to familiarize myself with the API.

The C implementation of Conway’s strictly operates on Playdate OS-vended frame buffers and uses the display as game state, removing the need for separate data structures and dynamic allocations. As a result, the porting process was very mechanical because the bit manipulation and pointer operations in the C example have direct Swift analogs:

static inline int val(uint8_t* row, int x) {
    return 1 - ((row[x/8] >> (7 - (x%8))) & 1);
}

static inline int ison(uint8_t* row, int x) {
    return !(row[x/8] & (0x80 >> (x%8)));
}

struct Row {
  var buffer: UnsafeMutablePointer<UInt8>

  func value(at column: Int32) -> UInt8 {
    isOn(at: column) ? 1 : 0
  }

  func isOn(at column: Int32) -> Bool {
    let byte = buffer[Int(column / 8)]
    let bitPosition = 0x80 >> (column % 8)
    return (byte & bitPosition) == 0
  }
}

I built the source into a dynamic library and used pdc (the Playdate compiler) to wrap the final dylib into a pdx (Playdate executable).

$ swiftc \
    -emit-library test.swift \
    -o build/pdex.dylib \
    ...

$ file build/pdex.dylib
pdex.dylib: Mach-O 64-bit dynamically linked shared library arm64

$ $HOME/Developer/PlaydateSDK/bin/pdc build Test

$ ls Test.pdx
pdex.dylib pdxinfo

I opened my game file Test.pdx using the Playdate simulator and as you might expect, it worked on the first try … just kidding, it crashed!

After some debugging, I realized the Makefile used to compile the C example included an additional file setup.c from the SDK containing the symbol _eventHandlerShim needed to bootstrap the game. If this symbol is not present in the binary, the Simulator falls back to bootstrapping the game using the symbol _eventHandler which my binary did contain, but meant my game skipped an important setup step.

So, I compiled setup.c into an object file using clang, linked it into my dynamic library, re-ran, and voila! I had Conway’s Game of Life written in Swift running on the Playdate Simulator.

Running on the Hardware

After successfully running on the simulator, I wanted to run the game on real hardware. A colleague graciously allowed me to borrow their Playdate and I began hacking away.

I started by matching the triple used by the C examples for the device and seeing what happened.

$ swiftc ... -target armv7em-none-none-eabi
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "pd_api.h"
         ^
$HOME/Developer/PlaydateSDK/C_API/pd_api.h:13:10: error: 'stdlib.h' file not found
#include <stdlib.h>
         ^

These errors did not previously occur because I was targeting the host machine and used the host headers for the C standard library. I considered using the same host headers for the target device, but didn’t want to debug platform incompatibilities. Little did I know, I would have to do this regardless.

Instead, I decided to follow the route used by the C example programs which leverage the libc headers from a gcc toolchain installed with the Playdate SDK. I copied the include paths used by the C examples and re-ran the compile.

$ mkdir build

$ GCC_LIB=/usr/local/playdate/gcc-arm-none-eabi-9-2019-q4-major/lib

$ swiftc \
    -c test.swift \
    -o build/test.o \
    -target armv7em-none-none-eabi \
    -Osize -wmo -enable-experimental-feature Embedded \
    -I $HOME/Developer/PlaydateSDK/C_API/ \
    -Xcc -DTARGET_EXTENSION \
    -Xcc -I -Xcc $HOME/Developer/PlaydateSDK/C_API/ \
    -Xcc -I -Xcc $GCC_LIB/gcc/arm-none-eabi/9.2.1/include \
    -Xcc -I -Xcc $GCC_LIB/gcc/arm-none-eabi/9.2.1/include-fixed \
    -Xcc -I -Xcc $GCC_LIB/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include

$ file build/test.o
test.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped

The compile succeeded and I had an object file for the real hardware. I went through similar steps to link and package the object file into a pdx, using clang as the linker driver.

I deployed the game onto a Playdate, and … it crashed.

For some reason, when the frame-update function pointer was called, the game would crash! Debugging this issue was confusing at first, but due to past experience deploying Swift onto a Cortex M7, I realized I likely had a calling convention mismatch. I added a compiler flag -Xfrontend -experimental-platform-c-calling-convention=arm_aapcs_vfp to try to match the calling convention used by the Playdate OS.

Once again, I deployed my game to the Playdate and … it actually worked! You can see the game in action below:

I then integrated my manual compilation steps into the Makefiles found in the Playdate SDK, going through a number of options before landing on the final solution found in swift-playdate-examples. The result of this effort was a single make command to build a pdx compatible with both the simulator and hardware!

Improving the API with Swift

After porting Conway’s Game of Life, I began a more ambitious project: a paddle-and-ball style game named Swift Break. However, I quickly encountered friction using the raw Playdate C API directly in Swift. In typical programming fashion, I took a detour to work on the API’s ergonomics instead of the game! At this point, I had also piqued the interest of some colleagues who contributed further improvements.

One hurdle was the naming conventions of the imported API. In C, enum cases are often prefixed with their type’s name to prevent programmers from inadvertently mixing unrelated enum instances and case constants. However, in Swift, such prefixes are unnecessary as the compiler type-checks comparisons to ensure the correct cases are used.

Fortunately, Swift already provides tools for addressing this precise issue, known as API notes. I added an API notes file to the Playdate SDK and renamed enum cases with more idiomatic Swift names:

// Before
if event == kEventPause { ... }

// After
if event == .pause { ... }

A bigger issue, however, was the lack of nullability annotations in the C API. This meant the generated code had redundant null checks everywhere, bloating code size and hurting performance. While I usually would have used API notes to add the missing annotations, this was not possible. The C API uses structs with function pointers as a “vtable”, and unfortunately, these are not currently modifiable with API notes. Due to this incompatibility, I had to adopt a suboptimal solution: pervasively using Optional.unsafelyUnwrapped throughout the Swift code.

Although this approach eliminated the null checks, it dramatically hurt readability:

// C API in Swift with redundant null checks
let spritePointer = playdate_api.pointee.sprite.pointee.newSprite()

// C API in Swift without redundant null checks
let spritePointer = playdate_api.unsafelyUnwrapped.pointee.sprite.unsafelyUnwrapped.pointee.newSprite.unsafelyUnwrapped()

To address the readability issues, I created a thin Swift overlay on top of the C API. I wrapped function pointer accesses into static and instance methods on Swift types and converted function get/set pairs to Swift properties. Creating a sprite became much more intuitive and introduced zero overhead on top of the equivalent imported C calls.

var sprite = Sprite(bitmapPath: "background.png")
sprite.collisionsEnabled = false
sprite.zIndex = 0
sprite.addSprite()

Colleagues further improved the overlay by abstracting Playdate APIs requiring manual memory management to be automatically handled. An excellent example is the C API’s moveWithCollisions function, which returns a buffer of SpriteCollisionInfo structs that must be freed by the caller. Using the overlay allowed us to avoid manually deallocating the buffer and made the API easier to use:

// moveWithCollisions without the overlay
var count: Int32 = 0
var actualX: Int32 = 0
var actualY: Int32 = 0
let collisionsStartAddress = playdate_api.pointee.sprite.pointee.moveWithCollisions(sprite, 10, 10, &actualX, &actualY, &count)
let collisions = UnsafeBufferPointer(start: collisionsStartAddress, count: count)
defer { collisions.deallocate() }
for collision in collisions { ... }

// moveWithCollisions with the overlay
sprite.moveWithCollisions(goalX: 10, goalY: 10) { actualX, actualY, collisions in
    for collision in collisions { ... }
}

These improvements dramatically streamlined writing code for the Playdate. Additionally, as Swift’s support for ownership and non-copyable types improves, I anticipate even more ergonomic representations of the C APIs without language overhead.

Completing Swift Break

Equipped with a refined Swift Playdate API, I returned to developing Swift Break.

I nailed down the basics pretty quickly, but couldn’t resist adding extra features just for the fun of it. One of the highlights was implementing basic logic to deflect ball bounces based on the location where the ball and paddle collide.

This feature required calculating a normal vector relative to a hypothetical curve representing a rounded paddle and then reflecting the ball’s velocity about the normal. Here’s a visualization of the intended behavior:

Note: Making the animation for this post ironically helped me root cause a bug in the bouncing logic. Under some combinations of entry angle and normal angle, the current design can cause the ball to bounce down into the paddle instead of up.

To turn the math into an algorithm, I had to perform the following steps:

Check if the object the ball collided with is the paddle
Compute the location of the collision along the paddle from -1 to +1
Map the location into a deflection angle from from -π/6 to +π/6
Rotate the collision normal vector by the deflection angle
Reflect the ball’s velocity along the rotated normal

I then directly translated this algorithm into code inside the ball collision callback:

if otherSprite.tag == .paddle {                                // 1
  let placement = placement(of: collision, along: otherSprite) // 2
  let deflectionAngle = placement * (.pi / 6)                  // 3
  normal.rotate(by: deflectionAngle)                           // 4
}
ballVelocity.reflect(along: normal)                            // 5

Running on the Hardware (Again!)

Throughout the development of “Swift Break,” I regularly deployed the game to the Playdate Simulator. However, the real challenge emerged when I decided to run the game on actual Playdate hardware. As usual, I loaded the game, and … yet again, it crashed, but this time a lot of things were going wrong.

To cut a long debugging story short, I found that the -Xfrontend flag mentioned earlier did not entirely resolve the calling convention issues. To address this, I needed to configure the compiler to match the CPU and floating-point ABI of the microcontroller in the Playdate. This aspect was overlooked when I was porting Conway’s Game of Life since I happened to both not pass structs by value and didn’t use floating-point operations.

The final and most confusing crash arose from a specific Playdate C API call returning an enum from the Playdate OS. After a thorough debugging process, e.g. using printf everywhere, I uncovered a discrepancy in the memory layout of the enum between the system built with gcc and the game built with swiftc. With further research I found the difference stemmed from gcc defaulting to -fshort-enums while swiftc via clang used -fno-short-enums for the armv7em-none-none-eabi triple.

I collected these new and removed flags into the following compile command:

$ swiftc \
    -c test.swift \
    -o build/test.o \
    -target armv7em-none-none-eabi \
    -Osize -wmo -enable-experimental-feature Embedded \
    -I $HOME/Developer/PlaydateSDK/C_API \
    -Xcc -D__FPU_USED=1 \
    -Xcc -DTARGET_EXTENSION \
    -Xcc -falign-functions=16 \
    -Xcc -fshort-enums \
    -Xcc -mcpu=cortex-m7 \
    -Xcc -mfloat-abi=hard \
    -Xcc -mfpu=fpv5-sp-d16 \
    -Xcc -mthumb \
    -Xcc -I -Xcc $HOME/Developer/PlaydateSDK/C_API/ \
    -Xcc -I -Xcc $GCC_LIB/gcc/arm-none-eabi/9.2.1/include \
    -Xcc -I -Xcc $GCC_LIB/gcc/arm-none-eabi/9.2.1/include-fixed \
    -Xcc -I -Xcc $GCC_LIB/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include \
    -Xfrontend -disable-stack-protector \
    -Xfrontend -experimental-platform-c-calling-convention=arm_aapcs_vfp \
    -Xfrontend -function-sections

With these adjustments, I attempted once more, and finally “Swift Break” successfully ran on the Playdate hardware! I’ve included a brief video showcasing the game below:

Wrapping Up

Thanks for diving into the bring-up journey with me. From refining the Swift Playdate API to tackling issues involving calling conventions, CPU configurations, and memory layout disparities, there was no shortage of challenges.

However, with the issues now resolved, creating Playdate games in Swift is a streamlined process. Just run make and enjoy a development experience with Swift that is both expressive and performant.

You can find all the code examples mentioned in this post in the swift-playdate-examples repository with accompanying “Getting Started” documentation.

I hope this post encourages you to explore the possibilities of using Swift in unconventional environments. Feel free to reach out with your experiences, questions, or game ideas on the Swift Forums!

Happy coding! 🎮

Iterate Over Parameter Packs in Swift 6.0

2024-03-07T06:30:00-04:00

Parameter packs, introduced in Swift 5.9, make it possible to write generics that abstract over the number of arguments. This eliminates the need to have overloaded copies of the same generic function for one argument, two arguments, three arguments, and so on. With Swift 6.0, pack iteration makes it easier than ever to work with parameter packs. This post will show you how to make the best use of pack iteration.

Parameter Packs Recap

First, let’s review parameter packs. Consider the following code:

let areEqual = (1, true, "hello") == (1, false, "hello")
print(areEqual)
// false

The above code simply compares two tuples. However, this code wouldn’t work if the tuples contained 7 elements!

The Swift standard library provided comparison operators for tuples up to only 6 elements for a long time:

func == (lhs: (), rhs: ()) -> Bool

func == <A, B>(lhs: (A, B), rhs: (A, B)) -> Bool where A: Equatable, B: Equatable

func == <A, B, C>(lhs: (A, B, C), rhs: (A, B, C)) -> Bool where A: Equatable, B: Equatable, C: Equatable

// and so on, up to 6-element tuples

In each of the generic functions above, every element of the input tuple has to have its type declared in the generic parameter list of the function. Thus, we need to add a new element to the generic parameter list any time we want to support a larger tuple size. Because of this, the artificial limit of 6-element tuples was imposed.

Parameter packs added the ability to abstract a function over a variable number of type parameters. This means that we can lift the 6-element limit using an == operator written like this:

func == <each Element: Equatable>(lhs: (repeat each Element), rhs: (repeat each Element)) -> Bool

Let’s break down the types we see in the above signature:

Note each Element in the list of generic parameters. The each keyword indicates that Element is a type parameter pack, meaning that it can accept any number of generic arguments. Just like with non-pack (scalar) generic parameters, we can declare a conformance requirement on the type parameter pack. In this case, we require each Element type to conform to the Equatable protocol.
This function takes in two tuples, lhs and rhs, as arguments. In both cases, the tuple’s element type is repeat each Element. This is called the pack expansion type, which consists of a repeat keyword followed by a repetition pattern, which has to contain a pack reference. In our case, the repetition pattern is each Element.
At the call site, the user provides value parameter packs for each tuple that will be substituted into their corresponding type parameter packs. At runtime, the repetition pattern will be repeated for each element in the substituted pack.

With the tuple equality operator implemented using parameter packs, let’s look at the call site again to understand these concepts better.

let areEqual = (1, true, "hello") == (1, false, "hello")
print(areEqual)
// false

The call to == substitutes the type pack {Int, Bool, String} for the Element type pack. Note that both lhs and rhs have the same type. Finally, the function == is called with value packs {1, true, "hello"} for the value pack of the lhs tuple and {1, false, "hello"} for the value pack of the rhs tuple.

Why Pack Iteration?

The example with the new signature of the tuple comparison operator looks great, but how do we actually use the values of the lhs and rhs tuples inside the body of the function? Feel free to take a moment to think about this.

It turns out that there is just no concise way of implementing the function prior to Swift 6.0. One solution involves creating a local function that compares a pair of elements from the two tuples, and then using pack expansion to call that function for every pair of elements, like this:

struct NotEqual: Error {}

func == <each Element: Equatable>(lhs: (repeat each Element), rhs: (repeat each Element)) -> Bool {
  // Local throwing function for operating over each element of a pack expansion.
  func isEqual<T: Equatable>(_ left: T, _ right: T) throws {
    if left == right {
      return
    }
    
    throw NotEqual()
  }

  // Do-catch statement for returning false as soon as two tuple elements are not equal.
  do {
    repeat try isEqual(each lhs, each rhs)
  } catch {
    return false
  }

  return true
}

The above code doesn’t look great, right? To simply check a condition for each pair of elements, we need to declare a local function isEqual, that just compares the given elements. However, this is not enough to make the function return early since the local isEqual function will still be called on every pair of elements in the parameter packs lhs and rhs when expanding them. Because of this, isEqual has to be marked throws and throw an error once a pair of mismatched elements is found. Then, we catch the error in a catch block to return false.

Introducing Pack Iteration

Swift 6.0 greatly simplifies this task with the introduction of pack iteration using the familiar for-in loop syntax.

More specifically, with pack iteration, the body of the == tuple comparison operator simplifies down to a simple for-in repeat loop:

func == <each Element: Equatable>(lhs: (repeat each Element), rhs: (repeat each Element)) -> Bool {

  for (left, right) in repeat (each lhs, each rhs) {
    guard left == right else { return false }
  }
  return true
}

In the above code, we are able to utilize the for-in loop capability to iterate over the tuples pairwise.

Note that when iterating over packs, we use the new for-in repeat syntax, followed by a value parameter pack that we are iterating over. At every iteration, the loop binds each element of the value parameter pack to a local variable. This means that in this case, the i^th element of lhs will be bound to a local variable left on the i^th iteration. In the body of the loop, you can use the local variable as you normally would. In our case, we compare each pair of elements and return false once we find a pair where left != right, using a familiar guard statement. And, of course, we no longer need to throw any errors as we had to before!

Using Pack Iteration

Let’s now explore more ways you can utilize pack iteration in your Swift code with some examples.

First, consider a situation where you need to write a function to check that all arrays in a given value parameter pack are empty:

func allEmpty<each T>(_ array: repeat [each T]) -> Bool {
  for a in repeat each array {
    guard a.isEmpty else { return false }
  }

  return true
}

The above function is generic over a type parameter pack each T and takes in a value parameter pack array, the type of which is declared using repeat [each T] pack expansion, where [each T] is the repetition pattern. At the call site, it is repeated for each element in the substituted pack, resulting in values expanding into a list of array literals.

On each iteration of the for-in repeat loop, an element of the value parameter pack array is bound to a local variable a. Note that with pack iteration, elements of the value pack are evaluated on demand, meaning that we are able to return out of the function early without examining all arrays of the value pack. In this case, we utilize the guard statement.

Here is how you might use the allEmpty function:

print(allEmpty(["One", "Two"], [1], [true, false], []))
// False

Now, let’s see an example of advanced usage of parameter packs that is greatly simplified by pack iteration. First, let’s declare the following protocol:

protocol ValueProducer {
  associatedtype Value: Codable
  func evaluate() -> Value
}

The above protocol ValueProducer requires the evaluate() method that’s return type is the associated type Value that conforms to Codable protocol.

Suppose you get a parameter pack of values of type Result<ValueProducer, Error>, and you need to iterate only over the success elements and call the evaluate() method on its value. Also, suppose you need to save the result of each call into an array. Pack iteration makes this task super easy!

func evaluateAll<each V: ValueProducer, each E: Error>(result: repeat Result<each V, each E>) -> [any Codable] {
  var evaluated: [any Codable] = []
  for case .success(let valueProducer) in repeat each result {
    evaluated.append(valueProducer.evaluate())
  }

  return evaluated
}

Let’s first note the signature of the evaluateAll function. In the generic parameter list, it declares two type parameter packs: each V: ValueProducer, and each E: Error. Every element of the pack each V has to conform to the protocol ValueProducer declared above, and every element of the pack each E has to conform to the Error protocol. The function takes in a single argument result with a pack expansion type repeat Result<each V, each E>. This means that the pattern Result<each V, each E> will be repeated for every element of packs each V and each E at runtime.

To implement the body of the function, we first initialize the evaluated array. Next, note how we can use the for case pattern to execute the loop’s body only for the success case of the Result enum. We can grab the valueProducer variable, which will contain a value of the ValueProducer type. We can now append the result of the call to the evaluate() method to our evaluated array, which we finally return.

Here’s how you might use this function:

struct IntProducer: ValueProducer {

  let contained: Int

  init(_ contained: Int) {
    self.contained = contained
  }

  func evaluate() -> Int {
    return self.contained
  }
}

struct BoolProducer: ValueProducer {

  let contained: Bool

  init(_ contained: Bool) {
    self.contained = contained
  }

  func evaluate() -> Bool {
    return self.contained
  }
}

struct SomeError: Error {}

print(evaluateAll(result:
                    Result<SomeValueProducer, SomeError>.success(SomeValueProducer(5)),
                    Result<SomeValueProducer, SomeError>.failure(SomeError()),
                    Result<BoolProducer, SomeError>.success(BoolProducer(true))))

// [5, true]

Summary

We are excited to bring pack iteration to Swift 6.0! As seen in this article, pack iteration makes interacting with value parameter packs significantly more straightforward, making such an advanced feature more accessible and intuitive to incorporate into your Swift code.

Swift 5.10 Released

2024-03-05T10:00:00-04:00

Swift was designed to be safe by default, preventing entire categories of programming mistakes at compile time. Sources of undefined behavior in C-based languages, such as using variables before they’re initialized or a use-after-free, are defined away in Swift.

An increasingly important source of undefined behavior is concurrent code that inadvertently accesses memory from one thread at the same time that another thread is writing to the same memory. This kind of unsafety is called a data race, and data races make concurrent programs exceptionally difficult to write correctly. Swift solves this problem through data isolation provided by actors and tasks, which guarantees mutually exclusive access to shared mutable state. Data isolation enforcement has been under active development since 2020 when the Swift concurrency roadmap was posted.

Swift 5.10 accomplishes full data isolation in the concurrency language model. This important milestone has taken years of active development over many releases. The concurrency model was introduced in Swift 5.5 including async/await, actors, and structured concurrency. Swift 5.7 introduced Sendable as the fundamental concept for thread-safe types whose values can be shared across arbitrary concurrent contexts without introducing a risk of data races. And now, in Swift 5.10, full data isolation is enforced at compile time in all areas of the language when the complete concurrency checking option is enabled.

Full data isolation in Swift 5.10 sets the stage for the next major release, Swift 6. The Swift 6.0 compiler will offer a new, opt-in Swift 6 language mode that will enforce full data isolation by default, and we will embark upon the transition to eliminate data races across all software written in Swift.

Swift 5.10 will produce data-race warnings in some circumstances where the code could be proven safe with additional compiler analysis. A major focus of language development for the Swift 6 release is improving the usability of strict concurrency checking by mitigating false positive concurrency errors in common code patterns that are proven to be safe.

Read on to learn about full data isolation in Swift 5.10, new unsafe opt-outs for actor isolation checking, and the remaining concurrency evolution ahead of Swift 6.

Data-race safety in Swift 5.10

Full data isolation

Swift 5.10 rounds out the data-race safety semantics in all corners of the language, and fixes numerous bugs in Sendable and actor isolation checking to strengthen the guarantees of complete concurrency checking. When building code with the compiler flag -strict-concurrency=complete, Swift 5.10 will diagnose the potential for data races at compile time except where an explicit unsafe opt-out, such as nonisolated(unsafe) or @unchecked Sendable, is used.

For example, in Swift 5.9, the following code fails an isolation assertion at runtime due to a @MainActor-isolated initializer being evaluated outside the actor, but it was not diagnosed under -strict-concurrency=complete:

@MainActor
class MyModel {
  private init() {
    MainActor.assertIsolated()
  }

  static let shared = MyModel()
}

func useShared() async {
  let model = MyModel.shared
}

await useShared()

The above code admits data races. MyModel.shared is a @MainActor-isolated static variable, which evaluates a @MainActor-isolated initial value upon first access. MyModel.shared is accessed synchronously from a nonisolated context inside the useShared() function, so the initial value is computed off the main actor. In Swift 5.10, compiling the code with -strict-concurrency=complete produces a warning that the access must be done asynchronously:

  warning: expression is 'async' but is not marked with 'await'
    let model = MyModel.shared
                ^~~~~~~~~~~~~~
                await

The possible fixes for resolving the data race are 1) access MyModel.shared asynchronously using await, 2) make MyModel.init and MyModel.shared both nonisolated and move the code that requires the main actor into a separate isolated method, or 3) isolate useShared() to @MainActor.

You can find more details about the changes and additions to the full data isolation programming model in the Swift 5.10 release notes.

Unsafe opt-outs

Unsafe opt-outs, such as @unchecked Sendable conformances, are important for communicating that code is safe from data-races when it cannot be proven automatically by the compiler. These tools are necessary in cases where synchronization is implemented in a way that the compiler cannot reason about, such as through OS-specific primitives or when working with thread-safe types implemented in C/C++/Objective-C. However, @unchecked Sendable conformances are difficult to use correctly, because they opt the entire type out of data-race safety checking. In many cases, only one specific property in a type needs the opt-out, while the rest of the implementation adheres to static concurrency safety.

Swift 5.10 introduces a new nonisolated(unsafe) keyword to opt out of actor isolation checking for stored properties and variables. nonisolated(unsafe) can be used on any form of storage, including stored properties, local variables, and global/static variables.

For example, global and static variables can be accessed from anywhere in your code, so they are required to either be immutable and Sendable, or isolated to a global actor:

import Dispatch

struct MyData {
  static let cacheQueue = DispatchQueue(...)
  // All access to 'globalCache' is guarded by 'cacheQueue'
  static var globalCache: [MyData] = []
}

When building the above code with -strict-concurrency=complete, the compiler emits a warning:

warning: static property 'globalCache' is not concurrency-safe because it is non-isolated global shared mutable state
  static var globalCache: [MyData] = []
             ^
note: isolate 'globalCache' to a global actor, or convert it to a 'let' constant and conform it to 'Sendable'

All uses of globalCache are guarded by cacheQueue.async { ... }, so this code is free of data races in practice. In this case, nonisolated(unsafe) can be applied to the static variable to silence the concurrency warning:

import Dispatch

struct MyData {
  static let cacheQueue = DispatchQueue(...)
  // All access to 'globalCache' is guarded by 'cacheQueue'
  nonisolated(unsafe) static var globalCache: [MyData] = []
}

nonisolated(unsafe) also eliminates the need for @unchecked Sendable wrapper types that are used only to pass specific instances of non-Sendable values across isolation boundaries when there is no potential for concurrent access:

// 'MutableData' is not 'Sendable'
class MutableData { ... }

func processData(_: MutableData) async { ... }

@MainActor func send() async {
  nonisolated(unsafe) let data = MutableData()
  await processData(data)
}

Note that without correct implementation of a synchronization mechanism to achieve data isolation, dynamic analysis from exclusivity enforcement or tools such as the Thread Sanitizer may still identify failures.

Language evolution ahead of Swift 6

The next release of Swift will be Swift 6. The complete concurrency model in Swift 5.10 is overly restrictive, and several Swift Evolution proposals are in active development to improve the usability of full data isolation by removing false postive data-race errors. This work includes lifting limitations on passing non-Sendable values across isolation boundaries when the compiler determines there is no potential for concurrent access, more effective Sendable inference for functions and key-paths, and more. You can find the set of proposals that will round out Swift 6 at Swift.org/swift-evolution.

Next Steps

Try out complete concurrency checking

You can help shape the transition to the Swift 6 language mode by trying out complete concurrency checking in your project and providing feedback on your experience.

If you find any remaining compiler bugs where complete concurrency checking does not diagnose a data race at compile time, please report an issue.

You can also provide feedback that helps improve the concurrency documentation, compiler error messages, and the upcoming Swift 6 migration guide. If you encounter a case where the compiler diagnoses a data-race warning that you don’t understand or you’re not sure how to resolve a given data-race warning, please start a discussion thread on the Swift forums using the concurrency tag.

Downloads

Official binaries for Swift 5.10 are available for download from Swift.org for macOS, Windows, and Linux.

Swift Evolution Appendix

The following language proposals were accepted through the Swift Evolution process and implemented in Swift 5.10:

SE-0327: On Actors and Initialization
SE-0383: Deprecate @UIApplicationMain and @NSApplicationMain
SE-0404: Allow Protocols to be Nested in Non-Generic Contexts
SE-0411: Isolated default value expressions
SE-0412: Strict concurrency for global variables

Swift joins Google Summer of Code 2024

2024-02-23T06:00:00-04:00

We’re happy to announce that Swift will once again be joining Google Summer of Code 2024!

Summer of Code is an annual program, organized by Google, which provides hands-on experience for newcomers contributing to open source projects. Participants usually are students, but do not have to be.

Swift has been participating in Summer of Code since 2018, and every year we’ve had successful projects, helping the Swift project among various aspects including the compiler, runtime, and general package and tooling ecosystem. If you’re curious, here are the two most recent project summaries for 2022 and 2023.

Many GSoC participants become part of the Swift community and keep contributing even as the program ends. This is the most exciting part for us: helping you become a part of the Swift community!

If you are eligible, and would like to contribute to Swift during this year’s GSoC, these are the steps to take:

Check out the existing project ideas page.
If a project excites you, proceed to the GSoC category on the Swift forums to discuss the project.
Once you are confident in your understanding of the project and how to approach it, write an official proposal and submit it to the GSoC website.

You can also come up with your own project ideas. To do so, you’ll need to start a discussion thread on the forums and pitch the idea similar to how the existing ideas are listed on the ideas page. Proposing new ideas is exciting, but more difficult as you’ll have to ensure the project gets a mentor willing to take it on.

The forums are also a great resource of past GSoC discussions and projects. You can also read the GSoC Contributor Guide to get a good grasp of what participating in the program entails.

Official proposal applications need to be sent through the Summer of Code website. Applications start on March 18, 2024, and end on April 2, 2024 at 18:00 UTC.

We look forward to working with you all again this year!

On-device ML research with MLX and Swift

2024-02-20T06:00:00-04:00

The Swift programming language has a lot of potential to be used for machine learning research because it combines the ease of use and high-level syntax of a language like Python with the speed of a compiled language like C++.

MLX is an array framework for machine learning research on Apple silicon. MLX is intended for research and not for production deployment of models in apps.

MLX Swift expands MLX to the Swift language, making experimentation on Apple silicon easier for ML researchers.

As part of this release we are including:

A comprehensive Swift API for MLX core
Higher level neural network and optimizers packages
An example of text generation with Mistral 7B
An example of MNIST training
A C API to MLX which acts as the bridge between Swift and the C++ core

We are releasing all of the above under a permissive MIT license.

This is a big step to enable ML researchers to experiment using Swift.

Motivation

MLX has several important features for machine learning research that few if any existing Swift libraries support. These include:

Native support for hardware acceleration. MLX can run compute intensive operations on the CPU or GPU.
Automatic differentiation for training neural networks and the gradient-based machine learning models

For more information on MLX see the documentation.

The Swift programming language is fast, easy-to-use, and works well on Apple silicon. With MLX Swift, you now have a researcher-friendly machine learning framework with the ability to easily experiment on different platforms and devices.

A Quick Tour

Getting set up with MLX Swift is quick and easy with Xcode or SwiftPM.

In MLX Swift, building and performing operations with N-dimensional arrays is simple. In the following example, all of the operations will be run on the default device, which is the GPU unless otherwise specified.

import MLX
import MLXRandom

let r = MLXRandom.normal([2])
print(r)
// array([-0.125875, 0.264235], dtype=float32)

let a = MLXArray(0 ..< 6, [3, 2])
print(a)
// array([[0, 1],
//        [2, 3],
//        [4, 5]], dtype=int32)

// last element of 0th row
print(a[0, -1])
// array(1, dtype=int32)

// slice of the first two rows        
print(a[0 ..< 2])
// array([[0, 1],
//        [2, 3]], dtype=int32)

// add with broadcast
let b = a + r

print(b)
// array([[-0.510713, 1.04633],
//        [1.48929, 3.04633],
//        [3.48929, 5.04633]], dtype=float32)

You can also use function transformations in MLX Swift. Function transformations in MLX are useful for training models with automatic differentiation as well as optimizing compute graphs for speed or memory use. Below is an example which computes the gradient of a function.

func fn(_ x: MLXArray) -> MLXArray {
    x.square()
}

let gradFn = grad(fn)

let x = MLXArray(1.5)
let dfdx = gradFn(x)

// prints 2 * 1.5 = 3
print(dfdx)

The documentation contains a few more complete examples to help you get started with MLX Swift:

Text generation with an LLM: A complete LLM text generation example with Mistral 7B. The example will generate text using any Mistral or Llama-style model including pre-quantized MLX models, many of which are available on Hugging Face.
Training an MLP on MNIST: The example trains a simple multi-layer perceptron to classify MNIST digits using the MLX Swift neural network and optimizers packages.

Further Resources

Here are a few more resources to get started with MLX Swift:

Swift documentation and examples
GitHub repository
We encourage you to file an issue if you encounter any problems or have suggestions for improvements.
We welcome contributions. If you are interested in contributing to MLX Swift, check out our contribution guidelines.

Swift Summer of Code 2023 Summary

2024-02-13T06:00:00-04:00

The Swift project regularly participates in Google Summer of Code in order to help people new to the open source ecosystem dip their toes in contributing to Swift and its growing ecosystem.

During the 2023 edition of the program, we ran three projects, all of which completed their assigned projects successfully.

The projects in this edition were:

Swift Memcache Library
Incremental Parsing in SwiftParser
Key Path Inference and Diagnostic Improvements

We’d like to extend our sincere thanks to the participants and mentors who poured their time and passion into these projects, and use this post to highlight their work to the wider community. Below, each project is described in a small summary.

Let’s take a look at each project, in the words of the mentees and mentors themselves:

Swift Memcache

Mentee: Delkhaz Ibrahimi
Mentor: Franz Busch

The goal of the project was to develop a native Memcached connection abstraction for the Swift on Server ecosystem. This connection was implemented using SwiftNIO, offers native Swift Concurrency APIs and integrates well with the rest of the server ecosystem. The benefit of using Swift Concurrency for building such client is that it can make use of structured concurrency which brings cancellation, executor awareness, and simple integration with distributed tracing in the future.

The focus during the project was implementing the Memcache meta command protocol and offering basic get and set functionalities.

Below is a short example how the new MemcacheConnection type can be used to set and get a value for a given key:

// Instantiate a new MemcacheConnection with host, port, and event loop group
let memcacheConnection = MemcacheConnection(host: "127.0.0.1", port: 11211, eventLoopGroup: .singleton)

// Initialize the service group
let serviceGroup = ServiceGroup(services: [memcacheConnection], logger: logger)

try await withThrowingTaskGroup(of: Void.self) { group in
    group.addTask { try await serviceGroup.run() }
    
    // Set a value for a key.
    let setValue = "bar"
    try await memcacheConnection.set("foo", value: setValue)
    
    // Get the value for a key.
    // Specify the expected type for the value returned from Memcache.
    let getValue = try await memcacheConnection.get("foo", as: String.self)
}

After finishing the foundational work to implement the get and set commands, support for delete, append, prepend, increment and decrement was added. Lastly, support for checking and updating the time-to-live for keys was added.

The new MemcacheConnection type lays the ground work to implement a higher-level MemcacheClient that offers additional functionality such as connection pooling, retries, key distribution across nodes and more. However, implementing such a client was out of scope for this year’s GSoC project.

If you’d like to learn more about this project and Delkhaz’s experience, see this thread on the Swift forums.

Implement Incremental Re-Parsing in SwiftParser

Mentee: Ziyang Huang
Mentor: Alex Hoppen

This project aimed to improve the performance of the SwiftParser for scenarios like editor syntax highlighting, where minor edits are applied to the file. By adding incremental parsing and re-using parts of the syntax tree that remain unchanged, large performance improvements can be made.

The most challenging part of this project was to make sure we parse the source files correctly. Considering the code snippet below:

foo() {}
someLabel: switch x {
    default: break
}

This source is parsed as a FunctionCallExprSyntax and a LabeledStmtSyntax. When we remove the “switch x” part of this code, a naïve implementation could reuse foo() {} as a function call since the edit didn’t touch it. But this is not correct since the someLabel block now became a labeled trailing closure of foo() {}.

To solve this problem, we collect some additional information for every syntax node during the initial parse to mark the potentially affected range for each node. That information is used to correctly re-parse the foo() function call and include someLabel as a labeled trailing closure in the call.

The implementation speeds up parsing by about 10x when we parse source incrementally while only incurring a 2~3% of performance loss during normal parsing.

If you’d like to read more about this project and Ziyang’s experience in his own words, head over to his GSoC experience post on the Swift forums.

Key Path Inference and Diagnostic Improvements

Mentee: Amritpan Kaur
Mentor: Pavel Yaskevich

This project was focused on performance and diagnostic improvements to type-checking of key path literal expressions as well as improvements to new features such as keypaths-as-functions introduced to the language by SE-0249.

During compilation, the key path expression root and value were type-checked sequentially to resolve a key path type from this context. However, the design of the type-checker’s evaluation of key path component types, their relationships to each other, and key path capabilities results in hard to understand compiler errors and even failures to type-check some valid Swift code.

Some of the problems with this approach can be illustrated by the following code example:

struct User {
  var name: Name
}
struct Name {
  let firstName: String
}

func test(_: WritableKeyPath<User, String>) {}

test(\.name.firstName)

The compiler produces the following error:

error: key path value type 'WritableKeyPath<User, String>' cannot be converted to contextual type 'KeyPath<User, String>'
test(\.name.firstName)
     ^

There are multiple issues with this error diagnostic: contextual type is actually WritableKeyPath and key path should be inferred as read-only, the source information is lost and the compiler is unenable to point out a problem with an argument to a call to the function test.

To address these and other issues, we explored a different design for key path literal expression type-checking: infer the root type of the key path first and propagate that information to the components and infer capability based on the components before setting the type for the key path expression. This made it a lot easier to diagnose contextual type failures and support previously failing conversions. This approach improves the performance as well because the literal is resolved only if the context expects a key path and root type is either provided by the developer explicitly or is able to be inferred from the context.

With the new approach implemented the compiler now produces the following diagnostic:

error: cannot convert value of type 'KeyPath<User, String>' to expected argument type 'WritableKeyPath<User, String>'
test(\.name.firstName)
     ^

If you’d like to learn more about the details of this project, we recommend having a look at this excellent and very detailed writeup written by Amritpan on the forums.

Mentee Impressions

It’s great to see what projects our GSoC participants accomplished this year! Even better though is seeing participants enjoy their time working with the Swift project, as a big part of Summer of Code is giving mentees (and mentors) a space to grow and learn about open source development.

Here are a few impressions of the mentees about their experience:

Delkhaz (Swift Memcache):

As we wrap up this technical update, it’s a bittersweet moment for me to share that my formal journey as a Google Summer of Code student has reached its conclusion, but what an incredible journey it’s been. This transformative experience has enriched my understanding of open source development and honed my skills as a developer. I want to extend a heartfelt thank you to everyone who has been a part of this adventure with me.

While this chapter may be closing, I’m thrilled to announce that I will remain actively involved in the project. I’m particularly excited about contributing toward taking this project to its v1 or production stage. So, this isn’t a goodbye; it’s just the beginning of a new chapter. Looking forward to staying in touch and continuing this journey with all of you.

Special thanks are in order for my mentor Franz, for his exceptional mentorship during my time in the program. His wisdom and insights in our weekly sessions have been nothing short of transformative for me as a developer. Whether it was navigating the complexities of open-source contributions or striving for the highest standards in our API development, Franz’s guidance has been indispensable. I’ve gained a multifaceted understanding of software development thanks to his continued support. I couldn’t have asked for a more impactful mentorship experience, and for that, I am deeply grateful.

Ziyang (Implement Incremental Re-Parsing in SwiftParser):

After measurement, our implementation speed up parsing about 10 times when we parse source incrementally while only bring 2~3% of performance loss to normal parsing. 🎉 🎉

I also bring this feature to sourcekit-lsp and swift-stress-tester, it is really exciting to see my work can be actually put into use.

Special thanks to my mentor Alex for the quick response, detailed reviews and inspiring ideas.

Amritpan (Key Path inference and diagnostic improvements):

I enjoyed working on this project this year, primarily because it was a challenge that allowed me to deepen my understanding of the solver implementation, utilize improvements I made last year to the debug output, and make more impactful changes to the compiler codebase.

Refactoring the debug output last year helped me understand how the various pieces of information that the type checker collected were then evaluated to assign types from context. Taking a look at key path expression type checking failures revealed some of the fallibilities of the constraint system and solver and how various design decision choices could solve certain issues while causing others.

We hope this writeup inspires you to either apply to work with us or become a mentor on the Swift project in a future!

We are always looking for ideas, mentors, and general input about how we can make Swift’s ecosystem more inclusive and easier to participate in. If you have some ideas, would like to become a mentor in future editions, or if you’re just curious about other project ideas that were floated during previous editions, visit the dedicated GSoC category on the Swift forums. You can also check out last year’s GSoC summary blog post, where we highlighted last year’s projects.

If you’re interested in participating as a mentee, keep an eye on the official GSoC schedule and on the Swift forum’s GSoC category.

Swift OpenAPI Generator 1.0 Released

2024-01-31T08:00:00-04:00

We’re happy to announce the stable 1.0 release of Swift OpenAPI Generator!

OpenAPI is an open standard for describing the behavior of HTTP services with a rich ecosystem of tooling. One thing OpenAPI is particularly known for is tooling to generate interactive documentation. But the core motivation of OpenAPI is code-generation, which allows adopters to use an API-first approach to server development and, because many existing services document their API in this format, allows client developers to generate type-safe, idiomatic code to call these APIs.

Many real-world APIs have hundreds of operations, each with rich request and response types, header fields, parameters, and more. Writing and maintaining this code for every operation can be repetitive, verbose, and error-prone.

Swift OpenAPI Generator is a Swift package plugin that generates the code required to make API calls and implement API servers. The code is automatically generated at build-time, so it’s always in sync with the OpenAPI document and doesn’t need to be committed to your source repository.

Since the initial release six months ago, the project received over 250 pull requests, from more than 20 contributors, and has gained several new features and a simpler API.

Feature Highlights

Works with OpenAPI Specification versions 3.0 and 3.1.
Streaming request and response bodies, backed by AsyncSequence, enabling use cases such as JSON event streams, and large payloads without buffering.
Support for common content types, including JSON, multipart, URL-encoded form, base64, plain text, and raw bytes; all represented as value types with type-safe properties.
Flexible client, server, and middleware abstractions, decoupling the generated code from the HTTP client library and web framework.

A Quick Look

Consider a fictitious HTTP server that provides a single API endpoint to return a personalized greeting:

% curl 'https://example.com/api/greet?name=Jane'
{
    "message": "Hello, Jane"
}

This service can be described using the following OpenAPI document:

openapi: '3.1.0'
info:
  title: GreetingService
  version: 1.0.0
servers:
  - url: https://example.com/api
    description: Example service deployment.
paths:
  /greet:
    get:
      operationId: getGreeting
      parameters:
        - name: name
          required: false
          in: query
          description: The name used in the returned greeting.
          schema:
            type: string
      responses:
        '200':
          description: A success response with a greeting.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Greeting'
components:
  schemas:
    Greeting:
      type: object
      description: A value with the greeting contents.
      properties:
        message:
          type: string
          description: The string representation of the greeting.
      required:
        - message

Swift OpenAPI Generator can be configured to generate:

Code to make type-safe requests to an API server with any HTTP client library.
Code to bootstrap an HTTP server with any web framework using business logic that is decoupled from the network requests.

Generated Client API

The generated code provides a type, named Client, which provides a method for each operation defined in the OpenAPI document and can be used with any HTTP library that provides an integration package for Swift OpenAPI Generator.

The plugin produces the generated code at build time in a location determined by the build system. To use the generated code in your project, simply create a Client by providing the server URL and HTTP transport you’d like to use.

The following example creates a Greeting Service client that uses URLSession to make the underlying HTTP requests.

import OpenAPIURLSession
import Foundation

let client = Client(
    serverURL: URL(string: "http://localhost:8080/api")!,
    transport: URLSessionTransport()
)
let response = try await client.getGreeting()
print(try response.ok.body.json.message)

Generated Server API Stubs

The generated code provides a Swift protocol, named APIProtocol, which defines a method requirement for each operation defined in the OpenAPI document, and is designed to work with any web framework that provides an integration package for Swift OpenAPI Generator.

To implement an API server, define a type that conforms to APIProtocol, providing just the business logic for each operation.

To start the API server, use the generated registerHandlers function to configure the HTTP server to route the HTTP requests to your handler.

The following example implements the Greeting Service API in a type named Handler and configures a Vapor web server to serve the HTTP requests.

import OpenAPIRuntime
import OpenAPIVapor
import Vapor

struct Handler: APIProtocol {
    func getGreeting(_ input: Operations.getGreeting.Input) async throws -> Operations.getGreeting.Output {
        let name = input.query.name ?? "Stranger"
        return .ok(.init(body: .json(.init(message: "Hello, \(name)!"))))
    }
}

@main struct Server {
    static func main() async throws {
        let app = Vapor.Application()
        let transport = VaporTransport(routesBuilder: app)
        let handler = Handler()
        try handler.registerHandlers(on: transport, serverURL: URL(string: "/api")!)
        try await app.execute()
    }
}

Package Ecosystem

The Swift OpenAPI Generator project is split across multiple repositories to enable extensibility and minimize dependencies in your project.

apple/swift-openapi-generator: Swift package plugin and CLI.
apple/swift-openapi-runtime: Runtime library used by the generated code.
apple/swift-openapi-urlsession: Client transport using URLSession.
swift-server/swift-openapi-async-http-client: Client transport using AsyncHTTPClient.
swift-server/swift-openapi-vapor: Server transport using Vapor web framework.
swift-server/swift-openapi-hummingbird: Server transport using Hummingbird web framework.

Next Steps

To get started, check out the documentation, which contains step-by-step tutorials.

You can also experiment with example projects that use Swift OpenAPI Generator and integrate with other packages in the ecosystem.

Or if you prefer to watch a video, check out Meet Swift OpenAPI Generator from WWDC23.

To ask a question, request a feature, or report a bug, reach out to us on Github 👋.

On-Crash Backtraces in Swift

2023-11-08T06:00:00-04:00

The new Swift 5.9 release contains a number of helpful, new features for debugging code, including an out-of-process, interactive crash handler to inspect crashes in real time, the ability to trigger the debugger for just-in-time debugging, along with concurrency-aware backtracing to make it easier to understand control flow in a program that uses structured concurrency.

Out-of-Process Crash Handling

Prior to Swift 5.9, all you would get when your program fails is a message from the parent process (often the shell) telling you that the child process crashed:

$ ./crash
I'm going to crash now
zsh: segmentation fault  ./crash

On Apple platforms or on Windows, you could look at the crash logs captured by the operating system’s built-in crash reporter, but on Linux that’s typically all you had to go on.

Now, instead of the opaque message above, the result looks something like this:

$ ./crash
I'm going to crash now

💣 Program crashed: Bad pointer dereference at 0x0000000000000004

Thread 0 crashed:

0 reallyCrashMe() + 404 in crash at /Users/alastair/Source/crashDotSwift/crash.swift:4:15

     2│   print("I'm going to crash now")
     3│   let ptr = UnsafeMutablePointer<Int>(bitPattern: 4)!
     4│   ptr.pointee = 42                                                    
      │               ▲
     5│ }
     6│

1 crashMe() + 12 in crash at /Users/alastair/Source/crashDotSwift/crash.swift:8:3

     6│ 
     7│ func crashMe() {
     8│   reallyCrashMe()                                                     
      │   ▲
     9│ }
    10│

2 main + 12 in crash at /Users/alastair/Source/crashDotSwift/crash.swift:11:1

     9│ }
    10│ 
    11│ crashMe()                                                             
      │ ▲
    12│

Press space to interact, D to debug, or any other key to quit (30s)

Or if you run the same program within a pipeline (not attached to a terminal), you’ll see a report like this:

*** Program crashed: Bad pointer dereference at 0x0000000000000004 ***

Thread 0 crashed:

0               0x00000001045a3df0 reallyCrashMe() + 404 in crash at /Users/alastair/Source/crashDotSwift/crash.swift:4:15
1 [ra]          0x00000001045a3ea4 crashMe() + 12 in crash at /Users/alastair/Source/crashDotSwift/crash.swift:8:3
2 [ra]          0x00000001045a3c50 main + 12 in crash at /Users/alastair/Source/crashDotSwift/crash.swift:11:1
3 [ra] [system] 0x000000018705d058 start + 2224 in dyld


Registers:

 x0 0x0000000000000001  1
 x1 0x0000000000000000  0
 x2 0x0000000000000000  0
 x3 0x000060000016c1c0  c0 c1 28 fd 79 96 00 00 fb 07 00 00 00 00 00 00  ÀÁ(ýy···û·······

...

x26 0x0000000000000000  0
x27 0x0000000000000000  0
x28 0x0000000000000000  0
 fp 0x000000016b85f310  20 f3 85 6b 01 00 00 00 a4 3e 5a 04 01 00 00 00   ó·k····¤>Z·····
 lr 0x72268001045a3d44  8225402511295135044
 sp 0x000000016b85f280  a0 f2 85 6b 01 00 00 00 00 00 00 00 00 00 00 00   ò·k············
 pc 0x00000001045a3df0  28 01 00 f9 fd 7b 49 a9 ff 83 02 91 c0 03 5f d6  (··ùý{I©ÿ···À·_Ö


Images (42 omitted):

0x00000001045a0000–0x00000001045a4000 6776aba03ad432b68bc57220ac4e6ef8 crash /Users/alastair/Source/crashDotSwift/crash
0x0000000187057000–0x00000001870ea874 ee3f4181cec538c2b8a84d310be33491 dyld  /usr/lib/dyld

This new feature greatly improves the on-crash debugging experience on Linux, where it is on by default. It is useful on macOS as well, but must be manually enabled. It is not presently supported on Windows.

Interactive Backtraces

You might be wondering about the message on the last line of the in-terminal backtrace above, where it says:

Press space to interact, D to debug, or any other key to quit (30s)

Often when developing a program at the terminal, you might find that the program crashes, but you aren’t able to reproduce the problem. Without a suitable crash log, that can be very frustrating — you know your program has a bug, but you don’t know what it was or how to reproduce it.

The idea behind this feature is that it leaves the program suspended (by default for 30 seconds, but this is configurable) and provides you with the opportunity to either attach a debugger, or perform some additional inspection of the crashed process.

If you tap the spacebar when this prompt appears, you will be presented with a simple command prompt that allows you to change the backtracer settings, generate a new backtrace, list loaded images, display register and memory contents, and get a listing of all of the threads in the process. Typing help at the prompt will bring up a list of available commands:

>>> help
Available commands:

backtrace  Display a backtrace.
bt         Synonym for backtrace.
debug      Attach the debugger.
exit       Exit interaction, allowing program to crash normally.
help       Display help.
images     List images loaded by the program.
mem        Synonym for memory.
memory     Inspect memory.
process    Show information about the process.
quit       Synonym for exit.
reg        Synonym for registers.
registers  Display the registers.
set        Set or show options.
thread     Show or set the current thread.
threads    Synonym for process.

If you use the debug command or press D at the prompt, the backtracer will help you to attach a debugger to your program. Exactly what happens here is platform-dependent.

If you press any other key, or if the 30 second timer runs down, the program will be allowed to crash normally.

By default, the interactive feature will trigger if your program’s standard input and output are both attached to a terminal. In many cases, this means you’ll get the right behavior automatically if you’re running in a CI system or as part of an automated script, as those tend to run with the program’s output redirected to a pipe or a file.

In situations where you do not want this feature enabled, you can explicitly disable it by setting the environment variable SWIFT_BACKTRACE to interactive=no. You can also disable the color output with color=no, as well as combine multiple options like interactive=no,color=no.

Structured Concurrency Support

The backtracer is concurrency-aware and will correctly step back through asynchronous frames. For example, given the program:

func level(n: Int) async {
  if n < 5 {
    await level(n: n + 1)
  } else {
    let ptr = UnsafeMutablePointer<Int>(bitPattern: 4)!
    ptr.pointee = 42
  }
}

@main
struct CrashAsync {
  static func main() async {
    await level(n: 1)
  }
}

the backtrace will look like:

$ ./crashAsync

💣 Program crashed: Bad pointer dereference at 0x0000000000000004

Thread 1 crashed:

0 level(n:) + 308 in crashAsync at /Users/alastair/Source/crashDotSwift/crashAsync.swift:6:17

     4│   } else {
     5│     let ptr = UnsafeMutablePointer<Int>(bitPattern: 4)!
     6│     ptr.pointee = 42                                                  
      │                 ▲
     7│   }
     8│ }

1 level(n:) in crashAsync at /Users/alastair/Source/crashDotSwift/crashAsync.swift:3

     1│ func level(n: Int) async {
     2│   if n < 5 {
     3│     await level(n: n + 1)                                             
      │     ▲
     4│   } else {
     5│     let ptr = UnsafeMutablePointer<Int>(bitPattern: 4)!

2 level(n:) in crashAsync at /Users/alastair/Source/crashDotSwift/crashAsync.swift:3
3 level(n:) in crashAsync at /Users/alastair/Source/crashDotSwift/crashAsync.swift:3
4 level(n:) in crashAsync at /Users/alastair/Source/crashDotSwift/crashAsync.swift:3
5 static CrashAsync.main() in crashAsync at /Users/alastair/Source/crashDotSwift/crashAsync.swift:13

    11│ struct CrashAsync {
    12│   static func main() async {
    13│     await level(n: 1)                                                 
      │     ▲
    14│   }
    15│ }

Press space to interact, D to debug, or any other key to quit (30s)

On Apple platforms, this feature has no special requirements, but for other platforms the backtracer needs to be able to look up symbols to determine whether or not a given frame is asynchronous. If the necessary symbols are not available, the backtrace will follow the normal program stack rather than the async activation chain. This will usually result in it showing frames from the concurrency runtime, which are unlikely to be helpful when debugging most types of problem.

Improving Readability

The new backtracer also has a number of options to improve readability.

You can configure the maximum number of frames that the backtracer will generate (the default is 64), but since you might also want to see frames at the top of the stack, the backtracer also has a setting for the number of frames to capture there (by default 16). This is particularly handy if your program crashes due to excessive recursion, as you’ll usually see both the recursion and the cause of it, without being overwhelmed by thousands and thousands of frames.

The backtracer also skips over system frames and Swift thunks by default. These are usually not relevant except to compiler or runtime engineers, and generally result in more confusing output for most developers.

Additionally, the backtracer will automatically demangle both Swift and C++ mangled names.

Summary

The new on-crash debugging options in Swift 5.9 help you debug your programs when they misbehave. The backtracer has a number of helpful features including:

Out-of-process crash handling
Smart, in-line display of program source, where available
The option to pause and inspect your crashed program, or even trigger the debugger for just-in-time debugging
Support for Swift Concurrency
Support for C++ name mangling in addition to Swift
Colorized output for readability
Expanded configuration options (see documentation).

The new feature is enabled by default on Linux and can be enabled for macOS (see documentation). There is no Windows support at present.

Introducing Packages on Swift.org

2023-11-01T06:30:00-04:00

Today, Swift.org gains a useful, new top-level Packages page.

The page provides a streamlined entry to exploring the Swift package ecosystem. It has common categories like server, networking, testing, and logging, as well as categories of interest like packages containing macros. When you select a category, it provides a sample of some widely-used packages for that category, with information to help you explore further. It’s a great way to get a sense of the variety of packages available for Swift.

The package lists give you relevant information at a glance.

The package lists are powered by the Swift Package Index, thanks to the sponsorship and support of Apple.

Community Showcase

In addition to finding common categories of packages, you can also browse new and interesting work from across the Swift package ecosystem with the Community Showcase.

The Community Showcase contains a rotating selection of packages being discussed by the Swift community. Anyone can nominate a package in this forum thread, and nominations will be reviewed monthly by the Swift Website Workgroup.

The new Packages page is an exciting step in growing a valuable and thriving package ecosystem for the benefit of all Swift developers.

Swift Everywhere: Using Interoperability to Build on Windows

2023-10-13T06:00:00-04:00

This post was originally published at Speaking in Swift by The Browser Company under the title “Interoperability: Swift’s Super Power”.

Swift’s deliberate design choices over the years has resulted in a language that showcases how flexibility and compatibility does not need to come at the cost of usability. One of these design choices was Swift’s focus on native interoperability with other languages. The flexibility that this enables makes it a joy to build rich, native experiences in Swift across a variety of environments.

Traditionally when two languages need to interoperate, the function calls at the boundary between the two languages, also known as the Foreign Function Interface (FFI), will go through C using a library like libffi. This approach has some drawbacks such as incurred runtime performance costs and possibly extra boilerplate code. Instead, Swift embeds a copy of clang, the C and C++ compiler, which is able to directly translate between the languages avoiding penalties in code size and runtime performance. This level of interoperability composes wonderfully with existing systems and enables building complex software atop existing C libraries.

The Windows API

When building native rich, native applications, one important use-case of interoperability is the ability to invoke platform-specific APIs. The Windows API surface reflects its extensive history; the requirement to maintain backwards compatibility has resulted in the accretion of APIs of different shapes. As such, a significant portion of the API is old and low-level enough to be defined in C.

Since Swift uses clang rather than libffi to access C functions and data types, the Swift compiler uses a feature of clang known as (header) modules. Clang modules bundle a set of declarations together, identifying which declarations belong to a particular library, what other modules it may depend on, and what language the declarations are for. This is done by introducing an auxiliary file named module.modulemap which contains the definition of the module.

As such, to access the Windows APIs, we must modularize the Windows SDK into one or more clang modules. Fortunately this is not just a theoretical idea. The Swift toolchain contains a module definition for the Windows SDK in the form of the WinSDK clang module. To further refine these definitions, a Swift module overlays the clang definitions to provide more Swift friendly definitions in some cases. This exposes the C API surface area of the Windows SDK, and although does not contain all the more modern APIs, enables us to build a variety of command line and GUI apps on Windows.

A GUI application using Swift/Win32, which provides a layer of Swift syntactic conveniences for older, C-based Windows UI APIs.

Modern APIs aren’t exposed using just C, however, and there are large portions of the Windows SDK which are exposed as C++. Realising there is a vast software ecosystem of C++ code that Swift developers may want access to, Swift 5.9 has introduced support for extending its language level interoperability to C++. Although virtual methods and copyable types are not yet available, as Swift’s C++ interoperability matures, the native platform API surface available to Swift will also grow to include the majority of the C++ APIs in the Windows SDK.

This C++ Interop enables a new set of libraries, beyond just the platform APIs, to become available to Swift. This allows Swift code to also take advantage of a variety of high-performance, cross-platform libraries written over decades by the C++ community. Firebase, for example, is a commonly used cloud computing service and is used in many modern products, including The Browser Company’s browser, Arc. Although there is a Swift SDK for Firebase, it is limited to the Apple platforms and is based on Objective-C. However, there is also a cross-platform C++ SDK available. Now with C++ Interop, it is possible to expose this C++ SDK to Swift clients. Such a bridge is being built up with swift-firebase. Taking advantage of these C++ libraries cross-platform Swift software that would be difficult to build otherwise.

Component Object Model (COM)

While libraries are one mechanism for sharing code, they are not the only approach. Another style of code sharing is possible via inter-process communication (IPC), which allows two separate applications to communicate with each other and expose functionality to each other. One implementation of this technique that is prevalent on Windows is known as COM (Component Object Model).

Microsoft explored this idea at a higher level in 1990, evolving DDE (Dynamic Data Exchange) into “Object Linking and Embedding” or OLE. The approach was to enable sharing of custom document handlers which could be embedded into new applications without having to rewrite parsers and renders for the formats. To share the implementation of applications across processes, an application could implement well-defined interfaces (e.g. IOleObject) that could be consumed by other processes. Eventually, OLE would evolve into what would become to be known as the Component Object Model, or COM.

COM’s design was flexible and powerful, and resulted in it being adopted as a common design pattern across a multitude of environments. CoreFoundation adopted it for its plugin model. CFLite, and various forks thereof, brought an implementation of COM to Linux. XPCOM (Cross-Platform Component Object Model) is similar to COM and would gain popularity through Mozilla’s extensive usage, as would Open Office’s UNO technology. The model even found its way into driver development with the IOKit framework using a COM based model for kernel drivers.

At COM’s core is the idea of defining interfaces (which is normally done in the Interface Definition Language or IDL) that expose functionality to either through a library in the same address space or another process through IPC. Interfaces are identified by globally unique Interface IDs, and all inherit from a base interface called IUnknown. IUnknown exposes the two fundamental operations of COM:

object lifetime management
access to the object’s functionality

Similar to Swift, object lifetime management is implemented through reference counting, exposed in COM via the AddRef and Release methods. Access to the object’s functionality is implemented via the QueryInterface method, allowing consumers to dynamically request for the object’s functionality. Because consumers dynamically query for a specific COM interface, we cannot statically identify the operations at build time. But the cost is limited to a couple of pointer indirections, similar to C++’s virtual methods, which gives COM a negligible performance overhead.

COM Support in Swift with C Interop

COM provides not only an interface for working with software dynamically but is also an Application Binary Interface, or ABI, which means it defines how parameters are passed and function calls are arranged. If we want to communicate with COM interfaces from Swift, we need to ensure that we conform to these ABI requirements. Given that the lingua franca for FFI is C, the ABI for COM can be expressed in C. So, as a first step, what does IUnknown look like in C?

typedef struct IUnknownVtbl {
  ULONG (STDMETHODCALLTYPE *AddRef)(IUnknown *pUnk);
  ULONG (STDMETHODCALLTYPE *Release)(IUnknown *pUnk);
  HRESULT (STDMETHODCALLTYPE *QueryInterface)(IUnknown *pUnk, REFIID riid, void **ppvObject);
} IUnknownVtbl;

struct IUnknown {
    const struct IUnknownVtbl *lpVtbl;
} IUnknown;

If we were to describe this in Swift, we would expect this to be a protocol with a few constraints:

// typealias IID = WinSDK._GUID

public typealias REFIID = UnsafePointer<IID>

public protocol IUnknown: class {
  class var IID: IID { get }

  func AddRef() -> ULONG
  func Release() -> ULONG
  func QueryInterface(_ riid: REFIID, _ ppvObject: UnsafeMutablePointer<UnsafeMutableRawPointer?>?) -> HRESULT
}

extension IUnknown {
  func QueryInterface<Interface: IUnknown>() throws -> Interface? { … }
}

The : class on the protocol declaration adds a class-constraint on the protocol, indicating that any conforming type must be a class in Swift. The astute reader would spot the semantic parallels between IUnknown and class-constrained types in Swift. class types in Swift employ reference counting through ARC, and COM does the same through MRC (manual reference counting), which explains the AddRef and Release methods. That leaves the QueryInterface method which is responsible for dynamically querying the COM Interface, which maps to Swift’s casting operation. As it is not possible to provide a custom cast operation for a type in Swift, the QueryInterface() method is a funny spelling for the as keyword. This shows that, conceptually, IUnknown is just another way to say “I have a class type in Swift that is implemented somewhere else”!

Since COM concepts bridge so neatly to Swift, we can now build a bridge between COM and Swift. The associated code is available at Swift/COM and demonstrates the viability of interfacing with COM interfaces. As an example, Windows provides 3D acceleration through the DirectX APIs, which are exposed as a set of C++ and COM interfaces. DXSample uses the COM bridged interfaces to implement a 3D accelerated cube replete with shaders to demonstrate that this bridging is possible to accomplish and use in real world scenarios.

Interfaces provide a definition of how you interact with some foreign type, one that may even be implemented in a different language. When using an interface implemented by someone else, such as a DirectX type, we receive a raw pointer to IUnknown. The raw pointer representation of the COM interface is cumbersome to use. Wrapping the pointer to abstract the indirection makes COM more approachable.

open class ID3D12Object: IUnknown {
  public override class var IID: IID { IID_ID3D12Object }

  public func SetName(_ Name: String) throws {
    _ = try perform(as: WinSDK.ID3D12Object.self) { pThis in
      try CHECKED(pThis.pointee.lpVtbl.pointee.SetName(pThis, $0))
    }
  }
  …
}

It is also possible to implement a COM interface in Swift, providing a Swift implementation that can be called from C/C++ code even, although this support is nascent and will evolve with Swift’s C++ interoperability support. As COM has a strict ABI, once the object is constructed properly, it can easily be passed across the language boundary and, as such, a Swift type can easily be passed to any COM client.

COM Support in Swift with C++ Interop

The evolving C++ interop in Swift makes bridging COM to Swift simpler. The interface model in COM is very similar to classes in C++. A COM interface maps directly to a C++ class, and each function on a COM interface maps to a virtual method on the C++ type. For Windows APIs exposed as COM types, such as the DirectX APIs, the COM interfaces are primarily exposed as C++ classes with some optionality to get a C representation of the interface for bridging into other languages. As Swift’s C++ interoperability support improves, it will be possible to import COM interfaces as C++ classes which bridge naturally to Swift types. This reduces the boilerplate we saw above when bridging to COM through C. As of this writing, Swift’s C++ interop support for virtual method dispatch is under development and will soon be able to simplify COM access.

Swift’s work on C++ interoperability has helped our efforts to bridge Swift with COM in other ways as well, adding support for reference-counted foreign types in Swift with the SWIFT_SHARED_REFERENCE annotation. Because COM provides a reference counted interface, we can attribute COM interfaces with SWIFT_SHARED_REFERENCE to take advantage of ARC while importing types and get memory management for free, avoiding a class of memory safety issues.

Improving Swift Language Support for COM

Due to the current limitations with C++ interop, we must fallback to the common denominator for interop - C - when trying to bridge COM interfaces. When implementing wrapper types to work with COM interfaces, we notice that it requires a significant amount of boilerplate code. One of Swift’s goals is to have clear, expressive code and this certainly takes away from that. An idea that merits a proper evolution proposal is extending the Swift language to support COM better through annotations. Imagine being able to declare a type as being accessible to COM by simply annotating it with an attribute as the follows:

@COM(IID: IID_ICustomInterface, CLSID: CLSID_CustomInterface)
open class CCustomInterface: ICustomInterface {
  override open func QueryInterface<Interface: IUnknown>() throws -> Interface? {
    switch riid.pointee {
    case IID_ICustomInterface, IID_IUnknown:
      return Unmanaged<Self>.passRetained(self)
    default:
      return nil
    }
  }
  …
}

Swift macros could help alleviate some of this boilerplate, but in order to truly bridge the Swift type into COM, the object layout needs to be considered. Because COM is an ABI, how the object is represented in memory must be identical to that dictated by COM. Controlling the object layout impacts ABI and is not something that would be possible with macros alone. One way we could implement this COM attribute at the language level would be to add a tear-off entry to the object that would conform to the ABI requirements for COM as part of the Swift object layout (with an opt-in) enabling more transparent bridging to the system without having to manually re-construct the vtable.

Swift’s ongoing distributed actors work also aligns well with COM. Distributed COM (DCOM) allows for network transparency with COM objects and enables building robust distributed systems. Distributed actors do not mandate the wire format, which means that we could even re-use the standard wire protocol for DCOM (DCE/RPC). This would allow for native Swift applications on Windows to easily scale from command line applications to large scale distributed systems.

Interoperability on Windows

Swift’s arsenal of interoperability tools makes it a potent language for building rich, native applications and libraries on existing platforms, and provides a great alternative to C and C++ with its improved memory safety and ergonomics. On Windows particularly, the interoperability features allow us to gain access to a very large set of the system’s API. Best of all, since COM is used outside of the Windows ecosystem, improvements to Swift’s integration with Windows system APIs, such as the native COM bridging described above, would also help other platforms! New features such as C++ Interoperability, macros, and distributed actors are opening up a whole new set of opportunities for applications to be written in a more portable fashion.

This foray into Windows and our exploration of Swift’s approach to interoperability has given us a good foundation on how Swift’s interoperability tools allow us to build cross-platform applications that can access platform APIs.

Debugging Improvements in Swift 5.9

2023-09-28T07:00:00-04:00

Swift 5.9 introduced a number of new debugging features to the compiler and LLDB debugger.

Here are three changes that can help with your everyday debugging workflows.

Faster variable inspection with `p` and `po` p and `po` section" href="#faster-variable-inspection-with-p-and-po">

LLDB provides the shorthand p command alias to inspect variables and po to call the debugDescription property of objects. Originally, these were aliases for the rather heavyweight expression and expression -O commands. In Swift 5.9, the p and po command aliases have been redefined to the new dwim-print command.

The dwim-print command prints values using the most user-friendly implementation. “DWIM” is an acronym for “Do What I Mean”. Specifically, when printing variables, dwim-print will use the same implementation as frame variable or v instead of the more expensive expression evaluator.

In addition to being faster, using p no longer creates persistent result variables like $R0, which are often unused in debugging sessions. Persistent result variables not only incur overhead but also retain any objects they contain, which can be an unexpected side effect for the program execution.

Users who want persistent results on occasion can use expression (or a unique prefix such as expr) directly instead of p. If you wish to enable persistent results every time, you can take advantage of LLDB’s handy alias feature and put the following into the ~/.lldbinit file:

command unalias p
command alias p dwim-print --persistent-result on --

The dwim-print command also gives po new functionality. The po command can now print Swift objects even when only given a raw address. When running po <object-address>, LLDB’s embedded Swift compiler will automatically evaluate the expression unsafeBitCast(<object-address>, to: AnyObject.self) under the hood to produce the expected result.

Before Swift 5.9:

(lldb) po 0x00006000025c43d0
(Int) 105553155867600

With Swift 5.9:

(lldb) po 0x00006000025c43d0
<MyApp.AppDelegate: 0x6000025c43d0>

Support for generic type parameters in expressions

LLDB now supports referring to generic type parameters in expression evaluation. For example, given the following code:

func use<T>(_ t: T) {
    print(t) // break here
}

use(5)
use("Hello!")

Running po T.self, when stopped in use, will print Int when coming in through the first call, and String in the second.

In addition to displaying the concrete type of the generic, you can use this to set conditions that look for concrete types. For example, if you add the condition T.self == String.self to the above breakpoint, use will only stop when the variable t is a String. (Note this last example only works on nightly builds of the Swift 5.9 toolchain.)

More details about the implementation of this feature can be found in the original LLDB pull request.

Fine-grained scope information

The Swift compiler now emits more precise lexical scopes in debug information, allowing the debugger to better distinguish between different variables, like the many variables named x in the following example:

func f(x: AnyObject?) {
  // function parameter `x: AnyObject?`
  guard let x else {}
  // local variable `x: AnyObject`, which shadows the function argument `x`
  ...
}

In Swift 5.9, the compiler now uses more accurate ASTScope information to generate the lexical scope hierarchy in the debug information, which results in some behavior changes in the debugger.

In the example below, the local variable a is not yet in scope at the call site of getInt() and will only be available after it has been assigned. With the debug information produced by previous versions of the Swift compiler, the debugger might have displayed uninitialized memory as the contents of a at the call site of getInt(). In Swift 5.9, the variable a only becomes visible after it has been initialized:

  1 func getInt() -> Int { return 42 }
  2
  3 func f() {
  4     let a = getInt()
                ^
  5     print(a)
  6 }

(lldb) p a
error: <EXPR>:3:1: error: cannot find 'a' in scope

(lldb) n
  3 func f() {
  4     let a = getInt()
  5     print(a)
        ^
  6 }

(lldb) p a
42

For more details, see the pull request that introduced this change.

Get involved

If you want to learn more about Swift debugging and LLDB, provide feedback, or contribute to the tooling itself, join us in the LLDB section of the Swift development forums.

Swift 5.9 Released

2023-09-18T07:00:00-04:00

Swift 5.9 is now available! 🎉

This is a major new release that adds an expressive macro system to the language and introduces support for integrating Swift into C++ codebases through bidirectional interoperability.

It also introduces parameter packs, an improved expression evaluator while debugging, enhanced crash handling, Windows platform improvements, and more.

Read on for a deep dive into changes to the language, standard library, tooling, platform support, and next steps for getting started with Swift 5.9.

Thank you to everyone in the Swift community who made this release possible. Your Swift Forums discussions, bug reports, pull requests, educational content, and other contributions are always appreciated!

Language and Standard Library

Swift’s fundamental goal is to encourage code that is clear and concise, while remaining safe and efficient.

This release adds three long-desired features that further that goal: a new macro system for more expressive libraries, parameter packs to make overloaded APIs natural to use, and new ownership features to offer more control over performance in low-level code.

Macros

Macros help developers reduce repetitive boilerplate and create more expressive libraries that can be distributed as a Swift package.

Using a macro is easy and natural. Macros can either be expanded with a function-like freestanding #macroName syntax:

let _: Font = #fontLiteral(name: "SF Mono", size: 14, weight: .regular)

or attached to declarations with an @MacroName attribute:

// Move storage from the stored properties into a dictionary,
// turning the stored properties into computed properties.
@DictionaryStorage
struct Point {
  var x: Int = 1
  var y: Int = 2
}

They work just like built-in language features but can’t be mistaken for normal code.

You write macros using a powerful and flexible approach: they are simply Swift functions that use the SwiftSyntax library to generate code to be inserted into the source file.

Macros make it easy for your library’s users to adopt powerful capabilities that adapt to the code they’re used in, like the new Observation module, which allows Swift classes to automatically notify other code when their properties change.

The Swift community has been hard at work creating tools and frameworks that build upon macros. For some examples, take a look at swift-power-assert, swift-spyable, swift-macro-testing, and MetaCodable.

Swift 5.9 supports macros on macOS and Linux, with Windows support coming soon.

Parameter packs

Parameter packs let you write generic types and functions which work over an arbitrary number of types.

For example, without parameter packs, if you wanted to write a function called all to check whether any number of Optional values are nil, you would need to write a separate overload for each argument length you wanted to support, creating an arbitrary upper limit:

func all<W1>(_ optional: W1?) -> W1?
func all<W1, W2>(_ optional1: W1?, optional2: W2?) -> (W1, W2)?
func all<W1, W2, W3>(_ optional1: W1?, optional2: W2?, optional3: W3?) -> (W1, W2, W3)?

With parameter packs, you can express this API as a single function that has no upper limit, allowing you to pass any number of arguments:

func all<each Wrapped>(_ optional: repeat (each Wrapped)?) -> (repeat each Wrapped)?

Calling an API that uses parameter packs is intuitive and requires no extra work:

if let (int, double, string, bool) = all(optionalInt, optionalDouble, optionalString, optionalBool) {
  print(int, double, string, bool)
}
else {
  print("got a nil")
}

Ownership

Ownership features can help developers fine-tune memory management behavior in performance-critical code.

The new consume operator tells Swift to deinitialize a variable and transfer its contents without copying it. The consuming and borrowing parameter modifiers provide hints that Swift can use to eliminate unnecessary copying and reference-counting operations when passing a parameter. Finally, noncopyable structs and enums allow you to create types which, like a class, can’t be meaningfully copied when assigned, but like a struct or enum, do not need to be reference-counted because only one storage location can own the instance at a time.

These major features are the foundation for further evolution that puts more expressive power and performance control into your hands. We’re excited about what you can do with Swift 5.9, and we’re working toward a future with a larger suite of variadic generics and ownership features.

Additional Features

Swift 5.9 also includes smaller, quality-of-life changes to the language, like the ability to use if and switch as expressions for variable assignment and return values:

statusBar.text = if !hasConnection { "Disconnected" }
                 else if let error = lastError { error.localizedDescription }
                 else { "Ready" }

A new package access level lets other modules in the same package access APIs, but hides them from code outside the package. It’s great for splitting up large modules into several smaller ones without exposing internals to the package’s clients.

Developers using Swift Concurrency may appreciate the more convenient DiscardingTaskGroup types for task groups that don’t generate results and the advanced custom actor executors feature for controlling the exact environment that an actor is run in.

A full list of Swift 5.9 Evolution proposals can be found at the end of this post.

Developer Experience

Crash Handling

On Linux, the Swift runtime will now catch program crashes and Swift runtime errors and display a backtrace on the program’s output. The backtracer is out-of-process and includes support for async functions.

This feature is also available on macOS but is disabled by default. To enable it, set SWIFT_BACKTRACE=enable=yes and sign your program with the com.apple.security.get-task-allow entitlement.

Debugging

Swift 5.9 introduces new features to LLDB and the Swift compiler aimed at making Swift debugging faster and more reliable.

The p and po commands now print local variables and properties as fast as the frame variable or v commands by bypassing the Swift compiler when evaluating simple expressions.

Swift expressions can now refer to generic type parameters. This allows setting a conditional breakpoint in a generic function that only triggers when a type parameter is instantiated with a specific concrete type.

The debug info produced by the Swift compiler now more precisely scopes local variables, making it less likely to display variables backed by uninitialized memory in the debugger.

Ecosystem

C++ Interoperability

Swift 5.9 supports bidirectional interoperability with C++ and Objective-C++ for certain kinds of APIs.

For example, if you have a C++ function like:

// Clang module 'PromptResponder'
#pragma once
#include <vector>

std::vector<std::string> generatePromptResponse(std::string prompt);

you can call it directly from your Swift code:

import PromptResponder

let codeLines = generatePromptResponse("Write Swift code that prints hello world")
  .map(String.init)
  .filter { !$0.isEmpty }

for line in codeLines {
  print(line)
}

C++ interoperability is actively evolving, with some aspects subject to change in future releases as the community gathers feedback from real world adoption in mixed Swift and C++ codebases.

For information on enabling C++ interoperability and the supported language subset, please refer to the documentation.

Special thanks to the C++ Interoperability Workgroup for their focus and dedication in supporting this feature.

Swift Package Manager

The Swift Package Manager has a number of improvements in Swift 5.9:

Packages can use the new package access modifier, allowing access of symbols in another target / module within the same package without making them public. SwiftPM automatically sets the new compiler configuration to ensure this feature works out-of-the-box for packages.
The CompilerPluginSupport module enables defining macro targets. Macro targets allow authoring and distributing custom Swift macros as APIs in a library.
The new .embedInCode resource rule allows embedding the contents of a resource into an executable by generating a byte array.
The allowNetworkConnections(scope:reason:) setting gives a command plugin permissions to access the network. Permissions can be scoped to Unix domain sockets as well as local or remote IP connections, with an option to limit by port. For non-interactive use cases, the --allow-network-connections command-line flag allows network connections for a particular scope.
SwiftPM can now publish to a registry following the specification defined in SE-0391, as well as support signed packages, which may be required by a registry. Trust-on-first-use (TOFU) validation checks can now use signing identities in addition to fingerprints, and are enforced for source archives as well as package manifests.
SwiftPM now supports cross compilation based on the Swift SDK bundle format. While the feature is still considered experimental, we invite users to try it out and provide feedback.

See the Swift Package Manager changelog for the complete list of changes.

Swift Syntax

swift-syntax is an essential tool for parsing Swift code and helps power the new macro system. This year, swift-syntax received a number of improvements:

Syntax node names are more consistent and accurately reflect the Swift language.
Error recovery in the new SwiftParser is greatly improved, leading to more precise error messages for incorrect or missing syntax.
Incremental parsing is now supported, allowing editors and other tools to only reparse those parts of a syntax tree that have changed.
The documentation of swift-syntax has been greatly expanded.

Over the last year, swift-syntax has been a huge success as an open source project. Since the release of Swift 5.8, more than 30 distinct contributors have worked on the package, accounting for more than 30% of the commits. In addition, the community tool swift-ast-explorer.com is invaluable in exploring and understanding the SwiftSyntax tree. Thank you to everyone who contributed!

Server

Custom actor executors and other features from Swift 5.9 are making their way into the Swift on server ecosystem.

The server workgroup also recently published their annual update for 2023, detailing plans to increase adoption of concurrency within key libraries, as well as other efforts.

Windows Platform

Windows support for Swift 5.9 greatly improves stability and the developer experience.

The Windows installer now supports installation both before and after Visual Studio installation, and no longer requires repair after a Visual Studio upgrade. Initial work has also begun to enable multiple, parallel toolchains installed side-by-side on Windows.

The Swift toolchain also added new flags (-windows-sdk-root, -windows-sdk-version, -visualc-tools-root, -visualc-tools-version) to help control the Windows SDK and Visual C++ tools that it builds against.

The Windows SDK (WinSDK) module saw improvements in coverage, enabling access to a wider set of system APIs. The Visual C++ (vcruntime) module was greatly restructured to support C++ interoperability.

Structured Concurrency is now significantly more stable on Windows, eliminating stack overflows and other execution failures for common patterns such as iterating over an AsyncStream with many elements.

Improvements to path handling in the LSP and SwiftPM makes both of these tools more robust on Windows. LLDB also saw initial work towards improving support for Windows, enabling fundamental debugging workflows in LLDB on Windows. While still a work in progress, this will significantly improve the developer experience on Windows.

Small improvements have also been made to reduce the size of the toolchain on Windows.

Next Steps

Downloads

Official binaries are available for download from Swift.org for macOS, Windows, and Linux. The Swift 5.9 compiler is also included in Xcode 15.

Website

Swift.org has revamped certain key pages, including a richer home page and clearer download and install instructions.

If you’re new to Swift or looking to dive deeper, check out the updated Getting Started guides.

Language Guide

The Swift Programming Language book has been updated for Swift 5.9 and is now published with DocC.

This is the official Swift guide and a great entry point for learning Swift.

The Swift community also maintains a number of translations.

Swift Evolution Appendix

The following language, standard library, and Swift Package Manager proposals were accepted through the Swift Evolution process and implemented in Swift 5.9.

SE-0366: consume operator to end the lifetime of a variable binding
SE-0374: Add sleep(for:) to Clock
SE-0377: borrowing and consuming parameter ownership modifiers
SE-0380: if and switch expressions
SE-0381: DiscardingTaskGroups
SE-0382: Expression Macros
SE-0384: Importing Forward Declared Objective-C Interfaces and Protocols
SE-0386: New access modifier: package
SE-0388: Convenience Async[Throwing]Stream.makeStream methods
SE-0389: Attached Macros
SE-0390: Noncopyable structs and enums
SE-0392: Custom Actor Executors
SE-0393: Value and Type Parameter Packs
SE-0394: Package Manager Support for Custom Macros
SE-0395: Observation
SE-0396: Conform Never to Codable
SE-0397: Freestanding Declaration Macros
SE-0398: Allow Generic Types to Abstract Over Packs
SE-0399: Tuple of value pack expansion
SE-0400: Init Accessors
SE-0401: Remove Actor Isolation Inference caused by Property Wrappers
SE-0402: Generalize conformance macros as extension macros

SSWG 2023 Annual Update

2023-08-17T06:00:00-04:00

Once a year, the Swift Server workgroup (SSWG) reflects on recent community accomplishments and lays out focus areas for the year ahead.

Since our last update, the Swift on server ecosystem has welcomed new projects, seen significant progress in the adoption of structured concurrency, improved its tooling, and more.

Let’s start by reviewing the progress made in 2022 then look ahead at the goals for the next 12 months.

2022 in Review

Continued focus on growing the ecosystem

The ecosystem has seen a number of new libraries introduced including:

a Kafka client library that started as a GSoC project
a Cassandra client library released by Apple and pitched to the SSWG incubation process
a GraphQL library pitched to the SSWG incubation process
a RabbitMQ library
a Memcached client library was proposed as a GSoC project

There were also three new packages proposed and accepted into the SSWG’s incubation process:

Continuing the concurrency journey

We are happy to see that the adoption of Swift Concurrency in the ecosystem has progressed significantly. All libraries in the SSWG incubation process have adopted new async/await APIs where applicable and are continuing to roll out Sendable support.

We are also seeing a trend of new APIs using only Swift Concurrency, and new projects with internals written using Swift Concurrency, like the Kafka client library.

We’re also excited to see the introduction of Custom Actor Executors. The introduction of Custom Actor Executors offers more control over the behavior of concurrent code, helps improve performance, and will enable us to bridge more code into Swift concurrency.

Expanding the tooling

Notable highlights in tooling include:

The Swift Extension for Visual Studio Code reached version 1.0.0 and added new features like Swift Package plugin integration, Test Coverage and Test Explorer support, and more.
Swift Package plugins have seen adoption in many libraries, from formatters and linters, to code generators such as SwiftProtobuf, gRPC swift, Smoke, and Soto.
Swiftly is now available to try out and provides a simple way to install Swift on Linux and switch between versions.

Improving build times

There have been a number of improvements to build times for Swift projects, including compiler optimizations, new build systems, and package manager enhancements.

Swift Crypto Extras continues to add new APIs that allow libraries to avoid vending their own copies of BoringSSL. This, combined with the new Swift Certificates and ASN.1 libraries, helps libraries like WebAuthn Swift avoid including their own cryptography libraries and instead use these new packages and APIs. This avoids compiling the same code multiple times and provides a significant speed improvement during compilation.

Additionally, SSWG member Gwynne merged a PR for Swift 5.9 that offers a 90% improvement to link time and memory usage on Linux, which should greatly help when building Swift applications in constrained environments.

Increasing adoption of server-side Swift

The SSWG has continued to work with the community to increase adoption of Swift on the server:

The SSWG Guides and incubation processes have been migrated to Swift.org to make them more discoverable.
Many of the Swift server packages have adopted Swift Package Index documentation hosting to make discovering and using packages easier.
The SSWG has created a survey to better understand the Swift on server community and help ensure efforts are applied to the right areas.
We are observing an increase in the number of conference talks focused on production success stories and technical deep dives, reflecting a maturity in adoption and recognition of Swift on server.

Goals for 2023

The SSWG believes 2023 is turning out to be another exciting year for Swift on the server, with a continued focus on the following goals:

Continued focus on growing the ecosystem
Adoption of structured concurrency
Expand the documentation and guides
Improve tooling

Continued focus on growing the ecosystem

In addition to supporting existing libraries, there are a number of areas of focus for this year:

a Swift-native Memcached client
a common connection pool library to make it easy to adopt connection pooling
a shared middleware implementation for use in web frameworks like Smoke, Hummingbird, and Vapor
Encouraging adoption of distributing tracing to round out the observability story
Better showcases of Swift on server deployments and success stories
Better visibility of Swift as a server language

Adoption of structured concurrency

The SSWG believe that structured concurrency is a key feature that will make Swift on server stand out and provide a clear benefit to the ecosystem.

Some plans for this year include:

Produce an adoption guide for structured concurrency covering best practices around Sendable, async/await, TaskGroup, and Task APIs.
Apply concurrency best practices to core ecosystem libraries such as swift-service-lifecycle.

Expand the documentation and guides

Documentation can always be improved and the SSWG will continue to expand our guides and usage documentation for the ecosystem.

The SSWG are working with the Swift Website Workgroup to add guides for those new to Swift on the server as well as ensure that the existing guides can be easily found.

The SSWG also plan to expand the documentation in key areas like security and deployment, covering topics like GitHub’s Dependabot and AWS’s Swift support in their CDK.

Some of the upcoming design changes to Swift.org will help place Swift on server documentation in a more prominent position to increase visibility.

Improve tooling

Swiftly is growing in popularity on Linux for managing multiple toolchains, and the SSWG would like to port it to Windows and macOS as well.

There are a number of other tooling enhancements being explored, including:

Adding support for Swift Package Manager to GitHub’s dependabot
Investigating Canonical’s Chiseled Containers to see if we can provide Swift containers with a very small footprint and a hardened security profile
Investigating what we can do with Swift Package plugins to improve the deployment experience of Swift on server

New SSWG Members

The SSWG is happy to welcome four new members:

Dave Moser - Dave joined the SSWG in May. Dave is part of the solution architecture team driving Swift on AWS, and has been involved with the Swift on server efforts for the last couple of years.
Jimmy McDermott - Jimmy also joined the SSWG in May and represents Transeo. Jimmy has been involved with Swift on server since Vapor’s early days and is the CTO of Transeo, where he and his team use Vapor to scale services to millions of users.
Franz Busch - Franz officially joined the SSWG on October 23rd and works on the SwiftNIO team at Apple.
Joannis Orlandos - Joannis joined the SSWG at the start of this year. Joannis was a core contributor to Vapor and maintains a number of libraries in the ecosystem including MongoKitten.

Franz takes over from Fabian Fett who has completed a two year stint on the SSWG. Dave takes over from Todd Varland who also completed a long stint on the SSWG. Kaitlin Mahar has changed roles at MongoDB and also completed a number of years on the SSWG. We are extremely grateful for all they’ve done in their time on the SSWG and thank them for their hard work!

Going Forward

If you have any ideas to share with the SSWG or want to pitch a library to the SSWG Incubation Process, please get in touch with us, either via the forums or through Slack.