App Thinning — définition, composants et fonctionnement

Qu'est-ce qu'App Thinning

App Thinning — est une technologie comprehensive d'optimisation de distribution d'applications iOS, introduite par Apple avec iOS 9 (septembre 2015). L'objectif d'App Thinning est de minimiser la taille de l'application que l'utilisateur télécharge sur son appareil, sans modifier le code source ni les fonctionnalités. La technologie fonctionne à trois niveaux : lors de la phase de compilation, du côté de l'App Store (distribution) et sur l'appareil (gestion des ressources).

Avant App Thinning, les développeurs incluaient dans le fichier binaire des ressources pour tous les appareils possibles — images @2x et @3x, code 32 bits et 64 bits, shaders Metal pour différents GPU. Cela entraînait un gonflement de la taille de l'application : un utilisateur d'iPhone 6 Plus avec écran Retina HD recevait des ressources vectorielles pour iPad Pro qui n'étaient jamais utilisées. Apple a résolu ce problème en transférant une partie du travail de compilation vers les serveurs de l'App Store.

Selon les recherches d'Apple (WWDC 2015, Session 412), une application type prenant en charge plusieurs architectures et résolutions peut être réduite de 30 à 50 % après application d'App Thinning. Pour les jeux avec une grande quantité de textures haute définition, le gain peut atteindre 70 à 80 %. Apple continue d'améliorer la technologie : iOS 17 a ajouté des optimisations pour ARM64e et une meilleure gestion des On-Demand Resources pour les applications utilisant Swift Package Manager.

Le problème résolu par App Thinning

La taille des applications mobiles ne cesse d'augmenter. Selon Sensor Tower (2025), la taille moyenne des applications iOS a augmenté de 45 % au cours des 5 dernières années. Pour les utilisateurs avec un forfait de données limité ou une connexion Internet lente, chaque mégaoctet compte. App Thinning résout ce problème sans intervention du développeur — il suffit d'activer la prise en charge dans les paramètres du projet et de télécharger le build dans App Store Connect.

Comment fonctionne App Thinning

Le processus d'App Thinning commence après le téléchargement de l'archive de l'application dans App Store Connect. L'App Store analyse le fichier binaire et le divise en segments par architectures (armv7, arm64, arm64e), résolutions d'écran (iPhone, iPad) et versions iOS. Pour chaque combinaison, une variante distincte est créée. Lorsque l'utilisateur clique sur «Télécharger », l'App Store détermine le modèle d'appareil, la version iOS et le type de connexion (Wi-Fi / réseau mobile) et envoie uniquement la variante correspondante.

Pour l'utilisateur, le processus est transparent — il n'y a pas d'option «version légère » ni de dialogue de paramètres. L'App Store sélectionne automatiquement la variante la plus appropriée en fonction des métadonnées de l'appareil, qui sont envoyées au serveur lors de la demande de téléchargement. Si l'appareil utilise le Wi-Fi, l'App Store peut envoyer une variante avec des ressources de meilleure qualité (par exemple, une vidéo ProRes pour iPhone 16 Pro). Lors du téléchargement via le réseau mobile, l'ensemble minimal possible est utilisé.

Le deuxième niveau d'optimisation — Bitcode. Lorsque l'option ENABLE_BITCODE est activée, Xcode compile l'application non pas en code machine, mais en une représentation intermédiaire LLVM. L'App Store recompile le Bitcode pour l'architecture du processeur de l'utilisateur, permettant à Apple d'appliquer des optimisations du compilateur pour les nouvelles générations de puces (A17, M4) sans que le développeur mette à jour l'application. Bitcode est obligatoire pour watchOS et tvOS, mais optionnel pour iOS.

Composants d'App Thinning : Slicing, Bitcode, ODR

App Thinning se compose de trois mécanismes indépendants, chacun responsable d'un aspect spécifique de l'optimisation. Le Slicing divise le fichier binaire en variantes par architecture et résolution d'écran. Le développeur configure le Slicing via les Asset Catalogs — Xcode inclut automatiquement dans la tranche uniquement les ressources qui correspondent à l'appareil cible. Par exemple, l'iPhone SE (troisième génération) recevra uniquement les images @2x et le code arm64, tandis que l'iPad Pro M4 recevra les images @3x et le code arm64e.

Bitcode — est LLVM IR (Intermediate Representation) — une représentation du programme indépendante de la machine. Lorsque Bitcode est activé, Xcode ne génère pas le code machine final, mais enregistre la représentation intermédiaire. App Store Connect lors du téléchargement du build reçoit le Bitcode et le recompile pour les architectures de tous les appareils pris en charge. Bitcode permet à Apple d'appliquer des optimisations indisponibles lors de la phase de compilation du développeur — par exemple, l'utilisation de nouvelles instructions processeur (SME, SVE) sur les puces M4.

On-Demand Resources (ODR) — le troisième mécanisme, qui permet de décharger les ressources de l'application après utilisation. Le développeur marque les ressources (niveaux de jeu, images pour l'onboarding, vidéos) avec des tags ODR. iOS télécharge les ressources marquées à la demande en arrière-plan et les décharge en cas de manque de mémoire ou après utilisation. Les ODR sont particulièrement efficaces pour les jeux avec une grande quantité de contenu — les premiers niveaux peuvent être fournis avec l'application, et les autres téléchargés au fur et à mesure de la progression.

Quand choisir chaque composant

Le choix des mécanismes d'App Thinning dépend du type d'application et de son public cible. Le Slicing est recommandé en permanence — il ne nécessite aucune action supplémentaire du développeur autre qu'une organisation correcte des Asset Catalogs et offre une réduction stable de 20 à 30 % de la taille. Bitcode vaut la peine d'être activé si l'application utilise des shaders Metal personnalisés ou prévoit de prendre en charge les nouvelles architectures Apple sans recompilation. ODR est justifié pour les applications avec un grand volume de contenu — jeux, éditeurs de photos, applications de streaming.

Pour une application professionnelle type (flux de données, formulaires, API REST), le Slicing et une configuration minimale d'ODR pour les images d'onboarding suffisent. Les jeux avec graphismes 3D bénéficient des trois mécanismes : Slicing supprime les shaders inutiles, Bitcode optimise le rendu pour le GPU, et ODR décharge les niveaux terminés. Selon Apple (WWDC 2024), la combinaison des trois mécanismes réduit la taille initiale d'installation de 45 à 55 % en moyenne par rapport à un binaire universel.

Configuration d'App Thinning dans Xcode

Pour activer App Thinning dans un projet Xcode, plusieurs étapes sont nécessaires. Le Slicing se configure via App Thinning dans les paramètres de build : Build Settings → App Thinning. Trois valeurs sont disponibles : None (sans optimisation), Automatic (configuration automatique par défaut) et Manual avec sélection de variantes spécifiques pour les tests. Apple recommande Automatic pour la plupart des projets.

Pour les Asset Catalogs, il est important d'organiser correctement les ressources : les images sont placées dans un catalogue universel avec indication de la largeur/hauteur, et Xcode crée automatiquement les variantes @1x, @2x et @3x. Xcode lors de la compilation inclut uniquement les résolutions utilisées dans le projet. Les shaders Metal sont compilés séparément pour chaque famille de GPU — Apple GPU, PowerVR, Mali — ce qui est également géré via les Asset Catalogs.

Bitcode est activé par le flag ENABLE_BITCODE = YES dans les Build Settings. Pour iOS, ce flag est optionnel (désactivé par défaut depuis Xcode 14), mais pour watchOS et tvOS il est obligatoire. Lors de l'activation de Bitcode dans un projet utilisant des bibliothèques tierces, toutes doivent également être compilées avec Bitcode, sinon la compilation échouera. Bitcode augmente le temps de compilation de 20 à 30 %, mais offre une compatibilité totale avec les architectures futures.

Vérification des résultats d'App Thinning

Après le téléchargement dans App Store Connect, les tailles des tranches peuvent être vérifiées dans la section Activity → Build Metric. App Store Connect affiche l'Estimated App Store Size pour différents appareils. Pour une vérification locale, Xcode fournit la commande xcodebuild avec le flag -exportArchive et l'option thinning pour créer des tranches sur la machine locale. Le résultat du Slicing peut être consulté dans l'Organizer (Window → Organizer) après l'archivage — l'onglet App Thinning Profiles montre les tailles pour différents appareils.

# Vérification locale du Slicing
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "export/" \
  -exportOptionsPlist "export.plist" \
  -thinning "<thin-for-all-variants>"

Xcodebuild avec le flag -thinning crée des fichiers .app pour chaque combinaison d'architecture, de largeur de bits et de GPU. Le paramètre <thin-for-all-variants> crée toutes les variantes possibles — utile pour la vérification. Pour les pipelines CI, spécifiez une combinaison spécifique, par exemple iPhone14,4 (iPhone SE 3). Les fichiers .app résultants peuvent être analysés avec l'utilitaire app-size.

Avantages et impact d'App Thinning

Le principal avantage d'App Thinning est la réduction de la taille du téléchargement pour l'utilisateur final. Selon Apple (WWDC 2024), une application type utilisant les trois mécanismes d'App Thinning se télécharge en moyenne 40 % plus rapidement sur le réseau mobile et occupe 35 % moins d'espace disque. Cela affecte directement le taux de conversion d'installation : selon Sensor Tower, chaque 10 Mo de taille d'application réduit la conversion de 1 %.

Le deuxième avantage — l'optimisation pour les appareils futurs grâce à Bitcode. Apple peut recompiler les applications Bitcode pour les nouvelles architectures sans intervention du développeur. Par exemple, lors de la transition d'Intel vers Apple Silicon (M1), les applications Bitcode fonctionnaient sur macOS via Rosetta 2 sans compilation supplémentaire. Les développeurs qui n'avaient pas activé Bitcode ont dû recompiler leurs applications pour arm64.

Le troisième avantage — ODR (On-Demand Resources) réduit la charge sur le stockage de l'appareil. Les jeux avec des dizaines de niveaux, comme Asphalt 8 : Airborne, utilisent ODR pour télécharger de nouvelles pistes au fur et à mesure de la progression. Le développeur peut définir des Initial Install Tags pour les ressources téléchargées avec l'application, et des Prefetch Tags pour le contenu téléchargé en arrière-plan après l'installation. Apple contrôle les limites ODR : jusqu'à 512 Mo par demande et jusqu'à 20 Go de cache total sur l'appareil.

Limitations d'App Thinning

App Thinning présente plusieurs limitations importantes à prendre en compte lors de la conception de l'application. Premièrement, le Slicing ne s'applique pas aux applications distribuées via Enterprise (in-house) ou Ad Hoc — ces builds contiennent toutes les variantes et ne passent pas par l'App Store. Pour tester le Slicing, le développeur peut utiliser TestFlight, qui traite également le Slicing du côté des serveurs Apple.

Deuxièmement, Bitcode augmente le temps de compilation et la taille de l'archive .xcarchive d'environ 30 à 50 %. Toutes les bibliothèques tierces ne supportent pas Bitcode — si au moins une dépendance est compilée sans Bitcode, la compilation du projet avec ENABLE_BITCODE échouera. Apple recommande de vérifier la compatibilité des bibliothèques avant d'activer Bitcode. De plus, Bitcode ne supporte pas Swift Package Manager dans son intégralité — certains paquets Swift peuvent casser la compilation Bitcode.

Troisièmement, les On-Demand Resources ne garantissent pas une disponibilité immédiate du contenu — le téléchargement ODR se fait en arrière-plan et peut être retardé si l'appareil est en mode faible batterie ou si le signal est faible. Le développeur doit implémenter la gestion des statuts de téléchargement ODR via NSBundleResourceRequest et afficher un indicateur de progression à l'utilisateur. Un échec de téléchargement ODR ne doit pas bloquer les fonctionnalités de l'application — un graceful fallback est nécessaire.