Claude Code
Un message de refus d'App Review ou de Google Play est un texte structuré : un numéro de guideline, une description, parfois une capture d'écran. C'est exactement le type d'entrée qu'un agent traite bien. Voici comment le trier avec Claude Code, décider si la correction se trouve dans votre web app ou dans le projet WebViewGold, et rédiger la réponse qui vous fera approuver.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Apple cite la guideline (par exemple « Guideline 4.2 - Design - Minimum Functionality ») et décrit ce que le reviewer a vu ; Google cite la règle (« Minimum Functionality », « User Data », « Broken Functionality ») et joint souvent une capture d'écran ou un modèle d'appareil et une version d'OS. Copiez le texte complet, y compris la description de la capture. Ouvrez ensuite Claude Code dans votre projet et collez-le avec le prompt de tri ci-dessous. L'agent ne voit pas la capture d'écran : décrivez ce qu'elle montre en une phrase.
Ne commencez pas par contester l'avis du reviewer. La plupart des refus d'apps basées sur le web sont justifiés et se corrigent en une heure ; la vue d'ensemble des motifs de refus les classe par fréquence.
Voici un message de refus de l'App Store Review (ou de Google Play). Notre app est une web app qui tourne dans le wrapper natif WebViewGold ; le code web se trouve dans ce dépôt, les projets natifs sont des projets Xcode et Android Studio séparés que je configure à la main. Triez-le : 1. Citez chaque numéro de guideline ou de règle mentionné et expliquez en deux phrases ce que demande le reviewer et pourquoi cette règle existe. 2. Pour chaque point, déterminez si la correction relève (a) de ce code web, (b) d'un réglage WebViewGold ou d'un fichier du projet natif (Config.swift, Config.java, Info.plist, AndroidManifest.xml), ou (c) des métadonnées du store (fiche, captures d'écran, notes pour la validation, réponses sur la confidentialité). Dites lequel et pourquoi. 3. Pour (a), trouvez le code concerné, proposez la plus petite modification qui règle le point et implémentez-la sur une branche, avec un commit par point. 4. Pour (b) et (c), rédigez des instructions précises à mon intention : fichier, nom du réglage, valeur, et ce qu'il faut vérifier ensuite. 5. Si un point ressemble à un malentendu du reviewer, dites-le et indiquez-moi quelles preuves (captures d'écran, compte de démonstration, notes pour la validation) permettraient de le lever. 6. Terminez par une checklist que je peux vérifier sur un vrai appareil avant de soumettre à nouveau. Texte du refus : [collez ici]
L'app se comporte comme le site web. Web : masquez dans l'app les éléments réservés au site web, ajoutez une navigation façon app. Natif : activez le push, l'écran hors ligne et une fonctionnalité de plus, comme la biométrie ou la feuille de partage. Décrivez les fonctionnalités natives dans les notes pour la validation.
Écran blanc, plantage, lien mort, ou le reviewer n'a pas pu se connecter. Web : corrigez l'état d'erreur, retirez les contenus provisoires. Natif : splash screen et indicateur de chargement, contenu exclusivement en HTTPS. Métadonnées : compte de démonstration fonctionnel dans les notes pour la validation.
Pas de lien vers la politique de confidentialité, ou inscription sans suppression de compte. Web : page /privacy et action Supprimer le compte qui fonctionne. Métadonnées : URL de la politique de confidentialité dans App Store Connect et dans la Play Console.
Connexion Google ou Facebook proposée sans Sign in with Apple. Web : ajoutez le fournisseur Apple. Natif : le Social Login Helper de WebViewGold gère la fenêtre de connexion Google, Apple est détecté automatiquement.
Biens numériques vendus via Stripe dans l'app. Web : faites passer les achats par revenuecat:// en natif, masquez les prix web. Natif : clés RevenueCat dans Config.swift et Config.java.
Captures d'écran du site web, mentions d'autres plateformes, fonctionnalités promises qui n'existent pas. Métadonnées : captures de la vraie app, description honnête.
Textes d'autorisation pour des fonctionnalités que l'app n'utilise jamais. Natif : supprimez les descriptions d'utilisation inutiles dans Info.plist et les autorisations inutiles dans AndroidManifest.xml.
Contenu sous l'encoche, zones tactiles minuscules, défilement horizontal. Web : padding safe-area, zones tactiles de 44 px, tests à 320 px.
Mon WebView iOS est enfin approuvé. Merci !!
| Symptôme dans le refus | Correction dans la web app (Claude Code) | Correction dans WebViewGold |
|---|---|---|
| « Simple site web » / wrapper trop léger | Masquer l'en-tête et le pied de page marketing dans l'app, navigation façon app | Activer le push, l'écran hors ligne, le pull-to-refresh, le partage natif ; les mentionner dans les notes pour la validation |
| Écran blanc au lancement | Corriger les erreurs non interceptées, ajouter des états de chargement et d'erreur | Splash screen avec remainSplashOption, vérifier l'URL dans webviewurl / HOME_URL |
| La connexion Google échoue (disallowed_useragent) | Rien, le fournisseur bloque les WebViews intégrées | Déclencheurs du Social Login Helper dans Config.swift et Config.java |
| Hors ligne, une page blanche s'affiche | Gérer les échecs de fetch | L'écran hors ligne natif est activé par défaut ; ajoutez un dossier local de secours si nécessaire |
Les reviewers lisent les réponses courtes et factuelles. L'agent sait ce qui a changé, puisque c'est lui qui a fait les modifications.
Rédigez une réponse pour le Resolution Center d'App Store Connect (ou le formulaire de recours de Google Play) au refus que j'ai collé plus tôt. Basez-vous uniquement sur les modifications que nous avons réellement faites dans ce dépôt depuis le refus, plus les réglages natifs que j'ai confirmés : [listez-les, par ex. notifications push via OneSignal activées, écran hors ligne activé]. Structure : une phrase pour remercier le reviewer, puis un point numéroté par motif de refus indiquant ce qui a changé et où le reviewer peut le voir (nom de la route ou de l'écran), puis le compte de démonstration et une phrase indiquant qu'un nouveau build en version X a été soumis. Ton : factuel, poli, sans excuses, sans mention d'outils d'IA ni du nom du produit wrapper. 200 mots maximum. Donnez-moi aussi une version en un paragraphe pour le champ Review Notes.
Les modifications web sont en ligne dans l'app dès que vous déployez. Vérifiez-les dans le vrai build de l'app sur un appareil, pas dans Safari.
Si quelque chose a changé dans Config.swift, Config.java, Info.plist ou le manifest, compilez une nouvelle version (augmentez le numéro de build) dans Xcode, Android Studio ou le Cloud Builder.
Corrigez les captures d'écran, les réponses sur la confidentialité et les notes pour la validation dans la console. Ajoutez le compte de démonstration si le reviewer n'a pas pu se connecter.
Publiez la réponse dans le Resolution Center, joignez des captures d'écran si un point relevait d'un malentendu, soumettez le nouveau build. Les validations suivantes sont souvent plus rapides que la première.
Collez le nouveau message dans la même session Claude Code ; elle a encore le contexte. Après le troisième tour, lisez que faire après trois refus et contactez le support.
Inutile de le cacher, mais mettez en avant ce que l'app apporte à l'utilisateur et ses fonctionnalités natives. Les reviewers évaluent l'expérience, pas l'architecture.
Il peut corriger la partie web : mise en page façon app et éléments du site web masqués. La partie native (push, écran hors ligne, biométrie) se résume à quelques réglages dans les projets WebViewGold, que vous ou l'agent activez, plus une phrase dans les notes pour la validation.
Apple répond généralement sous 24 à 48 heures. Google prend quelques jours, jusqu'à une semaine pour les nouveaux comptes. Répondre dans le Resolution Center avant de soumettre à nouveau peut accélérer les choses côté Apple.
Les refus liés au contenu (jeux d'argent, allégations médicales, contenu protégé par le droit d'auteur, affirmations trompeuses) concernent ce que propose l'app, pas la façon dont elle est construite. L'agent peut vous aider à reformuler ou à retirer le contenu, mais la décision vous appartient.
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.
