Source linked

Apple Rewrote TrueType Hinting in Swift, and It's 13% Faster

Apple's security team migrated the critical TrueType hinting interpreter from C to memory-safe Swift, achieving a 13% performance improvement and eliminating a major attack surface.

swiftappletruetypefont renderingmemory safetysoftware engineering

Apple’s security team just shipped a rewrite of the TrueType hinting interpreter that runs 13% faster than the C code it replaced — while eliminating a huge class of memory-safety bugs. Scott Perry published the story and the source on Swift.org.

TrueType font parsers process untrusted data from web pages, PDFs, and user-installed fonts. That makes the hinting interpreter — a bytecode engine that runs programs embedded inside fonts — a prime attack surface. Perry’s team rewrote it in memory-safe Swift for the Fall 2025 releases across macOS, iOS, and all Apple platforms.

Why the TrueType Interpreter Was the Perfect Target

TrueType was designed in the late 1980s for low-resolution displays where hinting radically changes glyph appearance. By 2008, fonts could be embedded in web pages, exposing the interpreter to untrusted code from anywhere on the internet. The C implementation had input-driven control flow, complex data structures, and careful memory management — exactly the kind of code where memory errors are easiest to exploit.

A rewrite required pixel-identical output, not just interface compatibility. Hinting can completely change how a glyph looks, so any behavioral divergence would be visible in rendered text across the entire OS. Perry defined correctness as bit-for-bit identical bitmaps to the C implementation.

Pixel-Perfect Compatibility Through Exhaustive Testing

To validate correctness, the team built two test suites. The unit test suite achieved 99.7% code coverage for both the C and Swift interpreters and ships with the open-source release. For real-world workloads, they used a fuzzer to minimize a corpus of 10 million PDF files down to 4,200 documents without losing any code coverage. Those documents embedded 25,572 fonts containing 27 million glyphs, each rendered at four different transformations and compared to the reference interpreter.

Perry reports that test code outnumbered implementation code 4:1 — nearly four times as many lines of test code as Swift interpreter code.

How Swift’s Features Delivered 13% Speedup

Performance was the final hurdle. The team iterated on benchmarks rendering all glyphs from three different fonts, guided by PDF render-time measurements. They adopted ~Copyable value types throughout the architecture to eliminate the overhead of automatic reference counting and runtime exclusivity checking — both exacerbated by unavoidable aliasing in the interpreter’s design. Span, introduced in Swift 6.2 with back-deployment to macOS 10.14.4 and iOS 12.2, let them operate efficiently on sequences of these value types.

They also reorganized data layout. The original C code stored glyph outline points in one struct with eight arrays — cache-friendly but rigid. The Swift implementation uses a sequence of points with individual flags and coordinate pairs, matching Swift idioms without sacrificing performance.

The result: an interpreter that is not only memory-safe but measurably faster than the hand-tuned C it replaces. Apple has published the full source code on Swift.org, giving the community a concrete reference for writing systems-level Swift with performance parity to C.


Source: Swift at Apple: Migrating the TrueType Hinting Interpreter
Domain: swift.org

Read original source ->

External source stays available while the OJO article and comment thread stay local.

Comments load interactively on the live page.