Captures d’écran App Store refusées : causes et solutions

Apple refuse des captures d’écran App Store quand elles ne montrent pas fidèlement l’app, en vertu de la section 2.3 (Accurate Metadata, métadonnées exactes) des App Review Guidelines. Les motifs les plus courants sont des captures d’écran qui ne montrent pas l’app en cours d’utilisation (2.3.3), des captures iPad qui sont en fait des images iPhone étirées, des images ou des noms d’autres plateformes comme Android (2.3.10), des prix dans l’image (2.3.7) et des fonctionnalités que l’app n’a pas vraiment (2.3 et 2.3.1). Une capture d’écran refusée fait en général passer l’app au statut Métadonnées refusées, que vous corrigez dans App Store Connect avant de répondre à l’App Review, sans nouveau build.

Vous trouverez ci-dessous chaque règle qui concerne les captures d’écran, dans les termes d’Apple, les motifs que nous voyons le plus souvent, les erreurs d’import qui ressemblent à des refus mais n’en sont pas, et la façon de répondre.

Quelles règles de l’App Review concernent les captures d’écran ?

Elles se trouvent toutes dans la section 2.3 des App Review Guidelines d’Apple, qui commence ainsi : « assurez-vous que toutes les métadonnées de votre app, y compris les informations de confidentialité, la description de l’app, les captures d’écran et les aperçus, reflètent fidèlement l’expérience principale de l’app. » Les points numérotés qui comptent pour les captures d’écran :

Le tableau paraphrase pour gagner de la place ; citez le texte exact de la règle quand vous répondez à l’App Review. Les numéros des règles changent parfois, alors vérifiez la page en ligne plutôt qu’un vieil article de blog (celui-ci compris) avant d’en citer une.

Les motifs de refus de captures d’écran les plus courants

1. La capture d’écran ne montre pas l’app en cours d’utilisation (2.3.3)

La règle 2.3.3 dit : « Les captures d’écran doivent montrer l’app en cours d’utilisation, et pas seulement l’écran titre, la page de connexion ou l’écran de lancement. » Elle autorise aussi les « superpositions de texte et d’images » : une capture d’écran mise en page avec une légende, un fond et un cadre d’appareil ne pose donc aucun problème. Ce qui est signalé, c’est une capture d’écran où l’app elle-même est absente ou réduite à un prétexte : un slogan sur un dégradé, un logo, un formulaire de connexion, un carrousel d’onboarding. Gardez une vraie interface, remplie de contenu, sur chaque capture d’écran, et soignez particulièrement la première, parce que c’est la plus visible (nous avons détaillé quoi mettre sur votre première capture d’écran App Store à part).

2. Des captures iPad qui sont en réalité des captures iPhone (2.3.3)

C’est l’un des refus que les développeurs signalent le plus souvent sur les forums d’Apple : l’emplacement iPad 13 pouces est rempli avec une capture iPhone étirée, complétée par des marges ou placée dans un cadre d’iPad. L’App Review considère que cela ne montre pas l’app en cours d’utilisation sur iPad. La solution : capturer l’app qui tourne sur un iPad (ou dans le simulateur iPad Pro 13 pouces) et concevoir la série iPad à partir de ces captures. Si votre app ne prend pas en charge iPadOS, vous n’avez pas besoin de série iPad du tout.

3. D’autres plateformes dans l’image (2.3.10)

La règle 2.3.10 vous demande de ne pas « inclure de noms, d’icônes ou d’images d’autres plateformes mobiles ou de boutiques d’apps alternatives dans votre app ou vos métadonnées, sauf fonctionnalité interactive spécifique et approuvée. » Dans les captures d’écran, cela veut généralement dire :

• Un cadre de téléphone Android, ou les barres d’état et de navigation d’Android, souvent parce qu’on a réutilisé une série Google Play
• Des badges « Disponible sur Google Play » ou une légende « Disponible sur Android »
• Une interface propre à Android dans une app multiplateforme capturée sur le mauvais appareil

Gardez une série séparée par store. Les générateurs qui exportent les deux depuis un même projet facilitent les choses ; une convention de nommage dans Figma aussi.

4. Prix et arguments promotionnels (2.3.7)

La règle 2.3.7 indique que « les métadonnées comme le nom de l’app, le sous-titre, les captures d’écran et les aperçus ne doivent pas inclure de prix, de conditions ou de descriptions qui ne sont pas propres au type de métadonnées. » Des légendes comme « Seulement 2,99 $/mois », « Offre de lancement : -50 % » ou un bandeau avec le prix d’un essai gratuit sont des motifs typiques. Décrivez plutôt ce que fait l’app ; les prix, l’App Store les affiche déjà.

5. Des fonctionnalités que l’app n’a pas (2.3, 2.3.1)

Des mockups de fonctionnalités à venir, un design nettement différent de l’interface publiée ou une capture issue d’une autre version de l’app peuvent tous être jugés trompeurs. La règle 2.3.1 cite explicitement le fait de « mettre en avant des contenus ou des services que l’app ne propose pas réellement ». Faites vos captures d’écran à partir du build que vous soumettez.

6. Des fonctionnalités payantes montrées sans indiquer qu’elles sont payantes (2.3.2)

La règle 2.3.2 demande que « la description de l’app, les captures d’écran et les aperçus indiquent clairement si des éléments, niveaux, abonnements, etc. mis en avant nécessitent des achats supplémentaires. » Si votre capture principale montre une fonctionnalité Pro, une petite étiquette « Pro » ou « Premium » dans l’interface ou la légende, plus une formulation claire dans la description, évite la question.

7. Vraies données, contenus sous licence et interface inachevée

La règle 2.3.9 demande des informations de compte fictives plutôt que les données d’une vraie personne, et vous rend responsable des droits sur tout ce qui est affiché. Des photos de célébrités, des logos d’équipes sportives ou des affiches de films dans un fil de démo sont un risque si vous n’en avez pas les droits. Par ailleurs, la règle 2.1 demande que les soumissions soient des versions finales, sans texte de remplissage ni autre contenu temporaire : les menus de débogage, le « Lorem ipsum » et les bandeaux d’environnement de test n’ont donc rien à faire dans les captures d’écran non plus. Notre guide pour des captures d’écran propres depuis le simulateur et l’émulateur explique comment préparer des données de démo et une barre d’état soignée.

Les erreurs d’import qui ne sont pas des refus

Certains problèmes de captures d’écran n’arrivent jamais jusqu’à l’App Review, parce qu’App Store Connect refuse le fichier à l’import. Ils sont plus rapides à corriger, mais tout aussi bloquants.

Les spécifications des captures d’écran d’Apple listent chaque taille acceptée par groupe d’appareils, et notre référence des tailles de captures d’écran réunit les plus courantes dans un seul tableau.

Comment répondre à un refus de captures d’écran

1. Lisez le message dans App Store Connect

Les détails du refus apparaissent dans la section App Review de la page de votre app dans App Store Connect (beaucoup de développeurs l’appellent encore le Centre de résolution, son ancien nom). Apple indique le numéro de la règle et, en général, une note sur les captures d’écran et la taille d’appareil en cause. Lisez-le attentivement : « vos captures d’écran iPad 13 pouces » et « vos captures d’écran iPhone » n’appellent pas la même correction.

2. Corrigez les métadonnées, pas le build

Pour le statut Métadonnées refusées, la référence des statuts d’Apple dit : « Lisez le message de l’App Review, modifiez les métadonnées pour résoudre le problème, puis répondez au message de l’App Review. » Remplacez les captures d’écran signalées dans chaque localisation qui les contient ; une correction en anglais seulement ne réglera pas un problème qui existe aussi dans votre série allemande. Vérifiez aussi les tailles mises à l’échelle dans le Gestionnaire de médias.

3. Répondez brièvement et précisément

Dites ce que vous avez changé, et où. Par exemple :

Thanks for the review. We've replaced the 13-inch iPad screenshots
in all 6 localizations with captures of the app running on iPad Pro
(13-inch). The previous images were scaled iPhone screenshots.
The build is unchanged.

4. Si vous n’êtes pas d’accord, expliquez ou faites appel

Si vous pensez que l’examinateur a mal lu la capture d’écran (par exemple, une fonctionnalité qu’il n’a pas trouvée se trouve derrière une connexion), répondez avec les étapes pour y accéder et ajoutez les identifiants d’un compte de démo dans les Informations pour l’App Review. Si cela ne règle rien, la page App Review d’Apple décrit l’appel auprès de l’App Review Board : expliquez précisément pourquoi l’app respecte les règles, soumettez un seul appel par soumission refusée, et répondez d’abord aux questions en suspens. Apple propose aussi des rendez-vous App Review de 30 minutes pour parler des règles avant de soumettre.

Une checklist avant soumission

• Chaque capture d’écran montre une vraie interface de l’app, remplie de contenu, issue du build que vous soumettez
• Les captures iPad sont de vraies captures sur iPad, ou il n’y en a pas parce que l’app ne prend pas en charge iPadOS
• Aucun cadre Android, aucune interface système Android, aucun badge Google Play ni nom d’une autre plateforme
• Aucun prix, aucune réduction ni aucun tarif d’essai dans les images
• Les fonctionnalités payantes sont signalées comme payantes quelque part dans la fiche
• Les images conviennent à un public 4+ et vous en détenez les droits
• Les données de démo sont fictives ; pas de texte de remplissage ni d’interface de débogage
• Tailles exactes acceptées en pixels, PNG ou JPEG, sans transparence, jusqu’à 10 par taille
• Corrections appliquées à chaque localisation, pas seulement à la langue principale

Pour les problèmes de design qui ne vous vaudront pas de refus mais vous coûteront des installations, consultez les erreurs courantes sur les captures d’écran d’app, et pour tout le processus, de la capture à l’import, comment créer des captures d’écran App Store.