Mit OpenAI Codex entstehen Apps schneller als je zuvor. Genau das sieht man im App Review: unvollständige Funktionen, Platzhaltertexte, Abstürze beim ersten Start oder Apps, die einander zum Verwechseln ähneln. Apple reagiert darauf mit Ablehnungen nach Guideline 2.1 (App Completeness) und 4.3 (Spam). Dieser Ratgeber erklärt, was hinter beiden Regeln steckt, warum KI-gebaute Apps besonders häufig betroffen sind und wie Sie Ihre Einreichung so vorbereiten, dass sie beim ersten Versuch durchgeht.
Was Guideline 2.1 verlangt
Guideline 2.1 fordert, dass die eingereichte Version vollständig und testbar ist. Abgelehnt werden Apps, die abstürzen, Fehler zeigen, Platzhalter wie Lorem ipsum enthalten, auf tote Links verweisen oder Funktionen bewerben, die nicht erreichbar sind. Ebenfalls unter 2.1 fällt ein fehlender Demo-Zugang: Erfordert die App eine Anmeldung, müssen Sie in App Store Connect funktionierende Zugangsdaten hinterlegen, die alle Funktionen freischalten. Bei Hardware-Abhängigkeiten oder Funktionen, die nur an bestimmten Orten funktionieren, gehört eine Erklärung oder ein Demo-Video in die Review-Notizen.
Auch In-App-Käufe, die im Review nicht gekauft werden können, weil Produkte in App Store Connect fehlen oder nicht zur Prüfung eingereicht wurden, führen zu einer Ablehnung nach 2.1. Reichen Sie die Produkte deshalb gemeinsam mit der App-Version ein und testen Sie Käufe vorher in der Sandbox-Umgebung.
Warum Codex-Apps hier häufig scheitern
Ein Coding-Agent baut, was Sie beauftragen, und lässt oft liegen, was niemand erwähnt hat. Typisch sind Bildschirme mit Beispieldaten, die nie durch echte ersetzt wurden, Einstellungsseiten mit Schaltern ohne Funktion, Fehlerfälle ohne Behandlung bei fehlender Internetverbindung oder Backend-Endpunkte, die nur in der Entwicklungsumgebung existieren. Hinzu kommen Testfunktionen, die versehentlich im Release-Build bleiben.
Das Review-Team testet unter realen Bedingungen, häufig auf aktuellen iPhones und iPads mit der neuesten iOS-Version, teilweise in IPv6-Netzen. Läuft Ihre App nur im Simulator stabil oder setzt sie ein bestimmtes Netzwerk voraus, fällt das dort auf. Testen Sie deshalb ausdrücklich den ersten Start nach einer frischen Installation, ohne vorhandene Daten und mit verweigerten Berechtigungen. Gerade diese Situation übersieht man im Entwicklungsalltag, weil die eigene Testinstallation längst eingerichtet ist.
Guideline 4.3 und der Spam-Verdacht
Guideline 4.3 richtet sich gegen Apps, die anderen Apps im Store stark ähneln oder in einem übersättigten Bereich keinen eigenen Mehrwert bieten. Betroffen sind etwa mehrere fast identische Apps desselben Anbieters, Apps aus Vorlagen mit nur ausgetauschtem Logo oder generische Kategorien wie einfache Taschenlampen, Horoskope oder Chat-Oberflächen für ein Sprachmodell ohne eigene Idee. Weil KI-Werkzeuge sehr ähnlichen Code und sehr ähnliche Oberflächen erzeugen, ist dieses Risiko bei Codex-Apps real.
Wer dieselbe App für mehrere Kunden oder Standorte veröffentlichen möchte, sollte statt vieler Einzel-Apps eine App mit Auswahl oder Konfiguration anbieten. Für maßgeschneiderte Apps im Unternehmenskontext gibt es außerdem die Verteilung als Custom App über Apple Business Manager.
Checkliste vor der Einreichung
Gehen Sie vor jedem Upload diese Punkte durch:
- Sie lassen Codex den Code nach Platzhaltern, TODO-Kommentaren, Debug-Menüs und Testdaten durchsuchen und alle Fundstellen beheben.
- Sie testen den Release-Build über TestFlight auf mindestens einem iPhone und einem iPad, auch im Flugmodus und bei schlechter Verbindung.
- Sie prüfen, ob alle Links, Datenschutzerklärung und Support-Adresse erreichbar sind.
- Sie hinterlegen einen Demo-Zugang mit vollständigen Rechten und beschreiben in den Review-Notizen, wie man zu den Kernfunktionen kommt.
- Sie formulieren für sich in zwei Sätzen, was Ihre App einzigartig macht, und stellen sicher, dass dieser Mehrwert in den ersten Minuten sichtbar wird.
Wenn es doch zur Ablehnung kommt
Eine Ablehnung ist kein Urteil über das Projekt. Lesen Sie die Begründung genau, beantworten Sie Rückfragen im Resolution Center sachlich und mit Belegen und reichen Sie nach der Korrektur erneut ein. Bei 4.3 hilft oft eine nachvollziehbare Erklärung des Alleinstellungsmerkmals, manchmal ist aber eine echte Überarbeitung nötig. appsubmitter.io unterstützt bei Ablehnungen, übernimmt die Review-Kommunikation und prüft Einreichungen vorab mit KI-gestützten Guideline-Checks. Muss die App technisch nachgebessert werden, helfen die AI Code Engineers von neooutput. Ein kostenloses 15-Minuten-Erstgespräch schafft schnell Klarheit.
Häufige Fragen
Wie lange dauert ein erneutes Review nach einer Ablehnung?
Meist ähnlich lange wie das erste Review, häufig ein bis zwei Tage. Bei komplexen Rückfragen oder Einsprüchen kann es länger dauern.
Kann ich gegen eine Ablehnung Einspruch einlegen?
Ja, über das App Review Board. Das lohnt sich, wenn Sie überzeugt sind, dass die Guideline falsch angewendet wurde, und Ihre Argumente gut belegen können.
Hilft TestFlight, Ablehnungen zu vermeiden?
Ja, denn externe TestFlight-Builds durchlaufen bereits eine kurze Beta-Prüfung, und echte Testpersonen finden Abstürze und Lücken. Ein vollständiges App Review ersetzt das aber nicht.