Guideline 2.1 : comprendre et corriger un refus App Store

La guideline 2.1 est la règle qui fait tomber le plus de soumissions. Apple l'écrit lui-même sur sa page App Review : en moyenne, plus de 40 % des problèmes non résolus concernent la 2.1, celle qui couvre les plantages, le contenu provisoire et les informations incomplètes.

Cet article traite cette seule règle : ce qu'elle recouvre, ses deux variantes, la façon dont le reviewer teste ton app, et quoi lui répondre, avec trois refus que j'ai pris sur mes propres apps. Pour la vue d'ensemble de tous les motifs de refus, lis plutôt pourquoi Apple refuse une app.

Qu'est-ce que la guideline 2.1 App Completeness ?

La guideline 2.1 exige que l'app envoyée à Apple soit une version finale et complète : pas de plantage, pas de lien mort, pas de texte provisoire, un compte de démonstration si l'app demande une connexion, et des achats intégrés visibles et fonctionnels. Si le reviewer ne peut pas parcourir ton app jusqu'au bout, c'est un refus 2.1.

Le texte officiel se trouve dans les App Review Guidelines, section 2 « Performance ». Il se divise en deux alinéas.

2.1(a) demande que chaque soumission soit une version finale, avec toutes ses métadonnées et des URL qui fonctionnent. Le texte provisoire, les sites vides et tout contenu temporaire doivent disparaître avant l'envoi. L'app doit avoir été testée sur un appareil réel pour ses bugs et sa stabilité. Si elle demande une connexion, tu fournis un compte de démonstration et tu laisses ton serveur allumé. Un mode démo intégré peut remplacer ce compte, mais seulement avec l'accord préalable d'Apple, et il doit montrer toutes les fonctions de l'app. La phrase qui résume tout : « We will reject incomplete app bundles and binaries that crash ».

2.1(b) concerne les achats intégrés : ils doivent être complets, à jour, visibles par le reviewer et fonctionnels. Si un achat configuré dans App Store Connect est introuvable dans l'app, tu dois expliquer pourquoi dans les notes de revue.

Ce que la guideline 2.1 recouvre concrètement

Dans la pratique, un refus 2.1 tombe pour l'une de ces raisons :

• Un plantage. Au lancement, après une permission refusée, sans réseau. Un seul suffit.
• Un lien mort. Confidentialité, conditions d'utilisation, support : chaque URL déclarée sera ouverte.
• Une fonction inaccessible. Un bouton qui ne mène nulle part, un écran obligatoire impossible à franchir, un onboarding sans sortie. La forme la plus traître : invisible sur ton propre téléphone.
• Un compte de démonstration manquant ou expiré. Le reviewer reste bloqué à l'écran de connexion, ou le compte fourni ne marche plus, ou le serveur est coupé.
• Du contenu de remplissage. Lorem ipsum, « Bientôt disponible », écran vide, données de test visibles.
• Des achats intégrés introuvables. L'abonnement existe dans App Store Connect, mais le reviewer ne trouve pas l'écran qui le vend, ou l'achat échoue en sandbox. Les erreurs d'écran de paiement les plus courantes sont dans paywall iOS : 7 erreurs de débutant.

2.1 Information Needed ou 2.1(a) : quelle différence ?

Les messages d'Apple ne portent pas tous le même intitulé, et la différence change ta réponse.

« Guideline 2.1 - Information Needed » signifie que le reviewer n'a pas pu aller au bout de sa revue et te pose une question. Il manque un identifiant, une explication, un moyen d'atteindre une fonction. Ce n'est pas encore un constat de bug : c'est une demande. Parfois, une réponse précise dans App Store Connect suffit. Mais si la question révèle un vrai blocage dans l'app, il faut un nouveau build.

« Guideline 2.1(a) - Performance - App Completeness » signifie que le reviewer a constaté un problème : un plantage, un bug, un écran qui ne répond pas. Le message indique en général l'appareil utilisé et joint souvent une capture. Là, il faut corriger, renvoyer un build, puis répondre.

Comment Apple teste ton app

Mets-toi à la place du reviewer. Trois points comptent.

Il teste sur un appareil que tu n'as peut-être pas. Le message de refus précise souvent le modèle. La règle 2.4.1 indique que les apps iPhone doivent tourner sur iPad dès que possible, et une app conçue pour l'iPhone s'y affiche en mode compatibilité, dans une fenêtre au format iPhone. Mes refus 2.1 récents venaient d'un iPad Air : si tu ne testes que sur ton iPhone, tu ne vois pas ce que voit le reviewer.

Il part d'un premier lancement. App neuve, aucun cache, aucune session, aucune mise à jour téléchargée.

Le réseau doit fonctionner en IPv6 seul. La règle 2.5.5 exige que l'app fonctionne pleinement sur un réseau IPv6 uniquement, et la page de support d'Apple sur l'IPv6 en fait une exigence pour toutes les apps soumises depuis le 1er juin 2016. Le risque vient d'une adresse IPv4 écrite en dur : Apple conseille de tester sur un réseau IPv6 seul, données cellulaires coupées.

Pour reproduire ces conditions avant l'envoi, TestFlight sur plusieurs appareils reste le plus simple : voir TestFlight : tester son app iPhone.

Trois refus que j'ai pris, et leur vraie cause

Trois refus récents sur mes propres apps, avec leur vraie cause.

Solys : une démo de mini-jeu impossible à gagner sur iPad

Solys est mon réveil à mini-jeux. Le 18 août 2026, un build est refusé en « 2.1 Information Needed » : Apple demande un moyen de passer la mission de jeu. Le reviewer testait sur un iPad Air, avec l'app iPhone en mode compatibilité.

La cause réelle était dans la démo de mini-jeu de l'onboarding. Les hauteurs d'obstacles étaient écrites en points fixes. Sur la hauteur de carte disponible sur l'iPad en compatibilité, le passage devenait plus étroit que le personnage : la démo était impossible à gagner. Et le bouton « Continuer » ne s'allumait qu'en cas de victoire. Aucune issue : le reviewer ne pouvait pas voir l'app.

Le correctif : une géométrie proportionnelle à la taille mesurée de la carte, et un lien « Passer la démo » qui apparaît après une défaite.

La leçon : toute étape bloquée par une performance doit avoir une sortie sans condition. Et chaque écran obligatoire se teste sur le plus petit écran pris en charge ET sur iPad en mode compatibilité.

Nolera : un correctif invisible pour le reviewer

Le 17 septembre 2026, Nolera est refusée après une revue sur iPad Air. Le message combinait la 2.1(a) et d'autres points. Le correctif du problème signalé avait été livré par mise à jour à distance (OTA), sans nouveau build.

Le problème : au tout premier lancement, le reviewer voit le code embarqué dans le build, pas la mise à jour téléchargée ensuite. Pour lui, le correctif n'existait pas.

La leçon : un correctif destiné à la revue doit être dans le binaire envoyé à Apple.

Clic : la cause n'était pas dans l'app

Le 16 septembre 2026, Clic est refusée. L'app, elle, était à jour. La cause réelle était ailleurs : la politique de confidentialité publiée en ligne n'était pas à jour sur le fournisseur d'IA utilisé. Ce refus relève plutôt de la confidentialité que de la 2.1, mais il illustre la même chose : les causes réelles ne sont pas toujours celles que le message laisse croire.

La leçon : vérifie ce qui est en ligne, pas ce qui est dans ton dépôt. Ouvre chaque URL déclarée le jour de l'envoi.

Que répondre dans le Resolution Center

Après un refus, ta soumission passe en « Unresolved Issues » et la conversation avec Apple se tient dans la section App Review de ton app, qu'on appelle encore le Resolution Center. La procédure officielle pour répondre à App Review permet un message de 4 000 caractères au maximum, avec une pièce jointe.

Écris en anglais, sobrement. Le reviewer veut trois informations : ce qui bloquait, ce qui a changé, comment le vérifier. Voici le modèle que j'utilise (remplace le numéro de build et le correctif par les tiens) :

Hello,

Thank you for your review.

Issue: the onboarding game demo could not be completed on iPad
(iPhone app running in compatibility mode), so the user could
not continue.

Fix in build 1.0.3 (42):
- The game layout now scales to the measured screen size.
- A "Skip demo" link appears after a failed attempt, so the
  onboarding can always be completed.

How to verify: launch the app, start the onboarding demo,
lose once, then tap "Skip demo".

A screen recording is attached.

Best regards,

Quelques règles :

• Réponds à la question posée. Sur un « Information Needed », commence par la réponse exacte, pas par le contexte.
• Nomme le build et donne le chemin vers l'écran corrigé, en trois ou quatre actions.
• Joins une preuve. Une courte vidéo sur un appareil proche de celui du reviewer évite un nouvel aller-retour.
• Pas de plaidoyer. L'appel devant l'App Review Board existe, mais sur un refus 2.1 mérité, il ne fait que rallonger l'attente. Le détail des délais est dans délai de validation App Store.

Si le motif reste flou après lecture, la démarche complète est sur la page application refusée par Apple.

Notes de revue et compte de démo

La section App Review Information de ta version, dans App Store Connect, est ta meilleure défense contre la 2.1. D'après la référence officielle de ces champs, elle contient :

• Sign-in required : l'identifiant et le mot de passe d'un compte de démonstration. Ce compte ne doit pas expirer. Si ton app passe par une connexion tierce, fournis les identifiants de ce service.
• Notes : jusqu'à 4 000 octets, dans la langue de ton choix. Tout ce qui aide à tester.
• Contact : un nom, un e-mail et un numéro au format international.

Ce que je mets systématiquement dans les notes :

1. Le chemin vers chaque achat intégré, comme le demande la règle 2.1(b).
2. Les fonctions non évidentes : un geste, une permission, un contenu lié à une heure.
3. L'état du compte de démo : abonné ou non, données préremplies ou vierges.
4. Les limites connues : pour un matériel ou un environnement difficile à reproduire, Apple demande d'être prêt à fournir une vidéo.

Et une règle hors formulaire : garde ton serveur allumé pendant toute la revue. Un serveur de test coupé, c'est un compte de démo qui ne marche plus, donc un refus 2.1.

La checklist 2.1 avant soumission

Celle que j'applique avant chaque envoi, construite sur mes refus :

• App installée depuis zéro sur le plus petit iPhone pris en charge, le plus grand, et un iPad en mode compatibilité
• Onboarding parcouru en entier, en échouant volontairement à chaque étape qui demande une performance
• Chaque écran obligatoire doté d'une sortie sans condition
• Aucun correctif destiné à la revue livré uniquement par mise à jour à distance
• App lancée en mode avion, puis sur un réseau IPv6 seul
• Chaque URL déclarée ouverte le jour même : confidentialité, conditions, support
• Aucun texte provisoire, écran vide ou donnée de test visible
• Compte de démo testé le jour de l'envoi, sans date d'expiration, serveur allumé
• Chaque achat intégré trouvé depuis l'app et testé en sandbox, restauration comprise
• Notes de revue qui indiquent où se trouvent les achats et les fonctions non évidentes

Si c'est ta première publication, toutes les étapes en amont sont dans publier une application sur l'App Store.

Envoyer ton dossier avec quelqu'un qui a déjà pris ces refus

Dans L'Accélérateur iOS, la semaine 4 est entièrement consacrée au dossier App Store et à l'envoi à Apple. Le programme dure 4 semaines, avec 3 lives par semaine, pour 489 € ou 3 × 163 €.

Personne ne peut garantir qu'Apple acceptera ton app. Ce que je peux faire, c'est t'aider à éviter les refus 2.1 que j'ai déjà payés d'un cycle de revue.

Questions fréquentes

Que veut dire « Guideline 2.1 - Information Needed » ?

Le reviewer n'a pas pu terminer sa revue et te pose une question : un identifiant, une explication, un moyen d'accéder à une fonction. Réponds précisément dans App Store Connect. Si la question révèle un blocage réel dans l'app, comme sur Solys, corrige-le et envoie un nouveau build.

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

Pour un plantage, un bug ou un écran bloquant, oui : le correctif doit être dans le binaire. Une mise à jour à distance ne suffit pas, car le reviewer voit le code embarqué au premier lancement. Pour une simple information manquante, une réponse peut suffire.

Mon app demande une connexion : que fournir au reviewer ?

Un compte de démonstration qui n'expire pas, renseigné dans la section App Review Information, et un serveur allumé pendant toute la revue. Un mode démo intégré peut remplacer ce compte seulement avec l'accord préalable d'Apple, et il doit montrer toutes les fonctions.

Un refus 2.1 peut-il venir d'autre chose que l'app ?

Oui. Une URL morte dans la fiche, un compte de démo expiré, un serveur coupé ou un achat intégré mal configuré suffisent. Et parfois, comme sur Clic, la cause réelle est en ligne et non dans le code : vérifie tout ce que le reviewer peut ouvrir.