ChatGPT & Codex
Codex écrit l'app web ; les stores veulent une app. L'écart est plus petit qu'il n'y paraît : une URL HTTPS publique, une poignée de règles des stores que votre agent peut corriger en une session, et un projet WebViewGold qui transforme l'URL en app iOS et Android native. Voici le workflow complet, dans l'ordre qui évite de refaire le travail.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
OpenAI Codex est l'outil de code agentique au cœur de ce guide : la CLI Codex dans votre terminal, l'extension Codex dans VS Code ou Cursor, et Codex dans le cloud, qui exécute des tâches dans un conteneur isolé relié à votre dépôt GitHub et vous rend des pull requests. Les trois lisent le même fichier AGENTS.md de votre dépôt, et les trois peuvent effectuer la passe de préparation pour les stores décrite ci-dessous. Si vous avez créé l'app dans ChatGPT lui-même (Canvas, ou en copiant-collant du code dans les deux sens), le workflow est identique dès que le code se trouve dans un dépôt.
Ce que Codex ne peut pas faire, c'est signer un binaire iOS ou remplir App Store Connect. Cette partie revient à WebViewGold et aux deux consoles développeur, et ce sont surtout des formulaires. Déployez d'abord, corrigez les règles des stores ensuite, configurez le projet natif en dernier : il n'a besoin que de votre URL définitive.
Six étapes ; les étapes techniques prennent un après-midi, le reste consiste à attendre les comptes et les examens.
Poussez le dépôt sur GitHub et déployez avec Vercel, Netlify, Cloudflare Pages, Render ou votre propre serveur. localhost, les tunnels et les aperçus Canvas ne sont pas des URL d'app acceptables : l'examinateur ouvre l'app des jours plus tard, depuis un autre réseau. Utilisez votre propre domaine si vous le pouvez (pourquoi un domaine personnalisé vaut la peine).
Collez le prompt ci-dessous dans une session Codex ouverte sur le dépôt. Il audite la mise en page mobile, ajoute les pages légales, la suppression de compte, les états d'erreur et les ajustements propres à l'app, puis rend compte de chaque changement. Relisez le diff, déployez, et lancez la vérification de conformité App Store gratuite sur l'URL.
iOS : définissez webviewurl et host dans Config.swift. Android : définissez HOME_URL et HOST dans Config.java. Activez ensuite ce que votre app utilise : push (OneSignal, Firebase ou Pushwoosh), l'écran hors ligne, les déclencheurs du Social Login Helper pour la connexion Google ou Facebook, les clés RevenueCat si vous vendez des biens numériques. Le nom, l'icône et l'écran de démarrage se règlent dans les mêmes projets ; le Cloud Builder propose les mêmes options sous forme de formulaire dans le navigateur.
Xcode : archivez et envoyez vers App Store Connect. Android Studio : générez un App Bundle signé et conservez précieusement le keystore ; chaque future mise à jour devra être signée avec lui. Pas de Mac ni d'IDE ? Le Cloud Builder compile les deux apps dans le navigateur et les envoie vers les deux consoles.
Des captures d'écran de la vraie app (pas du site web), une description qui correspond à ce que verra l'examinateur, l'URL de la politique de confidentialité, les réponses App Privacy d'Apple, le formulaire Data safety de Google, la classification du contenu et des notes pour l'examen avec un compte de démo. ChatGPT rédige bien l'essentiel ; voir ChatGPT pour la politique de confidentialité et la fiche.
Soumettez le build iOS ; Apple répond généralement sous 24 à 48 heures. Sur Google Play, un compte développeur personnel créé après le 13 novembre 2023 doit d'abord mener un test fermé avec 12 testeurs pendant 14 jours : envoyez donc immédiatement un build sur un canal de test fermé et recrutez des testeurs pendant qu'Apple examine l'app. L'examen de Google lui-même prend quelques jours.
Lancez-le à la racine du dépôt. Codex parcourt la liste, modifie les fichiers et résume les changements ; vous relisez le diff avant de déployer. Remplacez MYAPPNATIVE par le marqueur de user agent que vous définirez dans WebViewGold.
Vous préparez cette app web pour sa publication en apps iOS et Android natives. Elle tournera dans un wrapper WebView natif (WebViewGold) qui charge notre URL de production. Traitez chaque point, modifiez le code et terminez par la liste de tous les changements et de tout ce que vous n'avez pas pu faire. 1. Mise en page mobile : meta viewport avec width=device-width et viewport-fit=cover ; aucun débordement horizontal de 320px à 1024px ; zones tactiles d'au moins 44x44px ; en-têtes, pieds de page et bottom sheets fixes avec un padding env(safe-area-inset-top) et env(safe-area-inset-bottom) ; aucune interaction uniquement au survol ; champs de saisie avec un font-size d'au moins 16px. 2. Pages légales : ajoutez /privacy et /terms comme de vraies routes (pas des modales), liées depuis le pied de page et l'écran des réglages. Utilisez des placeholders entre crochets pour le nom de l'entreprise, l'adresse et l'e-mail, et listez chaque service tiers que ce code appelle réellement (vérifiez package.json et les routes API). 3. Suppression de compte : si les utilisateurs peuvent s'inscrire, ajoutez une action Supprimer le compte dans les réglages, avec une boîte de dialogue de confirmation, reposant sur une fonction côté serveur qui supprime l'enregistrement de l'utilisateur et les données associées, ainsi qu'une page publique /delete-account. 4. États d'erreur et hors ligne : chaque chargement de données a besoin d'états de chargement, vide, d'erreur et de nouvel essai. Aucun écran blanc, aucun objet d'erreur brut. 5. Interface propre à l'app : quand navigator.userAgent contient le marqueur MYAPPNATIVE, masquez les bannières « Téléchargez notre app », les bandeaux cookies qui ne sont pas légalement obligatoires, l'en-tête desktop et les liens promotionnels externes. Placez la détection dans une seule fonction utilitaire. 6. Connexion : s'il existe une connexion Google, Facebook ou une autre connexion tierce, ajoutez Sign in with Apple comme option équivalente, ou indiquez ce dont le fournisseur d'authentification a besoin. Gardez la connexion par e-mail ou par magic link fonctionnelle. 7. Paiements : listez chaque endroit où un produit numérique, un abonnement ou des crédits peuvent être achetés. Ne modifiez pas encore le code de paiement ; nous le ferons passer par les achats intégrés. 8. Hygiène : aucun texte provisoire, aucun lien mort, aucune erreur de console sur les parcours principaux, titre de page égal au nom de l'app, meta description présente, aucun contenu mixte. N'ajoutez ni SDK natif ni outil de build ; le côté natif est géré par le wrapper. Gardez toutes les fonctionnalités existantes opérationnelles.
Excellent travail! Je n'ai jamais codé quoi que ce soit, mais j'ai réussi à travailler avec cela. Facile et rapide! Avec une grande aide des créateurs!
| Sujet | Votre app web (Codex) | Projet WebViewGold | Console du store |
|---|---|---|---|
| Politique de confidentialité | Route /privacy | Rien à faire | URL dans App Store Connect et la Play Console |
| Suppression de compte | Bouton et fonction côté serveur | Rien à faire | URL de suppression dans la Play Console |
| Notifications push | Facultatif : un bouton Activer qui ouvre registerpush:// au bon moment | Clés OneSignal, Firebase ou Pushwoosh ; demande d'autorisation au premier lancement activée ou non | Capability Push Notifications (iOS) |
| Sign in with Apple | Bouton et configuration du fournisseur d'authentification | Géré automatiquement ; déclencheurs du Social Login Helper pour Google et Facebook | Capability Sign in with Apple |
| Achats intégrés | Boutons d'achat qui ouvrent revenuecat://purchase?external_id=…&product=… | Clé API et ID de projet RevenueCat | Produits, prix, coordonnées bancaires et formulaires fiscaux |
Activez OneSignal, Firebase ou Pushwoosh dans le projet WebViewGold, désactivez la demande au premier lancement et laissez votre app web la déclencher après la première action significative avec window.location.href = "registerpush://". Pour les examinateurs, le push est le signe le plus clair d'une vraie fonctionnalité d'app.
WebViewGold affiche un écran hors ligne natif avec un bouton pour réessayer quand l'appareil n'a pas de connexion, et peut servir un repli HTML local. Votre app web a quand même besoin d'états d'erreur pour les requêtes qui échouent en cours de session.
Ouvrez la feuille de partage du système avec shareapp://message?=Regardez ça&url=https://app.example.com/item/42 ; confirmez les actions avec successhaptic://. Des appels d'une ligne, un comportement natif visible.
Appelez bioauth:// avant un écran sensible ; sur iOS, WebViewGold appelle ensuite onBioAuthSuccess(), onBioAuthFailure(code, message) ou onBioAuthUnavailable() dans votre page. Gardez une vérification côté serveur derrière.
Config.swift / Config.java est le domaine de production, pas un aperçu ni un tunnel.Non. WebViewGold est un projet Xcode terminé et un projet Android Studio terminé ; vous modifiez des valeurs de configuration, pas du code natif. Avec le Cloud Builder, vous n'ouvrez même pas d'IDE.
Pour la partie texte, oui : Config.swift et Config.java sont de simples fichiers source, vous pouvez donc ouvrir le projet WebViewGold dans une session Codex et lui demander de définir l'URL, le host et les interrupteurs de fonctionnalités. La signature, les certificats et les envois vers les stores restent entre vos mains (ou celles du Cloud Builder).
Oui, si elle offre de vraies fonctionnalités et se comporte comme une app. La guideline 4.2 d'Apple vise les sites web réemballés sans valeur ajoutée ; notifications push, gestion du hors ligne, partage natif et mise en page mobile soignée sont ce que les examinateurs recherchent. 96,4 % de toutes les apps WebViewGold sont approuvées par les équipes de validation dès la première tentative.
Non. Le contenu et les fonctionnalités sont livrés en déployant l'app web ; l'app native n'a besoin d'un nouveau build que si vous modifiez la configuration native (fournisseur de push, icône, nom, nouvelle version de WebViewGold).
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.