Swift.org

Redesigned Swift.org is now live

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

Over the past few months, the website workgroup has been redesigning Swift.org. On behalf of the website workgroup, I’m pleased to announce that we have merged the initial changes.

Our goal with the site redesign has been to make Swift.org more approachable for newcomers to Swift, highlight the language’s technical strengths, and make it easy to get started. That led to a focus on the website’s appearance, improving the user experience, and emphasizing important features such as Swift’s multiplatform support.

Today’s release includes refreshed home and install pages. Additionally, new pages have been designed to explore Swift use cases, including cloud services, command line tools, and embedded software. Looking forward, we plan to take an iterative approach to improving the website, including pushing changes live as we complete their design and implementation.

Brand new design

We explored several design options and found that the latest design conveys the fluidity and creativity of Swift through the splash of orange and the bird animation in the background.

Curated content and examples

The homepage now highlights Swift’s strengths alongside code examples that illustrate them. Additionally, we showcase various types of software that can be developed using Swift; these new use case pages provide information such as relevant packages, examples of Swift in action, code snippets, and links to resources for further learning.

Next Steps

We look forward to hearing your feedback on this first set of changes as we continue to redesign other sections of the site. There are several ways to offer feedback on the redesign and to get involved:

A forum announcement has been shared on the forums that can be used for discussion, and the website repository has GitHub issues.
The website itself is open source, and your contributions to the swiftlang/swift-org-website repository are welcome.
The Swift Information Architecture Project is an ongoing effort that has helped inform decisions related to the site redesign.

Thank you to the website workgroup and community members for contributing to these improvements.

Swift at Apple: Migrating the Password Monitoring service from Java

2025-06-02T06:00:00-04:00

Swift is heavily used in production for building cloud services at Apple, with incredible results. Last year, the Password Monitoring service was rewritten in Swift, handling multiple billions of requests per day from devices all over the world. In comparison with the previous Java service, the updated backend delivers a 40% increase in performance, along with improved scalability, security, and availability.

The Passwords app, introduced in the fall of 2024, helps users manage their passwords, passkeys, and verification codes. It allows them to store, autofill, and generate strong passwords that can be shared across all their devices, as well as share passwords with trusted contacts. One security feature included in the app is Password Monitoring, which warns users if one of their saved passwords shows up in a data leak. This feature has a server component, running on Linux-based infrastructure, that is maintained by Apple.

On a regular interval, Password Monitoring checks a user’s passwords against a continuously updated and curated list of passwords that are known to have been exposed in a leak. Importantly, this task is handled in a thoughtful, privacy-preserving way that never reveals users’ passwords to Apple. A detailed discussion of how this is done using the cryptographic private set intersection protocol is in the Password Monitoring section of the Apple Platform Security guide.

The migration from Java to Swift was motivated by a need to scale the Password Monitoring service in a performant way. The layered encryption module used by Password Monitoring requires a significant amount of computation for each request, yet the overall service needs to respond quickly even when under high load.

Choosing Swift for increased performance

For years, our team relied on Java to power large-scale, mission-critical services because of its proven stability and performance. However, Java’s memory management approach no longer aligns with our growing demands and efficiency goals. Instead of simply expanding hardware resources, we were seeking a more-efficient language to support our growth while reducing server overhead.

Prior to seeking a replacement language, we sought ways of tuning the JVM to achieve the performance required. Java’s G1 Garbage Collector (GC) mitigated some limitations of earlier collectors by introducing features like predictable pause times, region-based collection, and concurrent processing. However, even with these advancements, managing garbage collection at scale remains a challenge due to issues like prolonged GC pauses under high loads, increased performance overhead, and the complexity of fine-tuning for diverse workloads.

One of the challenges faced by our Java service was its inability to quickly provision and decommission instances due to the overhead of the JVM. The Password Monitoring service runs globally, so service load can greatly fluctuate throughout the day, even with client-side techniques to smooth over the distribution of traffic. The peak and trough of a day differ by approximately 50% regionally. To efficiently manage this, we aim to scale down when demand is low and scale up as demand peaks in different regions. A faster bootstrap time is a crucial requirement to support this dynamic scaling strategy.

Given the scale of our application and the volume of traffic we manage daily, the decision to transition from Java to another language was not made lightly. We evaluated our options, and found only a few languages that could help us achieve our goals. While you might expect that Apple would automatically choose Swift, we were pleasantly surprised by how well it fit the unique needs of a cloud-based service like ours. Swift has expressive syntax that was easy to learn, and could deliver the performance improvements necessary to meet the demands of our compute workloads. We decided to take a significant leap and started a rewrite of the Password Monitoring backend using Swift.

Our experience developing with Swift

We began rewriting our service using Vapor, a Swift web framework that provided Routing, Controller, and Content modules that we were able to build upon. Our service had additional requirements that led us to create a few custom packages with essential functionality: elliptic curve operations that are crucial for implementing password monitoring, auditing, configuration, error handling, and custom middleware.

One of the most significant aspects of Swift that impressed us was its emphasis on protocols. In Java, we relied heavily on inheritance, which can lead to complex class hierarchies and tight coupling. Swift’s approach of protocols and generics promotes modularity and reusability by allowing classes, structs, and enums to share common protocols, enabling a more flexible and scalable codebase. This shift in mindset encouraged us to think in terms of behaviors rather than concrete classes, resulting in cleaner and more maintainable code.

Safety is another area where Swift takes a distinctive approach compared to Java. For example, Swift’s optional type and safe unwrapping mechanisms eliminate the need for null checks everywhere, reducing the risk of null pointer exceptions and enhancing code readability. This safety-first approach ingrained throughout Swift’s language design, whether it is deterministic deallocation, copy-on-write (CoW), or value types, makes it inherently less prone to runtime errors.

Swift’s async/await support is a nice addition, streamlining how we handle async tasks. Previously, managing async operations often involved complex callback patterns or external libraries. Swift’s async/await syntax simplifies this process, making it more intuitive and less error-prone. We can now write async code that reads like sync code, leading to more readable, testable, and maintainable concurrency handling—especially critical in high-load, multi-threaded environments.

Overall, our experience with Swift has been overwhelmingly positive and we were able to finish the rewrite much faster than initially estimated. Swift allowed us to write smaller, less verbose, and more expressive codebases (close to 85% reduction in lines of code) that are highly readable while prioritizing safety and efficiency.

Our service benefited from a diverse ecosystem of Swift packages, including logging frameworks, a Cassandra client, and crypto libraries that were readily available. In addition to an excellent support system and tooling, Swift’s inherent emphasis on modularity and extensibility helped future-proof and simplify the integration and customizations needed for our service-specific functions.

Takeaways for future Swift on server development

We benchmarked performance throughout the process of development and deployment, allowing us to discover the trait of the Swift programming language that delighted us the most — its efficiency.

Swift’s deterministic memory management led to a much lower memory threshold for our service. Not only were our initial results heartening, but after a few iterations of performance improvements, we had close to 40% throughput gain with latencies under 1 ms for 99.9% of requests on our current production hardware. Additionally, the new service had a much smaller memory footprint per instance — in the 100s of megabytes — an order of magnitude smaller compared to the 10s of gigabytes our Java implementation needed under peak load to sustain the same throughput and latencies. The service runs on Kubernetes, and the migration’s efficiency improvements allowed us to release about 50% of its capacity for other workloads.

Our Swift implementation has run smoothly and efficiently in production, making it worth the effort we put into this migration. In addition to outperforming our previous Java-based application, Swift delivered better performance consistency, enhanced safety features, and robust reliability — all while requiring fewer resources by utilizing memory and CPU efficiently. With fewer lines of boilerplate code and more flexible design patterns that we used, we look forward to simplified maintenance of our application. Swift was a powerful choice for building fast, resilient, and maintainable applications in our high-demand environment.

ICYMI: Memory Safety, Ecosystem Talks, and Java Interoperability at FOSDEM 2025

2025-05-05T07:55:00-04:00

The Swift community had a strong presence at FOSDEM 2025, the world’s largest independently run open source conference, held every year in Brussels, Belgium. FOSDEM highlighted a range of Swift-related talks related to memory safety, a broad ecosystem around Swift including using it to develop web services and embedded projects, and new areas of the project including Java interoperability.

In case you missed it, here are a few highlights from the event:

Memory Safety in Swift

The main track of the conference featured a talk presented by Doug Gregor on memory safety: “Incremental Memory Safety in an Established Software Stack: Lessons Learned from Swift.”

If you’re interested in learning more about Swift’s memory safe features, this talk is a great place to start; it walks through the different dimensions of memory safety in Swift, the language’s safe interoperability with C(++), and reflects on lessons learned for both programming language design and adopting Swift in an established software codebase.

To learn more about memory in safety in Swift, see the Swift documentation page on memory safety,as well as a features vision document on memory safety.

Swift DevRoom

FOSDEM is primarily organized into DevRooms, volunteer-organized conference tracks around technical communities and topics. This year Swift celebrated its inaugural DevRoom organized by a local community member, Steven Van Impe, with contributions from a large group of volunteers including proposal reviewers, speakers, and day-of-operations support.

Swift’s first Swift DevRoom was a hit! 🎉 The room was packed with 12 talks, covering a wide range of topics and demos from the Swift ecosystem: talks related to running Swift on Linux, to showcasing various IDEs like VS Code, and a whole hour dedicated to embedded content. A few talks to highlight from the event:

Check out the complete lineup to learn more!

Java Interoperability

In the Free Java DevRoom, Konrad ‘ktoso’ Malawski presented on Java interoperability in Swift: “Foreign Function and Memory APIs and Swift/Java interoperability.“

Konrad’s talk was a technical deep dive into the Java interoperability effort that launched at the 2024, demonstrating the bridges and bindings needed to integrate systems written in these Swift and Java while still maintaining great performance. Catch up on this talk to see how you can leverage existing libraries without complete rewrites.

Work in early development has been released on GitHub for feedback and contributions, and your feedback is welcome on the forums.

Swift 6.1 Released

2025-03-31T06:00:00-04:00

Swift 6.1 is now available!

This release includes new language enhancements to improve productivity, diagnostics improvements, package traits, and ongoing work to improve data-race safety usability and compile times.

Read on for an overview of the changes to the language, package manager, and next steps for getting started with Swift 6.1.

Language and Standard Library

Concurrency

Swift’s concurrency model allows writing nonisolated on properties and functions to indicate that an API is safe to call from any concurrent context. Swift 6.1 extends nonisolated to types and extensions. This allows you to write nonisolated to prevent @MainActor inference on a type, or to apply nonisolated to all methods in an extension without having to annotate every method:

@MainActor
struct S {
  let id: Int
  let name: String

  // mutable state and MainActor methods
}

nonisolated extension S: CustomStringConvertible, Equatable {
  var description: String {
    "id: \(id), name: \(name)"
  }

  static func ==(lhs: S, rhs: S) -> Bool {
    lhs.id == rhs.id
  }
}

Swift 6.1 also improves type inference for task groups by inferring the child task result type of withTaskGroup and withThrowingTaskGroup. Previously, you always had to write the child task result type as an argument when creating the task group:

let messages = await withTaskGroup(of: Message.self) { group in
  for id in ids {
    group.addTask { await downloadMessage(for: id) }
  }

  var messages: [Message] = []
  for await message in group {
    messages.append(message)
  }
  return messages
}

In Swift 6.1, the child task result type can be inferred from the task group closure:

// No need for `(of: Message.self)` like before.
let messages = await withTaskGroup { group in
  for id in ids {
    group.addTask { await downloadMessage(for: id) }
  }

  var messages: [Message] = []
  for await message in group {
    messages.append(message)
  }
  return messages
}

The approachability of data-race safety remains an area of active development; you can find an overview of the approach in the vision document for improving the approachability of data-race safety. Many Swift Evolution proposals implementing the features described in the vision document are under active review, and your feedback will help shape these improvements.

Implementing Objective-C types in Swift

Swift 6.1 includes a new attribute, @implementation, which can be used together with @objc to provide an implementation for a declaration that has been imported from Objective-C. You can write @objc @implementation on a Swift extension to replace an Objective-C @implementation block.

You write headers as normal for an Objective-C class, but instead of writing an @implementation in an Objective-C file, you write an @objc @implementation extension in a Swift file. You can even port an existing class’s implementation to Swift one category at a time without breaking backwards compatibility.

Productivity enhancements

Swift allows including trailing commas in collection literals to make it easy to append, remove, reorder, or comment out the last element as any other element:

let rank = [
  "Player 1",
  "Player 3",
  "Player 2",
]

Swift 6.1 extends trailing comma support to tuples, parameter and argument lists, generic parameter lists, closure capture lists, and string interpolations:

let numbers = [1, 2, 0, 3, 4, 0, 0, 5]

let subsequences = numbers.split(
    separator: 0,
    maxSplits: 1,
)

In addition to improved development ergonomics, code generation tools like plugins and macros can be simplified, because generating a comma-separated list no longer needs a special condition for the last element.

You can find a complete list of language proposals that were accepted through the Swift Evolution process and implemented in Swift 6 on the Swift Evolution dashboard.

Package and build improvements

Swift 6.1 introduces package traits, a new configuration for packages that allows them to offer different APIs and features when used in specific environments, such as Embedded Swift and WebAssembly. Package authors can define a set of traits in their Package.swift that their package offers, which provide a way to express conditional compilation and optional dependencies. The package can specify a set of default traits that are enabled in clients, and clients can customize the traits they use when they declare the dependency:

dependencies: [
  .package(
    url: "https://github.com/Org/SomePackage.git",
    from: "1.0.0",
    traits: [
      .default, // enable all of the package's default traits
      "Embedded"
    ]
  ),
]

Many editing features, such as jump to definition for APIs in libraries you’re using, are powered by indexing. Before Swift 6.1, indexing occurred when you built your project, which meant that any additions or changes to the library were only surfaced by those editing features after you perform a build. Swift 6.1 enables background indexing by default for SwiftPM projects in SourceKit-LSP. Cross-module and global functionality stays updated as you make changes to your project.

Swift Testing

Swift 6.1 enables custom Swift Testing traits to perform logic before or after tests run in order to share set-up or tear-down logic. If you write a custom trait type which conforms to the new TestScoping protocol, you can implement a method to customize the scope in which each test or suite the trait is applied to will execute. For example, you could implement a trait which binds a task local value to a mocked resource:

struct MockAPICredentialsTrait: TestTrait, TestScoping {
  func provideScope(for test: Test, testCase: Test.Case?, performing function: @Sendable () async throws -> Void) async throws {
    let mockCredentials = APICredentials(apiKey: "fake")
    try await APICredentials.$current.withValue(mockCredentials) {
      try await function()
    }
  }
}

extension Trait where Self == MockAPICredentialsTrait {
  static var mockAPICredentials: Self { Self() }
}

@Test(.mockAPICredentials)
func example() {
  // Validate API usage, referencing `APICredentials.current`...
}

For more details, see ST-0007: Test Scoping Traits. Swift Testing in Swift 6.1 also includes refined versions of the #expect(throws:) and #require(throws:) macros which return their caught errors, making inspecting them in test functions more ergonomic (ST-0006).

Swift-DocC

Swift-DocC introduces a more human readable and human writable alternative for symbol link disambiguation based on parameter type and return type information. For example, consider these three function overloads with different parameter types and return types:

func doSomething(first: String,  second: Int) -> Double
func doSomething(first: String?, second: Int) -> Float
func doSomething(first: String?, second: Int) -> Double

Previously, if you wrote a link to one of these overloads you needed to include a short hash of that symbol’s unique identifier to disambiguate the link and uniquely reference the specific overload. Swift-DocC’s warnings aided in writing these hashes but a person can’t decode the resulting hash suffix (-3c5j) to determine which overload the link is referring to. Now, you can use a combination of parameter types and return types—like -(String,_), ->Float, or -(String?,_)->Double—to disambiguate the link and uniquely reference a specific overload.

You can discover the minimal combination of parameter types and return types for each overload from Swift-DocC’s warnings about ambiguous symbol links. For more details, see the Ambiguous Symbol Links section of Linking to Symbols and Other Content.

Install Swift 6.1

You can try out these exciting new developments in Swift 6.1 today!

If you’re building apps for Apple platforms, Swift 6.1 is included in Xcode 16.3, now available from the App Store. And the easiest way to install the standalone Swift 6.1 toolchain is using swiftly, the new Swift version manager that runs on macOS and Linux. Additional installation methods, including for Windows, are included on the Install Swift page.

Introducing swiftly 1.0

2025-03-28T02:00:00-04:00

Today we’re delighted to introduce the first stable release of swiftly, a Swift version manager that takes the pain out of installing, managing and updating your Swift toolchain.

The latest version of Swift is bundled with Xcode for writing apps for Apple platforms. But perhaps you want to install Swift on a different platform like Linux, or use a different version of the toolchain for building services or command line tools. Downloading, extracting and installing a trusted build of Swift along with the relevant dependencies for your operating system can require quite a few manual and error-prone steps.

swiftly has been around for some years as a community-supported tool for Swift developers using Linux. With this release, we’re officially supporting it as part of the core Swift toolchain, including hosting it as part of the Swift GitHub organization. We’ve also added macOS support to make it easier to install Swift separately from Xcode.

Introducing swiftly

swiftly is the best tool to install the standalone toolchain, providing commands to install Swift on a new system, update to the latest stable version, and experiment or test with nightly snapshots or older versions. It also makes it easy to switch effortlessly between multiple installed toolchains. You can even add a file to your project repository so swiftly will use the same toolchain version for all members of your development team.

Naturally, swiftly itself is written in Swift, and is able to update itself to the latest version.

Quick tour

Let’s take a look at some of the features of swiftly!

To get started, visit swift.org/install and install it.

swiftly will provide directions after installation if there are any system packages, or shell commands needed for smooth operation of the new toolchain.

The latest Swift toolchain is installed as the default, so you can immediately use it to start a new project. For example:

$ swift package init

The swiftly use command selects the default toolchain for Swift commands (e.g. swift test, swift build):

$ swiftly use 6.0.3
$ swift --version
--
Apple Swift version 6.0.3 (swiftlang-6.0.3.1.2 clang-1600.0.28.6)
Target: arm64-apple-macosx15.0

At a later point, if there’s a new release of Swift you can install it alongside the existing toolchain with the latest command:

$ swiftly install latest

Pre-release of versions of Swift are available, including nightly “snapshot” toolchains. They can be easily listed using swiftly:

$ swiftly list-available main-snapshot
--
Available main development snapshot toolchains
----------------------------------------------
main-snapshot-2025-03-25
...

Once you’ve identified a snapshot toolchain, it can be installed using its name:

$ swiftly install main-snapshot-2025-03-25
--
Installing main-snapshot-2025-03-25

Another way to temporarily use a specific version of Swift is to use the special ‘+’ selector. With this syntax, you don’t need to first switch to a different toolchain:

$ swiftly run lldb +main-snapshot-2025-03-25
--
(lldb) _

If you’re building a SwiftPM project in a team setting and want to enforce a common version of the Swift toolchain on all contributors, simply create a .swift-version file in the root of your project folder with the desired version (e.g. “6.0.3”).

As swiftly is updated with new features and bug fixes, you can run swiftly self-update to check and install new releases.

How swiftly works

By writing swiftly in Swift, we’re able to take advantage of the language’s features, support, and ecosystem of related projects. Swift comes with standard library features for working with the filesystem in its Foundation module. For network operations Async HTTP Client is there to work the HTTP requests. And to retrieve the latest Swift release, swiftly uses the Swift OpenAPI plugin to generate the code to interact with the swift.org website. Lastly, it takes advantage of Swift’s interoperability with C to use the existing libarchive library to work with archives. swiftly uses libarchive to extract the toolchains downloaded from the Swift website and the integration is simple.

It can be challenging to build shell programs that work well across multiple platforms with minimal system dependencies; this motivated us to switch swiftly away from using a shell program to install it and become a self-installing binary application. swiftly has access to excellent argument parsing capabilities, beautiful --help screens, and the full standard library.

The only remaining problem was being able to deliver the operating system and processor architecture specific binary to the users system with simplicity. The swift.org website helps with operating system detection, but it cannot reliably detect the Linux distribution. Luckily, there is the Swift Static Linux SDK that makes binaries that work with a wide range of distributions. The processor architecture can be determined on most unixes using uname -m . The result of all of this is the simplicity of a copy and paste from the website to your terminal and get started with Swift.

Installing Swift, swiftly

Moving forward, swiftly will become the default way to install Swift outside of Xcode. The initial version supports macOS and a variety of Linux distributions, including Ubuntu, Debian, Fedora, Red Hat Enterprise Linux and Amazon Linux.

The swiftly documentation provides further information about using swiftly in a CI/CD environment, as well as setting proxy servers and custom install locations for enterprise environments. swiftly is an open source project, and so you can raise new issues or contribute pull requests at its GitHub repository. You can also ask questions or discuss swiftly on the Swift Forums.

Special thanks to Patrick Freed for creating swiftly, contributing it to the Swift organization, and his continued contributions to this valuable tool. The community is what makes Swift amazing!

How Swift's server support powers Things Cloud

2025-02-21T06:00:00-04:00

You might be familiar with Things, a delightful personal task manager that has won two Apple Design Awards and is available across Apple devices including iPhone, iPad, Mac, Apple Watch, and Apple Vision Pro. At Cultured Code, the team behind Things, we care about a great user experience across every aspect of the product. This extends to our server back end, and after a rewrite our Things Cloud service has transitioned entirely to Swift. Over the past year in production, Swift has consistently proven to be reliable, performant, and remarkably well-suited for our server-side need.

Things Cloud serves as the backbone of the app’s experience, silently synchronizing to-dos across devices. The robustness of this work is ensured by a rigorous theoretical foundation, inspired by operational transformations and Git’s internals. After twelve years in production, Things Cloud has earned our users’ trust in its reliability. But despite the enduring strength of the architecture itself, the technology stack lagged behind.

Things Cloud synchronizes to-dos across different devices.

Switching to Swift

Our legacy Things Cloud service was built on Python 2 and Google App Engine. While it was stable, it suffered from a growing list of limitations. In particular, slow response times impacted the user experience, high memory usage drove up infrastructure costs, and Python’s lack of static typing made every change risky. For our push notification system to be fast, we even had to develop a custom C-based service. As these issues accumulated and several deprecations loomed, we realized we needed a change.

A full rewrite is usually a last resort, but in our case, it was the only viable path for Things Cloud. We explored various programming languages including Java, Python 3, Go, and even C++. However, Swift – which was already a core part of our client apps – stood out for its potential and unique benefits. Swift promised excellent performance, predictable memory management through ARC, an expressive type system for reliability and maintainability, and seamless interoperability with C and C++.

While we initially had concerns that Swift’s server support wasn’t as mature as that found in other ecosystems, both Apple and the open-source community had shown strong commitment to its evolution. Swift had reliably compiled on Linux for a long time; the Swift Server workgroup had coordinated server efforts since 2016; the SwiftNIO library gave us confidence in the foundational capabilities, and Vapor provided all the tools to get us up and running quickly.

Convinced by these benefits and the opportunity to use the same language for client and server development, we embarked on a three-year journey to rewrite Things Cloud. We’ve been using it internally for the past two years, and it has now been live in production for over a year.

The new Swift-based service architecture

We’ll outline the core components of our new service architecture, highlighting the Swift packages we use. We’ve found that these components work well together to provide reliability and stability, and we believe this serves as a valuable reference point for others considering a similar transition to Swift.

Overview of our new Swift-based service architecture.

Code

Our Swift server codebase has around 30,000 lines of code. It produces a binary of 60 MB, and builds in ten minutes.
It uses Vapor as an HTTP web framework, which uses SwiftNIO as its underlying network application framework.
We compile a single “monolith” binary from our Swift source code, but use it to run multiple services, each configured by passing different parameters at runtime.
We use Xcode for its robust suite of tools for development, debugging, and testing. It provides us with a familiar and consistent experience across both server and client environments.

Deployment

AWS hosts our entire platform, and is entirely managed by Terraform, an infrastructure as code tool.
We use a continuous integration pipeline to automate tests and build our Swift code into a Docker image. This is then deployed in a Kubernetes cluster alongside other components.
The HAProxy load balancer is used to route client traffic to the appropriate Swift service in the cluster.

Storage

Persistent data is stored in Amazon Aurora MySQL, a relational database, which we connect to with MySQLKit.
To keep the database small, we’re offloading less-used data to S3, which we access via the Soto package.
More ephemeral data, such as push notifications and caches, is stored in Redis, an in-memory key-value database, which we access via RediStack.

Other Services

The APNSwift package is used to communicate with the Apple Push Notification service.
AWS Lambda, a serverless compute service, powers our Mail to Things feature. This process is written in Python 3 due to its mature libraries for the processing of incoming emails. The results are passed to Swift using Amazon Simple Queue Service.

Monitoring

We take the resilience of Things Cloud seriously and go to great lengths to ensure it.
In Swift, we generate JSON logs using our own logger. To produce metrics, we’re using the Swift Prometheus.
We use Amazon CloudWatch to store and analyze logs and metrics. It triggers Incidents, which reach the responsible engineer via PagerDuty.
To test how well our service can recover from transient errors, we employ chaos testing. Each day, our self-written chaos agent performs random disruptive actions such as terminating a Swift service or restarting the database. We then verify that the system recovers as expected.

Results

We wanted to thoroughly test the performance and stability of the new Swift service architecture before it was deployed in production. So during the development phase, we deployed the new system alongside the existing legacy system. While the legacy system continued to be the operational service for all requests, the new system also processed them independently using its own logic and database.

This approach enabled us to develop and test the new system under real-world conditions without any risk to the user experience. Thanks to the confidence we built in the new system’s robustness and reliability through evaluating it with production workloads, we were able to deploy a hardened system from the very beginning.

Now, with over a full year in production, we’re pleased to report that Swift has fulfilled its promise for server-side development. It’s fast and memory-efficient. Our Kubernetes cluster comprises four instances, each with two virtual CPUs and 8 GB of memory, and has handled traffic peaks of up to 500 requests per second. Compared to the legacy system, this setup has led to a more than threefold reduction in compute costs, while response times have shortened dramatically.

Comparison between our legacy service and new Swift-based one.

And one extra win: Swift’s outstanding performance allowed us to replace our custom C-based push notification service with a Swift-based one; this significantly simplified our codebase and operations.

Conclusions

Swift turned out to be a great choice for server usage. It delivered on everything we had hoped for: We’re now using a modern and expressive programming language, the code runs and performs well, and the Swift ecosystem provides all the integrations we need. With a year of production use, we haven’t encountered a single operational issue.

For more information on our journey and experiences, you might enjoy our recent talk at the ServerSide.Swift conference.

We encourage other teams to consider using Swift for server-oriented projects. While we chose to undergo a complete rewrite, the gradual adoption of Swift is also an intriguing option, especially considering the recently announced initiative aimed at enhancing Java interoperability.

As for us, we believe our server architecture is in its best shape ever, and we’re thrilled about the new features we can build upon this solid foundation.

Introducing gRPC Swift 2

2025-02-14T06:00:00-04:00

Say hello to gRPC Swift 2: a major update that brings first-class concurrency support and more expressive APIs for a seamless developer experience.

Inconsistent and poorly documented service APIs create integration headaches for developers. gRPC is a modern, high-performance framework for building service APIs, enabling efficient communication between systems over a network.

Since services may be written with a different language than their clients, most gRPC services use Protocol Buffers (or “protobufs”) to define their APIs and the messages exchanged between clients and servers. Service contracts are defined in a neutral, cross-platform format using .proto files. This is the foundation of your service, not an artefact of its implementation. And thanks to the format’s efficient binary serialization, these messages are typically smaller and faster to process than other standard formats like JSON.

gRPC Swift is one of a family of similar tools that use the Protocol Buffers contract to generate code in the language you’re working with, making it easy to build clients and servers that adhere to your service contract. And the new gRPC Swift 2 offers an idiomatic, cross-platform, performant and feature-rich library for building highly-scalable services.

This release is a major update that takes advantage of many modern Swift features for cross-platform services development. When gRPC Swift was first developed back in 2018, Swift had not yet introduced concurrency features like async/await, so it was instead based on SwiftNIO’s event-driven concurrency model. For developers unfamiliar with these concepts, the prior version of gRPC Swift presented a steep learning curve. Now that Swift’s modern concurrency model is fully established, we seized the opportunity to rethink gRPC Swift for today’s Swift, incorporating lessons learned from our years of use at Apple for building internet-scale services.

Highlights

Modern, flexible, and easy-to-use APIs with idiomatic generated code.
Full support for building services and clients on Linux and Apple platforms.
Pluggable transports including a high-performance HTTP/2 transport built on top of SwiftNIO, and an in-process transport which is great for testing.
Smart client features like client-side load balancing, a pluggable name resolution mechanism and automatic retries.
A flexible interceptor layer allowing you to implement cross-cutting logic like authentication, logging, and metrics.

Hello, swift.org!

Consider the canonical “hello world” service with a single API which returns a greeting. You might define it like this in a .proto file:

syntax = "proto3";

service GreetingService {
  // Returns a personalized greeting.
  rpc SayHello(SayHelloRequest) returns (SayHelloResponse);
}

message SayHelloRequest {
  // The name of the person to greet.
  string name = 1;
}

message SayHelloResponse {
  // The personalized greeting message.
  string message = 1;
}

gRPC can be configured to generate:

Service code so you can implement the business logic.
Client code to make requests against the service.

Code for messages is generated by SwiftProtobuf and used in conjunction with the generated gRPC code.

Generated Service Code

The generated code includes a Swift protocol describing the requirements of the service with one method for each rpc in the service definition. To implement the business logic of your service just implement one of the service protocols. The example below uses the SimpleServiceProtocol which is the highest level API. If you need more flexibility you can use the ServiceProtocol or StreamingServiceProtocol which trade off conciseness for flexibility.

To start the service you need to create a server configured to use a transport and an instance of your service:

import GRPCCore
import GRPCNIOTransportHTTP2

struct Greeter: GreetingService.SimpleServiceProtocol {
  func sayHello(
    request: SayHelloRequest,
    context: ServerContext
  ) async throws -> SayHelloResponse {
    return SayHelloResponse.with {
      $0.message = "Hello, \(request.name)!"
    }
  }
}

@main
struct GreeterServer {
  static func main() async throws {
    // Create a plaintext server using the SwiftNIO based HTTP/2 transport
    // listening on 128.0.0.1:8080.
    let server = GRPCServer(
      transport: .http2NIOPosix(
        address: .ipv4(host: "127.0.0.1", port: 8080),
        transportSecurity: .plaintext
      ),
      services: [Greeter()]
    )

    // Start serving indefinitely.
    try await server.serve()
  }
}

Generated Client Code

gRPC generates an idiomatic client for you, simplifying service calls. To use it, first create a raw client and wrap it with the generated client specific to your service. This generated client provides a type-safe way for you to easily interact with your service.

import GRPCCore
import GRPCNIOTransportHTTP2

@main
struct SayHello {
  static func main() async throws {
    // Create a plaintext client using the SwiftNIO based HTTP/2 transport
    // connecting to a service listening on 128.0.0.1:8080.
    try await withGRPCClient(
      transport: .http2NIOPosix(
        target: .dns(host: "127.0.0.1", port: 8080),
        transportSecurity: .plaintext
      )
    ) { client in
      let greeter = GreetingService.Client(wrapping: client)
      let greeting = try await greeter.sayHello(.with { $0.name = "swift.org" })
      print(greeting.message)
    }
  }
}

Package Ecosystem

gRPC Swift 2 was designed with flexibility in mind. It’s distributed as a collection of packages, allowing you to pick and choose the components which best suit your needs. These features are provided by the following packages:

grpc/grpc-swift provides runtime abstractions and types.
grpc/grpc-swift-nio-transport implements client and server transports using HTTP/2 and is built on top of SwiftNIO.
grpc/grpc-swift-protobuf integrates with SwiftProtobuf to provide a code generator for services defined in .proto files.
grpc/grpc-swift-extras includes common gRPC add-ons, like the reflection and health services, integrations with Swift Service Lifecycle, and interceptors to trace RPCs using OpenTelemetry.

Next Steps

To get started with gRPC Swift 2 check out the tutorials and documentation which are hosted on the Swift Package Index, or try out one of the examples in the grpc/grpc-swift repository.

If you have feature requests, want to report a bug, or would like to contribute to the project then please reach out to us on GitHub or join us on the Swift forums. Let’s connect!

Updating the Visual Studio Code extension for Swift

2025-02-10T12:00:00-04:00

Today, we are excited to announce a new version of the Swift extension for Visual Studio Code – now published to the extension marketplace as an official supported release of the Swift team. The aim of this extension is to provide a high-quality, feature-complete extension that makes developing Swift applications on all platforms a seamless experience.

As we continue to invest in Swift as a first-class language for cross-platform development, both Apple and the broader developer community are rapidly iterating on the VS Code extension to expand its capabilities for server and cloud, embedded, and Linux and Windows app development. The original extension was developed by members of the Swift Server Working Group, and with its broader scope, they have graciously supported this transition to the GitHub /swiftlang organization and the creation of a new publisher for the extension.

For existing Swift developers using VS Code, the transition should be seamless: the old release should automatically install the new extension and disable itself, and moving forward all language features will be provided by the new extension. You’re welcome to uninstall the original extension, which has been renamed to reflect its deprecated status.

Further details about the migration can be found on the Swift Forums. If you have any issues migrating, please file an issue or comment on the forum post.

The Next Chapter in Swift Build Technologies

2025-02-01T02:00:00-04:00

Swift continues to grow in popularity as a cross-platform language supporting a wide variety of use cases, with support on a variety of embedded devices, form factors that encompass wearables to server, and a wide variety of operating systems. As Swift expands, there’s value in investing in matching cross-platform build tools that provide a powerful, consistent, and flexible experience across the ecosystem.

As a foundational step in this new chapter of Swift build technologies, today Apple is open sourcing Swift Build, a powerful and extensible build engine that provides a set of build rules for building Swift projects. Swift Build is the engine used by Xcode, which supports millions of apps in the App Store as well as the internal build process for Apple’s own operating systems. The open source repository also includes support for targeting Linux and Windows.

Introducing Swift Build

The primary responsibility of the build system is to transform user-authored inputs (such as a project description and source code) into output artifacts like command line tools, libraries, and applications. Build systems play an important role in providing a great developer experience, enabling higher level features which determine how users architect and work with their projects. Furthermore, the performance and reliability of a build system has a direct impact on developer productivity.

Swift Build is an infrastructural component designed to plan and execute builds requested by a higher-level client like Swift Package Manager or Xcode. It builds on top of the existing llbuild project to add capabilities including:

Robust integration with the Swift compiler to reliably and efficiently coordinate the build of Swift projects
Support for a wide variety of product types including libraries, command line tools, and GUI applications with advanced build configuration options
Build graph optimizations that maximize parallelism when building Swift and C code

Roadmap for Swift Build

Compared to the build engine in Xcode, the build engine in Swift Package Manager is fairly simple. On Apple platforms, having two different ways to build packages has also led to user confusion when the two implementations’ behavior didn’t match. Contributing Xcode’s build engine to the Swift project and developing it in open source alongside the Swift compiler provides the tools necessary to address these problems and deliver a great builds experience to all Swift users. With this release, SwiftPM now has the opportunity to offer a unified build execution engine across all platforms. This change should be transparent to users and maintain full compatibility with all existing packages while delivering a consistent cross-platform experience. At the same time, it lays the foundation to enable new features and improvements across all platforms and tools, and unlocks new performance optimizations and developer-facing features. As a small first step towards this vision, today the team is submitting a pull request to begin the process of integrating support for Swift Build in SwiftPM as an alternate build engine. In the coming months, we’d like to collaborate with the community to complete the work of unifying build system integrations so users can benefit from future tooling improvements across all platforms and project models.

We believe this is an important step in continuing to enable a healthy package ecosystem where developers can rely on a consistent, polished development experience — no matter what IDE they’re using or platform they’re targeting. We’ll be sharing more details about this work on the Swift forums, and we’re looking forward to hearing others’ feedback!

An invitation to participate

We look forward to working with the community to continue evolving how we build Swift code. You can find the swift-build repository in the Swift organization on GitHub, including a README and documentation describing how to build and contribute. Contributions via pull requests and issues are welcome, and we’d also love to solicit feedback and ideas for improvements on the Swift forum.

This is an exciting new chapter for Swift’s build system, and we’re looking forward to all the potential it opens for Swift!

Announcing Swift 6

2024-09-17T06:00:00-04:00

We’re delighted to announce the general availability of Swift 6. This is a major new release that expands Swift to more platforms and domains.

Many people know of Swift as a language for app development, with a million apps on the App Store. But Swift is great for more than just apps. Swift’s safety, speed, and approachability make it a great choice for many other use cases including libraries, internet-scale services, and the most performance-critical and secure code.

Swift 6 scales even further through new low-level programming features, an embedded Swift language subset, expanded Linux and Windows support, new cross-platform APIs including the new Swift Testing library, and more.

Read on for a deep dive into changes to the language, standard libraries, debugging, platform support, and next steps for getting started with Swift 6.

Language and Standard Library

Concurrency

Swift has long offered memory safety, ensuring that variables are initialized before they’re used, memory isn’t accessed after it’s been deallocated, and array indices are checked for out-of-bounds errors. Swift 6 now includes a new, opt-in language mode that extends Swift’s safety guarantees to prevent data races in concurrent code by diagnosing potential data races in your code as compiler errors.

Data-race safety checks were previously available as warnings in Swift 5.10 through the -strict-concurrency=complete compiler flag. Thanks to improved Sendable inference and new compiler analysis for transferring mutable state from one actor to another, Swift 6 warnings about data-race safety have fewer false positives. You can find more information about the Swift 6 language mode and how to migrate at Swift.org/migration.

Swift 6 marks the start of the journey to make data-race safety dramatically easier. The usability of data-race safety remains an area of active development, and your feedback will help shape future improvements.

Swift 6 also comes with a new Synchronization library for low-level concurrency APIs, including atomic operations and a new mutex API.

Typed throws

Swift 6 enables functions to specify the type of error that they throw as part of their signature. This feature is useful in generic code that forwards along errors thrown in client code, or in resource-constrained environments that cannot allocate memory, such as in embedded Swift code.

For example:

func parseRecord(from string: String) throws(ParseError) -> Record { 
  // ... 
}

A call to parseRecord(from:) will either return a Record instance or throw an error of type ParseError. A do..catch block will infer ParseError as the type of the error variable:

do {
  let record = try parseRecord(from: myString)
} catch {
  // 'error' has type 'ParseError'
}

Typed throws generalizes over throwing and non-throwing functions. A function that is specified as throws (without a specific error type) is equivalent to one that specifies throws(any Error), whereas a non-throwing function is equivalent to one that specifies throws(Never). Calls to functions that are throws(Never) are non-throwing and don’t require error handling at the call site.

Typed throws can also be used in generic functions to propagate error types from parameters, in a manner that is more precise than rethrows. For example, the Sequence.map method can propagate the thrown error type from its closure parameter, indicating that it only throws the same type of errors as the closure:

extension Sequence {
  func map<T, E>(_ body: (Element) throws(E) -> T) throws(E) -> [T] { 
    // ... 
  }
}

When given a closure that throws ParseError, map will throw ParseError. When given a non-throwing closure, E is inferred to Never and map will not throw.

Ownership

Swift 5.9 introduced non-copyable types with the ~Copyable syntax for modeling resources with unique ownership, and writing performance-conscious code by eliminating the runtime overhead associated with copying. Swift 6 now supports these types with the generics system, making it possible to write generic code that works with both copyable and non-copyable types.

For example:

protocol Drinkable: ~Copyable {
  consuming func use()
}

struct Coffee: Drinkable, ~Copyable { /* ... */ }
struct Water: Drinkable { /* ... */ }

func drink(item: consuming some Drinkable & ~Copyable) {
  item.use()
}

drink(item: Coffee())
drink(item: Water())

The Drinkable protocol has no requirement that its conforming types are Copyable. This means both the non-copyable type Coffee and copyable type Water can be passed into the generic drink function.

Switch statements can now be written to avoid copying within enum pattern-matching operations. This means that switch statements can be used with non-copyable payloads and can also provide performance benefits for copyable payloads, especially those based on copy-on-write containers like Array and Dictionary.

Non-copyable types are already used throughout the standard libraries. For instance, the new Atomic type in the Synchronization library is based on ~Copyable, Optional and Result can now wrap non-copyable types, and the unsafe buffer pointer types can now point to non-copyable elements. C++ interoperability also uses non-copyable types to expose C++ move-only types to Swift.

C++ interoperability

Swift 5.9 introduced bidirectional interoperability with C++ to seamlessly bring Swift to more existing projects. Swift 6 expands interoperability support to C++ move-only types, virtual methods, default arguments, and more standard library types including std::map and std::optional.

C++ types that do not have a copy constructor can now be accessed from Swift 6 as non-copyable types with ~Copyable. And for those times when it’s useful to expose a C++ type with a copy constructor as ~Copyable in Swift for better performance, a new SWIFT_NONCOPYABLE annotation can be applied to the C++ type.

Swift now also supports calls of C++ virtual methods on types annotated as SWIFT_SHARED_REFERENCE or SWIFT_IMMORTAL_REFERENCE.

When calling C++ functions or methods that have default argument values for some of their parameters, Swift now respects these default values, rather than requiring you to explicitly pass an argument.

Embedded Swift

Swift 6 includes a preview of Embedded Swift, a language subset and compilation mode suitable for embedded software development, such as programming microcontrollers. The toolchain supports ARM and RISC-V bare-metal targets.

Embedded Swift produces small and standalone binaries by relying on generic specialization. Since it doesn’t rely on a runtime or type metadata, Embedded Swift is suitable for platforms with tight memory constraints as well as use in low-level environments with limited runtime dependencies.

Embedded Swift remains an experimental feature, with ongoing development before stable support in a future Swift release.

128-bit Integers

Swift 6 rounds out the set of low-level integer primitives with the addition of signed and unsigned 128-bit integer types. These are available on all Swift platforms, and provide the same API as other fixed-width integer types in the standard library.

Productivity enhancements

Swift 6 introduces a number of productivity enhancements, including count(where:) to streamline counting the number of elements in a sequence that satisfy a predicate, pack iteration for writing natural for-loops over the elements in a value parameter pack, access control for imports to keep implementation details from leaking into your public APIs, @attached(body) macros for synthesizing and augmenting function implementations, expression macros as default arguments, and more.

You can find a complete list of language proposals that were accepted through the Swift Evolution process and implemented in Swift 6 on the Swift Evolution dashboard.

Debugging

Custom LLDB summaries with `@DebugDescription` @DebugDescription section" href="#custom-lldb-summaries-with-debugdescription">

Swift 6 provides a new debugging macro to easily customize how an object is displayed in LLDB when using the p command, and in the variables view in Xcode and VSCode, by using a formatting scheme that does not run arbitrary code.

Types that conform to CustomDebugStringConvertible provide a debugDescription property that returns a string describing the object. In LLDB, the po command calls this computed property on an object. In contrast, the p command uses LLDB’s type summary formatters to directly format the object using its stored property values.

@DebugDescription is a new macro in the standard library which lets you specify LLDB type summaries for your own types directly in code. The macro processes the debugDescription property, translating simple string interpolations involving stored properties into LLDB type summaries. This allows LLDB to use your custom formatting even when using p, and also in Xcode or VSCode’s variable display windows. The macro can use an existing conformance to CustomDebugStringConvertible, or you can provide a separate string interpolation only for use in LLDB’s p command. Providing a separate LLDB description string is useful if your CustomDebugStringConvertible implementation doesn’t meet the requirements of the @DebugDescription macro, or if you’re familiar with the LLDB Summary String syntax and you want to use it directly.

For example, the following code customizes how po in LLDB displays the Organization type with a conformance to CustomDebugStringConvertible, and the @DebugDescription macro exposes this custom formatting to the p command and the variables view:

@DebugDescription
struct Organization: CustomDebugStringConvertible {
  var id: String
  var name: String
  var manager: Person
  // ... and more

  var debugDescription: String {
    "#\(id) \(name) [\(manager.name)]"
  }
}

(lldb) p myOrg
(Organization) myOrg = "`#100 Worldwide Travel [Jonathan Swift]`" 

Improved startup performance with explicit modules

Swift 6 dramatically improves startup performance in the debugger when you use explicit module builds. When debugging locally-built code, LLDB can now import explicitly-built Swift and Clang modules directly from the project build artifacts. This avoids the need to recompile implicit Clang module dependencies from source, which can take a long time, and it’s very sensitive to issues with header search paths. If the first p or po command in LLDB takes a long time due to Clang module compilation, or if your debugging is frequently blocked by Clang header import problems, consider adopting explicit modules in your project!

Libraries

Foundation

Swift 6 unifies the implementation of Foundation across all platforms. The modern, portable Swift implementation provides consistency across platforms, it’s more robust, and it’s open source. macOS and iOS started using the Swift implementation of Foundation alongside Swift 5.9, and Swift 6 brings these improvements to Linux and Windows.

Core types like JSONDecoder, URL, Calendar, FileManager, ProcessInfo, and more have been completely reimplemented in Swift. These types share their implementation with macOS 15 and iOS 18, providing a new level of cross-platform consistency, reliability, and performance. Recently released APIs like FormatStyle, ParseStrategy, Predicate, and JSON5, from past macOS and iOS releases are now available on all Swift platforms. New Foundation APIs like Expression, calendar enumeration improvements, calendar recurrence rules, format style enhancements, and more are available simultaneously on macOS, iOS, Linux, and Windows - and they were built with community involvement.

If your Linux or Windows app imports the Foundation library from the Swift toolchain today, you get all of these improvements for free. And if your app is particularly sensitive to binary size, you can now import the FoundationEssentials library, which provides a more targeted subset of Foundation’s features that omits internationalization and localization data.

Swift Testing

Swift 6 introduces Swift Testing, a new testing library designed from the ground up for Swift. It includes expressive APIs that make it easy to write and organize tests. It provides detailed output when a test fails using macros like #expect. And it scales to large codebases with features like parameterization to easily repeat a test with different arguments.

For example:

@Test("Continents mentioned in videos", arguments: [
  "A Beach",
  "By the Lake",
  "Camping in the Woods"
])
func mentionedContinents(videoName: String) async throws {
  let videoLibrary = try await VideoLibrary()
  let video = try #require(await videoLibrary.video(named: videoName))
  #expect(video.mentionedContinents.count <= 3)
}

Swift Testing takes full advantage of macros. Its @Test and @Suite attached macros declare test functions and suite types respectively, and they accept arguments (known as traits) to customize various behaviors. The #expect and #require expression macros validate expected behaviors, and capture rich representation of expressions and their sub-values to produce detailed failure messages.

Since Swift Testing is included directly in Swift 6 toolchains, you can import Testing without needing to declare a package dependency. This means your tests do not need to build Swift Testing or its dependencies (including swift-syntax), and its macro implementation comes prebuilt. The package manager in Swift 6 automatically builds and runs Swift Testing tests in addition to XCTests (if present), and shows results from both libraries in log output. Swift Testing supports all platforms that Swift officially supports, including all Apple platforms, Linux, and Windows.

To learn more about this new open source project, visit the swift-testing repository on GitHub, and get involved with its ongoing development on the forums.

Platform Support

Swift is designed to support development and execution on all major operating systems, and platform consistency and expansion underpins Swift’s ability to reach new programming domains. Swift 6 brings major improvements to Linux and Windows across the board, including support for more Linux distributions and Windows architectures. Toolchains for all of the following platforms are available for download from Swift.org/install.

Fully static SDK for Linux

Swift 6 supports building fully statically linked executables for Linux; these have no external dependencies, so they are ideal for situations where you want to copy a program directly onto a system or into a container and run it without installing any extra software. The SDK can also be used to cross-compile to Linux from other platforms. Learn how to get started with the static SDK for Linux on Swift.org.

New Linux distributions

Swift 6 adds official support and testing for Debian and Fedora, as well as on Ubuntu 24.04.

Windows build performance

Prebuilt toolchains are now available for the arm64 architecture, which provides improved compiler performance for Windows on ARM hosts. In Swift 6, the Swift package manager also parallelizes builds across multiple cores on Windows by default. On a 10-core machine, this can improve build performance by up to a factor of 10!

Next Steps

Download Swift 6

You can try out these exciting new developments in Swift 6 today! Install the official Swift 6 toolchains for macOS, Linux, and Windows at Swift.org/install.

Get started with Swift

The Swift Programming Language book has been updated to reflect the latest Swift 6 syntax and features. It serves as the official Swift guide and an excellent starting point for learning the language.

To help kickstart your Swift journey, Swift.org/getting-started offers tutorials for various use cases, including building a cross-platform library, a web service using Vapor, and an embedded application for a microcontroller. There are also articles for diving deeper into some of Swift’s most popular features.

Explore the package ecosystem

The Swift package ecosystem is continuously growing with new technologies to help you with a variety of tasks in your projects. You can explore package highlights at Swift.org/packages, which features popular package categories and a selection of new and notable packages that are hand-curated from an open nomination process every month.

Get involved

Your experience with Swift 6 and your feedback can help shape the future evolution of the language, the tools, the package ecosystem, and the community. You can get involved by sharing your packages, documentation improvements, educational content, bug reports and enhancement requests, code contributions, and participating in forum discussions. Learn more at Swift.org/contributing.

Swift 6 is the culmination of countless contributions from members across the Swift community, and it marks a decade of building this incredible language, ecosystem, and community together. Thank you to everyone who participated in development and provided feedback. Your contributions make Swift a better language.

Introducing Oblivious HTTP support in Swift

2024-08-21T06:00:00-04:00

We’re excited to introduce an implementation of provisional support for Oblivious HTTP to the Swift ecosystem, with the availability of a new package called SwiftNIO Oblivious HTTP.

Oblivious HTTP is a protocol to allow a client to make requests of a server without the server being able to identify the source of those requests. Conventional HTTP requests can reveal identifying information about the client such as the originating IP address, and can allow multiple requests from the same client to be identified as originating from the same node. In contrast, Oblivious HTTP provides a secure mechanism for protecting identifying client information, achieved by combining HTTP message encryption with a trusted third party relay service, providing increased privacy to users without incurring a significant performance overhead.

Oblivious HTTP is a vital foundational technology that supports an emerging range of privacy-preserving networking technologies, including proposals for enhancing privacy in DNS. At Apple, we’re also using it to enable the industry-leading privacy of Apple devices into the cloud with Private Cloud Compute. Oblivious HTTP helps ensure that personally identifiable data about the requesting source is never available to the device processing the request. It also hardens the system against attempts to target an individual’s personal data requests.

SwiftNIO Oblivious HTTP

The package we’re releasing today is still in active development, and forms part of the SwiftNIO project for development of maintainable high-performance network code. It supports two separate standards:

An implementation of RFC 9292, which standardizes a binary representation for serializing HTTP.
An implementation of RFC 9457, which defines Oblivious HTTP itself.

These two implementations can either used together or separately; they enable Swift clients to use services that rely on Oblivious HTTP, as well as enabling Swift servers to implement the specification.

The package itself is split into two libraries:

The headline library OblivousHTTP provides an implementation of the binary HTTP encoding scheme from RFC 9292 required to implement Oblivious HTTP, as well as bindings to that scheme for SwiftNIO.
The second library ObliviousX provides more generalizable APIs that form the basis of the encryption scheme used by Oblivious HTTP, but which can also be applied to other encodings of your choice.

Binary HTTP Encoding

The Binary HTTP representation from RFC 9292 defines a mechanism to serialize and deserialize an abstract HTTP message that does not rely on a specific wire format, such as HTTP/1.1 or HTTP/2. SwiftNIO Oblivious HTTP offers a very simple serialization and deserialization API. As an example of how to use the API to serialize and deserialize:

import ObliviousHTTP
import NIOCore
import NIOHTTP1

let serializer = BHTTPSerializer()
var buffer = ByteBuffer()
serializer.serialize(.request(.head(.init(method: .GET))), into: &buffer)
serializer.serialize(.request(.body(payload)), into: &buffer)
serializer.serialize(.request(.end(nil)), into: &buffer)

var parser = BHTTPParser(role: .server)
parser.append(buffer)
parser.completeBodyReceived()

while let message = try parser.nextMessage() {
    print(message)
}

Oblivious Encapsulation

The Oblivious HTTP specification marries the binary serialization format for HTTP with an encryption scheme built on top of Hybrid Public Key Encryption (HPKE). This encryption scheme is entirely general, so it may be used for any arbitrary data in addition to binary HTTP messages.

The ObliviousX library provides a complete series of APIs for working with this encapsulation scheme. They come in two flavours: single-shot functions, that implement the OHTTP scheme from RFC 9457, and streaming flavours that implement the scheme defined in the draft chunked OHTTP specification. As an example of the use of the one-shot APIs:

import ObliviousX

// Encryption

let message = Data("Hello, this is my secret message".utf8)
let (encapsulatedRequest, sender) = OHTTPEncapsulation.encapsulateRequest(
    keyID: serverKeyID,
    publicKey: serverPublicKey,
    ciphersuite: .P256_SHA256_AES_GCM_256,
    mediaType: "text/plain",
    content: message
)

// Decryption
let (header, consumedBytes) = OHTTPEncapsulation.parseRequestHeader(
    encapsulatedRequest: encapsulatedRequest
)
assert(header.keyID == serverKeyID)
assert(header.kem == .P256_HKDF_SHA256)
assert(header.kdf == .HKDF_SHA256)
assert(header.aead == .AES_GCM_256)

let decapsulator = OHTTPEncapsulation.RequestDecapsulator(
    requestHeader: header,
    message: encapsulatedRequest.dropFirst(consumedBytes)
)
let (deEncapsulated, context) = try decapsulator.decapsulate(
    mediaType: "text/plain",
    privateKey: serverPrivateKey
)

assert(deEncapsulated == message)

What’s Next

This package is released in an early development stage to solicit feedback and contributions. You can get started by trying out the SwiftNIO Oblivious HTTP library on GitHub, as well as join us on the Swift forums to discuss the library and suggest improvements.

While the core encryption scheme is believed to work well, we’re still completing design work for the complete set of bindings for Binary HTTP and Oblivious HTTP. In addition, the following items are on our roadmap:

Producing a better binding to SwiftNIO, in the form of ChannelHandlers that can be dropped into the ChannelPipeline.
Producing versions of BinaryHTTP that use swift-http-types instead of SwiftNIO’s types, for better composition with the rest of the Swift ecosystem and potentially remove the need to depend on SwiftNIO at all.
Final support for chunked Oblivious HTTP, when that draft is finalized at the IETF.
Other API tweaks to support a wider range of use cases.

We welcome community feedback at this stage of the design process, as well as contributions in the form of pull requests and issues, as we work to refine support over the coming months and deliver greater privacy protections to the foundations of the modern internet.

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

Redesigned Swift.org is now live

Brand new design

Curated content and examples

Next Steps

Swift at Apple: Migrating the Password Monitoring service from Java

Choosing Swift for increased performance

Our experience developing with Swift

Takeaways for future Swift on server development

ICYMI: Memory Safety, Ecosystem Talks, and Java Interoperability at FOSDEM 2025

Memory Safety in Swift

Swift DevRoom

Java Interoperability

Swift 6.1 Released

Language and Standard Library

Concurrency

Implementing Objective-C types in Swift

Productivity enhancements

Package and build improvements

Swift Testing

Swift-DocC

Install Swift 6.1

Introducing swiftly 1.0

Introducing swiftly

Quick tour

How swiftly works

Installing Swift, swiftly

How Swift's server support powers Things Cloud

Switching to Swift

The new Swift-based service architecture

Code

Deployment

Storage

Other Services

Monitoring

Results

Conclusions

Introducing gRPC Swift 2

Highlights

Hello, swift.org!

Generated Service Code

Generated Client Code

Package Ecosystem

Next Steps

Updating the Visual Studio Code extension for Swift

The Next Chapter in Swift Build Technologies

Introducing Swift Build

Roadmap for Swift Build

An invitation to participate

Announcing Swift 6

Language and Standard Library

Concurrency

Typed throws

Ownership

C++ interoperability

Embedded Swift

128-bit Integers

Productivity enhancements

Debugging

Custom LLDB summaries with @DebugDescription @DebugDescription section" href="#custom-lldb-summaries-with-debugdescription">

Improved startup performance with explicit modules

Libraries

Foundation

Swift Testing

Platform Support

Fully static SDK for Linux

New Linux distributions

Windows build performance

Next Steps

Download Swift 6

Get started with Swift

Explore the package ecosystem

Get involved

Introducing Oblivious HTTP support in Swift

SwiftNIO Oblivious HTTP

Binary HTTP Encoding

Oblivious Encapsulation

What’s Next

Announcing Swift Homomorphic Encryption

Private Information Retrieval (PIR)

Custom LLDB summaries with `@DebugDescription` @DebugDescription section" href="#custom-lldb-summaries-with-debugdescription">