Refus Google Play
Google n'interdit pas les apps construites autour d'une WebView. Il interdit les apps qui encapsulent un site web dont le développeur n'est pas propriétaire, et celles qui n'apportent rien de plus que Chrome. Si le site est le vôtre, ce refus se corrige, généralement en une seule nouvelle soumission.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Deux parties distinctes des règles Play produisent ce refus. Les règles relatives au spam couvrent les apps dont le but principal est d'afficher un site web que le développeur n'a pas le droit d'encapsuler, les apps qui n'existent que pour générer du trafic d'affiliation, les apps copiées-collées avec le même contenu sous des noms différents et les apps sans réelle fonction. Les règles sur les fonctionnalités minimales exigent qu'une app s'installe, fonctionne de manière fiable et offre une expérience de base engageante, et non une page d'attente ou une page cassée.
Les examinateurs voient passer beaucoup d'apps qui encapsulent le site de quelqu'un d'autre, si bien qu'une app WebView est contrôlée plus attentivement qu'une app native. Votre travail consiste à rendre deux choses évidentes en quelques secondes : le site web vous appartient, et l'app fait mieux que d'ouvrir l'URL dans un navigateur. Tout ce qui suit sert l'un de ces deux objectifs.
Nom du développeur, nom de l'app, domaine chargé dans la WebView, URL de la politique de confidentialité et site web validé dans votre profil de développeur renvoient tous à la même marque. Un examinateur ne devrait jamais avoir à deviner si vous avez le droit d'encapsuler ce site.
Pas d'en-tête desktop, pas de bandeau cookies, pas de pied de page avec plan du site, pas de barre « Installez notre app », pas de lien qui ouvre une deuxième copie de votre site. Une navigation en bas, des boutons pleine largeur et un premier affichage rapide derrière l'écran de démarrage.
Notifications push, écran hors ligne natif, feuille de partage du système, verrouillage biométrique, scan de QR codes ou App Links. Une ou deux vraies fonctionnalités natives, utilisées pour quelque chose qui a du sens, font changer l'app de catégorie aux yeux de l'examinateur.
Chaque élément de menu mène quelque part, les formulaires s'envoient, la connexion fonctionne avec les identifiants fournis dans Accès à l'app, et rien n'affiche « bientôt disponible » ni « lorem ipsum ».
Passez les six points en revue : la plupart des apps refusées échouent sur deux ou trois d'entre eux à la fois.
La Play Console vous permet d'associer un site web à votre compte développeur et de le valider via Google Search Console (un enregistrement DNS TXT ou un fichier HTML sur votre domaine). Utilisez le même domaine que celui que charge l'app. Un domaine de prévisualisation Lovable, Bolt ou Replit ne peut pas être validé : c'est une raison de plus pour passer d'abord à un domaine personnalisé.
Le nom de l'app, le nom du développeur, la fiche du store et le domaine doivent raconter la même histoire. « Acme Fitness » publiée par « Acme Fitness Ltd » et qui charge app.acmefitness.com, c'est clair. « Fitness Tracker Pro » publiée par « John » et qui charge un sous-domaine .lovable.app ressemble au wrapper du produit de quelqu'un d'autre.
Activez les notifications push avec PUSH_ENABLED (OneSignal) ou FIREBASE_PUSH_ENABLED, conservez l'écran de secours hors ligne avec FALLBACK_USE_LOCAL_HTML_FOLDER_IF_OFFLINE et ajoutez l'invitation à noter l'app avec SHOW_RATE_DIALOG. Utilisez ensuite au moins l'une d'elles pour un vrai besoin dans votre app web, comme le suivi des commandes ou des rappels. Voir la documentation push Android.
Utilisez l'injection de CSS et de JavaScript personnalisés pour retirer le bandeau cookies, l'en-tête desktop et les badges des stores quand la page est chargée dans WebViewGold, ou définissez un USER_AGENT personnalisé et détectez-le dans votre app web pour afficher une mise en page réservée à l'app.
Si une partie de l'app se trouve derrière une connexion, ajoutez des identifiants de démonstration qui fonctionnent sous Contenu de l'app → Accès à l'app et décrivez ce que l'examinateur va trouver. Un examinateur bloqué sur l'écran de connexion voit une app sans aucune fonctionnalité.
Incrémentez le code de version, recompilez dans Android Studio ou dans le Cloud Builder, puis déployez à nouveau. Si vous pensez que l'examinateur n'a tout simplement pas vu que le site vous appartient, faites appel avec des preuves au lieu de vous contenter de resoumettre ; le guide des recours contient un modèle pour exactement ce cas.
Mon WebView iOS est enfin approuvé. Merci !!
| Passe l'examen | Se fait signaler | |
|---|---|---|
| Propriété du site | Votre propre produit sur votre propre domaine, validé dans le profil de développeur | Un site tiers, un site d'actualités aspiré, une vitrine d'affiliation |
| Contenu | Produit, outil ou communauté avec connexion et de vrais utilisateurs | Une landing page, un blog de trois articles, un formulaire qui ne mène nulle part |
| Mise en page | Mobile first, navigation façon app, zones sûres respectées | Mise en page desktop avec zoom par pincement, bandeau cookies à chaque lancement |
| Fonctionnalités natives | Push, écran hors ligne, feuille de partage, QR, biométrie, utilisés pour quelque chose | Aucune, ou des fonctionnalités annoncées dans la fiche mais absentes de l'app |
| Fiche | Captures d'écran de la vraie app, description honnête | Captures du site web dans un navigateur, mots-clés génériques |
Oui. Les règles relatives au spam visent les apps qui encapsulent un site web sans autorisation ou sans valeur ajoutée, pas le composant WebView lui-même. Des apps qui encapsulent le propre produit du développeur avec des fonctionnalités natives sont publiées tous les jours.
Souvent, associées à une mise en page d'app et à un produit complet qui fonctionne. Les examinateurs regardent l'ensemble ; une fonction push activée mais jamais utilisée aide moins qu'une fonction qui fait visiblement partie du produit.
Un refus qui porte sur le wrapper technique lui-même est un refus non lié au contenu : il est couvert par la garantie d'approbation si vous la faites valoir dans les 14 jours suivant l'achat. Un refus parce que le site encapsulé n'est pas le vôtre ou n'a pas de vrai contenu relève du contenu et n'est pas couvert.
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.
