ChatGPT & Codex
Codex schreibt die Web-App, die Stores wollen eine App. Die Lücke ist kleiner, als sie aussieht: eine öffentliche HTTPS-URL, eine Handvoll Store-Regeln, die dein Agent in einer Session erledigt, und ein WebViewGold-Projekt, das aus der URL eine native iOS- und Android-App macht. Hier ist der komplette Workflow in der Reihenfolge, die doppelte Arbeit vermeidet.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
OpenAI Codex ist das agentische Coding-Tool hinter diesem Guide: die Codex CLI in deinem Terminal, die Codex-Erweiterung in VS Code oder Cursor und Codex in der Cloud, das Aufgaben in einem abgeschotteten Container mit Zugriff auf dein GitHub-Repository ausführt und dir Pull Requests zurückgibt. Alle drei lesen dieselbe AGENTS.md-Datei in deinem Repository, und alle drei können den Store-Readiness-Pass unten durchführen. Hast du die App direkt in ChatGPT gebaut (in Canvas oder indem du Code hin und her kopiert hast), ist der Workflow identisch, sobald der Code in einem Repository liegt.
Was Codex nicht kann: eine iOS-Binary signieren oder App Store Connect ausfüllen. Das übernehmen WebViewGold und die beiden Entwicklerkonsolen, und es sind vor allem Formulare. Erst deployen, dann die Store-Regeln umsetzen, zuletzt das native Projekt konfigurieren: Es braucht nur deine finale URL.
Sechs Schritte; die technischen dauern einen Nachmittag, den Rest der Zeit wartest du auf Konten und Reviews.
Pushe das Repository zu GitHub und deploye mit Vercel, Netlify, Cloudflare Pages, Render oder auf deinem eigenen Server. localhost, Tunnel und Canvas-Vorschauen sind keine brauchbaren App-URLs: Der Reviewer öffnet die App Tage später aus einem anderen Netzwerk. Nutze wenn möglich deine eigene Domain (warum sich eine eigene Domain lohnt).
Füge den Prompt unten in eine Codex-Session im Repository ein. Er prüft das mobile Layout, ergänzt die rechtlichen Seiten, die Kontolöschung, Fehlerzustände und die App-exklusiven Anpassungen und meldet jede Änderung. Prüfe das Diff, deploye und lass den kostenlosen App-Store-Readiness-Check über die URL laufen.
iOS: Setze webviewurl und host in Config.swift. Android: Setze HOME_URL und HOST in Config.java. Dann schaltest du ein, was deine App nutzt: Push (OneSignal, Firebase oder Pushwoosh), den Offline-Bildschirm, Social-Login-Helper-Trigger für den Google- oder Facebook-Login, RevenueCat-Keys, wenn du digitale Güter verkaufst. Name, Icon und Splash-Screen liegen in denselben Projekten; der Cloud Builder bietet dieselben Optionen als Formular im Browser.
Xcode: archivieren und zu App Store Connect hochladen. Android Studio: ein signiertes App Bundle erzeugen und den Keystore sicher aufbewahren; jedes künftige Update muss damit signiert werden. Kein Mac, keine IDE? Der Cloud Builder kompiliert beide Apps im Browser und lädt sie in beide Konsolen hoch.
Screenshots aus der echten App (nicht von der Website), eine Beschreibung, die zu dem passt, was der Reviewer sieht, die URL der Datenschutzerklärung, Apples App-Privacy-Angaben, Googles Data-safety-Formular, die Altersfreigabe und Review-Notizen mit einem Demo-Account. ChatGPT entwirft das meiste davon gut; siehe ChatGPT für Datenschutzerklärung und Store-Eintrag.
Reiche den iOS-Build ein; Apple antwortet meist innerhalb von 24 bis 48 Stunden. Auf Google Play muss ein privates Entwicklerkonto, das nach dem 13. November 2023 erstellt wurde, zuerst einen geschlossenen Test mit 12 Testern über 14 Tage durchführen. Lade also sofort in einen geschlossenen Test-Track hoch und gewinne Tester, während Apple prüft. Googles eigenes Review dauert ein paar Tage.
Führe ihn im Root des Repositorys aus. Codex arbeitet die Liste ab, bearbeitet die Dateien und fasst die Änderungen zusammen; du prüfst das Diff vor dem Deploy. Ersetze MYAPPNATIVE durch den User-Agent-Marker, den du in WebViewGold setzt.
Du bereitest diese Web-App für die Veröffentlichung als native iOS- und Android-Apps vor. Sie läuft in einem nativen WebView-Wrapper (WebViewGold), der unsere Produktions-URL lädt. Arbeite jeden Punkt ab, bearbeite den Code und schließe mit einer Liste aller Änderungen und allem, was du nicht erledigen konntest. 1. Mobiles Layout: meta viewport mit width=device-width und viewport-fit=cover; kein horizontaler Overflow von 320px bis 1024px; Tippflächen von mindestens 44x44px; fixe Header, Footer und Bottom Sheets mit env(safe-area-inset-top) und env(safe-area-inset-bottom) gepolstert; keine Interaktionen, die nur per Hover funktionieren; Eingabefelder mit einer font-size von mindestens 16px. 2. Rechtliche Seiten: Lege /privacy und /terms als echte Routen an (keine Modals), verlinkt aus dem Footer und dem Einstellungs-Screen. Verwende Platzhalter in eckigen Klammern für Firmenname, Adresse und E-Mail, und liste jeden Drittanbieterdienst auf, den diese Codebasis tatsächlich aufruft (prüfe package.json und die API-Routen). 3. Kontolöschung: Wenn sich Nutzer registrieren können, ergänze in den Einstellungen eine Aktion 'Konto löschen' mit Bestätigungsdialog, gestützt auf eine serverseitige Funktion, die den Nutzerdatensatz und die zugehörigen Daten löscht, plus eine öffentliche Seite /delete-account. 4. Fehler- und Offline-Zustände: Jeder Datenabruf braucht einen Lade-, Leer-, Fehler- und Wiederholen-Zustand. Keine weißen Screens, keine rohen Fehlerobjekte. 5. App-exklusive UI: Wenn navigator.userAgent den Marker MYAPPNATIVE enthält, blende 'Lade unsere App herunter'-Banner aus, ebenso Cookie-Banner, die rechtlich nicht vorgeschrieben sind, den Desktop-Header und externe Werbelinks. Lege die Erkennung in eine einzige Hilfsfunktion. 6. Login: Gibt es einen Login mit Google, Facebook oder einem anderen Drittanbieter, ergänze Sign in with Apple als gleichwertige Option oder melde, was der Auth-Provider dafür braucht. Der Login per E-Mail oder Magic Link muss weiter funktionieren. 7. Zahlungen: Liste jede Stelle auf, an der ein digitales Produkt, ein Abo oder Credits gekauft werden können. Ändere den Zahlungscode noch nicht; wir leiten ihn später über In-App-Käufe. 8. Hygiene: kein Platzhaltertext, keine toten Links, keine Konsolenfehler in den Hauptabläufen, Seitentitel auf den App-Namen gesetzt, Meta-Description vorhanden, kein Mixed Content. Füge keine nativen SDKs oder Build-Tools hinzu; um die native Seite kümmert sich der Wrapper. Alle bestehenden Funktionen müssen weiter funktionieren.
Großartige Arbeit! Ich habe noch nie etwas programmiert, aber ich konnte damit arbeiten. Einfach und schnell! Auch mit großartiger Hilfe von den Erstellern!
| Thema | Deine Web-App (Codex) | WebViewGold-Projekt | Store-Konsole |
|---|---|---|---|
| Datenschutzerklärung | Route /privacy | – | URL in App Store Connect und in der Play Console |
| Kontolöschung | Button plus serverseitige Funktion | – | Lösch-URL in der Play Console |
| Push-Benachrichtigungen | Optional: ein Aktivieren-Button, der im richtigen Moment registerpush:// öffnet | Keys für OneSignal, Firebase oder Pushwoosh; Berechtigungsdialog beim ersten Start an oder aus | Push-Capability (iOS) |
| Sign in with Apple | Button und Einrichtung des Auth-Providers | Wird automatisch übernommen; Social-Login-Helper-Trigger für Google und Facebook | Sign-in-with-Apple-Capability |
| In-App-Käufe | Kauf-Buttons, die revenuecat://purchase?external_id=…&product=… öffnen | RevenueCat-API-Key und Projekt-ID | Produkte, Preise, Bank- und Steuerformulare |
Aktiviere OneSignal, Firebase oder Pushwoosh im WebViewGold-Projekt, schalte den Dialog beim ersten Start ab und lass deine Web-App nach der ersten sinnvollen Aktion fragen, mit window.location.href = "registerpush://". Für Reviewer ist Push das deutlichste Zeichen echter App-Funktionalität.
WebViewGold zeigt einen nativen Offline-Bildschirm mit einem Button zum erneuten Versuchen, wenn das Gerät keine Verbindung hat, und kann einen lokalen HTML-Fallback ausliefern. Für Requests, die mitten in der Session scheitern, braucht deine Web-App trotzdem eigene Fehlerzustände.
Öffne das System-Share-Sheet mit shareapp://message?=Schau dir das an&url=https://app.example.com/item/42; bestätige Aktionen mit successhaptic://. Einzeilige Aufrufe, sichtbares natives Verhalten.
Rufe vor einem sensiblen Screen bioauth:// auf; auf iOS ruft WebViewGold dann onBioAuthSuccess(), onBioAuthFailure(code, message) oder onBioAuthUnavailable() in deiner Seite auf. Behalte dahinter eine serverseitige Prüfung.
Config.swift / Config.java ist die Produktionsdomain, keine Preview- oder Tunnel-URL.Nein. WebViewGold ist ein fertiges Xcode-Projekt und ein fertiges Android-Studio-Projekt; du änderst Konfigurationswerte, keinen nativen Code. Mit dem Cloud Builder öffnest du überhaupt keine IDE.
Für die Textteile ja: Config.swift und Config.java sind normale Quelldateien, du kannst das WebViewGold-Projekt also in einer Codex-Session öffnen und es bitten, URL, Host und Feature-Schalter zu setzen. Signierung, Zertifikate und die Uploads in die Stores bleiben bei dir (oder beim Cloud Builder).
Ja, wenn sie echte Funktionalität bietet und sich wie eine App verhält. Apples Richtlinie 4.2 zielt auf neu verpackte Websites ohne Mehrwert; Push-Benachrichtigungen, Offline-Verhalten, natives Teilen und ein sauberes mobiles Layout sind das, worauf Reviewer achten. 96,4 % aller WebViewGold-Apps werden von den Review-Teams beim ersten Versuch freigegeben.
Nein. Inhalte und Features lieferst du per Deploy der Web-App aus; die native App braucht nur dann einen neuen Build, wenn du die native Konfiguration änderst (Push-Dienst, Icon, Name, eine neue WebViewGold-Version).
Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.
$109 pro Plattform, einmalig
Die WebViewGold-Lizenz: ein fertiges Xcode- oder Android-Studio-Projekt. URL einfügen, Name und Icon setzen, Features einschalten, bauen und einreichen. Kostenlose Updates für immer.
Pakete auf der Hauptseite ansehen$349 pro Lizenz, einmaliges Add-on
Kein Mac, kein Xcode, kein Android Studio: Du konfigurierst im Browser, wir bauen beide Apps in der Cloud und übergeben sie an App Store Connect und die Play Console.
So funktioniert der Cloud Builder Kostenlose Demo ausprobieren$698 pro Plattform $798
Schick uns deine URL und dein Icon. Unser Team konfiguriert, baut und liefert deine App innerhalb von 72 Stunden, White-Label, inklusive Quellprojekten. Beide Plattformen für $1,158.
Full-Service-Details Powered by
Winter-Sale-Preise gültig bis 31. Dezember 2026.
App Store & Google Play Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen
Lieber abgeben? Full Service: Wir konfigurieren, bauen und liefern innerhalb von 72 Stunden, ab $698 pro Plattform. Fragen? Chatte mit uns – 24/7.
Erstattungen erfolgen zu den in unseren FAQ genannten Bedingungen: eine nicht inhaltsbedingte Ablehnung durch Apple und/oder Google, geltend gemacht innerhalb von 14 Tagen nach dem Kauf.