Slicing : définition, principe de fonctionnement et lien avec App Thinning

Qu’est-ce que le Slicing

Slicing est un composant d’App Thinning chargé de créer des variantes (tranches) du fichier binaire de l’application côté App Store. Lorsque le développeur télécharge un binaire universel (fat binary) contenant du code et des ressources pour toutes les configurations prises en charge, l’App Store l’analyse et génère plusieurs tranches : séparément pour iPhone avec processeur A17, séparément pour iPad avec M4, séparément pour Apple Watch. Chaque tranche ne contient que les fragments de code et les ressources nécessaires à cette combinaison spécifique d’architecture et de résolution.

Avant iOS 9, les développeurs créaient manuellement des fichiers binaires séparés pour différents appareils ou distribuaient un fat binary universel contenant tout à la fois. Le Slicing a entièrement automatisé ce processus : le développeur prépare un projet dans Xcode, télécharge une archive dans App Store Connect, et le Slicing côté serveur crée le nombre optimal de variantes. L’utilisateur ne voit jamais le processus de découpage — il reçoit un .app prêt, optimisé pour son appareil.

Le Slicing s’applique non seulement au code et aux images, mais aussi aux shaders Metal. Le GPU Apple utilise son propre jeu d’instructions (Metal Shading Language), qui diffère des instructions PowerVR ou ARM Mali. Le Slicing inclut dans la tranche uniquement les shaders pour la famille de GPU de l’appareil cible. Ceci est particulièrement important pour les jeux avec des shaders personnalisés — par exemple, les effets de post-traitement haute définition ne sont compilés que pour les appareils avec un GPU puissant (iPad Pro M4, iPhone 16 Pro Max).

Différence entre Slicing et compilation simple par architecture

Le compilateur Xcode crée un fat binary avec plusieurs architectures (armv7, arm64, arm64e), mais ne supprime pas les ressources — toutes les images pour toutes les résolutions restent dans le .app. Le Slicing va plus loin : il analyse les Asset Catalogs, les shaders Metal et les bibliothèques Swift, supprimant de chaque tranche ce qui n’est pas nécessaire pour la cible spécifique. Par exemple, les graphismes @3x ne se retrouvent pas dans la tranche pour iPhone SE, et les contrôleurs spécifiques à l’iPhone (s’ils sont extraits dans des ressources séparées) ne se retrouvent pas dans la tranche pour iPad Air.

Comment fonctionne le Slicing

Le processus de Slicing commence après le téléchargement du build dans App Store Connect et comprend trois étapes : analyse, découpage et empaquetage. À l’étape d’analyse, le serveur App Store analyse le fichier binaire, extrait des informations sur les architectures, les appareils, les résolutions d’écran et les versions d’iOS prises en charge. L’App Store utilise un mapping de tous les modèles commerciaux Apple vers leurs spécifications techniques — la base de données des appareils est mise à jour avec chaque version d’iOS.

À l’étape de découpage, le serveur crée des copies séparées du fichier binaire pour chaque combinaison unique. Pour ce faire, l’App Store extrait des images des Asset Catalogs avec des balises spécifiques (idiom, subtype, scale), sélectionne uniquement celles qui correspondent à l’appareil cible et assemble un nouveau lot de ressources. La bibliothèque standard Swift est également soumise au découpage — les symboles et méthodes inutilisés en sont supprimés (dead code stripping).

À l’étape d’empaquetage, chaque tranche est placée dans un paquet de distribution séparé et liée à des métadonnées — une liste de modèles d’appareils pour lesquels cette tranche est destinée. Lorsque l’utilisateur télécharge l’application, l’App Store sélectionne la tranche appropriée en fonction du modèle d’appareil, de la version d’iOS et du type de connexion. S’il n’y a pas de correspondance exacte, le serveur utilise la tranche la plus proche en caractéristiques. Apple stocke toutes les variantes dans le réseau CDN CloudKit pour une livraison rapide dans le monde entier.

Le Slicing dans le contexte d’App Thinning

Le Slicing est l’un des trois mécanismes d’App Thinning, mais c’est celui qui contribue le plus à réduire la taille du téléchargement. Bitcode est responsable de l’optimisation du code machine, On-Demand Resources de la gestion des ressources sur l’appareil, et le Slicing de la suppression des ressources redondantes lors de la distribution. Sans Slicing, les deux premiers mécanismes fonctionnent, mais les utilisateurs reçoivent des ressources pour tous les appareils, ce qui augmente la taille de 20 à 40 % selon le nombre d’Asset Catalogs.

La différence entre Slicing et Bitcode réside dans le point d’application : le Slicing travaille au niveau des ressources (images, shaders, fichiers NIB), Bitcode au niveau du code machine. Le Slicing divise le code par architectures (arm64 vs arm64e), Bitcode permet à Apple de recompiler le code pour de nouvelles architectures. Bitcode + Slicing ensemble offrent une optimisation maximale : Bitcode génère du code pour une architecture spécifique, et le Slicing supprime les ressources inutiles pour cette architecture.

La relation avec On-Demand Resources — Slicing et ODR ne se chevauchent pas. Le Slicing détermine quelles ressources parviendront à la distribution sur l’appareil, tandis que l’ODR gère quand ces ressources sont chargées et déchargées. Le développeur peut marquer une ressource avec une balise ODR, et le Slicing l’inclura dans la tranche si elle correspond à l’appareil. Apple recommande d’utiliser les trois mécanismes simultanément pour une taille d’installation minimale.

Variantes de Slicing pour différents appareils

Le Slicing crée des tranches séparées selon plusieurs dimensions : architecture du processeur, taille de l’écran (résolution), version d’iOS et famille de GPU (pour Metal). L’architecture détermine le jeu d’instructions du CPU : arm64 — jeu de base 64 bits (iPhone 5s — iPhone X), arm64e — jeu étendu avec prise en charge de Pointer Authentication et PAC (iPhone XS et plus récents, iPad Pro avec A12X+). La tranche pour arm64e inclut du code avec des instructions de protection mémoire non disponibles sur les appareils arm64.

Résolution d’écran — la deuxième dimension clé du Slicing. Apple utilise les échelles @1x (iPhone 3GS), @2x (iPhone 4 — iPhone SE 3), @3x (iPhone 6 Plus et plus récents) et spécifiques à l’iPad (2x et 3x avec des métriques supplémentaires). Le Slicing inclut dans la tranche uniquement les images dont l’échelle correspond à l’appareil cible. Avec une organisation appropriée des Asset Catalogs dans Xcode, cela élimine le besoin de gérer manuellement les ensembles de ressources — il suffit d’ajouter une image au catalogue en spécifiant les types d’appareils pris en charge.

Famille de GPU — la troisième dimension, d’importance cruciale pour les applications Metal. Apple classe les GPU par générations : Apple GPU family 1 (A7), family 2 (A8), ... family 8 (M4). Les shaders Metal sont compilés pour chaque famille séparément, car le jeu d’instructions Metal Shading Language s’élargit avec chaque génération de GPU. Le Slicing inclut dans la tranche uniquement les shaders pour la famille de GPU de l’appareil cible, ce qui réduit considérablement la taille des jeux et applications utilisant Metal pour le rendu.

Impact de l’architecture sur la taille de la tranche

L’architecture du CPU affecte directement la taille de la tranche : le code arm64e contient des instructions supplémentaires de Pointer Authentication (PAC) et de Signed Return Address, qui augmentent le fichier binaire de 5 à 10 % par rapport à arm64. Cependant, cette augmentation est compensée par le fait que le Slicing n’inclut le code arm64e que dans les tranches pour les appareils avec processeurs A12+. Pour l’iPhone SE (troisième génération) avec A15 Bionic, le Slicing crée une tranche séparée optimisée pour les capacités de cette puce.

Configuration du Slicing dans Xcode

La configuration du Slicing dans Xcode est minimale — la configuration principale s’effectue via les Asset Catalogs et les Build Settings. L’Asset Catalog doit contenir des ressources organisées par type d’appareil (Any, iPhone, iPad, Apple Watch, Apple TV) avec l’échelle et le mode d’affichage correctement indiqués. Xcode inclut automatiquement dans la compilation uniquement les ressources qui correspondent aux appareils cibles spécifiés dans les paramètres Deployment Target.

Le paramètre clé du Slicing dans Xcode est le Build Setting App Thinning. Valeurs disponibles :

• None — Slicing désactivé, l’application est distribuée en fat binary universel
• Automatic — Xcode active le Slicing avec les paramètres par défaut
• Manual — le développeur sélectionne des combinaisons spécifiques pour le Slicing

Targeted Device Families dans General → Deployment Info détermine pour quels types d’appareils l’application est compilée (iPhone / iPad / Universal). Le Slicing s’appuie sur ce paramètre lors du découpage — si l’application ne prend en charge que l’iPhone, aucune tranche pour iPad n’est créée. Deployment Target (version minimale d’iOS) affecte également le Slicing : les anciennes versions d’iOS peuvent nécessiter des tranches armv7, qui ne sont pas nécessaires pour iOS 13+. Apple recommande de définir Deployment Target sur la dernière version stable d’iOS — cela réduit le nombre de tranches et la taille du binaire.

Paramètres d’Asset Catalog pour le Slicing

Pour une efficacité maximale du Slicing, les Asset Catalogs doivent utiliser des balises spécifiques pour chaque ressource. Xcode fournit dans Attributes Inspector pour les images : Width Class (Any, Compact, Regular), Height Class (Any, Compact, Regular), Gamut (sRGB, Display P3), Memory (Any, Low, High), Graphics (Any, Low, High). En combinant ces balises, le développeur contrôle dans quelles tranches chaque image apparaît. Par exemple, une image pour iPad avec les balises Regular Width + Regular Height n’apparaîtra que dans les tranches pour iPad en orientation paysage.

# Exporter la tranche pour un appareil spécifique
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "sliced/" \
  -exportOptionsPlist "export.plist" \
  -thinning "iPhone17,2" # iPhone 16 Pro Max

Xcodebuild avec le paramètre -thinning et l’identifiant du modèle crée une tranche uniquement pour ce modèle. La liste des identifiants se trouve dans la base de données des appareils Apple (format : iPhone17,2 — iPhone 16 Pro Max, iPad14,1 — iPad Pro 11 M4). Cette méthode est utile pour vérifier la taille de la tranche avant l’envoi à App Store Connect. CI/CD peut utiliser cette commande pour une vérification automatique — si la taille de la tranche dépasse la limite (par exemple, 100 Mo pour un téléchargement mobile), le pipeline émet un avertissement.

Vérification des résultats du Slicing

Après avoir téléchargé l’archive dans App Store Connect, Apple fournit des statistiques détaillées sur les tailles des tranches. App Store Connect → Activity → sélectionnez le build → App Thinning — affiche la taille estimée de l’App Store pour chaque catégorie d’appareil : iPhone, iPad, Apple Watch, tvOS. Les tailles sont ventilées par versions d’iOS et types de processeur. Si une tranche dépasse la taille attendue, App Store Connect la marque d’un avertissement jaune.

Vérification locale via Xcode Organizer : après archivage, ouvrez Window → Organizer, sélectionnez l’archive et cliquez sur App Thinning Profiles. Xcode affichera les tailles pour chaque tranche possible en fonction de la configuration actuelle du projet. L’option Export est également disponible pour créer un IPA avec un profil de Slicing spécifique. Xcode génère un fichier .app-thinning.plist contenant des informations sur les ressources incluses dans chaque tranche.

Pour automatiser la vérification du Slicing en CI/CD, utilisez xcodebuild avec -thinning et analysez la taille des fichiers .app créés. Apple fournit l’utilitaire en ligne de commande app-size (installé via Xcode Command Line Tools), qui génère un rapport détaillé : taille du code, taille des ressources par catégorie (images, shaders, NIB), taille des bibliothèques Swift. La comparaison des tailles de tranches avant et après optimisation des Asset Catalogs permet d’identifier les ressources qui ne participent pas au Slicing en raison d’une configuration incorrecte.

# Analyser la taille de la tranche
app-size -m "sliced/App.app" \
  --format json

App-size génère un rapport JSON ventilé par catégories de ressources. Si le Slicing est configuré correctement, la section « images » ne contiendra qu’un seul ensemble d’échelle (@2x ou @3x), et non toutes les variantes. Une erreur de configuration d’Asset Catalog se manifeste lorsque toutes les échelles (@1x, @2x, @3x) sont présentes dans la tranche — cela signifie que Xcode n’a pas pu déterminer l’appareil cible pour ces images et que le Slicing n’a pas fonctionné.