Les refus les plus fréquents des magasins
Presque tout refus est de la paperasse, pas du code. C'est une bonne nouvelle : l'essentiel se règle en un après-midi, et tout peut s'éviter avant l'envoi.
Ceux d'Apple
1. Un compte de test qui ne marche pas. Le relecteur doit pouvoir entrer. Si l'application a un login et que vous n'avez pas laissé d'identifiants valides dans les notes de revue, le refus est certain. Vérifiez cet accès le jour de l'envoi, pas la semaine d'avant.
2. Une confidentialité qui ne correspond pas. Ce que l'application collecte doit être ce que la fiche annonce, et la politique de confidentialité doit vivre à une adresse qui s'ouvre.
3. Impossible de supprimer le compte. Si l'application permet de créer un compte, elle doit permettre de le supprimer, depuis l'intérieur. L'un des plus faciles à éviter et des plus fréquents à recevoir.
4. "C'est un site web emballé." Une application qui n'est que votre site dans un cadre, sans rien qui justifie sa présence, est refusée. Si votre cas est du contenu et un formulaire, la voie honnête est souvent le web.
5. Un paiement en dehors. Le contenu numérique consommé dans l'application doit passer par l'achat du magasin. Les biens physiques et les services rendus dehors, non. Confondre les deux, c'est un refus et parfois un retrait.
6. Du contenu utilisateur sans garde-fous. Si les gens écrivent, publient ou discutent, l'application a besoin de filtrage, de signalement, de blocage et d'un contact. Sans les quatre, cela ne passe pas.
Ceux de Google
1. Un formulaire de sécurité des données erroné. Le champion. Ce que vous déclarez doit correspondre à ce que fait l'application, y compris ce que les bibliothèques tierces envoient dehors.
2. Des autorisations sans justification. Localisation, appareil photo, contacts : chaque autorisation demandée a besoin d'une fonction visible qui l'utilise. Une autorisation en trop est un refus.
3. Un niveau d'API cible ancien. L'exigence monte chaque année. Une application sous le minimum n'est ni publiée ni mise à jour.
4. Un test fermé non accompli. Les nouveaux comptes développeur personnels doivent passer la période de test avec des testeurs avant de publier. Ce n'est pas un refus de contenu, c'est un prérequis, et il retient le lancement.
5. Une politique de confidentialité absente. Une adresse publique qui s'ouvre, avec le vrai texte.
Que faire avant l'envoi
- connectez-vous avec le compte de test écrit dans les notes, le jour de l'envoi ;
- ouvrez la politique de confidentialité dans une fenêtre privée ;
- reprenez autorisation par autorisation : chacune a-t-elle un écran qui l'utilise ?
- confirmez que le formulaire de données dit ce que fait l'application ;
- s'il y a des comptes, trouvez le bouton de suppression du compte ;
- s'il y a du contenu utilisateur, trouvez le bouton de signalement.
Six vérifications, quinze minutes, et elles couvrent la plupart des refus de cette liste.
Le résumé
- le refus est courant et presque toujours de la paperasse, pas du code ;
- chez Apple : compte de test, confidentialité, suppression de compte, "site emballé", paiements et contenu utilisateur ;
- chez Google : formulaire de données, autorisations en trop, niveau d'API et test fermé ;
- le coût d'un refus est du calendrier, et c'est pourquoi vérifier avant paie ;
- si l'application est du contenu et un formulaire, elle n'a peut-être pas besoin du magasin.