Apple переписала TrueType-интерпретатор хинтинга с C на Swift — и сделала это не только ради безопасности, но и скорости. Формат TrueType появился ещё в конце 80-х и до сих пор используется везде: в шрифтах вроде Helvetica, в PDF, на сайтах и в системах. Внутри него живет байткод-интерпретатор, который подсказывает растеризатору, как точнее рисовать глифы на экране. Проблема в том, что этот интерпретатор работает с данными из ненадёжных источников — шрифты приходят из интернета, и любая ошибка в памяти открывает путь к атаке. Именно его и переписали.
Новый интерпретатор на Swift запустили в осенних релизах 2025 года. Главные цели: полная memory safety, пиксельная идентичность вывода (чтобы ни один глиф не изменился) и производительность не хуже старого кода. Все три выполнили. Swift-версия в среднем на 13% быстрее, чем оригинал на C. Без единого бага с момента включения — утверждают авторы.
Чтобы добиться такого результата, инженеры Apple прошлись по узким местам. Отказались от class в пользу ~Copyable-структур — избавились от лишних retain/release. Использовали Span из Swift 6.2, чтобы не копировать данные при передаче. Переписали горячие участки на continuation-passing — вместо аллокаций массива при pop со стека передают замыкание, работающее со срезом. И не стали делать абстракции слишком обобщёнными — форсировали инлайнинг через атрибуты, чтобы оптимизатор видел всё насквозь.
Данные на границе C и Swift выстроили через проекционные типы с Ref и // SAFETY:-комментариями — код остался читаемым, но без копирования. На тесты ушло в четыре раза больше строк, чем на сам интерпретатор: юнит-тесты с 99,7% покрытия и фаззинг на 10 миллионах PDF-файлов, сжатых до 4200 при 25 572 шрифтах и 27 миллионах глифов.
Исходники нового интерпретатора Apple выложила на GitHub. Это production-код, не форк под открытую разработку, а референс. После миграции компания собрала наработки в инструкции для LLM-ассистентов и уже использует их в других проектах по переводу C/C++ на Swift.