Guideline 2.3.3 : captures refusées par Apple, les refaire

Un refus « Guideline 2.3.3 - Performance - Accurate Metadata » veut dire qu'Apple juge que tes captures ne montrent pas l'app en train de servir. La règle est chiffrée : pour chaque type d'appareil, plus de la moitié des captures doivent montrer le vrai écran de l'app en usage. Le refus porte sur la fiche, pas sur le binaire : tu remplaces les captures et tu renvoies le même build.

Je l'ai vécu le 27 octobre 2026 avec Vigie, mon app de suivi ASO. Mes captures montraient des cartes d'interface redessinées autour d'une mascotte, sans téléphone. Apple les a refusées. Ce guide reprend le message reçu, ce qu'Apple appelle « app in use », ce qui passe et ce qui ne passe pas, puis la check-list que j'applique depuis. Les règles citées viennent des pages officielles d'Apple, relues le 3 novembre 2026.

Le message d'Apple, mot pour mot

Le message commence par l'intitulé de la règle, puis nomme la taille d'appareil visée. Pour Vigie, la phrase qui portait le refus était celle-ci :

The 6.7-inch iPhone screenshots do not show the actual app in use.

D'autres refus 2.3.3 détaillent ce que le reviewer attend. Celui-ci a été publié sur les forums d'Apple en octobre 2024 par un développeur dont les emplacements iPad montraient un cadre d'iPhone. Voici le passage qui liste les exigences, mot pour mot :

Some or all of the provided screenshots do not sufficiently show
the app in use. Screenshots should highlight the app's core concept
to help users understand the app's functionality and value.

- Marketing or promotional materials that do not reflect the UI
  of the app are not appropriate for screenshots.
- The majority of the screenshots should highlight the app's main
  features and functionality.
- Confirm that the app looks and behaves identically in all
  languages and on all supported devices.
- Make sure that the screenshots show the app in use on the
  correct device, unless they are included to demonstrate that
  the app can be used on multiple Apple platforms. For example,
  iPhone screenshots should be taken on iPhone, not on iPad.

En français : un visuel publicitaire qui ne montre pas l'interface de l'app n'a pas sa place parmi les captures. La majorité doit montrer les fonctions principales. Et chaque capture montre le bon appareil : une capture d'iPhone se prend sur iPhone, pas sur iPad, sauf pour montrer que l'app fonctionne sur plusieurs plateformes Apple.

Ce qu'Apple appelle « app in use »

Le texte de la guideline 2.3.3 est court : « Screenshots should show the app in use, and not merely the title art, login page, or splash screen. » Les captures doivent montrer l'app en usage, pas seulement le logo, l'écran de connexion ou l'écran de lancement. Le même texte autorise les textes et les images ajoutés par-dessus.

La page d'aide App Review sur la 2.3.3 précise la façon de juger. Apple évalue la série de chaque type d'appareil, et n'approuve que si plus de la moitié des captures montrent l'app en usage. Chaque langue est jugée à part. La page liste aussi ce qu'il faut éviter :

• des captures qui ne montrent qu'une page de connexion ou un écran de lancement ;
• une interface qui ne correspond pas à la vraie, ou un visuel publicitaire trompeur ;
• des habillages qui écrasent l'app, ou le matériel seul, sans interface derrière.

En clair, « en usage » veut dire : l'interface réelle de ton build, avec du contenu, en train de faire ce pour quoi on télécharge l'app. Un titre court au-dessus d'un vrai écran reste une capture en usage.

Combien de captures doivent montrer l'app

Apple donne deux exemples : avec trois captures, deux doivent montrer l'app. Avec quatre, trois. Le reste se déduit de la même règle, plus de la moitié.

Captures envoyées	Minimum en usage	Visuels marketing possibles
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
8	5	3
10	6	4

Le compte se fait par type d'appareil et par langue. Une seule capture par appareil suffit, si elle montre l'app en usage. D'après les spécifications des captures, Apple exige au moins une capture pour l'iPhone avec Dynamic Island à écran moyen, et en accepte jusqu'à 10 par taille. Si ton interface est la même sur toutes les tailles et dans toutes les langues, la plus haute résolution exigée suffit : App Store Connect la réduit pour les tailles plus petites. Les dimensions exactes sont dans la taille des captures App Store.

Ce qui passe, ce qui ne passe pas

Capture	Verdict	Ce qui décide
Vrai écran de l'app, titre court au-dessus	Passe	Le texte ajouté est permis par la 2.3.3
Vrai écran posé dans un iPhone	Passe	L'interface réelle, sur le bon appareil
Logo, écran de lancement ou connexion seuls	Refusée	Cité mot pour mot par la règle
Visuel marketing sans interface	Toléré en minorité	Seulement si la majorité montre l'app
Cartes d'interface redessinées, sans l'app	Refusée	Mon refus du 27 octobre 2026
Écran maquetté qui n'existe pas dans le build	Refusée	Interface qui ne correspond pas à la vraie
Téléphone vide ou décor sans interface derrière	Refusée	Listé dans ce qu'il faut éviter
Capture d'iPhone dans les emplacements iPad	Refusée	Le mauvais appareil, d'après le refus du forum
Image qui s'étend sur deux captures	Passe	Permis, tant que l'app reste visible
Barre d'état d'une autre plateforme	Refusée, au titre de 2.3.10	Renvoyé par Apple vers la guideline 2.3.10

Apple n'impose pas de cadre de téléphone. Une capture plein écran de l'app suffit. Le cadre a un mérite : il rend évident, au premier coup d'œil, que l'image est l'app.

Mon cas : Vigie refusée le 27 octobre 2026

Pour la version 1.1 de Vigie, j'avais suivi une tendance des studios de captures : une fresque continue, une mascotte, et des cartes d'interface flottantes au lieu d'un téléphone entier. Les cartes étaient redessinées pour l'occasion, avec des apps fictives. C'était joli. Ce n'était pas l'app.

Le reviewer a écrit que les captures de l'iPhone 6,7 pouces ne montraient pas l'app en usage. Je n'ai pas contesté : il avait raison. J'ai refait toute la série avec une règle simple :

1. Chaque panneau montre un iPhone avec une capture native du simulateur, collée au pixel près, sans retouche de l'interface.
2. Une carte agrandie n'apparaît qu'en plus du téléphone, jamais à sa place, et elle est découpée dans cette même capture.
3. Le décor reste autour, jamais par-dessus l'écran.

Ce refus ne demandait aucun nouveau build. J'ai remplacé les captures et renvoyé la même version le soir même. J'ai ensuite changé de build pour corriger un titre dans l'app, sans rapport avec les captures. Vigie 1.1 était en vente le 29 octobre avec cette série.

Une carte redessinée, même fidèle, n'est pas l'app. Le reviewer veut voir l'écran que l'utilisateur aura entre les mains.

Corriger sans nouveau build

1. Lis le message en entier. Il dit quelle taille d'appareil est visée, parfois quelle langue. Toutes les séries concernées doivent changer, pas seulement la première.
2. Refais les captures depuis le build envoyé. Simulateur ou appareil, avec du contenu réel. Plus de la moitié en usage, pour chaque appareil et chaque langue.
3. Remplace les captures dans App Store Connect. D'après l'aide sur la gestion des visuels, c'est possible quand l'app est dans l'un de ces statuts : Prepare for Submission, Invalid Binary, Rejected, Metadata Rejected ou Developer Rejected.
4. Renvoie, selon le statut affiché. Pour Metadata Rejected, le tableau des statuts dit : lis le message, corrige les métadonnées, puis réponds au message d'App Review. Si la soumission affiche Unresolved Issues, suis la procédure d'Apple : dans Apps, View App Review Issues & Messages, puis Resolve, Edit sur l'élément refusé, Add for Review, et enfin Resubmit to App Review.
5. Ne touche plus aux captures une fois l'envoi fait. D'après le même tableau des statuts, en Waiting for Review, tu ne peux ni envoyer ni modifier des captures.

Chaque élément refusé ne se modifie qu'une fois avant le renvoi : vérifie ta nouvelle série avant de cliquer. La réponse que j'écrirais au reviewer, en anglais :

Hello App Review team,

Thank you for your feedback regarding Guideline 2.3.3.

We replaced the [6.9-inch iPhone] screenshots in all localizations.
Each screenshot now shows the actual app interface, captured from
the submitted build: [main screen], [key feature], [result screen].

The build is unchanged.

Best regards,
[Your name]

Le ton et la forme d'une bonne réponse sont détaillés dans répondre à App Review.

La check-list avant d'envoyer tes captures

• Plus de la moitié des captures de chaque type d'appareil montrent le vrai écran, avec du contenu.
• La même règle tient dans chaque langue, pas seulement en anglais.
• Aucune capture ne montre seulement le logo, l'écran de lancement ou la connexion.
• L'interface montrée existe dans le build envoyé, à l'identique.
• Les titres et le décor laissent l'interface lisible.
• Les captures d'iPhone sont prises sur iPhone, celles d'iPad sur iPad.
• Aucune trace d'une autre plateforme, même dans la barre d'état.
• Si ton app a un mode sombre, une capture le montre : la page d'aide d'Apple le conseille.
• Les fichiers sont en JPEG ou en PNG, sans transparence.

Apple rappelle aussi, sur sa page sur la fiche produit, que les premières captures peuvent apparaître dans les résultats de recherche. Pour moi, une capture qui montre clairement l'app en train de servir vend mieux qu'un slogan. Les autres motifs de refus de la fiche sont dans pourquoi Apple refuse une app.

Des captures qui passent du premier coup

Le Kit Captures réunit mes modèles et le skill qui crée tes captures à partir des vrais écrans de ton app, dans les tailles demandées par Apple. Si ta fiche vient d'être refusée, le Kit Review Apple contient ma checklist avant l'envoi, mes refus corrigés et les modèles de réponse au reviewer. La démarche complète est sur la page application refusée par Apple.

Si tu prépares ta première sortie, fais ton diagnostic gratuit : il remet les étapes dans l'ordre et t'envoie ma checklist anti-refus Apple.

Questions fréquentes

Que veut dire « Guideline 2.3.3 - Performance - Accurate Metadata » ?

C'est l'intitulé du refus pour des captures qui ne montrent pas l'app en usage. Apple juge que trop de captures sont des visuels marketing, des écrans de lancement ou des interfaces qui ne sont pas celles de l'app. Le message précise souvent la taille d'appareil concernée.

Faut-il un nouveau build après un refus 2.3.3 ?

Non. Le refus porte sur la fiche App Store. Tu remplaces les captures dans App Store Connect, puis tu renvoies la même version en répondant au message d'App Review.

Combien de captures doivent montrer l'app en usage ?

Plus de la moitié, pour chaque type d'appareil et dans chaque langue. Avec trois captures, deux doivent montrer l'app. Avec quatre, trois. Une seule capture suffit si elle montre l'app en usage.

Peut-on mettre du texte marketing sur les captures App Store ?

Oui. La guideline 2.3.3 autorise les textes et images ajoutés par-dessus. Ils ne doivent pas cacher l'interface, et la majorité des captures doit toujours montrer l'app en usage.

Faut-il un cadre d'iPhone autour des captures ?

Non, Apple ne l'exige pas : une capture plein écran de l'app passe. Le cadre aide le lecteur à comprendre que l'image est l'app. Il doit être celui du bon appareil : jamais un cadre d'iPhone sur une capture destinée à l'iPad.

Peut-on modifier les captures pendant que l'app attend la review ?

Non. En statut Waiting for Review, App Store Connect ne permet ni d'envoyer ni de modifier des captures. Pour les changer, retire la soumission de la revue ou attends la décision.