Aller au contenu
WebViewGold Du vibe coding à l'App Store
Français
Obtenir WebViewGold

ChatGPT & Codex

Refusée ? Collez le message dans Codex et corrigez le jour même

Un refus est une liste de tâches rédigée par un examinateur. Apple nomme la guideline, Google nomme la règle, et tous deux décrivent ce qu'ils ont vu. Codex sait très bien transformer cela en changements de code, à condition de lui dire quels correctifs relèvent de l'app web et lesquels relèvent du projet WebViewGold. Voici la routine de triage que nous utilisons au support.

Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.

  • Garantie d'approbation – ou remboursement sous 14 jours
  • Aucun codage requis
  • Paiement unique, mises à jour gratuites
  • Support humain 24/7
  • Conçu en Allemagne depuis 2014 · ISO 27001

La routine de triage

La plupart des refus listent deux ou trois points. Traitez chacun séparément.

  1. Lisez et classez chaque point

    Chaque point appartient à l'une de quatre catégories : WEB (votre code), NATIVE (configuration WebViewGold ou fonctionnalité native), METADATA (fiche, captures d'écran, réponses sur la confidentialité, notes pour l'examen) ou CONTENT (le sujet même de l'app). Codex peut corriger la première, vous guider pour la deuxième et la troisième, et vous seul pouvez trancher la quatrième.

  2. Collez le refus dans Codex

    Utilisez le prompt de triage ci-dessous dans le dépôt. Incluez le message complet et toutes les captures d'écran jointes par l'examinateur (décrivez-les si vous ne pouvez pas joindre d'images). Codex associe chaque point à des fichiers et des routes, et implémente les correctifs web.

  3. Testez sur un build installé sur un appareil

    Un correctif web est en ligne dès que vous déployez, mais vérifiez-le dans le vrai build de l'app avec les yeux de l'examinateur : mode avion, compte de démo, chaque onglet. TestFlight et le canal de test interne de Google existent pour ça.

  4. Appliquez les correctifs natifs et de métadonnées

    Activez ou configurez la fonctionnalité WebViewGold (fournisseur de push, écran hors ligne, capability Sign in with Apple, clés RevenueCat), recompilez, envoyez. Corrigez dans la console les captures d'écran, la description, les réponses App Privacy ou le formulaire Data safety.

  5. Répondez et resoumettez

    Répondez dans le Resolution Center (Apple), ou faites appel / resoumettez dans la Play Console, avec une liste factuelle des changements, puis soumettez le nouveau build. Les examens suivants sont généralement plus rapides que le premier.

Le prompt de triage

À coller dans Codex avec le texte du refus
Voici ci-dessous un message de refus de l'App Review (ou de Google Play) concernant la version app native de cette app web. L'app native est un wrapper WebViewGold qui charge notre URL de production ; le wrapper gère nativement les notifications push, l'écran hors ligne, les helpers de connexion sociale et les achats intégrés, et tout le reste se trouve dans ce code. Pour chaque point du refus : 1) citez la guideline ou la règle ; 2) dites ce que l'examinateur a le plus probablement vu dans notre app, avec les fichiers et routes concernés ; 3) classez le correctif en WEB (ce dépôt), NATIVE (configuration du wrapper) ou METADATA (fiche du store) ; 4) implémentez dès maintenant les correctifs WEB ; 5) pour les correctifs NATIVE et METADATA, rédigez-moi des instructions précises. Terminez par un brouillon de réponse à l'examinateur qui indique ce qui a changé, dans un langage simple et factuel, sans excuses et sans argumenter.

Message de refus :
[COLLEZ ICI]

Correspondance guideline → correctif

GuidelineCe que l'examinateur a vuCorrectifOù
Apple 4.2 Fonctionnalité minimaleUn site web dans un cadre : mise en page desktop, aucun comportement natifNotifications push, écran hors ligne, feuille de partage ou Face ID ; masquer l'interface propre au site web ; décrire les fonctionnalités natives dans les notes pour l'examenNATIVE + WEB + METADATA
Apple 2.1 ComplétudeÉcran blanc, connexion cassée, texte provisoire, liens mortsÉtats d'erreur, compte de démo fonctionnel, suppression des textes provisoires, HTTPS partoutWEB + METADATA
Apple 5.1.1 Collecte de donnéesPas d'URL de confidentialité ou pas de suppression de compteRoute /privacy, Supprimer le compte dans les réglages avec suppression côté serveurWEB + METADATA
Apple 4.8 Services de connexionConnexion Google sans Sign in with AppleAjouter le fournisseur et le bouton Apple ; WebViewGold gère le fluxWEB
Apple 3.1.1 Achat intégréCheckout Stripe pour un abonnement ou des crédits dans l'appFaire passer les biens numériques par revenuecat://purchase?… dans l'app native ; garder Stripe sur le webWEB + NATIVE
Apple 2.3 Métadonnées exactesCaptures d'écran du site web, « bêta », fonctionnalités inexistantesCaptures de l'app compilée, description honnêteMETADATA
Apple 2.5.1 / autorisations inutiliséesTextes d'usage de la caméra ou de la localisation pour des fonctionnalités que l'app n'a pasSupprimer les textes de permission inutilisés dans le projet WebViewGoldNATIVE
Apple 4.0 DesignContenu sous l'encoche ou l'indicateur d'accueil, boutons minusculesSafe-area insets, zones tactiles de 44 pxWEB
Apple 1.2 / Google UGC et contenu IAChat ou communauté sans signalement ni blocageAction de signalement, option de blocage, modération, contact dans la politiqueWEB
Incohérence Data safety (Google)Le formulaire indique qu'aucune donnée n'est collectée, l'app envoie des analytics ou des tokens pushCorriger le formulaire pour qu'il corresponde au codeMETADATA

WebViewGold nous a permis d'avoir le temps de mise sur le marché le plus court et le plus efficace jamais possible parmi toutes les autres plates-formes d'application que nous avons essayées au cours des 5 dernières années. Je ne sais pas pourquoi je ne vous ai pas découvert plus tôt, mais je suis vraiment, vraiment content de l'avoir fait. Nous approchons actuellement les 6000 téléchargements d'application sur l'App Store iOS et Google Play Store sans aucun problème!

Antonio Davila · CodeCanyon

Correctif web ou correctif natif ?

Correctifs web (Codex s'en charge)

Mise en page, pages légales, suppression de compte, états d'erreur, bouton Sign in with Apple, achats routés via le pont JavaScript, boutons de signalement. En ligne au prochain déploiement, sans nouveau build, sauf si l'examinateur veut voir un nouveau numéro de version.

Correctifs natifs (configuration WebViewGold)

Activer le push, l'écran hors ligne, les clés RevenueCat, les déclencheurs du Social Login Helper, les textes de permission, l'icône et le nom. Modifiez la valeur, recompilez, envoyez. Le Cloud Builder recompile dans le navigateur.

Correctifs de métadonnées (console)

Captures d'écran, description, mots-clés, URL de confidentialité, réponses App Privacy et Data safety, notes pour l'examen, compte de démo. Aucun build nécessaire ; modifiez et resoumettez le même binaire si rien d'autre n'a changé.

Décisions de contenu (vous)

Jeux d'argent, allégations médicales, contenus protégés par le droit d'auteur, usurpation d'identité. Codex ne peut pas contourner ces points par le code. Décidez s'il faut changer le produit ou son périmètre avant de resoumettre.

Rédiger la réponse dans le Resolution Center

Tenez-vous-en à ce qui a changé et à l'endroit où l'examinateur peut le voir. Une réponse efficace ressemble à ceci : « Merci pour votre examen. Nous avons traité les points comme suit. Guideline 4.2 : l'app envoie désormais des notifications push pour le suivi des commandes (OneSignal), affiche un écran hors ligne natif et propose la connexion Face ID pour l'espace compte ; les éléments du site web comme le pied de page et le bandeau cookies sont masqués dans l'app. Guideline 5.1.1 : la suppression de compte est disponible sous Réglages → Compte → Supprimer le compte et efface toutes les données de l'utilisateur. Le compte de démo reste [email protected] / Demo1234. Le build 1.0.1 (3) contient ces changements. » Rien d'autre : pas d'explication de votre modèle économique, pas de mention d'autres apps qui sont passées.

Si vous pensez que l'examinateur a manqué quelque chose (par exemple une fonctionnalité derrière la connexion qu'il n'a pas utilisée), dites où elle se trouve et joignez une capture d'écran. La politesse et la précision l'emportent sur la quantité. Une version réutilisable se trouve dans le modèle de réponse Resolution Center ; l'équivalent Google est le modèle d'appel Play Console.

Avant de resoumettre

  • Chaque point du refus a un changement correspondant que vous pouvez montrer dans l'app.
  • Le numéro de build est supérieur à celui du build refusé, et la version citée dans la réponse correspond.
  • Le compte de démo fonctionne toujours, et les notes pour l'examen mentionnent chaque fonctionnalité native ajoutée.
  • Pour un refus de l'app WebViewGold non lié au contenu, la garantie d'approbation App Store & Google Play – ou remboursement sous 14 jours – s'applique ; notre chat 24/7 vous aide aussi à formuler la réponse.

Questions fréquentes

Codex a-t-il besoin de tout le dépôt pour ça ?

Oui, car les correctifs touchent des routes, des écrans de réglages et des fonctions serveur. Lancez-le dans le dépôt (CLI ou IDE) ou comme tâche cloud sur le dépôt GitHub plutôt que de coller des extraits dans ChatGPT.

J'ai déjà des notifications push et j'ai quand même reçu un refus 4.2. Que faire ?

Vérifiez que l'examinateur a pu les voir : la demande d'autorisation doit apparaître pendant sa session, et les notes pour l'examen doivent préciser à quoi servent les notifications. Ajoutez une deuxième fonctionnalité native visible (écran hors ligne, feuille de partage, Face ID) et masquez les éléments propres au site web dans l'app.

Où répondre sur Google Play ?

Les refus liés aux règles apparaissent dans la Play Console sous État des règles, avec une option d'appel ; pour la plupart des problèmes, il suffit d'envoyer une version corrigée. Utilisez le message de la console pour décrire ce qui a changé.

Combien de fois puis-je resoumettre ?

Autant de fois que nécessaire ; chaque soumission est réexaminée. Si vous avez été refusé trois fois pour la même guideline, lisez le guide dédié sur la marche à suivre avant de soumettre à nouveau.

Trois façons de mettre votre app dans les stores

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.

Faites-le vous-même

$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

Full Service

$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 WeSetupYourWebViewApp

Prix Soldes d'hiver valables jusqu'au 31 décembre 2026.

Prêt à publier votre app ?

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.