Rejet App Store 2.1 App Completeness : tester le build de release avant de resoumettre (2026)

Un rejet App Store au titre de la règle 2.1 App Completeness signifie que le testeur n'a pas pu utiliser votre app comme le ferait un client. Elle a peut-être planté, affiché du contenu provisoire, bloqué le testeur sur un écran de connexion ou masqué un achat intégré. La correction tient rarement en une seule ligne de code. Avant de resoumettre, exécutez un court plan de test sur le build de release, avec une installation neuve et les mêmes identifiants que ceux fournis à App Review. Cet article détaille ce plan et montre comment d'autres développeurs ont corrigé le même rejet.

Que vérifie la règle 2.1 App Completeness de l'App Store ?

La règle 2.1 vérifie que le build soumis est une app terminée et fonctionnelle. Il lui faut des métadonnées complètes, des liens qui fonctionnent, un compte démo, un backend en ligne et des achats intégrés que le testeur peut trouver et utiliser.

Les App Review Guidelines d'Apple divisent la règle 2.1 en deux parties. La 2.1(a) indique que les soumissions « doivent être des versions finales, avec toutes les métadonnées nécessaires et des URL entièrement fonctionnelles », et que le texte provisoire et les sites web vides doivent être supprimés. Elle demande aussi de tester sur un appareil pour détecter bugs et problèmes de stabilité, et d'« inclure les informations d'un compte démo (et d'activer votre service backend !) si votre app comporte une connexion ». Apple « rejettera les bundles d'app incomplets et les binaires qui plantent ou présentent des problèmes techniques évidents ». La 2.1(b) précise que les achats intégrés doivent être « complets, à jour, visibles par le testeur et fonctionnels ». Si un achat configuré est introuvable dans l'app, expliquez pourquoi dans vos notes de review.

Ce rejet est fréquent. La page Preparing for App Review d'Apple indique : « En moyenne, plus de 40 % des problèmes non résolus concernent la règle 2.1 : App Completeness, qui couvre les plantages, le contenu provisoire, les informations incomplètes, et plus encore. »

Pourquoi tester le build de debug ne détecte-t-il pas les problèmes 2.1 ?

Un build de debug ne fonctionne pas comme la copie du testeur. Celui-ci installe un build de release signé pour la distribution sur un appareil vierge, sans session enregistrée ni raccourcis de debug.

Votre simulateur est déjà connecté. Votre API locale pointe peut-être vers un serveur de staging qui ne tombe jamais. Les flags de debug contournent le paywall et les feature flags sont activés par défaut. Le testeur n'a rien de tout cela. La page de review d'Apple demande aussi de « tester minutieusement sur des appareils équipés des dernières versions logicielles » : le testeur peut donc utiliser une version d'iOS plus récente que votre téléphone de test.

TestFlight est ce qui se rapproche le plus de l'environnement du testeur. Selon la présentation de TestFlight, vous pouvez ajouter jusqu'à 100 testeurs internes issus de votre équipe App Store Connect et jusqu'à 10 000 testeurs externes. Un build reste testable jusqu'à 90 jours. Envoyez le build exact que vous comptez soumettre, installez-le depuis TestFlight sur un appareil qui n'a jamais exécuté l'app, et testez cette copie.

Que doit couvrir un plan de test du build de release avant de resoumettre ?

Un plan de test du build de release vérifie tous les points où un testeur découvrant l'app peut rester bloqué : lancement, autorisations, connexion, backend, contenu, liens, achats, pannes réseau et iPad. Exécutez les étapes dans l'ordre sur le build TestFlight et notez chaque résultat pour pouvoir le citer dans vos notes de review.

1. Installation neuve sur la dernière version d'iOS. Supprimez toute copie précédente, installez depuis TestFlight et lancez sans aucun état enregistré. Faites trois lancements à froid et vérifiez que l'onboarding ne plante pas.
2. Refusez une fois chaque demande d'autorisation. Refusez notifications, localisation, appareil photo et suivi. L'app doit tout de même atteindre un écran utilisable. Vérifiez aussi qu'Info.plist contient une description d'usage pour chaque ressource protégée utilisée par l'app ou ses SDK.
3. Connectez-vous avec les identifiants de démo exacts. Copiez-les depuis App Store Connect, pas depuis votre gestionnaire de mots de passe. Le compte doit contenir des données réalistes, ne pas exiger de vérification d'e-mail et ne pas utiliser d'authentification à deux facteurs liée à votre propre téléphone.
4. Vérifiez que le backend est celui de production et qu'il est en ligne. Le build doit pointer vers les endpoints de production. Limites de débit, listes d'IP autorisées et blocages géographiques ne doivent pas bloquer un testeur. La règle 2.1(a) vous demande d'activer votre service backend.
5. Parcourez chaque onglet et chaque écran. Cherchez du lorem ipsum, des écrans « Bientôt disponible », des états vides sans explication, des images de test et des boutons qui ne font rien.
6. Touchez chaque lien. Cela inclut politique de confidentialité, support, conditions d'utilisation et toutes les web views. Apple indique qu'« un lien vers le support utilisateur avec des coordonnées à jour et un lien vers votre politique de confidentialité sont requis pour toutes les apps ».
7. Ouvrez chaque achat intégré. Connectez-vous avec un nouveau compte. Vérifiez que chaque produit soumis avec la version s'affiche avec un prix, peut être acheté dans la sandbox, et que la restauration des achats fonctionne.
8. Testez sur un réseau lent ou coupé. Activez le mode avion au milieu d'un parcours. Un message d'erreur clair est acceptable. Un indicateur de chargement sans fin, ou un plantage, ne l'est pas.
9. Vérifiez l'iPad si vous le prenez en charge. Si l'app fonctionne sur iPad, lancez-la dessus et assurez-vous que la mise en page ne bloque pas l'utilisateur.

Le compte démo de l'étape 3 provoque plus de rejets répétés que toute autre étape. Notre guide pour configurer un compte démo pour l'App Review explique comment en créer un qui dure.

Comment associer un message de rejet 2.1 à une correction ?

Pour associer un rejet 2.1 à une correction, lisez la phrase qui suit le numéro de la règle. Elle nomme le symptôme, et chaque symptôme renvoie à une étape du plan de test.

Imaginons une app de suivi d'habitudes rejetée avec le message « We were unable to review the app because it crashed on launch » (nous n'avons pas pu examiner l'app car elle a planté au lancement). Une seconde note indique que le testeur n'a pas trouvé les achats intégrés. Le tableau ci-dessous associe les symptômes courants à une cause, un test et une correction.

Pour une méthode plus générale permettant de lire n'importe quel message de rejet, consultez Rejet App Store : comment le corriger, règle par règle.

À quoi ressemblaient les rejets 2.1 d'autres développeurs ?

Les cas publics de rejet 2.1 suivent le même schéma. L'app fonctionne dans l'environnement du développeur et échoue chez le testeur à cause d'un détail que seule une installation neuve ou la connexion d'un inconnu pouvait révéler.

• Plantage dû à une description d'usage manquante. Sur les forums Solar2D, un développeur s'est vu répondre « We were unable to review the app because it crashed on launch » sur un iPhone 13 mini sous iOS 18.3.2, alors que l'app fonctionnait dans TestFlight. Un autre membre a trouvé ceci dans le journal de plantage joint : « This app has crashed because it attempted to access privacy-sensitive data without a usage description. » Le développeur a ensuite indiqué que l'app était acceptée après l'ajout de NSUserTrackingUsageDescription.
• Connexions via réseaux sociaux inutilisables par le testeur. Sur les Apple Developer Forums, un développeur a signalé des rejets 2.1 répétés parce que les testeurs « n'ont pas pu utiliser les connexions via réseaux sociaux ». Il avait fourni des comptes démo Apple et Google, mais la connexion avec l'identifiant Apple exigeait un code de vérification envoyé sur le téléphone du développeur. Le personnel d'Apple a répondu qu'App Review le contacterait directement. Aucune solution publique n'a été publiée.
• Achats intégrés « introuvables dans le binaire soumis ». Dans un fil de la communauté RevenueCat, un développeur a été rejeté parce qu'un abonnement mensuel n'avait pas été trouvé dans le binaire, alors que les achats en sandbox fonctionnaient. Un participant a expliqué qu'un rejet similaire avait été résolu en répondant avec un guide détaillé et des captures d'écran de chaque chemin vers le paywall. L'équipe RevenueCat a conseillé d'afficher chaque produit soumis sur le paywall par défaut et de garder les fichiers de test StoreKit hors du scheme d'archivage.

Dans ces trois cas, les tests du développeur réussissaient. L'échec n'apparaissait que du point de vue du testeur : pas de téléphone pour la 2FA, pas de session existante, aucune idée de l'emplacement du paywall. C'est précisément ce point de départ que recrée le plan de test ci-dessus.

Que doivent contenir les notes pour App Review après un rejet 2.1 ?

Après un rejet 2.1, les notes de review doivent fournir des identifiants de démo fonctionnels, lister ce qui a changé depuis le build rejeté et indiquer précisément où trouver les achats intégrés et les fonctionnalités peu évidentes.

La page de review d'Apple demande d'indiquer les informations de compte et toute configuration particulière dans la section App Review Information. Si une fonctionnalité nécessite un matériel ou un environnement difficile à mettre en place, « soyez prêt à fournir une vidéo de démonstration ou le matériel ». La règle 2.3.1(a) ajoute que les nouvelles fonctionnalités doivent être décrites « avec précision » dans les Notes for Review et que « les descriptions génériques seront rejetées ». Une note courte et structurée fonctionne bien :

Demo account: review@example.com / (password)
Account is pre-verified, has no 2FA and has 30 days of sample data.

Fixes since last submission (2.1):
- Launch crash on fresh install fixed (tested build 42 on latest iOS, clean device).
- In-app purchases: Settings > Upgrade shows Monthly and Yearly.
- Backend is production and will stay live during review.

Non-obvious features:
- Widgets: long-press Home Screen > add "Streaks" widget.

Si des obligations légales ou de sécurité empêchent de fournir un compte démo, la règle 2.1(a) autorise un mode démo intégré, mais uniquement avec l'accord préalable d'Apple, et ce mode doit présenter l'ensemble des fonctionnalités de l'app. Ne passez pas à un mode démo sans cet accord.

Comment resoumettre ou faire appel d'un rejet 2.1 ?

Pour resoumettre après un rejet 2.1, envoyez ou sélectionnez le build que vous avez testé, répondez à App Review dans App Store Connect en décrivant vos modifications, mettez à jour les notes de review et soumettez de nouveau. Ne faites appel que si vous pensez que le testeur a mal compris l'app.

1. Vérifiez que le numéro de build associé à la version dans App Store Connect correspond au build TestFlight que vous avez testé.
2. Répondez au message de rejet avec un bref résumé de chaque correction. Pour un problème d'achat ou de navigation, ajoutez des instructions pas à pas et des captures d'écran.
3. Mettez à jour la section App Review Information avec des identifiants et des notes à jour.
4. Soumettez pour review. En octobre 2026, Apple indique examiner généralement « au moins 50 % des soumissions en moins de 24 heures et 90 % en moins de 48 heures ».

Si vous pensez qu'Apple s'est trompé, la page App Review vous permet de faire appel auprès de l'App Review Board. Donnez des raisons précises pour lesquelles l'app est conforme, et « ne soumettez qu'un seul recours par soumission qui n'a pas passé la review ». Pour un rejet 2.1, toutefois, reproduire le problème sur un appareil vierge est généralement plus rapide que d'argumenter. Si vous préférez déléguer la resoumission, notre service de soumission App Store couvre la préparation de la review et le traitement des retours de rejet pour les deux stores pour 599 $, frais de compte développeur en sus.

Les problèmes 2.1 réapparaissent souvent lors de mises à jour ultérieures : un nouveau feature flag, une clé d'API renouvelée ou un compte démo expiré. Intégrez ce plan de test à votre routine de release, aux côtés de la checklist de soumission App Store. Pour les mises à jour, un déploiement progressif limite le nombre d'utilisateurs touchés par un bug passé inaperçu. Pour obtenir un second avis sur un build rejeté, envoyez le message de rejet à yagyeshsrbobde@gmail.com.