Apple rewrote a font bytecode interpreter from C to Swift — and it got 13% faster

A safer interpreter that's also faster

Apple's writeup covers a rewrite that sounds counterintuitive: take a performance-sensitive C bytecode interpreter, move it to a memory-safe language, and end up faster. The TrueType hinting interpreter runs little bytecode programs embedded in fonts to nudge glyph outlines onto a pixel grid at low resolution. Crucially, it executes data from untrusted sources — PDFs, web pages — which makes it a prime attack surface: "input-driven control flow, complex data structures, and careful memory management," exactly where C goes wrong.

The numbers Apple put on it

The Swift version shipped in the Fall 2025 OS releases with concrete results:

• 13% average speedup over the C implementation
• Pixel-identical rendering, verified across 27 million glyphs under four transformations each
• The memory-safety bug class eliminated, with only "a small number of thoroughly verified unsafe statements" at the C interop boundary
• A test suite with 99.7% code coverage, with nearly 4× as many lines of test code as interpreter code
• A 10-million-PDF fuzzer corpus minimized to 4,200 files with no loss of coverage

To hit the speed targets in a safe language, the team leaned on newer Swift features: noncopyable types (\~Copyable) to drop reference-counting overhead, the Span type for copy-free sequence access, projection types wrapping C structs, and continuation-passing to keep stack operations off the heap. Scott Perry of Apple's Security team led it; the code is on GitHub as a reference implementation, under MIT rather than Apple's usual Apache 2.

"Welcome to the club"

The people who've done memory-safe text rendering recognized the milestone. A principal engineer who works on fonts in Rust offered the warmest read:

"Welcome to the club of doing high performance text in a memory safe language!" — a principal engineer researching 2D graphics and fonts in Rust

It also revived an old what-if: Microsoft floated rewriting its font stack in Rust back in 2023 for the same reasons, and more than one reader wondered what Apple's world would look like had it picked Rust as the default instead of Swift.

The asterisk on Swift's shiny new lifetimes

The sharpest counter came from a developer who'd tried the exact features the post showcases:

"When I tried to use the lifetime features shown off in this post, I ran into constant compiler crashes with very simple programs, until I gave up and wrote off the features as unusable. This happened on both stable and nightly compilers… I suspect they're using a narrow subset of what the features are supposed to support." — comex

That's the honest frame: Apple's team got a polished result out of a feature set that's still rough for everyone else. Others poked at scope — hinting only fires at low resolution, and one reader noted Apple draws much of its own UI unhinted, so this interpreter mostly earns its keep rendering PDFs. The takeaway isn't "Swift beats C." It's that a security-critical interpreter can be moved off C without paying the performance tax everyone assumed was mandatory — if you also write 4× the test code.