Swift Release Notes

What's Changed

• Update links for repositories moved from apple to swiftlang by @TTOzzi in #1048
• Refactored file generation logic to be string-based and added validation tests by @TTOzzi in #1047
• Include _GenerateSwiftFormat in buildOnlyTests by @TTOzzi in #1050
• Add support for InlineArray type sugar by @TTOzzi in #1043
• Ensure newline after trailing line comments to prevent formatting issues by @TTOzzi in #1015
• .swift-format: Specify an exhaustive configuration by @AnthonyLatsis in #1057
• Introduce multilineTrailingCommaBehavior configuration by @TTOzzi in #1044
• Use Invoke-Program for the Windows build command by @bnbarham in #1060
• Enable cross-PR testing by @ahoppen in #867
• Fix removing empty trailing closure parentheses in a curried call by @a7medev in #1071
• Add workflow to auto-update PrintVersion on release branch creation by @TTOzzi in #1068
• Fix UseSingleLinePropertyGetter dropping comments by @TTOzzi in #1062
• Fix auto_update_version workflow to trigger only on release branch creation by @TTOzzi in #1074
• Fix invalid rewrite in UseExplicitNilCheckInConditions by skipping when explicit optional type annotation is present by @TTOzzi in #1075
• chore: restrict GitHub workflow permissions - future-proof by @incertum in #1073
• Fix up AttributeTypeSyntax handling by @bnbarham in #1086
• Remove added group around base type in AttributedTypeSyntax by @bnbarham in #1088
• Skip the update-version job on a fork by @kkebo in #1091
• [6.3] Update version to 6.3 by @github-actions[bot] in #1089
• Add GitHub workflow to ensure formatting is not broken on a set of pilot projects by @ahoppen in #1090
• print lint location and message in plain bold instead of white by @QuietMisdreavus in #1092
• Order conditionally-compiled imports by @a7medev in #1077
• Normalize release version to x.y.z in auto-update-version action by @TTOzzi in #1095
• Keep attributed getters intact in UseSingleLinePropertyGetter by @TTOzzi in #1104
• Respect indentBlankLines when stripping whitespace inside block comment blank lines by @TTOzzi in #1101
• Format source code and run git diff instead of listing first by @ahoppen in #1093
• Update release automerge from 6.2 to 6.3 by @bnbarham in #1098
• Bump to 6.0 by @bnbarham in #1107
• Merge main into release/6.3 by @github-actions[bot] in #1109
• Add Dependabot configuration for GitHub Actions by @shahmishal in #1110
• Update pull request workflow to use the tagged github-workflows by @bnbarham in #1111
• Bump actions/checkout from 4 to 6 by @dependabot[bot] in #1112
• Remove Ben Barham from code owners by @bnbarham in #1113
• Use the tagged workflows for all workflows, not just PR testing by @bnbarham in #1115
• Bump the default publishing version on main to 604 by @bnbarham in #1116
• Update allowed publishers by @bnbarham in #1117
• Add Holly Borla to code owners by @rintaro in #1123
• Don't test with swift-5.x in Publish Release workflow by @rintaro in #1122
• Merge main into release/6.3 by @github-actions[bot] in #1121
• [6.3] Change swift-syntax dependency to release/6.3 by @rintaro in #1125
• [6.3] Add Holly Borla to code owners by @hborla in #1126
• Merge main into release/6.3 by @github-actions[bot] in #1127
• [6.3][cherrypick] Add option to install without building. by @3405691582 in #1174
• [6.3][cherrypick] Fix rpath handling on OpenBSD. by @3405691582 in #1176
• Bump the Swift version to 6.3.2 by @shahmishal in #1182
• Bump the Swift version to 6.3.3 by @shahmishal in #1206
• [6.3][Workflow] Accept warnings in Publish Release by @rintaro in #1230

New Contributors

• @a7medev made their first contribution in #1071
• @incertum made their first contribution in #1073
• @QuietMisdreavus made their first contribution in #1092
• @hborla made their first contribution in #1126

Full Changelog: 602.0.0...603.0.0

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

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

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

TrueType and the hinting engine

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

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

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

Rewriting in Swift

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

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

Validating correctness

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

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

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

Achieving high performance

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

Minimizing runtime overhead

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

These sources of overhead can be eliminated by giving up the convenience of copyability, adopting ~Copyable value types (see also: struct instead of class) throughout the architecture, reserving reference types for high-level abstractions.

Span, introduced in Swift 6.2 with back-deployment support all the way back to macOS 10.14.4 and iOS 12.2, allowed us to efficiently operate on sequences of these types.

Moving data around

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

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

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

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

[Code snippets omitted for brevity]

Short-lived allocations

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

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

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

[Code snippets omitted for brevity]

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

Dynamic dispatch

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

Zero-cost abstractions

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

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

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

Memory-safe and faster than C

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

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

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

[Chart and legend omitted]

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

Swift in practice

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

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

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

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

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

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

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

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

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

• Local community: they’re building local connections among Swift developers and organizations.
• Room for experimentation: by being less formal and sometimes featuring works in progress, meetups create space to share ideas, get feedback, and learn from one another.

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

— Dave Lester

Now on to other news about Swift:

Videos to watch

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

Community highlights

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

New package releases

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

Swift Evolution

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

Under active review:

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

Recently accepted:

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