Votre IPA paraît trop volumineuse ou App Store Connect signale une hausse du poids de l’app iOS.

Cette semaine, exportez un App Thinning Size Report avec Xcode 27, puis comparez ses résultats aux variantes affichées dans App Store Connect. Ne prenez pas la taille de l’Archive ni celle du fichier IPA pour la taille finale téléchargée par les utilisateurs.

Ce guide s’adresse aux développeurs iOS indépendants qui préparent une version et doivent comprendre une hausse récente du poids de leur app.
Il concerne aussi les petites équipes qui distribuent plusieurs variantes ou des ressources localisées.
Si vous répétez vos Archives sur un Mac distant, vous trouverez enfin une méthode pour comparer les versions sans confondre les mesures.

01

Commencez par identifier la taille que vous mesurez

Un fichier volumineux sur votre Mac ne signifie pas automatiquement que chaque personne téléchargera un fichier de cette taille. Une Archive contient les éléments de compilation et de distribution nécessaires à la suite du processus. L’IPA exportée est un artefact de distribution. La taille proposée au téléchargement dépend, elle, de la variante préparée pour l’appareil concerné.

L’installation ajoute une autre mesure : l’espace occupé par l’app une fois installée. Il ne faut donc pas traiter comme interchangeables le poids de l’Archive, celui de l’IPA, la taille téléchargée et l’espace d’installation. Apple recommande de s’appuyer sur les données de taille fournies par Xcode et App Store Connect plutôt que de déduire le résultat final à partir d’un fichier local. Consultez la documentation Apple sur la mesure de la taille d’une app et le rapport App Thinning.

Mesure Ce qu’elle représente Où la vérifier Décision à prendre
Archive Produit de compilation conservé dans Xcode, avec des éléments utiles à la distribution et au diagnostic Organisateur Xcode Ne pas l’assimiler à un téléchargement utilisateur
IPA exportée Fichier destiné à un mode de distribution donné Dossier d’export S’en servir pour contrôler le paquet exporté, pas toute la distribution App Store
Variante d’appareil Combinaison de ressources et de code préparée pour une famille d’appareils Rapport App Thinning et App Store Connect Comparer les appareils réellement pris en charge
Téléchargement estimé Volume fourni à l’utilisateur pour une variante App Store Connect Évaluer l’impact sur l’acquisition et le téléchargement
Espace installé Place occupée après installation, qui peut différer du volume téléchargé Rapport et essais sur appareil Vérifier aussi les contraintes de stockage

Une confusion fréquente apparaît quand une équipe compare la taille du dossier d’Archive d’une version récente à celle d’une ancienne IPA. Les deux nombres peuvent être exacts et pourtant ne décrire ni le même artefact ni le même mode de distribution. Avant de supprimer des ressources, consignez le nom de la mesure, la variante concernée et le point d’entrée où le résultat a été obtenu.

Un fichier IPA envoyé est-il aussi volumineux que le téléchargement utilisateur ?

Non. L’IPA est un fichier exporté pour la distribution ; le téléchargement destiné à une personne dépend de la variante générée pour son appareil et du traitement de distribution. Une IPA universelle peut contenir des éléments qui ne sont pas tous nécessaires à chaque variante. Vous pouvez donc constater un écart entre la taille locale de l’IPA et le volume affiché pour un appareil précis.

La bonne vérification consiste à comparer les données de même nature : IPA exportée avec IPA exportée, variante avec variante, téléchargement estimé avec téléchargement estimé. Ne présentez pas la taille d’un fichier local comme le poids garanti pour tous les utilisateurs. Pour les versions publiées, la page Apple sur les builds et leurs métadonnées dans App Store Connect est le contrôle complémentaire à effectuer.

02

Produisez un rapport exploitable avant d’optimiser

Le rapport App Thinning Size Report donne une lecture par variante, au lieu d’une valeur unique extraite d’un fichier sur votre disque. Il permet de vérifier si les appareils ne reçoivent pas les mêmes ressources et de distinguer le poids estimé du téléchargement de l’espace occupé après installation. Ces mesures répondent à des questions différentes ; gardez-les séparées dans vos comparaisons.

Comment générer le rapport App Thinning Size Report dans Xcode ?

La procédure est simple, à condition de conserver le même projet, le même schéma et les mêmes options d’export lors des comparaisons.

  1. Ouvrez le projet avec Xcode 27 et sélectionnez le schéma réellement utilisé pour la version distribuée. Vérifiez que la configuration de publication est active, plutôt qu’une configuration de développement destinée aux essais locaux.
  2. Archivez l’application. Dans l’Organisateur, sélectionnez l’Archive correspondant au commit que vous souhaitez mesurer. Notez le commit et la configuration : sans ces éléments, une comparaison entre versions risque d’attribuer à tort une différence à un changement de code.
  3. Lancez l’export adapté à votre destination. Dans les options proposées, demandez la génération du rapport App Thinning Size Report si elle est disponible pour ce mode d’export. Conservez le fichier du rapport avec l’IPA et les notes de version.
  4. Lisez le rapport par variante. Relevez la taille estimée au téléchargement et l’espace installé, puis repérez si une famille d’appareils présente un résultat très différent des autres.
  5. Une fois le build traité, ouvrez sa fiche dans App Store Connect et comparez les tailles affichées. Apple y fournit des informations sur les builds et leurs variantes ; utilisez cette vue pour confirmer le résultat associé à la distribution, au lieu de vous arrêter à l’export local.

La documentation Apple sur la taille des apps et App Thinning décrit la génération du rapport. Si votre interface d’export évolue, fiez-vous au libellé proposé par votre version de Xcode plutôt qu’à une capture d’écran ancienne.

Conservez les rapports d’une version à l’autre dans un emplacement lié à la révision du projet. Un rapport sans référence au commit, au schéma ou aux options d’export devient difficile à exploiter : vous ne saurez plus si l’écart vient d’une modification du produit ou d’une méthode de mesure différente.

03

Les ressources expliquent souvent les écarts les plus visibles

Les images, les polices, les fichiers audio et vidéo ainsi que les contenus localisés peuvent peser sur une app, mais leur contribution dépend de ce qui est réellement inclus et livré. Un dossier qui paraît volumineux n’est pas une preuve suffisante : certains fichiers peuvent ne pas être intégrés au produit, tandis que des ressources intégrées peuvent exister en plusieurs variantes.

Commencez par comparer les ressources du projet avec les variantes du rapport. Cherchez les images dupliquées, les formats conservés par erreur et les langues ou contenus dont l’application n’a plus besoin. Les catalogues d’assets permettent d’associer des ressources à des variantes d’appareils ; Apple explique le rôle des variantes dans les catalogues d’assets. Le bénéfice dépend donc de votre configuration réelle, et pas seulement du fait d’utiliser un catalogue.

Pour une app de création audio ou vidéo, le problème peut être différent de celui d’une app principalement textuelle. Des pistes intégrées pour toutes les langues, des vidéos de démonstration ou des projets d’exemple peuvent être nécessaires au produit, mais pas forcément au premier lancement. Dans ce cas, demandez-vous si chaque fichier doit être disponible immédiatement, ou si une partie peut être fournie plus tard. Apple décrit des méthodes avancées de réduction de taille, notamment autour des ressources livrées à la demande. Elles demandent toutefois de vérifier le parcours utilisateur, la disponibilité hors connexion et les effets sur la première utilisation.

Évitez de convertir toutes les images ou de déplacer tous les médias d’un seul coup. Pour chaque changement, relevez le gain dans le rapport et contrôlez le rendu, la qualité audio ou vidéo, le temps nécessaire pour afficher le contenu et le fonctionnement sans réseau. Une réduction du téléchargement initial n’est pas forcément un gain si elle dégrade un usage essentiel.

04

Le code, les frameworks et les symboles ne correspondent pas au même périmètre

Si les ressources n’expliquent pas l’augmentation, examinez le binaire et les frameworks intégrés. Comparez les produits exportés des deux versions et identifiez les composants ajoutés ou mis à jour. Une dépendance peut accroître le contenu distribué même si vous n’avez modifié que quelques lignes dans votre propre code.

Ne comptez pas les fichiers de symboles de diagnostic comme s’ils étaient tous installés avec l’app. Les fichiers dSYM servent à symboliser les rapports de plantage ; leur présence dans un dossier d’Archive n’implique pas qu’ils soient inclus dans le téléchargement utilisateur. Mesurez le produit distribué et vérifiez séparément les artefacts de diagnostic.

Dans les réglages de compilation, examinez notamment le niveau d’optimisation réellement appliqué à la configuration de publication. La référence Apple décrit les réglages de compilation et les niveaux d’optimisation disponibles. La valeur affichée dans le projet peut être remplacée par une configuration, un fichier de réglages ou un paramètre ciblant une cible particulière. Pour savoir quelle valeur s’applique réellement, consultez les instructions Apple pour inspecter les réglages effectifs d’une cible.

Ne changez pas une option d’optimisation uniquement parce que son nom suggère un binaire plus petit. Faites un export avant et après, puis vérifiez la taille mesurée, les tests et le comportement de l’application. Apple propose également des optimisations de base pour réduire la taille d’une app. Appliquez-les à un problème identifié, pas comme une liste de cases à cocher universelle.

05

Vérifiez les variantes et le téléchargement attendu

App Thinning peut conduire à des résultats différents selon l’appareil : les ressources et éléments binaires nécessaires ne sont pas forcément identiques pour chaque variante. Par conséquent, une valeur issue d’un export local ne permet pas de conclure à la taille téléchargée par l’ensemble de votre public. Sélectionnez dans App Store Connect les builds et variantes correspondant aux appareils que vous prenez réellement en charge, puis comparez-les au rapport exporté.

Où consulter la taille des variantes dans App Store Connect ?

Ouvrez la fiche de votre application, puis la section qui répertorie ses builds et leurs métadonnées. Sélectionnez le build traité et examinez les informations de taille disponibles pour les variantes d’appareils. Les intitulés peuvent évoluer avec l’interface, mais le point essentiel reste le même : vérifiez les données liées au build distribué et non seulement celles de l’Archive locale. La page Apple consacrée à l’affichage des builds et de leurs métadonnées décrit cet espace.

Notez séparément les résultats de chaque famille d’appareils importante pour votre audience. Si une seule variante est plus lourde, recherchez d’abord une ressource ou une dépendance spécifique à cette variante. Si toutes les variantes progressent de façon comparable, examinez plutôt les changements communs : nouvelles fonctions, médias intégrés, frameworks ou configuration de compilation.

Une alerte de téléchargement cellulaire appelle aussi une vérification du bon indicateur. Apple documente un seuil de référence de 200 Mo pour les téléchargements cellulaires ; son effet dépend du contexte de téléchargement et des réglages disponibles sur l’appareil. Ce n’est ni le plafond d’un fichier d’Archive ni une preuve qu’une app dépassant ce seuil ne peut pas être distribuée. Vérifiez la formulation actuelle de la documentation Apple sur la réduction de la taille des apps et confrontez-la à la taille de la variante affichée dans App Store Connect.

Ne cherchez pas à réduire le poids uniquement pour passer sous un seuil si cela oblige à supprimer une fonction importante. Évaluez le volume téléchargé, l’espace après installation et le profil de vos utilisateurs. Une app de montage utilisée avec des fichiers médias volumineux ne se juge pas comme un utilitaire léger : la taille initiale, le stockage disponible et les contenus à télécharger ensuite comptent ensemble.

06

Choisissez la suite selon les mesures disponibles

  • Si l’IPA est volumineuse, mais que les variantes App Store Connect restent adaptées, conservez l’export comme artefact de distribution et ne réduisez pas les ressources sans motif. Vérifiez tout de même le résultat sur les appareils principaux.
  • Si une variante est sensiblement plus lourde que les autres, ciblez les assets, langues ou dépendances propres à cette variante, puis produisez un nouveau rapport.
  • Si toutes les variantes augmentent, comparez les changements de ressources et de frameworks avec la version précédente ; inspectez aussi les réglages effectifs de la configuration de publication.
  • Si le téléchargement dépasse le seuil cellulaire pertinent pour votre public, priorisez les éléments non indispensables au premier lancement et testez une livraison différée uniquement si le parcours reste fiable.
  • Si le téléchargement est acceptable mais que l’espace installé pose problème, travaillez sur le contenu conservé après installation et mesurez l’espace sur appareil ; une réduction du fichier téléchargé ne répond pas nécessairement à ce problème.
  • Si les résultats ne sont pas comparables, recommencez avec le même commit, le même schéma et les mêmes options d’export. Ne prenez pas de décision à partir de rapports produits selon des méthodes différentes.

Cette liste évite deux erreurs courantes : supprimer des médias dont les utilisateurs ont besoin pour gagner quelques mégaoctets à l’export, ou conclure que tout va bien parce que l’IPA locale est petite. Le rapport et la fiche du build doivent confirmer ensemble le diagnostic.

07

Installez une comparaison reproductible sur votre Mac de compilation

Pour détecter une régression avant la publication, archivez le rapport avec les informations qui permettent de le reproduire : révision du projet, schéma, configuration, options d’export et date du build. À chaque version candidate, comparez les mêmes variantes et consignez les écarts plutôt que de garder uniquement une taille globale.

Cette méthode est particulièrement utile quand une petite équipe produit plusieurs versions ou maintient des ressources audio, vidéo et localisées. Sans historique, une hausse progressive peut passer inaperçue ; avec un rapport associé au commit, vous pouvez relier l’écart à une modification précise et décider s’il est acceptable avant l’envoi.

Si vous répétez ces contrôles sur une machine distante, séparez bien la capacité de compilation de la question du poids de l’app : le Mac exécute Xcode, mais c’est le rapport de distribution qui vous dit ce que vous devez optimiser. Vous pouvez consulter la présentation de l’environnement Mac distant proposé par VpsMesh pour évaluer si ce mode de travail correspond à votre cycle de publication.

Pour une session ponctuelle de compilation ou une période de validation, louer un Mac peut éviter l’achat d’une machine dédiée. Cela ne remplace toutefois pas un Mac local si vous dépendez d’interfaces physiques ou si votre charge est lourde et constante. Un poste personnel immobilise du capital et son espace disque reste partagé avec les autres tâches ; une chaîne de compilation générique peut, de son côté, offrir moins de contrôle sur la conservation de vos Archives et rapports. Dans ces cas précis, un Mac distant loué par VpsMesh peut vous donner un environnement macOS accessible pour répéter les Archives et conserver les résultats sans acheter une machine supplémentaire. Vous pouvez examiner les formules de location de Mac mini avant de choisir entre location, achat et compilation locale.