ChatGPT & Codex
Eine Ablehnung ist eine To-do-Liste, geschrieben von einem Reviewer. Apple nennt die Richtlinie, Google die Policy, und beide beschreiben, was sie gesehen haben. Codex ist gut darin, daraus Code-Änderungen zu machen, solange du ihm sagst, welche Fixes in die Web-App gehören und welche ins WebViewGold-Projekt. Hier ist die Triage-Routine, die wir im Support nutzen.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Die meisten Ablehnungen nennen zwei oder drei Punkte. Behandle jeden einzeln.
Jeder Punkt gehört zu einer von vier Arten: WEB (dein Code), NATIV (WebViewGold-Konfiguration oder ein natives Feature), METADATEN (Store-Eintrag, Screenshots, Datenschutzangaben, Review-Notizen) oder INHALT (worum es in der App geht). Codex kann die erste Art beheben und dich bei der zweiten und dritten anleiten; über die vierte kannst nur du entscheiden.
Nutze den Triage-Prompt unten im Repository. Füge die vollständige Nachricht ein und alle Screenshots, die der Reviewer angehängt hat (beschreibe sie, wenn du keine Bilder anhängen kannst). Codex ordnet jeden Punkt Dateien und Routen zu und setzt die Web-Fixes um.
Ein Web-Fix ist live, sobald du deployst, aber prüfe ihn im echten App-Build mit den Augen des Reviewers: Flugmodus, der Demo-Account, jeder Tab. Genau dafür gibt es TestFlight und Googles internen Test-Track.
Aktiviere oder konfiguriere das WebViewGold-Feature (Push-Dienst, Offline-Bildschirm, Sign-in-with-Apple-Capability, RevenueCat-Keys), baue neu, lade hoch. Korrigiere in der Konsole Screenshots, Beschreibung, App-Privacy-Angaben oder das Data-safety-Formular.
Antworte im Resolution Center (Apple) oder lege in der Play Console Einspruch ein bzw. reiche erneut ein, jeweils mit einer sachlichen Liste der Änderungen, und reiche dann den neuen Build ein. Folge-Reviews sind meist schneller als das erste.
Unten steht eine Ablehnungsnachricht von App Review (oder Google Play) für die native App-Version dieser Web-App. Die native App ist ein WebViewGold-Wrapper, der unsere Produktions-URL lädt; der Wrapper übernimmt Push-Benachrichtigungen, den Offline-Bildschirm, Social-Login-Helper und In-App-Käufe nativ, alles andere ist diese Codebasis. Für jeden Punkt der Ablehnung: 1) Zitiere die Richtlinie oder Policy; 2) sag, was der Reviewer in unserer App höchstwahrscheinlich gesehen hat, mit konkreten Dateien und Routen; 3) ordne den Fix ein als WEB (dieses Repo), NATIV (Wrapper-Konfiguration) oder METADATEN (Store-Eintrag); 4) setze WEB-Fixes sofort um; 5) schreib für NATIV- und METADATEN-Fixes exakte Anweisungen für mich. Schließe mit einem Antwortentwurf an den Reviewer, der in einfacher, sachlicher Sprache sagt, was sich geändert hat, ohne Entschuldigungen und ohne zu diskutieren. Ablehnungsnachricht: [HIER EINFÜGEN]
| Richtlinie | Was der Reviewer gesehen hat | Fix | Wo |
|---|---|---|---|
| Apple 4.2 Mindestfunktionalität | Eine Website im Rahmen: Desktop-Layout, kein natives Verhalten | Push-Benachrichtigungen, Offline-Bildschirm, Share Sheet oder Face ID; reine Website-UI ausblenden; die nativen Features in den Review-Notizen beschreiben | NATIV + WEB + METADATEN |
| Apple 2.1 Vollständigkeit | Leerer Screen, kaputter Login, Platzhaltertext, tote Links | Fehlerzustände, funktionierender Demo-Account, Platzhalter entfernen, überall HTTPS | WEB + METADATEN |
| Apple 5.1.1 Datenerfassung | Keine Datenschutz-URL oder keine Kontolöschung | Route /privacy, Konto löschen in den Einstellungen mit serverseitiger Löschung | WEB + METADATEN |
| Apple 4.8 Login-Dienste | Google-Login ohne Sign in with Apple | Apple-Provider und Button ergänzen; WebViewGold übernimmt den Ablauf | WEB |
| Apple 3.1.1 In-App-Kauf | Stripe-Checkout für ein Abo oder Credits in der App | Digitale Güter in der nativen App über revenuecat://purchase?… abwickeln; Stripe bleibt im Web | WEB + NATIV |
| Apple 2.3 Korrekte Metadaten | Website-Screenshots, "Beta", Features, die es nicht gibt | Screenshots aus der gebauten App, ehrliche Beschreibung | METADATEN |
| Apple 2.5.1 / ungenutzte Berechtigungen | Nutzungstexte für Kamera oder Standort bei Features, die die App gar nicht hat | Ungenutzte Berechtigungstexte im WebViewGold-Projekt entfernen | NATIV |
| Apple 4.0 Design | Inhalte unter der Notch oder dem Home-Indikator, winzige Buttons | Safe-Area-Insets, 44-px-Tippflächen | WEB |
| Apple 1.2 / Google UGC- und KI-Inhalte | Chat oder Community ohne Melden und Blockieren | Melden-Aktion, Blockieren-Option, Moderation, Kontaktangabe in der Datenschutzerklärung | WEB |
| Google: Data safety stimmt nicht | Das Formular sagt, es werden keine Daten erhoben, die App sendet aber Analytics oder Push-Tokens | Formular an den Code anpassen | METADATEN |
WebViewGold hat uns die kürzeste und effizienteste Time-to-Market ermöglicht, die jemals möglich war, verglichen mit allen anderen App-Plattformen, die wir in den letzten 5 Jahren ausprobiert haben. Ich weiß nicht, warum ich euch nicht schon früher entdeckt habe, aber ich bin wirklich, wirklich froh, dass ich es getan habe. Wir nähern uns derzeit fast 6000 App-Downloads im iOS App Store & Google Play Store ohne Probleme!
Layout, rechtliche Seiten, Kontolöschung, Fehlerzustände, Sign-in-with-Apple-Button, Käufe über die Bridge leiten, Melden-Buttons. Live mit dem nächsten Deploy, kein neuer Build nötig, außer der Reviewer will eine neue Versionsnummer sehen.
Push aktivieren, Offline-Bildschirm, RevenueCat-Keys, Social-Login-Helper-Trigger, Berechtigungstexte, Icon und Name. Wert ändern, neu bauen, hochladen. Der Cloud Builder erledigt den Rebuild im Browser.
Screenshots, Beschreibung, Keywords, Datenschutz-URL, Antworten zu App Privacy und Data safety, Review-Notizen, Demo-Account. Kein Build nötig; bearbeiten und dieselbe Binary erneut einreichen, wenn sich sonst nichts geändert hat.
Glücksspiel, medizinische Aussagen, urheberrechtlich geschütztes Material, Identitätsvortäuschung. Daran kann Codex nicht vorbeiprogrammieren. Entscheide vor der erneuten Einreichung, ob du das Produkt oder den Umfang änderst.
Beschränke dich darauf, was sich geändert hat und wo der Reviewer es sehen kann. Eine Antwort, die funktioniert, sieht so aus: "Vielen Dank für das Review. Wir haben die Punkte wie folgt umgesetzt. Richtlinie 4.2: Die App sendet jetzt Push-Benachrichtigungen zu Bestellupdates (OneSignal), zeigt einen nativen Offline-Bildschirm und bietet Face-ID-Login für den Kontobereich; Website-Elemente wie Footer und Cookie-Banner sind in der App ausgeblendet. Richtlinie 5.1.1: Die Kontolöschung ist unter Einstellungen → Konto → Konto löschen verfügbar und entfernt alle Nutzerdaten. Der Demo-Account bleibt [email protected] / Demo1234. Build 1.0.1 (3) enthält diese Änderungen." Sonst nichts: keine Erklärung deines Geschäftsmodells, kein Hinweis auf andere Apps, die durchgekommen sind.
Wenn du glaubst, dass der Reviewer etwas übersehen hat (zum Beispiel ein Feature hinter dem Login, das er nicht genutzt hat), sag, wo es zu finden ist, und häng einen Screenshot an. Höflichkeit und Präzision schlagen Masse. Eine wiederverwendbare Version findest du im Template für die Resolution-Center-Antwort; das Gegenstück für Google ist das Einspruchs-Template für die Play Console.
Ja, denn die Fixes betreffen Routen, Einstellungs-Screens und Serverfunktionen. Führe es im Repository aus (CLI oder IDE) oder als Cloud-Aufgabe auf dem GitHub-Repo, statt Schnipsel in ChatGPT einzufügen.
Prüfe, ob der Reviewer sie sehen konnte: Der Berechtigungsdialog muss in seiner Session erscheinen, und die Review-Notizen müssen sagen, wofür die Benachrichtigungen da sind. Ergänze ein zweites sichtbares natives Feature (Offline-Bildschirm, Share Sheet, Face ID) und blende reine Website-Elemente in der App aus.
Richtlinienbedingte Ablehnungen erscheinen in der Play Console unter Richtlinienstatus mit einer Einspruchsoption; bei den meisten Problemen lädst du einfach ein korrigiertes Release hoch. Beschreibe in der Nachricht in der Konsole, was sich geändert hat.
So oft wie nötig; jede Einreichung wird erneut geprüft. Wurdest du dreimal wegen derselben Richtlinie abgelehnt, lies vor der nächsten Einreichung den eigenen Guide dazu, was jetzt zu tun ist.
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.
