# Guideline 2.3.3 : captures refusées par Apple, les refaire > Guideline 2.3.3 : plus de la moitié de tes captures doivent montrer le vrai écran de l'app en usage. Ce qui passe, ce qui est refusé, la correction sans build. Page originale : [Guideline 2.3.3 : captures refusées par Apple, les refaire](https://devoria.fr/blog/guideline-2-3-3-captures-app-en-usage) Auteur : [Mehdi Azizi](https://devoria.fr/mehdi-azizi) Publication : 2026-11-04 Dernière révision du contenu : 2026-11-04 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 : ```text 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](https://developer.apple.com/forums/thread/765166) 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 : ```text 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](https://developer.apple.com/app-store/review/guidelines/#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](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots) 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](https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications), 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](https://devoria.fr/blog/taille-capture-ecran-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](https://devoria.fr/blog/guideline-2-3-10-metadonnees-app-store) | 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](https://developer.apple.com/help/app-store-connect/manage-app-information/manage-your-app-store-assets), 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](https://developer.apple.com/help/app-store-connect/reference/app-information/app-and-submission-statuses) 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](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/manage-a-submission-with-unresolved-issues/) : 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 : ```text 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](https://devoria.fr/blog/repondre-app-review-resolution-center). ## 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](https://developer.apple.com/app-store/product-page/), 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](https://devoria.fr/blog/pourquoi-apple-refuse-votre-app). ## Des captures qui passent du premier coup Le [Kit Captures](https://devoria.fr/kits/captures-app-store) 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](https://devoria.fr/kits/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](https://devoria.fr/expertise/application-refusee-par-apple). Si tu prépares ta première sortie, [fais ton diagnostic gratuit](https://devoria.fr/diagnostic) : 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. ## Ton projet [Kit Review](https://devoria.fr/kits/review-apple) : Tout ce que je vérifie avant d'envoyer une app à Apple, la même vérification pour Google Play, et trois skills qui font la relecture avec Claude Code. 49 €, paiement unique. Inclus : La checklist avant l'envoi ; Les refus que j'ai pris, et ce que j'ai corrigé ; Les notes pour le testeur ; Les skills de vérification. Prérequis : une app iPhone ou Android presque prête, et Claude Code ou Cursor. Téléchargement immédiat après le paiement. [Kit iOS & Android Devoria](https://devoria.fr/kits/ios) : Le code de départ de mes apps, le parcours jusqu'à l'App Store et Google Play avec les messages à donner à Claude, et tous les kits. Claude part d'une app qui tourne déjà. 99 €, paiement unique. Inclus : Le code de départ de ton app ; Les styles visuels ; Le parcours pas à pas ; Kit Review ; Kit Captures ; Kit ASO ; Mises à jour à vie ; Bonus : la séance 1:1 à moitié prix. Prérequis : pour l'iPhone, un Mac avec Xcode 26 ou plus et un compte Apple Developer (99 $ par an) pour publier. Pour Android, Android Studio sur un Mac, un PC Windows ou Linux, et un compte Google Play Console (25 $, une fois). Et Claude Code (abonnement payant) ou Cursor. Téléchargement immédiat après le paiement. [Diagnostic gratuit](https://devoria.fr/diagnostic) : quelques questions sur ton projet. Il dit ce qui te bloque vraiment, l'ordre des quatre étapes et le kit qui correspond. En laissant ton e-mail, tu reçois la checklist anti-refus Apple : les points vérifiés avant chaque envoi, tirés des refus reçus par les apps du studio. [Une heure avec moi](https://devoria.fr/coaching) : On regarde ton app ou ton projet Claude, écran partagé : ce qui bloque, ce que je change en premier, et dans quel ordre. 100 € la séance d'une heure, en visio, paiement en une fois. Sujets : L'audit de ton app ; Ton travail avec Claude ; Ta fiche et ton paywall ; Un refus d'Apple.