John Sundell:

New in Swift 6.4 […] is a warning which is emitted when a nested closure performs a weak capture while the parent closure implicitly captures that object as a strong reference.

At first glance, that new diagnostic could be a bit puzzling, since it might seem unnecessary to have to specify such a weak capture twice (or, alternatively, move it to the parent closure’s capture list), but it turns out that it’s an incredibly useful new warning that can help us avoid a quite common kind of memory management bug.

[…]

Finally, in situations where capturing self strongly doesn’t actually lead to a retain cycle, we can silence the new warning for nested weak captures by explicitly adding self to the outer closure’s capture list, such as when creating a Task within the following example[…]

Previously:

• Swift 6.4
• Xcode 27 Announced
• How to Automate Memory Leak Detection With XCTest
• Avoiding Implicit Retain Cycles When Using Swift Function References
• Weak Self: Closure Rules of Thumb
• Swift “guard” Capture Specifier Pitch
• Implicit Capturing of Self in Swift 5.3
• Dealing With Weak in Closure-based Delegation
• Stop the weak-strong Swift Dance

Scott Perry:

My team rewrote Apple’s TrueType hinting interpreter in Swift, ask me anything.

[…]

I feel like naming just one would be a disservices to all of the features that made this effort possible (C interop, generics, noncopyable/nonescapable types) but at the end of the day I think the star of the show was the optimizer; despite being faster than the code it replaced, the new code is super readable and that was only possible because the optimizer was able to completely eliminate all of our abstractions.

The new version is faster, but the main motivation was security concerns.

Dmitrii Kalianov:

Is hinting useful/being used in the days of hi-dpi displays? I was under impression that Apple switched to grayscale anti-aliasing and ditched hinting.

Scott Perry:

For the most part hinting isn’t really necessary anymore, but thanks to being Turing-complete it has been Hyrum’s law-ed by at least one CJK font that uses hinting to lay out strokes in its characters.

Alex Rosenberg:

There were three major TrueType implementations at Apple IIRC:

• The original 68K one
• A rewrite for Copland that lived with ATS/ATSUI after Copland was cancelled
• iPhone shipped one derived from heavily-modified FreeType that was current until today

Scott Perry:

One of the axioms for this project was that I wanted my team to write the most boring code possible—nearly identical structurally to the code it was replacing, because to do otherwise would introduce binary compatibility risk. The other axiom was 100% test coverage for all new code as it landed, with the same units testing both interpreters.

Rosyna Keller:

Is the font parsing code itself still C++?

Scott Perry:

There is also a “Safe Font Parser” for WebKit in Lockdown Mode, but it supports a subset of all the myriad features provided by font formats.

Previously:

• Glow Leopard
• llama.ttf
• A Year of Windows Kernel Font Fuzzing
• Emoji Fonts Use Undocumented Features
• Font Parsing Vulnerabilities

Update (2026-06-16): Scott Perry (Hacker News):

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.

[…]

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.

[…]

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.

[…]

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.

The interpreter source is on GitHub.

Marcin Krzyzanowski:

@_lifetime(copy code, copy twilightZone, copy glyphZone)

See also: Phillip Tennen’s Writing a TrueType font renderer (Hacker News).

Previously:

• Lifetime Dependencies in Swift 6.2 and Beyond