Rewriting Apple’s TrueType Hinting Interpreter in Swift
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.
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.
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.
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
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.
Is the font parsing code itself still C++?
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
Reffor lifetime safety, brokers bounds-safe access to the underlying data, and returns idiomatic Swift types to its callers.
The interpreter source is on GitHub.
@_lifetime(copy code, copy twilightZone, copy glyphZone)
See also: Phillip Tennen’s Writing a TrueType font renderer (Hacker News).
Previously:
3 Comments RSS · Twitter · Mastodon
>I was under impression that Apple switched to grayscale anti-aliasing and ditched hinting.
My impression was Apple's subpixel rendering never used hinting, but rather scaled down a larger font, whereas Windows ClearType (_also_ basically deprecated) _did_ use hinting, the trade-off being that ClearType looks sharper, but Apple's approach is more typographically accurate.
>Apple uses FreeType in iOS[14] and macOS[16] next to Apple Advanced Typography.
Does that mean subpixel rendering is related to Copland / ATSUI, whereas grayscale rendering (and _all_ rendering on iOS) is currently FreeType? (Leaving aside Safari's special case.)
Also, does this rewrite mean appleOS 27 _doesn't_ use FreeType?
Seems like a successful rewrite. Keep it boring, 100% test coverage backtested to the old version, focus on observable behaviors. I debate Swift being "super readable", but it was pragmatic to use given his requirements.
Compare this to the disaster rewrite of mDNSResponder -> discoveryd. Or Canonicals's CoreUtils rewrite in Rust (which is focused entirely on the ideology of "#RUST!" being magical).
>Seems like a successful rewrite. Keep it boring, 100% test coverage backtested to the old version, focus on observable behaviors. I debate Swift being "super readable", but it was pragmatic to use given his requirements.
Yes, it's good to see that the team in charge had these in mind, ensuring compatibility while adding increased security:
>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.
It's also great to see that they were able to make the Swift interpreter faster than the C interpreter they replaced. Increased optimized performance should always be one of the main goals for rewrites, not change for change's sake.
>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.
>On average, the Swift interpreter runs 13% faster than the C interpreter it replaced.
Source: https://www.swift.org/blog/migrating-truetype-hinting-to-swift/
