ChatGPT & Codex
Bei einer WebViewGold-App ist jeder Merge in main ein Release: Die native App lädt deine Produktions-URL, ein fehlerhaftes Deployment erreicht also innerhalb von Minuten die Nutzer im App Store und bei Google Play. Codex kann jeden Pull Request auf GitHub prüfen, bevor er gemergt wird. Bring ihm deine Store-Regeln in der AGENTS.md bei, dann meldet es die Probleme, die zu Ablehnungen und Leaks führen, nicht nur Bugs.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Bei einer vollständig nativen App erreicht Code die Nutzer erst, nachdem du gebaut, eingereicht und das Review bestanden hast. Eine WebViewGold-App lädt deine Produktions-URL, ein Merge in main ist also in der Store-Version live, sobald er deployt ist. Das ist der große Vorteil des Ansatzes (keine erneute Einreichung für Web-Änderungen, siehe Web- und native Updates) und zugleich der Grund, warum ein unachtsamer Pull Request die App auf jedem Handy kaputtmachen oder zwischen zwei Reviews einen Stripe Checkout für Credits vor iOS-Nutzer stellen kann. Apple und Google schauen bei jedem nativen Update, das du einreichst, erneut hin, und eine zwischenzeitlich gebrochene Regel fällt dann auf.
Das Codex Code Review schließt diese Lücke. Sobald das Repository mit Codex verbunden ist, prüft es Pull Requests auf GitHub automatisch oder wenn jemand @codex review kommentiert, und es veröffentlicht ein normales GitHub-Review mit Befunden an konkreten Zeilen. Zwei Details prägen das Setup: Auf GitHub meldet es nur Befunde mit hoher Priorität (P0 und P1), und es liest Review-Regeln aus einem Abschnitt ## Code Review Rules in deinen AGENTS.md-Dateien, wobei es für jeden geänderten Pfad die Datei im Root plus die spezifischste verschachtelte Datei anwendet. Die Store-Regeln müssen also aufgeschrieben und als P1 markiert sein.
Verbinde in Codex GitHub und gib dem Codex-Connector Zugriff auf das Repository. Reviews auf GitHub brauchen keine Cloud-Umgebung; Codex liest den Pull Request selbst.
Öffne in Codex die Einstellungen für das Code Review, wähle das Repository und schalte das automatische Review ein. Für die Konfiguration brauchst du Push- oder Admin-Rechte am GitHub-Repository. Ohne automatische Reviews forderst du eines mit dem Kommentar @codex review im Pull Request an.
Füge den Abschnitt ## Code Review Rules unten in die AGENTS.md im Root ein (oder in die AGENTS.md aus unserem Template). Fang kurz an: OpenAI empfiehlt wenige, knappe Regeln und überlässt Formatierung und Lint der CI. Verschachtelte AGENTS.md-Dateien können Regeln für einzelne Ordner ergänzen, zum Beispiel strengere für deine Server-Funktionen.
Verlange in den Einstellungen des GitHub-Repositorys für den main-Branch Pull Requests und bestandene Checks. Codex kommentiert; es blockiert keine Merges. Das erledigt der Branch-Schutz.
Öffne einen Wegwerf-Pull-Request, der absichtlich eine Regel bricht, zum Beispiel mit einem Stripe-Zahlungslink, der angezeigt wird, wenn isNativeApp() true ist. Meldet Codex ihn nicht, formuliere die Regel konkreter und versuch es noch einmal; schließe den Pull Request dann, ohne zu mergen.
Füge das in die AGENTS.md ein und passe die Namen an deine Codebasis an. Die Zeile "Treat as P1" ist wichtig: GitHub-Reviews zeigen nur Befunde der Stufen P0 und P1, ohne sie könnte eine Store-Regel als unwichtig eingestuft werden und nie auftauchen.
## 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.
Ich bin sehr glücklich, dass ich diese App gekauft habe! Extrem einfach und großartige Dokumentation. Ich stand in Kontakt mit dem Kundenservice, sie antworteten sehr schnell und sehr freundlich. Sie lösten meine Frage innerhalb eines Tages. 10/10 würde ich empfehlen.
| Regel | Warum sie zählt | Ein typischer P1-Befund |
|---|---|---|
| Keine Secrets im Client-Code | Alles im Bundle kann jeder lesen, der die App oder die Website öffnet; ein Service-Role-Key der Datenbank oder ein OpenAI-Key bedeutet ein Datenleck oder eine hohe Rechnung | VITE_OPENAI_API_KEY direkt in einer React-Komponente verwendet |
| Digitale Güter über In-App-Kauf | Apples Richtlinie 3.1.1 und Google Plays Zahlungsrichtlinie (mit regionalen Ausnahmen); die häufigste Ablehnung bei KI- und SaaS-Apps, siehe Richtlinie 3.1.1 | Ein Button für ein Credit-Paket öffnet Stripe Checkout ohne isNativeApp()-Zweig |
| Kontolöschung funktioniert weiter | Apple 5.1.1(v) und Google Play verlangen für Apps mit Registrierung eine Löschung in der App | Ein Refactoring hat den Aufruf der serverseitigen Löschfunktion entfernt |
| Gleichwertiges Sign in with Apple | Apple 4.8 greift, sobald es einen Drittanbieter-Login gibt | Ein neuer Button "Weiter mit Google" ohne Apple-Option |
| Safe Areas, 44-px-Tippflächen, 16-px-Eingabefelder | Ablehnungen nach Apple 4.0 Design; iOS zoomt in Eingabefelder unter 16 px hinein, siehe Safe Areas und Tippflächen | Eine neue untere Navigation mit position: fixed; bottom: 0 und ohne Inset |
| Keine Website-Überbleibsel in der App | Reviewer lesen Download-Banner und Store-Links als "das ist eine Website" (Richtlinien 4.2 und 2.3) | Ein Banner "Hol dir die App", das für jeden User Agent gerendert wird |
| Nur dokumentierte Bridge-Schemas | Ein erfundenes Schema scheitert in der App lautlos | window.location.href = "share://..." statt shareapp:// |
Automatische Reviews wenden deine Regeln bereits an. Fordere vor einer Store-Einreichung einen fokussierten Durchgang für den Release-Pull-Request an; der Text nach @codex review schärft dieses eine Review, ohne die AGENTS.md zu ändern.
@codex review mit Fokus auf Blocker für das Release im App Store und bei Google Play. Wende die Code Review Rules aus AGENTS.md an und konzentriere dich auf: Secrets oder reine Server-Keys, die aus dem Client-Code erreichbar sind; digitale Güter, Abos oder Credits, die ohne den In-App-Kauf-Pfad verkauft werden, wenn isNativeApp() true ist; jede Änderung, die die Kontolöschung, die Seiten für Datenschutz und AGB oder die Gleichwertigkeit von Sign in with Apple schwächt; fixierte Header, Footer oder Sheets ohne Safe-Area-Insets, Tippflächen unter 44px und Eingabefelder unter 16px; Download-Banner oder Store-Links, die in der App sichtbar sind; Bridge-URL-Schemas, die nicht in https://www.webviewgold.com/llms-full.txt dokumentiert sind.
Ein Pull-Request-Review sieht eine einzelne Änderung. Bevor du einen neuen nativen Build einreichst, prüf die gesamte Strecke seit der letzten Einreichung: Tagge jeden eingereichten Stand und öffne dann einen Pull Request nur fürs Review, von main gegen einen Branch, der aus diesem Tag erstellt wurde. Kommentiere die Anfrage von oben, arbeite die Befunde ab und schließe den Pull Request, ohne zu mergen.
# 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."In der Codex CLI startet /review einen separaten Reviewer, der ein Diff liest (gegen einen Basis-Branch, nicht committete Änderungen oder einen Commit) und priorisierte Befunde meldet, ohne deine Dateien zu ändern. Wähle eigene Review-Anweisungen und füge das hier ein:
Prüfe die Änderungen gegenüber main als Release-Schranke für unsere WebViewGold-Apps für iOS und Android, die diese Web-App in einer nativen WebView laden. Melde jeden Verstoß gegen die Code Review Rules in AGENTS.md mit Datei, Zeile, Regel, dem Grund, warum er ein Release im App Store oder bei Google Play blockieren würde, und dem kleinsten Fix. Liste danach auf, was auf einem echten Handy geprüft werden muss (Layout unter der Notch und dem Home-Indikator, die Tastatur, die Eingabefelder verdeckt, Login- und Kaufabläufe). Melde keine Probleme mit Formatierung oder Benennung.
@codex behebe den P1-Befund (jede Erwähnung außer review) startet eine Cloud-Aufgabe, die auf den Branch pushen kann, also prüf auch diesen Commit.Code Review ist ein Codex-Feature, und Codex gehört zu den kostenpflichtigen ChatGPT-Plänen, deren Nutzungslimits vom Plan abhängen. Prüf die aktuellen Bedingungen für deinen Plan, bevor du automatische Reviews in einem viel genutzten Repository einschaltest.
Auf GitHub nicht: Dort meldet es nur Befunde der Stufen P0 und P1. Das ist auch der Grund, warum Store-Regeln ein ausdrückliches "treat as P1" brauchen. Überlass die Formatierung deinem Linter und der CI.
Ja. Kommentiere @codex mit einer anderen Anfrage als review, zum Beispiel "@codex behebe den P1-Befund zum Stripe-Button". Das startet eine Aufgabe mit dem Pull Request als Kontext, die einen Fix auf den Branch pushen kann, wenn die Berechtigung dafür vorhanden ist. Prüf diesen Commit wie jeden anderen.
Ja, sobald du dem GitHub-Connector von Codex Zugriff auf das Repository gibst. Für die Konfiguration automatischer Reviews brauchst du Push- oder Admin-Rechte daran.
Die aktuelle Dokumentation von OpenAI nennt den Abschnitt ## Code Review Rules. Benenne die Überschrift passend um, behalte die Regeln darunter und teste mit einem Pull Request, der absichtlich eine Regel bricht.
Das kann es, dann sehen die Reviews auch Änderungen an Config.swift und Config.java. Viele Teams halten es getrennt, weil native Änderungen selten sind. So oder so: Committe niemals Zertifikate, Provisioning-Dateien oder Keystores.
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.