Appleのフォントインタプリタが Swift 化、しかも13%高速に

Appleのセキュリティチームが、議論に決着をつけるたぐいの成果を公開しました。1991年以来 Apple プラットフォーム上で信頼できないフォントデータを解析してきたバイトコードインタプリタ、すなわち TrueType ヒンティングインタプリタが、C からメモリ安全な Swift へと書き換えられたのです。そして「平均すると、私たちの Swift インタプリタは、置き換え対象だった C インタプリタより13%高速に動作します」とのことです。¹ この記事を執筆したのは、Swift の採用を担当する Apple セキュリティチームの一員、Scott Perry 氏。ソースコードはリファレンス実装として GitHub に公開されており、正しさの基準は「テストに合格する」ことではなく、C のオリジナルと比べてピクセル単位まで同一にレンダリングされることでした。¹ メモリ安全で、C より高速、しかも2025年秋のリリース以降は本番環境で稼働中——この記事は、メモリ安全性がパフォーマンスを犠牲にするという主張に対する、これまでで最も強力な実証的回答だといえるでしょう。

TL;DR

• Apple が TrueType ヒンティングインタプリタを C から Swift へ書き換えたのは、フォントパーサがセキュリティ上きわめて重要な攻撃面だからです。このインタプリタはフォントに埋め込まれたバイトコードを実行しますが、それは「入力に駆動される制御フロー、複雑なデータ構造、そして慎重なメモリ管理——まさに完璧にするのが難しく、メモリエラーが悪用されやすいたぐいのコード」なのです。¹
• その成果は2025年秋のリリースに搭載され、「有効化以降、これに対するバグ報告は1件もなく」、C 実装より平均13%高速です。¹
• パフォーマンス向上は、具体的かつ移植可能な手法から生まれました。参照カウントと排他性チェックのオーバーヘッドを取り除く ~Copyable および ~Escapable 値型、安全なシーケンスアクセスのための Span、実行時間の約20%を占めていたコピーを排除した C 構造体上の射影型、そしてジェネリクスを特殊化可能に保つこと、です。¹
• 検証こそが静かなる傑作でした。両実装にまたがるカバレッジ99.7%のユニットテスト群、ファザーで最小化した1,000万件の PDF を25,572フォントを埋め込んだ4,200件の文書へ絞り込んだコーパス、それぞれ4種類の変換のもとでレンダリングされ1ビットずつ比較された2,700万グリフ、そしてインタプリタのコードのおよそ4倍にのぼるテストコード。¹
• インタプリタのソースは、リファレンス実装として意図された本番コードとして、MIT ライセンスのもと apple/truetype-hinting-interpreter-example で公開されています。²

フォントインタプリタがなぜセキュリティの物語なのか

TrueType フォントにはプログラムを含めることができます。Apple が1980年代後半に生み出したこのフォーマットには、特殊用途のバイトコードインタプリタを中心に構築されたヒンティングエンジンが搭載されており、低解像度ディスプレイ上でもアウトラインを忠実にラスタライズすることを目的としています。¹ 1994年に TrueType が PDF へ埋め込み可能になり、2008年に Web ページへ埋め込み可能になると、そのインタプリタは「インターネット上のどこからでもやってくる信頼できないフォント」からプログラムを実行しはじめました。¹ iOS セキュリティの歴史を追ってきた人なら、この話の行き着く先はご存じでしょう。フォントパーサは、このプラットフォームでもっとも有名な悪用チェーンのいくつかを担ってきました。記事は歴史の講義を持ち出すまでもなく、その構造的な理由を名指しします。入力に駆動される制御フローと手動のメモリ管理が同居する場所、そこにメモリエラーは棲みつくのです。

チームに課された制約は、この書き換えをまっさらな移植よりも難しいものにしました。バイナリ互換性が求められたため、既存のプログラムは「以前とまったく同じように機能しつづける必要があり、事実上、新しい実装が動いていることに気づかないほどでなければならない」とされ、しかもヒンティングは画面上でグリフの見え方を大きく変えうるため、正しさは「C 実装の出力との完全な互換性」と定義されました。¹ おおむね正しい、ではなく、ピクセル単位で同一であることが求められたのです。

検証の方法論こそがクラフトの物語

パフォーマンスの作業に取りかかる前に、チームは証明の仕掛けを築き上げました。ユニットテスト群は C 実装と Swift 実装の両方を対象とし、徹底したカバレッジ——両者ともに99.7%——を実現したうえで、オープンソースのリリースに同梱されています。¹ 実世界をカバーするために、チームはファザーを使って1,000万件の PDF ファイルからなるコーパスを、コードカバレッジを一切損なうことなく4,200件まで最小化しました。これらの文書には25,572のフォントが埋め込まれており、その2,700万グリフがそれぞれ4種類の変換のもとでレンダリングされ、得られたビットマップがリファレンスインタプリタと比較されました。¹ 最終的に、チームが書いたテストコードの行数は、インタプリタのコードのおよそ4倍にのぼりました。¹

この比率こそ、心に刻む価値のある部分です。あらゆる最適化が、振る舞いに変化が生じたかどうかをビットマップ1枚ずつ答えてくれるオラクルに対して走った——だからこそ、この書き換えを大胆に進めることができたのです。記事はまさにそのループを称えています。徹底したカバレッジと明確に定義された内部境界は「リファクタリングを大幅に容易にし、それが今度は計測と修正の最適化ループを加速させると同時に、バグを混入させるリスクを最小限に抑える」のです。¹

13%はどこから来たのか

記事はパフォーマンスの作業を4つのカテゴリに分けており、それぞれに移植可能な教訓が含まれています。¹

ノンコピー型で参照カウントと排他性チェックを排除する。 Swift の ARC と実行時排他性チェックは、エイリアシングによって悪化するオーバーヘッドを課しますが、このインタプリタの仕様には、削減しようのない量のエイリアシングが組み込まれています。その対処はアーキテクチャ的なものでした。全体を通じて ~Copyable 値型を採用し、参照型は高レベルの抽象化のために残しておくのです。そして Swift 6.2 で導入され、macOS 10.14.4 や iOS 12.2 まで遡ってバックデプロイ可能な Span が、シーケンスへの効率的なアクセスを提供します。¹

言語の境界でのコピーをやめる。 C のコードは、グリフの点を8つの配列からなる1つの構造体として格納していました。キャッシュには優しいものの、Swift らしくはありません。最初のブリッジコードはそのデータを Swift へコピーし、また戻していましたが、これらのコピーが新しいインタプリタの実行時間の約20%を占めていたのです。¹ その置き換えとなったのが、C の構造体をラップしてコピーなしで境界安全なアクセスを仲介する射影型でした。これは WebKit の Safer Swift Guidelines に従ったもので、C の要素への Ref を保持する @safe なノンコピー・ノンエスケープ構造体とし、すべての unsafe な式には、それを正当化する不変条件を記す // SAFETY: コメントを付けています。¹

短命なアロケーションを取り除く。 filter や map のような操作はアロケーションを行いますが、そのアロケーションが意味を持つのは、値がエスケープする場合だけです。インタプリタのスタックポップ操作は、ポップした要素の配列をアロケートする素朴なバージョンから、継続渡し方式のバージョンへと進化しました。呼び出し側は、要素が取り除かれる前にそれらを操作するクロージャを borrowing Span 越しに渡し、コンパイル時の排他性チェックが、そのクロージャの内部からスタックを変更できないことを保証します。¹ ヒープアロケーションも要素のコピーもなく、安全性の論拠は慣例によるものではなく構造的なものです。

ジェネリクスを特殊化可能に保つ。 プロトコルやジェネリクスからの動的ディスパッチは、たいていの場合は最適化で消し去ることができますが、無条件にそうなるわけではありません。プロファイリングに関するチームの指針はこうです。「ホットパスに特殊化されていないジェネリクスやプロトコルのウィットネステーブルが見えたら、それは最適化コンパイラに十分な可視性がないというサインだ」——そして、その実装はインライン化の恩恵を受けられるかもしれません。¹

その結果は、読みやすさを速度と引き換えにしたものではありませんでした。記事の言い回しを借りれば、Swift の型システムが抽象化——固定小数点数値型、組み込みの変換を備えたスタック要素、そして例の射影型——を可能にし、それらは最適化込みで構築されたうえで「コストをまったく増やすことなく、読みやすさを大幅に向上させた」のです。¹ そしてチームはスコープについても率直です。インタプリタの内部状態はすべてノンコピーな構造体ですが、トップレベルの型は Objective-C++ から呼び出される @objc クラスのままです。なぜなら「ホットパスは高速で、コールドパスは便利だから」です。¹

静かに潜むエージェントの観点

末尾近くのある段落は、その配置が示唆する以上の注目に値します。移行を終えたあと、チームは「学んだことを LLM コーディングアシスタント向けの指示に蒸留し、それ以降ほかのプロジェクトでも成功裏に活用してきた」とのことで、LLM は C や C++ を Swift へ変換する際のチームの効率を高めてくれました。¹ Apple のセキュリティチームは、移行のノウハウをエージェント向けの指示としてエンコードし、それを複数のコードベースで再利用しているのです。これは、Apple が今サイクルにエクスポート可能なエージェントスキルとして製品化したのと同じパターンで、Xcode 27 のエージェントスキルのエクスポートで取り上げています。手作業で築いた移行が、ひとつのプレイブックになる。そしてそのプレイブックが、次の10件の移行のためのレバレッジになるのです。

ここから何を学ぶか

この記事は、かつて議論の余地があった3つの主張を着地させます。メモリ安全な Swift は、もっとも熱いホットパス——バイトコードインタプリタ——においてさえ、セキュリティ上きわめて重要な C を置き換えられる。その置き換えは、魔法によってではなく、ノンコピー型、コピーの排除、そして特殊化に優しい設計を通じて、より高速になりうる。そして移行は、十分なテスト投資があれば、ピクセル単位で同一の等価性まで検証できる——チームはその規模を、実装に対しておよそ4対1と見積もりました。信頼できない入力に触れる C や C++ のパース処理コードを抱えている人にとって、この記事、公開リポジトリ、そしてSwift 6.4 のきめ細かな strict-memory-safety オプトインの組み合わせは、「いつか移行しよう」という姿勢を、先週よりも明らかに弁護しにくいものにしています。

FAQ

Apple は具体的に何を書き換えたのですか?

TrueType ヒンティングインタプリタです。これは、グリフのアウトラインをうまくラスタライズするためにフォントへ埋め込まれたヒンティングプログラムを実行するバイトコードインタプリタで、1991年の System 7 以来フォントスタックの一部となってきました。¹ それが2025年秋のリリースで C からメモリ安全な Swift へ移行し、レンダリング出力は C 実装とピクセル単位で同一です。¹

ここで Swift は本当に C より高速なのですか?

平均すれば、そのとおりです。置き換え対象だった C インタプリタより13%高速で、macOS に搭載されているすべてのヒンティング済みフォントに非システムフォントのサンプルを加えたうえで、グリフあたりの CPU メガサイクルで計測されました。¹ この向上は、ノンコピー型による参照カウントの排除、射影型による言語をまたぐコピーの除去、短命なアロケーションの取り除き、そしてジェネリクスを特殊化可能に保つことから生まれました。¹

コードを読むことはできますか?

はい。Apple はインタプリタを apple/truetype-hinting-interpreter-example で MIT ライセンスのもと公開しており、継続的なオープンソースプロジェクトというよりは、リファレンス実装として意図された本番コードと説明されています。² ユニットテスト群もそれに同梱されています。¹

なぜフォントインタプリタがセキュリティにとって重要なのですか?

信頼できない入力からプログラムを実行するからです。フォントは Web ページや PDF を通じてどこからでもやってきますし、入力に駆動される制御フローと慎重なメモリ管理というインタプリタの組み合わせは、まさにメモリ破壊の悪用が歴史的に棲みついてきた場所です。¹ その攻撃面をメモリ安全な言語へ移すことで、このバグのクラスをまるごと取り除けます。記事も、Swift 実装が有効化されて以降バグは1件もないと報告しています。¹

この移行は、Swift のツール群がこの1か月ずっと示してきた方向性を裏づけるものです。What’s New in Swift (2026)で取り上げたきめ細かなメモリ安全性の診断、Swift 6.2 concurrency in practiceで語られたデフォルトで高性能な並行処理の物語、そしてプロンプトインジェクションへの一次回答で Apple が公式に示したセキュリティの枠組み。シリーズ全体のハブはApple Ecosystem Seriesです。

References