Dans ce guide
Une construction rapide n'est pas un problème pour un relecteur. Ce qui fait renvoyer les apps, c'est ce qu'une construction rapide laisse souvent inachevé : contenu de test oublié, fonctionnalités minces, informations de confidentialité manquantes. Cette page associe ces points à la formulation officielle, pour que tu puisses les vérifier toi-même avant d'envoyer. Nous ne connaissons pas le fonctionnement interne des relecteurs et nous ne devinons pas.
L'auto-vérification, associée aux consignes
1. Texte factice et contenu temporaire
Apple, consigne 2.1 (App Completeness) : les envois "should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission" (doivent être des versions finales avec toutes les métadonnées nécessaires et des URL pleinement fonctionnelles ; le texte factice, les sites vides et les autres contenus temporaires doivent être supprimés avant l'envoi).
Vérification : cherche dans le projet « lorem », « TODO », « test », « example.com ». Ouvre chaque lien de l'app et de la fiche (URL d'assistance, URL de confidentialité, URL marketing) sur un téléphone.
2. Plantages et problèmes techniques évidents
Même consigne : "Make sure your app has been tested on-device for bugs and stability before you submit it..." (assure-toi que ton app a été testée sur appareil pour les bugs et la stabilité avant de l'envoyer...) "We will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems." (Nous rejetterons les bundles et binaires incomplets qui plantent ou présentent des problèmes techniques évidents.)
Vérification : installe le build de release, pas le build de debug, sur un vrai téléphone. Parcours le premier lancement, l'inscription, le parcours principal et un redémarrage. Voir test sur appareil réel et lire les rapports de plantage.
3. Connexion sans accès
La consigne 2.1 demande aussi de "include demo account info (and turn on your back-end service!) if your app includes a login." (inclure les informations d'un compte de démonstration, et activer ton service back-end !, si ton app comporte une connexion.)
Vérification : crée un compte de démonstration, indique ses identifiants dans les notes de revue, et confirme que ton back end tourne au moment de l'envoi.
4. Politique de confidentialité manquante
Consigne 5.1.1(i) : "All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner." (Toutes les apps doivent inclure un lien vers leur politique de confidentialité dans le champ de métadonnées d'App Store Connect et dans l'app, d'une manière facilement accessible.) La politique doit indiquer quelles données sont collectées et comment elles sont utilisées.
Vérification : le lien fonctionne, est accessible depuis l'app, et correspond à ce que l'app collecte réellement, y compris les données collectées par les bibliothèques ou services que tu as ajoutés. Pas d'avis juridique ici ; demande à un professionnel en cas de doute.
5. App trop mince
Consigne 4.2 (Minimum Functionality) : l'app "should include features, content, and UI that elevate it beyond a repackaged website." (devrait inclure des fonctionnalités, du contenu et une interface qui la placent au-delà d'un simple site web réemballé.)
Vérification : demande à quelqu'un d'autre ce que fait l'app que ne pourrait pas faire une page web. Si la réponse est maigre, ajoute la seule vraie fonctionnalité avant d'envoyer.
6. Google Play
L'aide Sécurité des données de Google indique que tous les développeurs ayant une app publiée sur Google Play doivent remplir le formulaire Sécurité des données, que les déclarations doivent correspondre au comportement réel de l'app, y compris pour les bibliothèques et SDK tiers, et qu'une politique de confidentialité est obligatoire. Si ton app permet de créer un compte, l'aide de Google sur la suppression de compte demande un chemin de suppression dans l'app et un lien web pour les demandes de suppression. Apple exige aussi la suppression de compte dans l'app (consigne 5.1.1(v)). Vérifie les pages Google actuelles avant d'envoyer.
Avant d'appuyer sur envoyer
- Build de release sur un vrai téléphone, parcours complet effectué
- Aucun contenu factice, tous les liens s'ouvrent
- Lien de politique de confidentialité dans la fiche et dans l'app
- Compte de démonstration dans les notes de revue, back end lancé
- Une réponse en une phrase à « que fait cette app ? »
Pour aller plus loin sur la vérification elle-même, voir motifs de refus de l'App Store et comment tester. Si un refus arrive malgré tout, traite-le comme un retour : lis-le, corrige le point désigné, et utilise ce modèle de prompt si tu travailles avec un assistant de code.
Où s'inscrit AppReviewX
La plupart de la liste ci-dessus se trouve plus vite par quelqu'un qui n'a pas construit l'app. AppReviewX te donne des retours privés et structurés d'autres développeurs : un retour que tu rédiges rapporte 1 crédit, les crédits achètent des retours sur ton app, et les nouveaux comptes démarrent avec 0 crédit. Pour Android, il existe des groupes de test pour l'exigence Google Play de 12 testeurs pendant 14 jours d'affilée.
Voir aussi : hub vibe coding, boucle de retour avec ton assistant de code.
Les règles changent ; vérifie les consignes liées. Ce n'est pas un avis juridique.