Refus Google Play
Google a refusé la version parce que son examinateur n'a pas pu dépasser votre écran de connexion. Rien n'est cassé dans l'app ; l'examinateur n'avait simplement aucun moyen d'entrer. Ajoutez un compte de test réutilisable dans la Play Console sous Identifiants de connexion (Sign-in details, la section que les anciens guides appellent App access), assurez-vous qu'il évite les codes à usage unique et les liens envoyés par e-mail, puis soumettez à nouveau.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Les examinateurs de Google doivent voir tout ce que fait votre app. Si une partie est réservée par une connexion, un abonnement, un lieu ou une autre forme d'authentification, vous devez leur fournir tout ce qu'il faut pour entrer : des identifiants de test, un compte de démonstration ou des instructions pour les codes et autres cas particuliers. Vous saisissez ces informations dans la Play Console sous Règles et programmes → Contenu de l'application → Identifiants de connexion (Sign-in details). Les anciens guides, les forums et certaines notifications appellent encore cette section App access ou Accès aux applications ; c'est la même chose. Vous pouvez enregistrer jusqu'à cinq ensembles d'instructions, chacun avec les informations de connexion et un champ Autres instructions pour tout ce que votre connexion a d'inhabituel.
Les exigences de Google concernant les identifiants de connexion sont courtes et strictes. Les identifiants doivent être accessibles en permanence, réutilisables, valables depuis n'importe quel pays, maintenus en état de marche et en anglais (ou accompagnés d'une version anglaise). Si votre connexion demande normalement un mot de passe à usage unique ou un second facteur, vous devez fournir des identifiants qui contournent cette étape. Une connexion par QR code nécessite à la place une URL statique, et un contenu derrière un paywall nécessite des instructions qui permettent à l'examinateur d'utiliser librement la partie payante. Un mot de passe qui expire pendant l'examen peut faire refuser l'app.
L'entrée dans État des règles porte le plus souvent un titre du type Need login credentials for app review. Elle explique que l'examinateur n'a pas pu accéder à tout ou partie de l'app et demande un compte de démonstration actif ainsi que toute autre ressource nécessaire à l'examen, par exemple des codes. La capture d'écran jointe montre en général votre écran de connexion, une page de confirmation d'e-mail ou un message « vérifiez votre boîte de réception ».
La même cause se cache aussi derrière d'autres refus. Un examinateur bloqué à la connexion peut classer l'app dans les fonctionnalités minimales, puisqu'un formulaire de connexion est tout ce qu'il a vu (le guide sur les fonctionnalités minimales couvre le reste de ce refus). Une déclaration pour la localisation en arrière-plan, la suppression de compte ou une autre fonctionnalité peut être refusée parce que l'examinateur n'a pas pu vérifier la fonctionnalité située derrière la connexion. Avant de réécrire quoi que ce soit d'autre, vérifiez que l'examinateur est vraiment entré.
Les builders IA génèrent par défaut une authentification moderne sans mot de passe. Excellente pour les utilisateurs, elle mène à une impasse pour un examinateur sur un appareil de test tout neuf.
Les liens de connexion par e-mail sans mot de passe sont un réglage par défaut courant dans les apps basées sur Supabase et dans de nombreux kits d'authentification. L'examinateur n'a pas accès à la boîte de réception de votre compte de test, et sur un téléphone le lien s'ouvre de toute façon dans le navigateur ou l'app de messagerie au lieu de votre WebView, comme l'explique le guide sur les magic links.
Un code à six chiffres envoyé par e-mail ou SMS à une adresse que vous seul contrôlez arrête net l'examen. Google demande des identifiants réutilisables qui sautent l'étape du code.
Dans une WebView, Google refuse sa propre page de connexion tant que l'assistant de connexion de WebViewGold n'est pas configuré (GOOGLE_LOGIN_HELPER_TRIGGERS, voir le correctif disallowed_useragent). Même quand elle fonctionne, un examinateur n'utilisera pas un compte Google personnel. Proposez aussi l'e-mail et le mot de passe.
Listes d'attente, codes d'invitation et parcours du type « un administrateur va valider votre compte » : une nouvelle inscription n'atteint jamais le produit. Validez à l'avance le compte d'examen.
Blocages par pays, règles de pare-feu strictes, défis anti-bots agressifs ou limites de débit sur la route de connexion peuvent bloquer l'appareil d'un examinateur. Google attend des identifiants qui fonctionnent quel que soit le lieu.
L'expiration d'un essai, les tâches de nettoyage des utilisateurs inactifs et votre propre parcours de suppression de compte (qu'un examinateur peut tester) peuvent supprimer le compte entre deux examens.
Mon WebView iOS est enfin approuvé. Merci !!
Environ trente minutes une seule fois ; il fonctionne ensuite pour chaque mise à jour.
Utilisez une adresse comme [email protected] qui n'existe que pour les examens des stores. Ne donnez jamais votre propre identifiant ni celui d'un vrai client : Google demande des identifiants créés pour les tests. Marquez l'e-mail comme confirmé dans le tableau de bord de votre fournisseur d'authentification, pour qu'aucun e-mail de confirmation ne soit nécessaire.
Si votre app connecte les utilisateurs uniquement par magic link ou code à usage unique, ajoutez une option classique e-mail et mot de passe que tout utilisateur peut choisir, par exemple un lien « Utiliser plutôt un mot de passe » sous le champ e-mail (le prompt ci-dessous s'en charge pour vous). La connexion par téléphone peut souvent utiliser un numéro de test fixe : Firebase Authentication, par exemple, permet d'enregistrer des numéros de test avec un code de vérification fixe. Écrivez les étapes exactes dans les instructions.
Ajoutez du contenu d'exemple réaliste pour que chaque écran montre son utilité, et accordez le droit payant sur votre serveur pour que les écrans premium soient examinables sans achat. Si votre app a des rôles (client et prestataire, membre et administrateur), créez un compte par rôle et utilisez un ensemble d'instructions pour chacun.
Excluez le compte des scripts de nettoyage et de l'expiration des essais. Après chaque examen, connectez-vous une fois pour vérifier qu'il existe toujours ; un examinateur qui teste votre parcours de suppression de compte a pu l'utiliser. Un petit script qui recrée le compte avec ses données d'exemple vous épargne un refus.
Autorisez la route de connexion depuis tous les pays et assurez-vous que la protection anti-bots ne met pas au défi un appareil Android tout neuf lors de son premier lancement. Si votre service ne fonctionne que dans un pays, gardez au moins le compte d'examen accessible dans le monde entier et indiquez-le dans les instructions.
Ouvrez Règles et programmes → Contenu de l'application → Identifiants de connexion (Sign-in details), choisissez Commencer ou Gérer, puis Ajouter de nouvelles instructions. Collez les identifiants exactement tels qu'ils se tapent sur l'écran de connexion et utilisez Autres instructions pour tout ce qui est inhabituel : quel bouton toucher, comment l'étape du code est évitée, quel rôle a le compte et où se trouvent les fonctionnalités principales.
Désinstallez l'app, installez le build depuis le canal de tests internes et connectez-vous en collant les identifiants depuis la Play Console. Si CLEAR_CACHE_ON_STARTUP vaut true dans Config.java, l'app efface les cookies à chaque démarrage, et l'examinateur doit donc se reconnecter après chaque lancement ; mentionnez-le. Si le verrouillage de l'app (enableBioMetricAuth) est activé, mentionnez-le aussi et essayez un appareil sans empreinte enregistrée pour savoir ce que verra l'examinateur. Les deux options sont décrites dans la référence Config.java pour Android.
Si seuls les identifiants de connexion ont changé, enregistrez-les et envoyez la mise à jour pour examen ; la Play Console liste les modifications en attente dans la Vue d'ensemble de la publication. Si vous avez modifié l'app, par exemple pour ajouter l'option mot de passe, importez une nouvelle version avec un code de version plus élevé. Une réponse d'une ligne dans État des règles qui renvoie vers les nouvelles instructions aide.
Anglais simple, étapes numérotées, pas de marketing. L'examinateur lit ce texte pendant que l'app est ouverte sur un appareil de test. Le modèle reste en anglais, car les examinateurs de Google lisent l'anglais.
Login method: email and password. On the start screen tap [Log in], then [Use a password instead] below the email field. This account is pre-confirmed and needs no one-time code or email link. It works from any country. Role: [customer]. A second instruction set contains the [provider / admin] account. The account has the [Pro] plan unlocked on our server, so all paid features are visible without a purchase. Where to find the main features: 1. [Bookings tab]: create and cancel a booking. 2. [Profile > Notifications]: turn on reminders; a test notification arrives within [2] minutes. 3. [Profile > Settings > Delete account]: account deletion. Please use the second test account for this, so the main account stays available for future reviews. The app asks for [location] only on the [Store finder] screen, after an in-app explanation. [Only if enabled:] The app is protected by an app lock on launch; [describe what appears on a device without fingerprint or face unlock]. Contact during review: [email address].
Conserve votre parcours par magic link ou par code et ajoute une connexion classique par mot de passe que tout utilisateur peut utiliser. C'est ce dont l'examinateur a besoin, et ce n'est pas une porte dérobée cachée.
Mon app connecte actuellement les utilisateurs avec des [magic links / codes à usage unique par e-mail] via [Supabase Auth / Firebase Auth / Clerk]. Ajoute une connexion standard par e-mail et mot de passe à côté de la méthode existante, sans la supprimer : - Sur l'écran de connexion, ajoute un lien bien visible « Utiliser plutôt un mot de passe » qui bascule le formulaire en e-mail + mot de passe. - Ajoute « Définir un mot de passe » dans les réglages du compte, pour que les utilisateurs existants puissent en créer un. - Utilise la connexion par mot de passe intégrée du fournisseur d'authentification. Ne construis aucun contournement personnalisé, secret ou caché. - Affiche une erreur claire en cas de mauvais mot de passe et inclus un parcours « Mot de passe oublié ». - Garde la session persistante entre les redémarrages de l'app ; l'app tourne dans une WebView Android. - Ne change rien d'autre. À la fin, liste les fichiers que tu as modifiés et explique comment créer un utilisateur de test pré-confirmé avec un mot de passe dans le tableau de bord de [fournisseur].
Seulement si l'inscription fonctionne instantanément, sans confirmation par e-mail, sans code ni validation, et même dans ce cas Google attend des identifiants quand une connexion est requise. Fournir un compte prêt à l'emploi est plus rapide et évite un second refus.
Non, si c'est une option normale et visible que chaque utilisateur peut utiliser. Ce que vous devez éviter, c'est un code ou une route secrète qui active un comportement différent pour les examinateurs ; cela relève des règles sur le comportement trompeur.
La solution robuste consiste à ajouter l'e-mail et le mot de passe. Un compte Google dédié à l'examen se heurte souvent à des étapes de vérification supplémentaires lorsqu'il se connecte sur un nouvel appareil, et la connexion Google dans une WebView a besoin de l'assistant de connexion de WebViewGold pour fonctionner tout court.
Seulement quand quelque chose change, mais chaque mise à jour est examinée avec les informations enregistrées. Gardez le compte valide en permanence et mettez à jour les instructions chaque fois que vous ajoutez un rôle, un paywall ou une nouvelle fonctionnalité principale.
Seulement si vous lui donnez un vrai compte, ce que vous ne devez pas faire. Google demande des identifiants créés pour les tests. Utilisez des données d'exemple qui montrent à quoi sert chaque écran.
Même résultat, charge de travail différente de votre côté. Les trois formules incluent la garantie d'approbation et le support humain 24/7.
$109 par plateforme, paiement unique
La licence WebViewGold : un projet Xcode ou Android Studio prêt à l'emploi. Collez votre URL, définissez le nom et l'icône, activez les fonctionnalités, compilez et soumettez. Mises à jour gratuites à vie.
Voir les offres sur la page principale$349 par licence, extension en paiement unique
Ni Mac, ni Xcode, ni Android Studio : configurez dans le navigateur, nous compilons les deux apps dans le cloud et les transmettons à App Store Connect et à la Play Console.
Comment fonctionne le Cloud Builder Essayer la démo gratuite$698 par plateforme $798
Envoyez-nous votre URL et votre icône. Notre équipe configure, compile et livre votre app sous 72 heures, en marque blanche, projets sources inclus. Les deux plateformes pour $1,158.
Détails du Full Service Propulsé par
Prix Soldes d'hiver valables jusqu'au 31 décembre 2026.
Garantie d'approbation App Store & Google Play – ou remboursement sous 14 jours
Vous préférez déléguer ? Full Service : nous configurons, compilons et livrons sous 72 heures, dès $698 par plateforme. Des questions ? Chattez avec nous 24/7.
Les remboursements sont accordés aux conditions indiquées dans notre FAQ : un refus non lié au contenu par Apple et/ou Google, demandé dans les 14 jours suivant l'achat.
