L'interpréteur de polices d'Apple est désormais en Swift, et 13 % plus rapide

L’équipe de sécurité d’Apple a publié le genre de résultat qui clôt les débats. L’interpréteur de hinting TrueType, un interpréteur de bytecode qui analyse des données de polices non fiables sur les plateformes Apple depuis 1991, a été réécrit du C vers du Swift à sûreté mémoire, et « en moyenne, notre interpréteur Swift s’exécute 13 % plus vite que l’interpréteur C qu’il remplace ».¹ Le billet est rédigé par Scott Perry, membre de l’équipe de sécurité d’Apple spécialisé dans l’adoption de Swift, le code source est sur GitHub en tant qu’implémentation de référence, et le critère d’exactitude n’était pas « passe les tests » mais un rendu pixel par pixel identique à l’original en C.¹ À sûreté mémoire, plus rapide que le C, et en production depuis les versions de l’automne 2025 : ce billet est à ce jour la réponse empirique la plus forte à l’affirmation selon laquelle la sûreté mémoire coûte en performance.

En bref

• Apple a réécrit l’interpréteur de hinting TrueType du C vers Swift parce que les analyseurs de polices constituent une surface d’attaque critique pour la sécurité : l’interpréteur exécute du bytecode embarqué dans les polices avec « un flux de contrôle piloté par les entrées, des structures de données complexes et une gestion mémoire délicate — exactement le genre de code qu’il est difficile de rendre parfait et où les erreurs mémoire sont plus faciles à exploiter ».¹
• Le résultat a été déployé dans les versions de l’automne 2025, n’a donné lieu à « aucun bug signalé depuis son activation », et tourne en moyenne 13 % plus vite que l’implémentation en C.¹
• La performance provient de techniques précises et portables : les types valeur ~Copyable et ~Escapable pour éliminer le comptage de références et le surcoût des vérifications d’exclusivité, Span pour un accès sûr aux séquences, des types de projection au-dessus des structures C qui ont supprimé des copies coûtant environ 20 % du temps d’exécution, et le maintien de génériques spécialisables.¹
• La vérification est le chef-d’œuvre discret : une suite de tests unitaires avec 99,7 % de couverture sur les deux implémentations, un corpus minimisé par fuzzer de 10 millions de PDF réduit à 4 200 documents embarquant 25 572 polices, 27 millions de glyphes rendus sous quatre transformations chacun et comparés bitmap par bitmap, et près de quatre fois plus de code de test que de code d’interpréteur.¹
• Le code source de l’interpréteur est publié sous apple/truetype-hinting-interpreter-example sous licence MIT, en tant que code de production conçu comme une implémentation de référence.²

Pourquoi un interpréteur de polices est une histoire de sécurité

Les polices TrueType peuvent contenir des programmes. Le format qu’Apple a créé à la fin des années 1980 embarque un moteur de hinting bâti autour d’un interpréteur de bytecode à usage spécialisé, conçu pour que les contours soient rastérisés fidèlement sur les écrans basse résolution.¹ Lorsque TrueType est devenu intégrable dans les PDF en 1994 et dans les pages web en 2008, cet interpréteur s’est mis à exécuter des programmes issus de « polices non fiables provenant de n’importe où sur Internet ».¹ Quiconque a suivi l’histoire de la sécurité iOS sait comment cela se termine : les analyseurs de polices ont porté certaines des chaînes d’exploitation les plus célèbres de la plateforme, et le billet nomme la raison structurelle sans avoir besoin de faire la leçon d’histoire. Le flux de contrôle piloté par les entrées combiné à une gestion mémoire manuelle, c’est là que vivent les erreurs mémoire.

Les contraintes de l’équipe ont rendu la réécriture plus difficile qu’un portage à partir de zéro. La compatibilité binaire impliquait que les programmes existants « devaient continuer à fonctionner exactement comme auparavant, sans même se rendre compte qu’une nouvelle implémentation était en place », et puisque le hinting peut changer radicalement l’aspect des glyphes à l’écran, l’exactitude a été définie comme une « compatibilité exacte avec les sorties de l’implémentation en C ».¹ Pixel par pixel identique, pas approximativement correct.

La méthodologie de vérification est l’histoire de l’artisanat

Avant le travail sur la performance, l’équipe a construit l’appareil de preuve. Une suite de tests unitaires cible à la fois les implémentations C et Swift avec une couverture exhaustive, 99,7 % pour les deux, et est livrée avec la publication open source.¹ Pour une couverture du monde réel, ils ont utilisé un fuzzer pour minimiser un corpus de 10 millions de fichiers PDF jusqu’à 4 200 sans aucune perte de couverture de code ; ces documents embarquent 25 572 polices dont les 27 millions de glyphes ont été rendus sous quatre transformations chacun, les bitmaps résultantes étant comparées à l’interpréteur de référence.¹ Au bout du compte, l’équipe avait écrit près de quatre fois plus de lignes de code de test que de code d’interpréteur.¹

Ce ratio est ce qu’il faut s’approprier. La réécriture a pu être menée de façon agressive parce que chaque optimisation était confrontée à un oracle qui répondait, bitmap par bitmap, si le comportement avait changé. Le billet attribue le mérite précisément à cette boucle : une couverture exhaustive et des frontières internes bien définies « rendent la refactorisation nettement plus facile, ce qui accélère à son tour la boucle d’optimisation mesurer-et-corriger tout en minimisant le risque d’introduire des bugs ».¹

D’où viennent les 13 %

Le billet décompose le travail sur la performance en quatre catégories, chacune porteuse d’une leçon transposable.¹

Supprimer le comptage de références et les vérifications d’exclusivité grâce aux types non copiables. L’ARC de Swift et la vérification d’exclusivité à l’exécution imposent un surcoût que l’aliasing aggrave, et la spécification de l’interpréteur intègre une quantité d’aliasing irréductible. La solution était architecturale : adopter partout des types valeur ~Copyable et réserver les types référence aux abstractions de haut niveau, Span, introduit dans Swift 6.2 et rétro-déployable jusqu’à macOS 10.14.4 et iOS 12.2, fournissant un accès efficace aux séquences.¹

Cesser de copier à la frontière du langage. Le code C stockait les points de glyphe sous la forme d’une seule structure de huit tableaux, conviviale pour le cache mais peu idiomatique en Swift. Le premier code de pontage copiait ces données vers Swift et inversement, et ces copies coûtaient environ 20 % du temps d’exécution du nouvel interpréteur.¹ Le remplacement consistait en des types de projection qui enveloppent la structure C et arbitrent un accès sûr en bornes sans copie, en suivant les Safer Swift Guidelines de WebKit : une structure @safe non copiable et non échappable contenant un Ref vers l’élément C, chaque expression non sûre portant un commentaire // SAFETY: documentant l’invariant qui la justifie.¹

Éviter les allocations à courte durée de vie. Des opérations comme filter et map allouent, et l’allocation n’a d’importance que si la valeur s’échappe. L’opération de dépilement (pop) de l’interpréteur a évolué d’une version évidente qui allouait un tableau d’éléments dépilés vers une version à passage de continuation : l’appelant transmet une closure qui opère sur un borrowing Span des éléments avant leur retrait, la vérification d’exclusivité à la compilation garantissant que la pile ne peut pas être mutée depuis l’intérieur de la closure.¹ Aucune allocation sur le tas, aucune copie d’élément, et l’argument de sûreté est structurel plutôt que conventionnel.

Conserver des génériques spécialisables. La répartition dynamique issue des protocoles et des génériques peut généralement être optimisée et éliminée, mais pas inconditionnellement. La recommandation de l’équipe pour le profilage : « si vous voyez des génériques non spécialisés ou des tables de témoins de protocole dans les chemins critiques, c’est le signe que l’optimiseur ne dispose pas d’une visibilité suffisante », et l’implémentation peut bénéficier de l’inlining.¹

Le résultat n’a pas troqué la lisibilité contre la vitesse. Le billet présente les choses ainsi : le système de types de Swift a permis des abstractions — des types numériques en virgule fixe (fixed-point), un élément de pile (stack element) avec des conversions intégrées, les types de projection — qui « n’ajoutaient aucun coût tout en améliorant substantiellement la lisibilité » une fois compilées avec les optimisations.¹ Et l’équipe est franche sur la portée : l’état interne de l’interpréteur n’est composé que de structures non copiables, mais le type de plus haut niveau reste une classe @objc appelée depuis l’Objective-C++, parce que « les chemins critiques sont rapides, et les chemins froids sont pratiques ».¹

L’angle discret des agents

Un paragraphe près de la fin mérite plus d’attention que son emplacement ne le suggère. Après avoir achevé la migration, l’équipe a « distillé ce que nous avons appris en instructions destinées aux assistants de programmation LLM, et nous les avons depuis utilisées avec succès sur d’autres projets », les LLM améliorant l’efficacité de l’équipe pour convertir du C et du C++ en Swift.¹ L’équipe de sécurité d’Apple encode son expertise de migration sous forme d’instructions pour agents et la réutilise à travers ses bases de code, exactement le même schéma qu’Apple a industrialisé ce cycle sous forme de compétences d’agent exportables, abordé dans l’export des compétences d’agent de Xcode 27. Une migration faite à la main devient un manuel ; le manuel devient un levier pour les dix migrations suivantes.

Ce qu’il faut en retenir

Le billet établit trois affirmations qui étaient autrefois discutables. Le Swift à sûreté mémoire peut remplacer du C critique pour la sécurité dans le plus brûlant des chemins critiques : un interpréteur de bytecode. Le remplacement peut être plus rapide, non par magie mais grâce aux types non copiables, à l’élimination des copies et à une conception favorable à la spécialisation. Et la migration peut être vérifiée comme équivalente pixel par pixel moyennant un investissement de test suffisant, que l’équipe a dimensionné à environ 4 contre 1 par rapport à l’implémentation. Pour quiconque détient du code d’analyse en C ou C++ qui touche à des entrées non fiables, la combinaison de ce billet, du dépôt ouvert et des options granulaires d’activation de la sûreté mémoire stricte de Swift 6.4 rend le « on migrera un jour » nettement moins défendable, et de façon mesurable, qu’il ne l’était la semaine dernière.

FAQ

Qu’a exactement réécrit Apple ?

L’interpréteur de hinting TrueType : l’interpréteur de bytecode qui exécute les programmes de hinting embarqués dans les polices afin que les contours de glyphes soient bien rastérisés, partie intégrante de la pile de polices depuis System 7 en 1991.¹ Il est passé du C au Swift à sûreté mémoire dans les versions de l’automne 2025, avec un rendu pixel par pixel identique à l’implémentation en C.¹

Swift est-il vraiment plus rapide que le C ici ?

En moyenne, oui : 13 % plus rapide que l’interpréteur C qu’il remplace, mesuré en mégacycles CPU par glyphe sur toutes les polices avec hinting livrées sur macOS plus un échantillon de polices hors système.¹ Les gains proviennent de l’élimination du comptage de références via les types non copiables, de la suppression des copies inter-langages grâce aux types de projection, de l’évitement des allocations à courte durée de vie et du maintien de génériques spécialisables.¹

Puis-je lire le code ?

Oui. Apple a publié l’interpréteur sous apple/truetype-hinting-interpreter-example sous licence MIT, décrit comme du code de production conçu comme une implémentation de référence plutôt que comme un projet open source actif.² La suite de tests unitaires est livrée avec.¹

En quoi un interpréteur de polices importe-t-il pour la sécurité ?

Parce qu’il exécute des programmes issus d’entrées non fiables. Les polices arrivent dans les pages web et les PDF en provenance de n’importe où, et la combinaison, propre à l’interpréteur, d’un flux de contrôle piloté par les entrées et d’une gestion mémoire délicate est précisément là où vivent historiquement les exploits de corruption mémoire.¹ Déplacer cette surface vers un langage à sûreté mémoire supprime toute la catégorie de bugs, et le billet rapporte aucun bug depuis l’activation de l’implémentation Swift.¹

La migration valide la direction que l’outillage de Swift signale depuis le début du mois : les diagnostics granulaires de sûreté mémoire dans Les nouveautés de Swift (2026), la concurrence performante par défaut dans La concurrence de Swift 6.2 en pratique, et le cadrage sécuritaire qu’Apple a officialisé dans sa réponse de première main à l’injection de prompt. Le hub complet de la série est la Série Écosystème Apple.

Références