Apple rewrites TrueType hinting engine in Swift, gains memory safety and 13% speed

Apple has replaced the C implementation of TrueType’s hinting interpreter with a memory-safe Swift version, shipping in its Fall 2025 OS releases. The hinting engine is a decades-old bytecode interpreter that adjusts glyph outlines for legibility, and because fonts arrive from untrusted sources — embedded in PDFs and web pages — it has long been a prime attack surface. Input-driven control flow and manual memory management made the original C code exactly the kind of component where exploitable memory bugs hide. Despite the safety overhead typically associated with Swift, the new interpreter averages 13% faster than the code it replaced, and Apple has open-sourced it.

The project’s bar was strict: pixel-identical rendering compared to the C implementation, since even tiny behavioral differences in hinting visibly change glyphs on screen. Validation combined a unit test suite with 99.7% code coverage across both implementations and a fuzzer-minimized corpus — 10 million PDFs reduced to 4,200 files embedding 25,572 fonts and 27 million glyphs, each rendered under four transformations and bit-compared against the reference. The team ended up writing nearly four times more test code than interpreter code.

The performance work is the most instructive part for engineers weighing similar migrations. Apple eliminated reference-counting and exclusivity-checking overhead by adopting non-copyable value types, used Swift 6.2’s Span for efficient sequence access, and replaced naive copy-based C-to-Swift bridging — initially 20% of runtime — with projection types that wrap C structures safely in place, following WebKit’s Safer Swift guidelines with documented SAFETY invariants on every unsafe expression. The result is a concrete counterexample to the assumption that memory-safe rewrites of performance-critical parsers must cost speed.