ChatGPT & Codex
Die meisten Probleme einer Web-App bei der ersten Einreichung (Safe Areas, rechtliche Seiten, Kontolöschung, Fehlerzustände, Website-Überbleibsel) sind voneinander unabhängig. Damit passen sie gut zu Codex in der Cloud: eine Aufgabe pro Fix, alle gleichzeitig in ihrem eigenen Workspace, und jede endet in einem Diff, das du prüfst, und einem Pull Request, den du mergst. Der Trick ist, die Arbeit so aufzuteilen, dass die Pull Requests nicht kollidieren.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Eine Codex-Cloud-Aufgabe läuft in der Cloud statt auf deinem Laptop. Du veröffentlichst einmal eine Umgebung (das GitHub-Repository, ein Installationsskript für die Abhängigkeiten, Netzwerkregeln und optionale Secrets), und jede Aufgabe, die du startest, bekommt einen eigenen isolierten Workspace, der daraus vorbereitet wird. Codex bearbeitet den Code, führt deine Lint- und Testbefehle aus und gibt dir ein Diff mit der Testausgabe zurück. Du kannst in derselben Aufgabe Nachbesserungen anfordern und dann committen oder einen Pull Request öffnen. Aufgaben laufen weiter, während dein Computer schläft, und du startest sie aus der Codex-App oder der Weboberfläche, aus der IDE-Erweiterung oder im Terminal mit codex cloud.
Store-Readiness-Arbeit passt dazu sehr gut. Die Fixes, die Reviewer verlangen, sind meist unabhängig (Safe Areas kümmern sich nicht um deine Datenschutzseite, die Kontolöschung nicht um Lade-Spinner), jeder hat eine überprüfbare Definition of Done, und keiner braucht die native App: Die WebViewGold-App lädt einfach, was du auf deiner Produktions-URL deployst. Statt einer langen Session, die alles anfasst, startest du vier oder fünf fokussierte Aufgaben, prüfst kleine Pull Requests und mergst sie einen nach dem anderen.
Was Cloud-Aufgaben nicht tun: die iOS- und Android-Apps bauen oder signieren, das Ergebnis auf einem Handy öffnen oder App Store Connect ausfüllen. Das bleibt bei dir, deinem WebViewGold-Projekt und den beiden Konsolen.
Etwa dreißig Minuten; jede spätere Aufgabe nutzt das wieder.
Cloud-Aufgaben arbeiten mit einer Kopie des Repositorys, die Datei reist also mit jeder Aufgabe mit. Sie braucht deine Befehle für Installation, Lint, Typecheck und Tests (Codex führt sie vor dem Abschluss aus) und die Store-Regeln als Invarianten formuliert. Starte mit dem AGENTS.md-Template für WebViewGold-Apps und ergänze den Abschnitt für parallele Arbeit unten.
Mehrere Fixes müssen wissen, ob die Seite in der nativen App läuft. Lege isNativeApp() an (eine User-Agent-Prüfung auf den Marker, den du in WebViewGold über useragent_iphone und useragent_ipad in Config.swift und USER_AGENT in Config.java setzt), in einer Aufgabe oder lokal, und merge ihn, bevor du auffächerst. Sonst schreiben fünf Aufgaben fünf Helper.
Verbinde GitHub, wähle das Repository und lass Codex die Laufzeitumgebung erkennen. Prüfe, dass das Installationsskript eine saubere Installation deiner Abhängigkeiten ausführt (zum Beispiel npm ci). Erlaube beim Netzwerkzugriff nur die Domains des Paketmanagers: Diese Aufgaben brauchen nicht das offene Internet, und eingeschränkter Zugriff verhindert, dass eine Aufgabe Inhalte abruft und befolgt, die du nie geprüft hast.
Layout, rechtliche Seiten und Fehlerzustände brauchen überhaupt keine Secrets. Wenn deine Tests eine Datenbank brauchen, richte sie auf ein separates Testprojekt. Leg niemals einen Service-Role-Key aus der Produktion oder ein Zahlungs-Secret in eine Umgebung, in der unbeaufsichtigte Aufgaben laufen.
Veröffentliche die Umgebung und starte dann eine Wegwerf-Aufgabe: "Führe die Befehle für Installation, Lint, Typecheck und Tests aus AGENTS.md aus, ändere nichts, melde die Ergebnisse." Scheitert das, repariere die Umgebung, bevor du mit der echten Arbeit anfängst; jede parallele Aufgabe würde genauso scheitern.
Füge das in deine bestehende AGENTS.md ein. Die Scope-Regel hält parallele Pull Requests mergebar; das Format für Pull Requests macht jeden davon in wenigen Minuten prüfbar.
## Commands (run all of them before you finish a task)
- Install: npm ci
- Lint: npm run lint
- Types: npm run typecheck
- Tests: npm test
## Store-readiness work
This web app is also published as native iOS and Android apps with WebViewGold.
The native apps load https://app.example.com in a WebView. Detect the app only
with isNativeApp() from src/lib/platform.ts.
Rules for every task:
- Stay inside the files and folders named in the task prompt. Several tasks run
in parallel; changes outside your scope cause merge conflicts. If a fix needs
a change elsewhere, describe it in the summary instead of making it.
- No new dependencies and no version upgrades unless the prompt asks for them.
- Native features are called only through the WebViewGold URL schemes listed in
the bridge section of this file. Never invent a native API.
- Digital goods inside the native app go through in-app purchase. Never add a
Stripe checkout or an external payment link for them behind isNativeApp().
- Users can sign up, so account deletion must keep working.
- Every screen works at 320px width, pads fixed bars with safe-area insets,
has tap targets of 44px or more and inputs with a font-size of 16px or more.
## Pull requests
Title: [store-readiness] <task name>
Body: what changed, which App Store or Google Play rule it serves, files
touched, how to test it on a phone, and what is left for a human.
Mein iOS WebView wurde endlich genehmigt. Danke!!
| Aufgabe | Berührt | Wann | Fertig, wenn |
|---|---|---|---|
| 0. Plattform-Helper | src/lib/platform.ts und bestehende User-Agent-Prüfungen | Allein, als Erstes | isNativeApp() existiert, Inline-Prüfungen sind ersetzt, Tests laufen durch |
| 1. Safe Areas, Tippflächen, Eingabegrößen | Globales CSS, Layout- und Button-Komponenten | Welle 1 | Fixierte Leisten nutzen env(safe-area-inset-*), Tippflächen ab 44 px, Eingabefelder ab 16 px, kein Overflow bei 320 px |
| 2. Seiten für Datenschutz und AGB | Neue Routen plus ein Footer-Link und ein Link in den Einstellungen | Welle 1 | /privacy und /terms werden als echte Seiten gerendert und nennen die Dienste, die der Code tatsächlich nutzt |
| 3. Kontolöschung | Einstellungs-Screen, eine neue Server-Funktion, /delete-account | Welle 1 | Die Löschung läuft serverseitig, meldet den Nutzer ab und bestätigt; die öffentliche Seite erklärt die Schritte |
| 4. Store-Audit (nur Bericht) | Eine neue Datei, STORE-AUDIT.md | Welle 1 | Jede Zahlung, jede Berechtigung, jeder Login-Provider und jeder externe Link ist mit Dateiverweisen aufgelistet |
| 5. Lade-, Leer- und Fehlerzustände | Daten-Hooks und Seitenkomponenten | Welle 2 (teilt Komponenten mit Aufgabe 1) | Keine leeren Screens, ein erneuter Versuch bei jedem gescheiterten Request, eine globale Error Boundary |
| 6. UI nur für die App | Banner, Cookie-Hinweis, Desktop-Header | Welle 2 (braucht Aufgabe 0, überschneidet sich mit Aufgabe 1) | Download-Banner und Website-Überbleibsel sind ausgeblendet, wenn isNativeApp() true ist |
| 7. Sign in with Apple, In-App-Käufe | Auth- und Zahlungscode | Später, eins nach dem anderen | Auf Basis des Audits geplant; braucht Konsolen-Setup von dir (Prompts 6 und 7 hier) |
Kopiere ihn einmal pro Aufgabe und fülle die eckigen Klammern aus. Die Scope-Zeile und die Anweisung "beschreiben statt ändern" verhindern Kollisionen; die Definition of Done macht den Pull Request schnell prüfbar.
Aufgabe: [NAME DER AUFGABE AUS DER TABELLE, z. B. "Safe Areas, Tippflächen, Eingabegrößen"] Kontext: Lies zuerst AGENTS.md. Diese Web-App läuft in nativen iOS- und Android-Apps, die mit WebViewGold gebaut sind und unsere Produktions-URL in einer WebView laden. Andere Codex-Aufgaben ändern gleichzeitig andere Teile dieser Codebasis. Scope: Ändere nur [DATEIEN ODER ORDNER]. Braucht der Fix eine Änderung außerhalb dieses Scopes, nimm sie nicht vor, sondern beschreibe sie in deiner Zusammenfassung. Nicht erlaubt: Abhängigkeiten hinzufügen oder aktualisieren, Skripte in package.json ändern, Auth- oder Zahlungscode anfassen, generierte Dateien bearbeiten oder native Features aufrufen, die nicht zu den WebViewGold-URL-Schemas in AGENTS.md gehören. Definition of Done: 1. [KONKRETE PRÜFUNGEN, z. B. jeder fixierte Header, Footer und jedes Bottom Sheet hat ein Padding mit env(safe-area-inset-top) / env(safe-area-inset-bottom); alle Buttons und Links sind mindestens 44x44px groß; alle Eingabefelder nutzen font-size 16px oder mehr; kein horizontales Scrollen bei 320px Breite] 2. Die Befehle für Lint, Typecheck und Tests aus AGENTS.md laufen in dieser Umgebung durch. 3. Für Nutzer im Desktop-Browser ändert sich nichts außer dem Fix selbst. Schließe mit einer Zusammenfassung für den Pull Request im Format aus AGENTS.md ab, inklusive einer Anleitung, wie man die Änderung auf einem Handy testet, und allem, was du nicht erledigen konntest.
Zahlungen, Berechtigungen und Login-Provider bestimmen deine späteren Aufgaben, und sie blind zu ändern ist riskant. Lass eine Aufgabe sie kartieren, ohne Code anzufassen; sie kann gefahrlos parallel laufen, weil sie nur eine Datei hinzufügt.
Ändere in dieser Aufgabe keinen Code. Lege STORE-AUDIT.md im Root des Repositorys mit diesen Abschnitten an und nenne für jeden Punkt Dateipfade und Zeilennummern: 1. Zahlungen: jede Stelle, an der ein Nutzer für etwas bezahlen kann. Jeweils: Route oder Komponente, was verkauft wird, digital oder physisch, aktueller Zahlungsanbieter und ob es in den nativen iOS- und Android-Apps über In-App-Kauf laufen muss (digitale Güter, Abos, Credits) oder bei Stripe bleiben darf (physische Waren, reale Dienstleistungen). 2. Berechtigungen: jede Browser-Berechtigung, die die Web-App anfordert (Standort, Kamera, Mikrofon, Benachrichtigungen, Zwischenablage), mit der Nutzeraktion, die sie auslöst. 3. Login: jede Anmeldemethode und jeder Drittanbieter, und ob Sign in with Apple angeboten wird. 4. Externe Links: jeder Link, der aus der App heraus unsere Domain verlässt. 5. Kontodaten: wo Nutzerdaten gespeichert werden und ob ein vollständiger serverseitiger Löschpfad existiert. 6. Offene Fragen, die du anhand des Codes nicht beantworten konntest. Die einzige Änderung im Pull Request ist die neue Datei STORE-AUDIT.md.
window.webkit.messageHandlers oder ein ausgedachtes window.WebViewGold-Objekt. WebViewGold-Features sind URL-Schemas wie registerpush:// oder shareapp://; alles andere bewirkt in der App nichts.OpenAI nennt keine feste Zahl; die Nutzungslimits hängen von deinem ChatGPT-Plan ab. In der Praxis ist die Grenze deine Review-Kapazität: Drei bis fünf kleine Aufgaben pro Welle kann eine Person an einem Nachmittag ordentlich prüfen.
Ja. Jede Aufgabe arbeitet mit einer Kopie deines Repositorys, die committete AGENTS.md (und verschachtelte in Unterordnern) gilt also genauso wie in der CLI oder der IDE-Erweiterung. Nicht committete lokale Änderungen sehen Cloud-Aufgaben nicht.
Nein. Sie führt deine Testbefehle in ihrer Umgebung aus, dazu browserbasierte Tests, wenn dein Repository welche hat und das Installationsskript sie einrichtet. Die echte Prüfung ist das Preview-Deployment auf deinem Handy und vor der Einreichung ein TestFlight- oder interner Test-Build.
Merge den wichtigeren und bitte Codex dann in der anderen Aufgabe, auf den aktuellen main zu rebasen und die Konflikte aufzulösen. Bei kleinen Diffs geht es oft schneller, die Aufgabe von einem frischen main neu zu starten.
Für diese Aufgaben ist das unnötig. Die Domains des Paketmanagers decken die Installationen ab; offener Zugriff lässt eine Aufgabe nicht vertrauenswürdige Seiten lesen und Daten an Orte schicken, die du nicht beabsichtigt hast. Füge gezielt Domains hinzu, wenn ein Test sie wirklich braucht.
Sie kann Config.swift und Config.java bearbeiten, wenn das native Projekt in einem Repository liegt, etwa um die URL oder den User-Agent-Marker zu setzen. Bauen, signieren oder hochladen kann sie nicht; das übernehmen Xcode, Android Studio oder der Cloud Builder.
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.