Ce que l'équipe Performance d'Apple a dit lors du lab de la WWDC26

À la WWDC26, Apple a placé cinq de ses propres ingénieurs Power & Performance devant la caméra, pour une heure de questions-réponses en direct avec les développeurs, et a répondu aux questions que les développeurs posent réellement : pourquoi un écran SwiftUI inactif décharge-t-il encore la batterie, comment simuler un ancien appareil que l’on ne possède pas, quelle est vraiment la plus grosse erreur de consommation d’énergie dans les apps en production. Les sessions soignées vous expliquent comment fonctionne un framework. Le Group Lab, lui, vous a montré comment les propres équipes d’Apple s’en servent. Cet article rassemble les conseils de terrain qui méritent d’être conservés.

Une note sur les sources : Apple a publié cette vidéo de lab sans sous-titres. Je l’ai transcrite en local avec Whisper, si bien que chaque citation du lab ci-dessous est une paraphrase de cette transcription, et non une transcription verbatim d’Apple. J’attribue les propos aux intervenants d’après les noms et les rôles donnés dans les présentations du lab, déduits du contexte de la conversation : Terry pour la performance, Yanni pour MetricKit, Kaspar pour Instruments, Kunal pour CoreOS Power, et Marco pour le pipeline de rendu, avec Cole à l’animation.¹ Lorsque les conseils du lab touchent à un point qu’Apple documente formellement, je cite la documentation ou la session correspondante et je le signale.

Le flux de travail de trace énergétique sans fil, qui sous-tend une grande partie des conseils du lab, commence vers 11:42.

TL;DR

• L’ancienne surface Objective-C de MetricKit est en voie de disparition : MXMetricManager est formellement déprécié depuis la 27.0, et les nouveaux types de métriques et de diagnostics sont exclusivement livrés sur la nouvelle API Swift.²³
• Xcode Organizer propose désormais Metric Goals, des références tirées de votre propre historique et des apps qu’Apple juge similaires à la vôtre, couvrant le lancement, le taux de blocages, les écritures disque, la batterie, le stockage et les hitches.⁴
• Le flux de travail énergétique que l’équipe recommande est le mode Power Profiler de Performance Trace : enregistrez une trace .aar sans fil sur l’appareil, partagez-la vers votre Mac, et lisez dans Instruments les couloirs de consommation du CPU, du GPU, de l’affichage et du réseau. Cette fonctionnalité est arrivée avec iOS 26, pas iOS 27.⁵
• Le travail d’Apple Intelligence s’exécute surtout sur le Neural Engine et dans Private Cloud Compute ; le travail d’une app sollicitant le CPU peut donc souvent s’exécuter en parallèle sans concurrence. Découpez les tâches d’arrière-plan en morceaux pour que le système puisse les suspendre et les reprendre.¹
• La plus grosse erreur de consommation que l’équipe observe est une télémétrie insuffisante : les développeurs optimisent le mauvais élément parce qu’ils n’ont jamais mesuré le bon.¹

Pourquoi un lab mérite d’être transcrit

Les sessions enregistrées d’Apple sont scriptées, répétées et montées. Un Group Lab n’est rien de tout cela. Ce sont des ingénieurs qui réagissent en temps réel aux questions de développeurs en exercice, et leurs réponses portent la texture de l’expérience de terrain : les anecdotes de guerre, la reconnaissance de schémas du type « on voit ça tout le temps », les petits aveux sur ce qui est difficile. Cette texture est précisément ce qu’une session soignée gomme.

Le hic, c’est qu’Apple a publié le lab sans sous-titres. Pour le citer, j’ai dû passer la vidéo par une reconnaissance vocale locale, ce qui signifie que les noms propres et les orthographes d’API en ressortent approximatifs. J’ai confronté chaque affirmation technique à la documentation d’Apple ou à la session WWDC correspondante avant de l’énoncer comme un fait, et je garde les propres mots du lab clairement signalés comme paraphrase. Considérez le cadrage des ingénieurs comme faisant autorité sur l’intention et les priorités, et considérez les citations comme la source de référence sur les détails.

L’histoire des données de terrain : MetricKit est en cours de reconstruction

Yanni, qui travaille sur MetricKit, l’a qualifiée d’année très importante pour le framework et a décrit une reconstruction de fond en comble autour d’une nouvelle API Swift-first. La motivation qu’il a donnée : l’API Swift est conçue pour Swift concurrency, et elle a été pensée pour une nouvelle granularité des données, où les développeurs obtiennent non seulement le rapport de métriques quotidien, mais aussi des découpages plus fins sur des intervalles plus courts. Point crucial, il a noté que les nouveaux types de diagnostics et de métriques ne sont livrés que sur la nouvelle API, ce qu’il a présenté comme la vraie raison de migrer.¹

La documentation d’Apple appuie le versant le plus tranchant de cette affirmation. MXMetricManager, le point d’entrée utilisé par les développeurs depuis l’arrivée de MetricKit, est désormais formellement déprécié : la page de référence d’Apple le marque déprécié en 27.0 et oriente les développeurs vers MetricManager à la place.² La session 222 de la WWDC26 rend l’exclusivité explicite : les nouveaux types de métriques et de diagnostics vivent sur la nouvelle API Swift et ne sont pas rétroportés vers l’ancienne.³ Si vous appelez encore MXMetricManager, vous n’êtes pas simplement sur un style plus ancien ; vous êtes coupé de tout ce qu’Apple ajoutera à l’avenir.

Le lab a aussi fait remonter une confusion récurrente sur la provenance des données de terrain et la façon de les lire. Kunal et Yanni ont tracé la frontière clairement : Instruments vous offre un profilage local approfondi sur un seul appareil posé sur votre bureau, tandis qu’Xcode Organizer et MetricKit vous fournissent une télémétrie de terrain agrégée, issue d’utilisateurs réels sur des appareils réels. Les deux divergent souvent, et cette divergence est tout l’intérêt. Kunal a décrit des développeurs qui poursuivent un blocage qu’ils savent reproduire dans Instruments, alors qu’Organizer montre que la véritable cause principale des blocages est tout autre chose, quelque chose qui ne se reproduit jamais sur un bureau.¹

Le nouveau levier côté Organizer, ce sont les Metric Goals. Kunal les a signalés comme la fonctionnalité qu’il souhaitait par-dessus tout que les développeurs essaient avant de quitter la WWDC. La session 258 en précise la nature : des cibles recommandées qu’Organizer dérive « en fonction des similarités techniques et fonctionnelles entre votre app et d’autres apps », combinées à vos propres références historiques, couvrant le temps de lancement, le taux de blocages, les écritures disque, la batterie, le stockage et les hitches.⁴ Le lab a exprimé cette valeur en termes humains. Cole a décrit un développeur brandissant une app vidéo et demandant si sa forte consommation d’énergie est un problème ou simplement le coût d’une lecture vidéo toute la journée. Avant les Metric Goals, personne ne pouvait répondre. Désormais, Organizer vous compare à des apps similaires et vous donne une référence à partir de laquelle raisonner.¹

Un dernier point d’hygiène des données de terrain est ressorti, et il mérite d’être dit sans détour parce que les développeurs continuent de se tromper : ne fabriquez pas votre propre minuteur de lancement. Le lab a relaté des développeurs qui inspectent les API du noyau pour obtenir l’heure de création du processus et s’en servent comme repère de lancement. La réponse de Yanni : MetricKit et Organizer ne mesurent délibérément pas le lancement de cette façon ; ils mesurent l’intervalle que l’utilisateur ressent réellement. La documentation d’Apple confirme la définition : le temps de lancement est « le nombre de millisecondes entre le moment où l’utilisateur touche votre icône et celui où votre premier écran est dessiné », mesuré après l’écran de démarrage statique.⁶ Votre propre minuteur ne peut pas voir l’instant du tap, car votre processus n’existe pas encore. L’outillage d’Apple, lui, le peut, et il n’ajoute aucune surcharge de mesure à votre app.

Le flux de travail énergétique que l’équipe recommande vraiment

Le conseil procédural le plus utile du lab portait sur la manière d’attraper les problèmes d’énergie qui ne se manifestent jamais sur votre bureau. Kaspar et Kunal revenaient sans cesse à un seul flux de travail : la trace sans fil.

Le mécanisme, dans la formulation de Kaspar, consiste à se déconnecter d’Instruments, à enregistrer sur l’appareil une trace qui peut tourner pendant plusieurs heures, puis à partager le fichier vers votre Mac et à l’ouvrir dans Instruments pour l’analyser plus tard. L’avantage, ce sont les conditions réelles : vous vous déplacez, vous subissez de vrais transferts cellulaires, vous laissez l’appareil chauffer, et vous capturez ce qui se passe réellement plutôt que ce qui se passe lors d’une session de bureau contrôlée. Kunal y a vu le moyen d’attraper une classe de bugs précise, les tâches d’arrière-plan planifiées alors qu’elles ne devraient pas l’être, qui restent invisibles tant que vous êtes connecté et en train d’observer.¹

Ce flux de travail est le mode Power Profiler de Performance Trace, et il vaut la peine d’être précis sur son origine : c’est une fonctionnalité d’iOS 26 issue de la WWDC25, pas une nouveauté d’iOS 27. Apple la documente sous « Measuring your app’s power use with Power Profiler ». Vous l’activez dans Réglages > Développeur > Performance Trace, vous la déclenchez avec un contrôle du Centre de contrôle, vous partagez le fichier .aar résultant vers votre Mac, et vous lisez dans Instruments la consommation ventilée par sous-système, à travers les couloirs CPU, GPU, affichage et réseau.⁵ Le lab l’a présentée comme leur recours de prédilection, pas comme une tête d’affiche de la 27. (La véritable sœur nouvelle cette année, c’est le flux de collecte lookback et le CLI macOS metalperftrace, que j’ai traités dans l’article sur le machine learning avec Metal. Ce sont des outils différents pour des tâches différentes ; ne les confondez pas.)

Deux autres techniques issues de la discussion sur l’énergie méritent d’être retenues :

• Le mode économie d’énergie comme substitut d’appareil modeste. Terry a proposé une astuce pour les développeurs qui ne possèdent que du matériel récent mais doivent savoir ce que donne l’app sur du matériel ancien : activez le mode économie d’énergie. Il ralentit les CPU pour économiser la batterie, ce qui fait remonter des problèmes que vous ne verriez autrement que sur un appareil plus ancien. Il a ajouté que cela tient aussi lieu de bonne pratique d’optimisation générale, car beaucoup d’utilisateurs activent le mode économie d’énergie par choix et votre app doit y rester agréable.¹
• Device Conditions pour la simulation thermique et réseau. Le lab a évoqué à plusieurs reprises un « condition inducer » pour forcer l’app dans un état thermique élevé ou sur une liaison réseau dégradée. Le nom officiel d’Apple pour cette fonctionnalité est Device Conditions ; l’intervenant lui-même ignorait où elle se trouve dans Xcode 27. Elle a historiquement résidé dans la fenêtre Devices et pourrait être intégrée au Device Hub. L’intervenant du lab a été soigneux quant à ce qu’elle fait et ne fait pas : elle induit artificiellement le comportement de limitation (throttling) d’un appareil chaud ; elle ne chauffe pas réellement le matériel. Vous pouvez donc observer comment votre app se comporte sous pression thermique, davantage de hitches, davantage de blocages, sans faire cuire votre téléphone.¹

Et une règle catégorique revenue plus d’une fois : ne profilez jamais sur le Simulateur. Kaspar a noté que le Simulateur tourne sur votre Mac, si bien que sa performance ne vous apprend rien sur la performance de l’appareil, quel que soit l’appareil sélectionné. Profilez sur un appareil physique, et appuyez-vous sur les données de terrain de MetricKit et d’Organizer pour couvrir la diversité d’appareils que vous ne pouvez pas vous offrir.¹

Triage de performance : chauffe, concurrence avec l’IA et travail découpé

Lorsque les questions ont porté sur la stratégie de triage, trois conseils se sont démarqués.

Le manuel thermique. Un développeur a posé une question sur une app ARKit et Metal utilisée en extérieur, en plein soleil, où l’appareil chauffe en permanence. La réponse de Kunal commençait par l’API : écoutez ProcessInfo.thermalState et réduisez l’expérience quand il grimpe.¹ Les leviers précis offerts par le panel : demander des ressources réseau plus légères pour que l’appareil passe moins de temps à décoder et à analyser, remplacer les animations riches par de plus simples, et abaisser la fréquence d’images ou la résolution de rendu sous pression. Kunal a noté que le système limite déjà les fréquences d’images des animations et de l’affichage dans les états thermiques plus élevés, si bien qu’une partie du soulagement est automatique et que vous ajoutez le vôtre par-dessus. Le mot de la fin de Marco là-dessus : pousser moins de pixels, c’est moins de travail, et « on ne contourne pas la thermodynamique ». Vous maîtrisez le calcul de votre app ; vous ne maîtrisez pas la physique, alors optimisez à fond la partie qui vous appartient.¹

Le modèle de concurrence d’Apple Intelligence. Une question pointue demandait comment iOS 27 priorise les tâches d’arrière-plan d’une app lorsque le système est occupé par du travail d’Apple Intelligence. La réponse de Terry était rassurante et précise : beaucoup de fonctionnalités d’Apple Intelligence s’exécutent sur le Neural Engine ou dans Private Cloud Compute, de sorte que si votre app utilise le CPU pendant qu’une charge d’IA utilise le Neural Engine, les deux peuvent souvent s’exécuter en parallèle sans se disputer la même ressource. La parade défensive qu’il a recommandée est structurelle : configurez les tâches d’arrière-plan en petits morceaux pour que le système puisse les suspendre et les reprendre, plutôt qu’en une seule tâche monolithique qui doit repartir de zéro à chaque interruption. Le travail découpé progresse même quand l’ordonnanceur ne vous exécute pas aussi souvent que vous le voudriez.¹

La cardinalité de StateReporting. La nouvelle fonctionnalité StateReporting de MetricKit vous permet de découper les métriques par état de l’application, ce qui est puissant et facile à mal employer. Le lab a donné une règle claire sur la cardinalité : ne rapportez pas de valeurs exactes qui changent fréquemment, comme le nombre précis d’éléments dans une liste. Regroupez-les plutôt en tranches, petite, moyenne, grande, pour pouvoir demander ensuite « dans cette plage de taille, la performance a-t-elle régressé ? » sans payer le coût d’enregistrer chaque comptage distinct. L’exemple de Yanni : une liste de 1 000 éléments et une liste de 1 001 éléments ne font aucune différence significative, donc enregistrer le nombre exact est une pure surcharge. Définissez les frontières qui comptent pour votre analyse et rapportez la tranche.

Sur le lancement en particulier, le panel a convergé vers un modèle mental unique qui relie les conseils de triage : déterminez le minimum de données nécessaires pour dessiner la première image, ne chargez que cela, et différez tout le reste. Terry a mis en garde contre l’échec courant qui consiste à lancer un tas de travail d’arrière-plan puis à bloquer le thread principal jusqu’à ce que tout soit terminé, ce qui gèle toute l’app pendant le lancement. Pour savoir si c’est votre problème, Kaspar a pointé la vue du thread principal du modèle System Trace, où un thread principal bloqué apparaît directement. Le panel a aussi décrit System Trace faisant remonter les priorités de thread, la préemption et un histogramme de changements de contexte ; je n’ai toutefois pas pu confirmer qu’il s’agit de fonctionnalités documentées d’Instruments 27, alors prenez cela comme la description que le lab fait de l’outil plutôt que comme une spécification.

Notes d’outillage : l’instrument Foundation Models et une rampe d’accès pour débutants

Deux points d’outillage complètent le lab.

Pour les développeurs qui livrent des fonctionnalités Foundation Models, Kaspar a décrit l’outil d’Instruments passant des simples métriques de comptage de tokens de l’an dernier à un véritable instrument de débogage qui capture les prompts et les réponses et montre combien de tokens sont mis en cache.¹ L’image précise à travers les sessions de la WWDC26 : l’instrument Foundation Models capture les données de prompt et de réponse depuis l’appareil pendant toute la durée de la trace (session 243, qui note aussi que la capture peut inclure des informations sensibles, et qu’elle est donc désactivée en production).⁷ Les comptages de tokens mis en cache passent par l’API usage sur les réponses du modèle (session 241).⁸ Deux mécanismes différents, l’un pour la chronologie de la trace et l’autre pour la comptabilité par réponse, qu’il vaut la peine de bien distinguer quand vous lisez vos chiffres.

Pour les débutants, le panel était cohérent sur le point de départ. Marco a recommandé le Time Profiler avec la vue flame graph en première passe, car un flame graph montre visuellement combien une pile d’appels vous coûte au lieu de vous faire lire des nombres dans un plan. Kaspar a ajouté le mode Top Functions comme étape suivante, une liste à plat des fonctions les plus lourdes pour repérer les coupables d’un coup d’œil sans parcourir un arbre d’appels profondément imbriqué.¹ Et le méta-conseil le plus répété du panel : mesurez avant d’optimiser. Le cadrage de Kunal : l’écueil le plus courant est une télémétrie insuffisante, qui amène les développeurs à optimiser des zones qui ne rapportent aucun gain réel. Le corollaire de Terry sur le lancement et le travail d’arrière-plan : une requête réseau envoyée deux fois moins souvent est un gain d’énergie gratuit. Regardez l’ensemble du tableau avant de plonger dans un sous-système en particulier.¹

Points clés à retenir

Pour les développeurs iOS qui livrent aujourd’hui : - Migrez de MXMetricManager vers la nouvelle API Swift MetricManager. L’ancienne surface est dépréciée depuis la 27.0, et les nouveaux types de métriques et de diagnostics sont exclusifs à la nouvelle API.²³ - Ouvrez Xcode Organizer et confrontez vos Metric Goals aux références d’apps similaires pour le lancement, les blocages, la batterie, les hitches, les écritures disque et le stockage.⁴ - Cessez de mesurer le lancement avec votre propre minuteur ; MetricKit et Organizer mesurent depuis le tap sur l’icône, ce que votre processus ne peut pas voir.⁶

Pour le triage de performance et d’énergie : - Utilisez la trace sans fil de Power Profiler (iOS 26, Réglages > Développeur > Performance Trace) pour attraper les problèmes de tâches d’arrière-plan et d’énergie en conditions réelles qui ne se reproduisent jamais sur votre bureau.⁵ - Profilez sur un appareil physique, jamais sur le Simulateur, et utilisez le mode économie d’énergie comme substitut d’un matériel ancien que vous ne possédez pas.¹ - Écoutez ProcessInfo.thermalState et réduisez la fréquence d’images, la résolution, la richesse des animations et le poids réseau sous pression.¹

Pour les équipes qui construisent des fonctionnalités d’IA : - Découpez le travail d’arrière-plan pour que l’ordonnanceur puisse le suspendre et le reprendre ; le travail CPU peut souvent s’exécuter en parallèle des charges d’IA du Neural Engine et de Private Cloud Compute sans concurrence.¹ - Regroupez en tranches les valeurs de StateReporting (petite, moyenne, grande) ; ne rapportez jamais de comptages exacts à variation rapide.¹ - Pour Foundation Models, lisez l’outil d’Instruments pour la capture des prompts et des réponses (session 243) et tirez les comptages de tokens mis en cache de l’API usage des réponses (session 241).⁷⁸

Ce lab se marie naturellement avec les analyses plus approfondies de la série : MetricKit et StateReporting dans iOS 27 sur le découpage des métriques par état de l’app, Instruments 27 et la réactivité des apps sur les nouveaux flux de diffing et de détection des blocages, et l’angle mort de la performance sur les raisons pour lesquelles les données de terrain et le profilage de bureau divergent. Le hub complet de la série est la Apple Ecosystem Series.

Références