Comment mesurer et réduire la taille d'une application iOS avec Xcode et App Store Connect

Les applications iOS ont tendance à grossir à chaque version : de nouveaux SDK, des images en plus haute résolution et du contenu hors ligne s'accumulent. Le téléchargement s'allonge et l'application occupe davantage d'espace sur l'appareil. L'optimisation commence par la mesure, car la principale source de poids varie d'une application à l'autre : les ressources pour certaines, le code compilé ou les dépendances intégrées pour d'autres. La « taille de l'application » ne se résume pas non plus à un seul chiffre. La taille de téléchargement, la taille d'installation et l'espace occupé après utilisation se recoupent, mais ne sont pas interchangeables. Dans une PR, un benchmark ou un compte rendu d'équipe, indiquez donc quelle métrique a changé et où elle a été mesurée. Si le contenu facultatif est téléchargé plus tard, le téléchargement et l'installation initiaux deviennent plus légers, mais une fois récupéré, ce contenu se retrouve tout de même sur l'appareil. Les Background Assets, y compris les packs essentiels et le contenu préchargé, peuvent même arriver avant le premier lancement. Il faut donc les comptabiliser séparément et les comparer dans un même état de téléchargement.

L'utilisateur voit ces chiffres à deux endroits. Sur la page de l'application dans l'App Store, le champ « Informations → Taille » indique la taille d'installation. Si l'application utilise des packs de ressources essentiels hébergés par Apple, une valeur « Jusqu'à … » incluant ce contenu peut y apparaître. Dans la section « Stockage iPhone », la taille de l'application et les « Documents et données », qui s'accumulent au fil des téléchargements et de l'utilisation, sont indiqués séparément. Les fichiers locaux APP, XCARCHIVE et IPA aident au diagnostic, mais ne correspondent pas à ce que distribue l'App Store : les archives peuvent contenir des symboles de débogage, et un IPA universel embarque des ressources pour plusieurs appareils. Pour estimer la taille pour des appareils précis, exportez une archive Release avec la commande xcodebuild -exportArchive et les paramètres -archivePath, -exportPath et -exportOptionsPlist. En cas de signature manuelle, le plist doit aussi contenir signingStyle=manual, teamID et une correspondance provisioningProfiles pour chaque application ou extension.

Le dossier d'export contient App Thinning Size Report.txt. Ce fichier liste les variantes avec la description de l'appareil et de l'OS, ainsi que des valeurs telles que « 112 MB compressed, 260 MB uncompressed ». La taille compressée est une estimation de la taille de téléchargement, la taille non compressée une estimation de la taille d'installation. Pour examiner un bundle, choisissez un IPA allégé d'après la description de sa variante et non d'après son nom de fichier : l'export peut aussi contenir un IPA universel. Décompressez-le avec ditto -x -k dans un nouveau répertoire créé par mktemp, puis repérez le .app dans le dossier Payload. Pour l'App Store et TestFlight, l'app thinning est en grande partie automatique, mais il faut le vérifier. Si des ressources propres à certains appareils apparaissent dans toutes les variantes, vérifiez les réglages des catalogues de ressources et les fichiers isolés. Lors des comparaisons, gardez identiques la configuration de build, la version de Xcode, la méthode de signature, la méthode d'export et la description de la variante, puis répétez la comparaison avec les valeurs traitées d'App Store Connect. Celles-ci restent elles aussi des estimations : Apple peut ajouter des DRM et recompresser les fichiers, et les tailles dans TestFlight peuvent différer de celles de l'App Store.

Le diagnostic commence par un inventaire de l'ensemble du bundle allégé : exécutable principal, Frameworks, PlugIns, catalogues de ressources et ressources isolées, localisations, médias, bases de données et modèles de ML. La commande find associée à stat, sort -n et tail -30 affiche les fichiers les plus volumineux, mais il s'agit de tailles logiques non compressées, donc de simples indices. Si le binaire compte, activez dans Build Settings l'option Write Link Map File (LD_GENERATE_MAP_FILE), compilez le projet et analysez le fichier .txt dans DerivedData. Regroupez les tailles de la section # Symbols par index de fichier, puis faites correspondre les index avec la section # Object files. Cela révèle le code généré volumineux, les bibliothèques statiques, les templates C++ et les SDK tiers. Les sommes par symbole indiquent à qui attribuer le poids, mais ne constituent pas un décompte complet : les en-têtes, le remplissage d'alignement, les signatures et les données de l'éditeur de liens n'y figurent pas. L'inlining, l'optimisation du module entier et la LTO brouillent l'attribution du code. Excluez les symboles supprimés comme code mort et établissez une carte pour chaque cible de build et chaque architecture.

Illustrons la démarche par un exemple fictif aux chiffres inventés : on modifie une seule chose à la fois, on recompile et on régénère le rapport pour la même variante. Une application riche en ressources pèse 112 Mo compressée et 260 Mo non compressée. L'estimation baisse de 31 Mo (environ 28 %) et de 58 Mo (environ 22 %), et App Store Connect indique 80 Mo au téléchargement et 200 Mo à l'installation. Les gains ne se reportent pas un pour un : la compilation, le découpage, la compression, l'alignement et la signature interviennent. Un tutoriel déplacé vers une livraison à distance est différé, pas supprimé. Une fois téléchargé, l'espace occupé augmente de nouveau d'environ 32 Mo, et l'archive comme les fichiers extraits peuvent coexister sur le disque. Testez donc le fonctionnement hors ligne, les nouvelles tentatives, la purge et le retéléchargement, et mesurez séparément les mises à jour différentielles.

Les ressources pèsent souvent plus lourd que le code. Placez les images intégrées dans des .xcassets afin que l'app thinning puisse sélectionner les ressources adaptées à chaque appareil. Le nombre de pixels doit correspondre à la taille d'affichage : une icône de 24 × 24 points nécessite 48 × 48 pixels en 2x et 72 × 72 en 3x, et elle doit être redimensionnée avant l'importation. Utilisez une illustration commune pour la graphie universelle, n'ajoutez des variantes par appareil ou par gamut de couleurs qu'en cas de nécessité et ne dupliquez pas les ensembles d'images. Après la migration, chargez les images par leur nom, par exemple UIImage(named: "toolbar_search"), et retirez les copies isolées restantes de Copy Bundle Resources. Confirmez le résultat en comparant les rapports d'une même variante avant et après. Pour les icônes, privilégiez les SF Symbols du système lorsque le design et la version minimale de l'OS le permettent.