Corriger les rejets d’icônes App Store : sRGB, canaux alpha et autres pièges

La validation des icônes App Store Connect échoue silencieusement. Vous envoyez un PNG 1024×1024 qui semble parfait dans tous vos éditeurs d’image, et la réponse est une variante de « L’image n’a pas pu être traitée. » Aucune mention de l’espace colorimétrique. Aucune référence à l’alpha. Juste un mur entre votre soumission et l’App Store.

En réalité, le validateur vérifie un ensemble restreint de propriétés techniques, et l’échec de n’importe laquelle d’entre elles produit la même erreur générique. Les trois causes les plus courantes sont un profil colorimétrique autre que sRGB (généralement Display P3 provenant d’outils de design modernes), un canal alpha que la boutique interdit explicitement, et — moins fréquemment — un mode couleur indexé qui ne devrait pas apparaître dans une icône produite en 2025 mais qui se présente quand même lorsque des fichiers passent par d’anciens pipelines d’optimisation. Ces trois problèmes se corrigent depuis le terminal en moins d’une minute une fois que vous savez ce que vous cherchez.

Ce qu’App Store Connect requiert réellement

Les exigences d’Apple pour l’icône de la fiche App Store sont précises. Le fichier doit être un PNG. Les dimensions doivent être 1024×1024 pixels. Il ne doit y avoir aucun canal alpha – pas d’alpha partiellement transparent, pas d’alpha entièrement opaque, simplement aucune donnée alpha du tout. L’espace colorimétrique devrait être sRGB : les Human Interface Guidelines d’Apple indiquent aussi Display P3 et Gray Gamma 2.2 parmi les espaces colorimétriques pris en charge pour les icônes d’applications, mais, d’après notre expérience, sRGB est le choix le plus sûr pour l’icône App Store. Et le mode couleur devrait être RGB TrueColor, pas une palette indexée.

La contrainte sur l’alpha existe parce qu’App Store Connect applique son propre arrondi des coins et son propre traitement de composition aux icônes. Une icône avec un canal alpha interférerait avec ce processus. La contrainte sRGB existe parce que la boutique affiche les icônes sur une large gamme d’appareils avec différents profils d’affichage ; sRGB est la base commune. Display P3, l’espace colorimétrique à large gamut d’Apple, est une option d’exportation courante dans des outils comme Figma, Sketch et Affinity Designer et, d’après notre expérience, les icônes marquées P3 sont à l’origine de nombreux échecs abordés dans ce guide.

Diagnostiquer le problème avec sips

macOS est livré avec sips (Scriptable Image Processing System), un outil en ligne de commande qui peut inspecter et transformer des images sans aucune dépendance tierce. C’est le moyen le plus rapide de voir exactement ce que votre fichier d’icône contient.

sips --getProperty all icon.png

La sortie est une simple liste de propriétés. Les champs qui comptent pour la validation App Store sont hasAlpha, space et profile. Un fichier problématique affiche généralement quelque chose comme ceci :

hasAlpha: yes
space: RGB
profile: Display P3

Cette combinaison échouera. La valeur space: RGB ne distingue pas entre RGB générique et sRGB – le champ profile est ce qui lève l’ambiguïté. Une icône conforme prête à être envoyée devrait afficher hasAlpha: no et un profil indiquant « sRGB IEC61966-2.1 » ou équivalent.

Vous pouvez également interroger des propriétés individuelles si vous souhaitez une vérification plus rapide lors d’un script de compilation :

sips --getProperty hasAlpha icon.png
sips --getProperty profile icon.png

Le problème de profil colorimétrique

La cause de rejet la plus courante est un profil colorimétrique Display P3. Les écrans Mac modernes sont compatibles P3, et les outils de design peuvent exporter avec un profil à large gamut si vous ne choisissez pas explicitement sRGB. Figma a supprimé l’option « Unmanaged » en août 2023 ; chaque fichier utilise désormais sRGB ou Display P3, et les exportations reprennent le profil du fichier sauf si vous le modifiez dans les paramètres d’exportation. Sketch propose un réglage similaire par document. Si votre designer travaille sur un MacBook Pro et exporte sans vérifier ce paramètre, le PNG résultant est P3.

La correction consiste à convertir – pas simplement à étiqueter – le fichier en sRGB. Il y a une distinction importante ici. L’option sips -s profile intègre un profil différent dans les métadonnées sans transformer les valeurs de pixels. Cela produit un mensonge : les pixels sont encodés en P3 mais étiquetés comme sRGB. L’option correcte est --matchTo, qui effectue une conversion d’espace colorimétrique réelle :

sips --matchTo '/System/Library/ColorSync/Profiles/sRGB Profile.icc'   icon.png --out icon-srgb.png

Ceci lit les pixels source comme P3, les convertit en équivalents sRGB, et écrit un nouveau fichier. La variation de couleur est imperceptible sur la plupart des écrans mais compte pour la conformité avec le validateur. Après l’exécution, confirmez le résultat :

sips --getProperty profile icon-srgb.png

Le profil devrait maintenant indiquer « sRGB IEC61966-2.1 ».

Supprimer le canal alpha

sips ne peut pas supprimer les canaux alpha. Il peut les inspecter, et il peut ajouter un profil à un fichier qui en a un, mais la suppression de la couche alpha nécessite un outil différent. La commande convert d’ImageMagick gère cela proprement :

convert icon-srgb.png -background white -alpha remove -alpha off icon-final.png

Les options fonctionnent en séquence. -background white définit la couleur de fond qui remplacera les pixels transparents. -alpha remove compose l’image sur ce fond, éliminant la transparence. -alpha off supprime entièrement le canal alpha de la sortie. Le résultat est un PNG plat et opaque que le validateur App Store accepte.

Si votre icône n’a pas de transparence réelle – tous les pixels sont entièrement opaques – mais que le fichier porte toujours un canal alpha dans sa structure, vous pouvez utiliser pngcrush à la place. Sa réduction sans perte du type de couleur, activée par défaut depuis pngcrush 1.8.0, réécrit une image RGBA entièrement opaque en RGB sans modifier les valeurs des pixels :

pngcrush -ow -rem alla icon.png

Le canal alpha est constitué de données de pixels, ce n’est pas un bloc de métadonnées ; l’option -rem alla ne le supprime donc pas. Elle supprime tous les blocs auxiliaires connus sauf tRNS, y compris tout profil colorimétrique intégré : vérifiez donc à nouveau le profil après l’opération. -ow écrase le fichier d’origine. C’est plus rapide et sans perte, mais la réduction ne se produit que lorsqu’il n’y a pas de transparence réelle à aplatir. Si identify -verbose icon.png | grep Alpha montre des pixels non opaques, utilisez ImageMagick.

Le cas limite du mode couleur indexé

RGB TrueColor stocke chaque pixel comme trois valeurs indépendantes de canal sur 8 bits (ou 16 bits). Le mode indexé stocke une palette de couleurs et y fait référence par index entier – un format conçu pour les petits GIFs en 1989, pas pour les icônes d’applications. La plupart des outils de design ne produisent jamais de PNG indexés, mais certains pipelines d’optimisation web – notamment les plus anciens utilisant des outils comme pngquant de manière agressive – peuvent convertir des icônes TrueColor en images indexées sous l’effet de la quantification de palette.

Pour vérifier le mode couleur avec ImageMagick :

identify -verbose icon.png | grep -E "^  Type"

Un fichier TrueColor indique Type: TrueColor ou Type: TrueColorAlpha. Un fichier indexé indique Type: Palette. Si vous voyez Palette, convertissez-le :

convert icon.png -type TrueColor icon-truecolor.png

En pratique, c’est la raison de rejet la moins courante, mais elle apparaît régulièrement dans les bases de code où les icônes ont été traitées par un script d’optimisation des ressources graphiques à un moment donné dans leur historique.

Le pipeline de correction combiné

Lorsqu’une icône présente les trois problèmes – profil P3, canal alpha, et potentiellement des métadonnées obsolètes – l’approche la plus propre est une courte chaîne de commandes : sips pour la conversion colorimétrique, puis une commande ImageMagick pour tout le reste :

sips --matchTo '/System/Library/ColorSync/Profiles/sRGB Profile.icc'   icon.png --out /tmp/icon-srgb.png   && convert /tmp/icon-srgb.png     -type TrueColor     -background white     -alpha remove     -alpha off     -strip     icon-final.png

L’option -strip à la fin supprime tous les profils intégrés, commentaires et blocs de métadonnées auxiliaires de la sortie. À ce stade, les pixels sont déjà convertis en sRGB, ce qui produit un PNG petit et propre ; pour conserver la balise sRGB explicite recommandée plus haut, omettez -strip. Après cette opération, une dernière exécution de sips --getProperty all icon-final.png devrait confirmer hasAlpha: no, space: RGB, et soit aucun profil, soit le profil sRGB explicitement intégré.

Corriger le problème à la source

Les corrections en ligne de commande fonctionnent, mais la vraie solution est de configurer votre outil de design pour exporter correctement la première fois. Dans Figma, définissez le profil colorimétrique du fichier sur sRGB, ou choisissez sRGB dans les paramètres d’exportation, avant d’exporter des ressources graphiques. Dans Sketch, cliquez sur une zone vide du canevas et réglez Color Profile dans l’Inspector. Dans Affinity Designer, ouvrez File → Document Setup, choisissez l’onglet Color et assurez-vous que le profil est défini sur sRGB IEC61966-2.1.

Pour les icônes App Store spécifiquement, le format d’export doit être PNG, 1024×1024, sans mise à l’échelle appliquée, avec le profil sRGB actif. Si votre pipeline CI/CD envoie les fichiers vers App Store Connect via xcrun altool ou l’API App Store Connect directement, ajoutez une étape de validation avant l’envoi qui exécute sips --getProperty hasAlpha et fait échouer la compilation si l’alpha est présent. Détecter cela avant l’appel API évite un aller-retour et une investigation manuelle.

La leçon sous-jacente ici est que la validation d’App Store Connect fait exactement ce qu’Apple a documenté. Le problème est que la documentation n’est pas mise en avant dans le flux de travail d’envoi, et les messages d’erreur ne correspondent pas à des conditions d’échec spécifiques. Une fois que vous connaissez les trois propriétés vérifiées, le processus de validation cesse d’être mystérieux et devient une simple liste de contrôle.

Analyses connexes

De la conception SwiftUI à l’App Store en quelques semaines – La chronologie et les décisions générales pour soumettre une application, y compris le provisionnement et le processus d’examen.
Créer une application de préparation aux examens avec des milliers de questions – Décisions d’architecture pour une application iOS modulaire avec un backend Supabase et un fonctionnement hors ligne.
Concurrence Swift 6 : guide de migration pratique – Migration des applications SwiftUI vers la concurrence stricte de Swift 6, avec de véritables avertissements du compilateur et leurs corrections.