ChatGPT & Codex
Avec une app WebViewGold, chaque merge sur main est une mise en production : l'app native charge votre URL de production, si bien qu'un mauvais déploiement atteint les utilisateurs de l'App Store et de Google Play en quelques minutes. Codex peut relire chaque pull request sur GitHub avant son merge. Apprenez-lui vos règles des stores dans AGENTS.md, et il signalera les problèmes qui provoquent des refus et des fuites, pas seulement les bugs.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Dans une app entièrement native, le code n'atteint les utilisateurs qu'après le build, la soumission et l'approbation. Une app WebViewGold charge votre URL de production : un merge sur main est donc en ligne dans la version du store dès son déploiement. C'est le grand avantage de l'approche (pas de nouvelle soumission pour les modifications web, voir mises à jour web ou natives), et c'est aussi la raison pour laquelle une pull request négligente peut casser l'app sur tous les téléphones, ou placer un checkout Stripe pour des crédits sous les yeux des utilisateurs iOS entre deux examens. Apple et Google regardent de nouveau à chaque mise à jour native que vous soumettez, et une règle enfreinte entre-temps refait alors surface.
La revue de code Codex comble cet écart. Une fois le dépôt connecté à Codex, il relit les pull requests sur GitHub automatiquement ou quand quelqu'un commente @codex review, et publie une revue GitHub normale avec des constats sur des lignes précises. Deux détails déterminent la configuration : sur GitHub, il ne remonte que les constats de haute priorité (P0 et P1), et il lit les règles de revue dans une section ## Code Review Rules de vos fichiers AGENTS.md, en appliquant le fichier racine plus le fichier imbriqué le plus spécifique pour chaque chemin modifié. Les règles des stores doivent donc être écrites noir sur blanc, et marquées comme P1.
Dans Codex, connectez GitHub et accordez au connecteur Codex l'accès au dépôt. Les revues sur GitHub n'ont pas besoin d'un environnement cloud ; Codex lit lui-même la pull request.
Ouvrez les réglages de revue de code dans Codex, choisissez le dépôt et activez la revue automatique. La configuration nécessite les droits push ou admin sur le dépôt GitHub. Sans revues automatiques, un commentaire @codex review sur une pull request en demande une.
Ajoutez la section ## Code Review Rules ci-dessous à l'AGENTS.md racine (ou à l'AGENTS.md issu de notre modèle). Commencez court : OpenAI recommande quelques règles concises et de laisser la mise en forme et le lint à la CI. Des fichiers AGENTS.md imbriqués peuvent ajouter des règles par dossier, par exemple des règles plus strictes pour vos fonctions serveur.
Exigez des pull requests et des vérifications réussies pour la branche main dans les réglages du dépôt GitHub. Codex commente ; il ne bloque pas les merges. C'est la protection de branche qui s'en charge.
Ouvrez une pull request jetable qui enfreint volontairement une règle, par exemple un lien de paiement Stripe affiché quand isNativeApp() est true. Si Codex ne le signale pas, rendez la règle plus concrète et réessayez, puis fermez la pull request sans la merger.
À coller dans AGENTS.md, en adaptant les noms à votre code. La ligne « Treat as P1 » est essentielle : les revues GitHub n'affichent que les constats P0 et P1, et sans elle une règle des stores risque d'être jugée mineure et de ne jamais apparaître.
## Code Review Rules
These rules protect the App Store and Google Play releases of our WebViewGold
apps, which load this web app in a native WebView. Treat every violation below
as P1.
### Secrets
- No API keys, service-role keys, private keys or tokens in client code, in
public env variables (NEXT_PUBLIC_*, VITE_*) or in committed .env files.
- Server-only keys (database service role, OpenAI, Stripe secret) are read in
server code only.
### Store rules
- Digital goods, subscriptions and credits: when isNativeApp() is true, buy
buttons use the in-app purchase path (revenuecat://purchase?...). No Stripe
checkout, card form or external payment link for digital goods in the app.
- Account deletion (settings screen and /delete-account) keeps working and
deletes server-side.
- A new Google, Facebook or other third-party login requires Sign in with
Apple with equal prominence.
- /privacy and /terms stay reachable from settings and the footer.
- No placeholder text, lorem ipsum, "coming soon" screens or dead links in
routes reachable from the app.
- No "Download our app" banners or App Store / Google Play links when
isNativeApp() is true.
### Mobile layout inside the WebView
- Fixed headers, footers and bottom sheets pad with env(safe-area-inset-*).
- Tap targets 44x44px or larger; inputs use font-size 16px or more.
- No hover-only controls; no horizontal scrolling at 320px width.
- Login and payment flows do not depend on window.open popups.
### WebViewGold bridge
- Bridge calls run only behind isNativeApp() and keep a web fallback.
- Only URL schemes documented in https://www.webviewgold.com/llms-full.txt.
Flag any scheme that is not in that file.
Je suis très content d'avoir acheté cette application ! Extrêmement facile et excellente documentation. J'ai été en contact avec le service client, ils ont répondu très rapidement et très amicalement. Ils ont résolu ma question en un jour. 10/10 recommanderaient.
| Règle | Pourquoi c'est important | Un constat P1 typique |
|---|---|---|
| Aucun secret dans le code client | Tout ce qui se trouve dans le bundle est lisible par quiconque ouvre l'app ou le site ; une clé service role de base de données ou une clé OpenAI signifie une fuite de données ou une facture salée | VITE_OPENAI_API_KEY utilisée directement dans un composant React |
| Biens numériques via l'achat intégré | Guideline 3.1.1 d'Apple et politique de paiement de Google Play (avec des exceptions régionales) ; le refus le plus courant pour les apps d'IA et SaaS, voir la guideline 3.1.1 | Un bouton de pack de crédits ouvre Stripe Checkout sans branche isNativeApp() |
| La suppression de compte continue de fonctionner | La 5.1.1(v) d'Apple et Google Play exigent une suppression dans l'app pour les apps avec inscription | Un refactoring a supprimé l'appel à la fonction de suppression côté serveur |
| Parité avec Sign in with Apple | La 4.8 d'Apple s'applique dès qu'une connexion tierce existe | Un nouveau bouton « Continuer avec Google » sans option Apple |
| Safe areas, zones de 44 px, champs de 16 px | Refus de design au titre de la 4.0 d'Apple ; iOS zoome sur les champs de moins de 16 px, voir safe areas et zones tactiles | Une nouvelle navigation en bas avec position: fixed; bottom: 0 et sans inset |
| Aucun reste du site web dans l'app | Les examinateurs lisent les bannières de téléchargement et les liens vers les stores comme « c'est un site web » (guidelines 4.2 et 2.3) | Une bannière « Téléchargez l'app » affichée pour tous les user agents |
| Uniquement des schémas du bridge documentés | Un schéma inventé échoue en silence dans l'app | window.location.href = "share://..." au lieu de shareapp:// |
Les revues automatiques appliquent déjà vos règles. Avant une soumission aux stores, demandez une passe ciblée sur la pull request de release ; le texte qui suit @codex review resserre cette revue-là sans modifier AGENTS.md.
@codex review pour les blocages de publication sur l'App Store et Google Play. Appliquez les Code Review Rules d'AGENTS.md et concentrez-vous sur : les secrets ou clés réservées au serveur accessibles depuis le code client ; les biens numériques, abonnements ou crédits vendus sans passer par l'achat intégré quand isNativeApp() est true ; toute modification qui affaiblit la suppression de compte, les pages de confidentialité et de conditions ou la parité avec Sign in with Apple ; les en-têtes, pieds de page ou feuilles fixes sans insets de safe area, les zones tactiles de moins de 44 px et les champs de moins de 16 px ; les bannières de téléchargement ou liens vers les stores visibles dans l'app ; les schémas d'URL du bridge qui ne sont pas documentés dans https://www.webviewgold.com/llms-full.txt.
La revue d'une pull request ne voit qu'une modification. Avant de soumettre un nouveau build natif, relisez tout le chemin parcouru depuis la dernière soumission : taguez chaque état soumis, puis ouvrez une pull request de revue uniquement, de main vers une branche créée à partir de ce tag. Commentez-y la demande ci-dessus, traitez les constats et fermez la pull request sans la merger.
# when you submit a build to the stores, tag the state of main
git tag store-1.2.0
git push origin store-1.2.0
# before the next submission: a base branch at the old state
git branch review/store-1.2.0 store-1.2.0
git push origin review/store-1.2.0
# review-only pull request: base = the old state, head = main
gh pr create --base review/store-1.2.0 --head main \
--title "Release review: changes since store 1.2.0" \
--body "Review only. Do not merge."Dans la CLI Codex, /review lance un relecteur distinct qui lit un diff (par rapport à une branche de base, aux modifications non commitées ou à un commit) et rapporte des constats classés par priorité sans modifier vos fichiers. Choisissez les instructions de revue personnalisées et collez ceci :
Relisez les modifications par rapport à main comme un contrôle de release pour nos apps iOS et Android WebViewGold, qui chargent cette app web dans une WebView native. Signalez chaque infraction aux Code Review Rules d'AGENTS.md avec le fichier, la ligne, la règle, la raison pour laquelle elle bloquerait une publication sur l'App Store ou Google Play, et la plus petite correction. Listez ensuite ce qui doit être vérifié sur un vrai téléphone (mise en page sous l'encoche et l'indicateur d'accueil, clavier qui masque les champs, parcours de connexion et d'achat). Ne signalez pas les problèmes de mise en forme ou de nommage.
@codex fix the P1 finding (toute mention autre que review) lance une tâche cloud qui peut pousser sur la branche : relisez donc aussi ce commit.La revue de code est une fonctionnalité de Codex, et Codex est inclus dans les offres ChatGPT payantes, avec des limites d'utilisation qui dépendent de l'offre. Vérifiez les conditions actuelles de votre offre avant d'activer les revues automatiques sur un dépôt très actif.
Pas sur GitHub : il n'y remonte que les constats P0 et P1. C'est aussi pour cela que les règles des stores ont besoin d'un « treat as P1 » explicite. Laissez la mise en forme à votre linter et à la CI.
Oui. Commentez @codex avec une demande autre que review, par exemple « @codex corrigez le constat P1 sur le bouton Stripe ». Cela lance une tâche avec la pull request comme contexte, qui peut pousser une correction sur la branche si elle en a l'autorisation. Relisez ce commit comme n'importe quel autre.
Oui, dès que vous accordez au connecteur GitHub de Codex l'accès au dépôt. La configuration des revues automatiques nécessite les droits push ou admin sur celui-ci.
La documentation actuelle d'OpenAI nomme la section ## Code Review Rules. Renommez la rubrique en conséquence, gardez les règles en dessous et testez avec une pull request qui enfreint volontairement une règle.
C'est possible, et les revues voient alors aussi les modifications de Config.swift et Config.java. Beaucoup d'équipes le gardent à part, car les modifications natives sont rares. Dans tous les cas, ne commitez jamais de certificats, de fichiers de provisioning ou de keystores.
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.