Der Prototyp läuft, das Team ist begeistert, und der Launch soll in zwei Wochen sein. Genau hier entstehen die meisten Enttäuschungen. Nicht weil OpenAI Codex zu langsam wäre, sondern weil zwischen Prototyp und Store-Freigabe Schritte liegen, die sich kaum beschleunigen lassen: Kontoverifizierungen, Testphasen, Reviews und Abstimmungen. Dieser Ratgeber zeigt einen realistischen Zeitplan für eine App, die gleichzeitig in den App Store und den Play Store soll, und erklärt, welche Aufgaben Sie parallelisieren können.
Warum Codex nur einen Teil beschleunigt
Codex verkürzt vor allem die reine Programmierzeit. Funktionen, Tests, Refactorings und Konfigurationen entstehen in Stunden statt Tagen. Was der Agent nicht beschleunigt, sind externe Abläufe: Die Verifizierung eines Organisationskontos bei Apple oder Google braucht ihre Zeit, die D-U-N-S-Nummer muss vorhanden sein, ein neues privates Play-Console-Konto verlangt einen geschlossenen Test über 14 Tage, und das App Review findet auf der Seite der Stores statt.
Dazu kommen interne Abstimmungen: Datenschutzerklärung, Impressum, Freigaben durch Rechtsabteilung oder Geschäftsführung, Texte für den Store-Eintrag und Grafiken. Diese Punkte sind oft der eigentliche Engpass, weil sie erst spät auf der Liste landen. Wer sie in der ersten Woche anstößt, gewinnt am Ende oft mehr Zeit als durch jede Beschleunigung beim Programmieren. Gleiches gilt für Inhalte wie Hilfetexte, E-Mail-Vorlagen und Support-Prozesse, die zum Launch bereitstehen müssen.
Ein realistischer Phasenplan
Für eine App mittlerer Komplexität mit Konten, Backend und einigen nativen Funktionen hat sich folgende Abfolge bewährt. Die Dauer hängt stark von Umfang und Vorarbeit ab, die Reihenfolge gilt aber fast immer:
- In der ersten Woche klären Sie Technologie, Backend und Kontotypen, beantragen Entwicklerkonten und gegebenenfalls die D-U-N-S-Nummer und richten Repository, AGENTS.md und CI ein.
- In den folgenden zwei bis vier Wochen härten Sie den Prototyp: echte Daten statt Beispielinhalte, Fehlerbehandlung, Kontolöschung, Berechtigungstexte, Barrierefreiheit und ein Sicherheits-Check.
- Parallel dazu entstehen Datenschutzerklärung, Store-Texte, Screenshots und die Liste aller SDKs für Privacy Labels und Data-safety-Formular.
- Danach verteilen Sie Builds über TestFlight und den internen beziehungsweise geschlossenen Test der Play Console und sammeln mindestens zwei Wochen lang Rückmeldungen.
- Zum Schluss reichen Sie bei beiden Stores ein, reagieren auf Rückfragen und planen den Veröffentlichungszeitpunkt, statt automatisch nach der Freigabe live zu gehen.
Was Sie parallelisieren sollten
Der größte Zeitgewinn entsteht, wenn Sie Wartezeiten überlappen lassen. Beantragen Sie Konten am ersten Tag, nicht wenn der Code fertig ist. Starten Sie den geschlossenen Test bei Google, sobald die App stabil genug für echte Nutzer ist, und arbeiten Sie währenddessen weiter. Reichen Sie bei Apple frühzeitig einen Build für externes TestFlight ein, denn auch die Beta-Prüfung deckt bereits Probleme auf.
Mit Codex lässt sich zudem gut parallel arbeiten: Während eine Person Store-Texte abstimmt, bearbeitet der Agent Fehlerberichte aus dem Test, schreibt fehlende Tests oder bereitet Übersetzungen vor. Wichtig ist eine klare Liste offener Punkte, damit nichts doppelt oder gar nicht passiert.
Puffer, die Sie einplanen sollten
Planen Sie für jede Plattform mindestens eine Ablehnung oder Rückfrage ein. Das ist kein Pessimismus, sondern bei Erstveröffentlichungen eher die Regel als die Ausnahme. Berücksichtigen Sie außerdem, dass Apple rund um Feiertage längere Bearbeitungszeiten ankündigt und neue Betriebssystemversionen im Herbst neue Anforderungen mitbringen können. Bei Google kann die Prüfung neuer Apps und neuer Konten länger dauern als bei Updates bestehender Apps.
Ein Marketing-Termin sollte deshalb nie auf den Tag der geplanten Einreichung fallen. Besser ist, die App freigeben zu lassen und dann manuell zum gewünschten Zeitpunkt zu veröffentlichen. Beide Stores bieten dafür eine Option, mit der Sie die Veröffentlichung nach der Freigabe selbst auslösen.
Zeitplan mit Begleitung verkürzen
Die AI Code Engineers von neooutput bringen Codex-Prototypen in beide Stores und kennen die typischen Verzögerungen aus der Praxis. appsubmitter.io übernimmt CI/CD, Signierung, Store-Einträge und Einreichung im eigenen Konto des Kunden, sodass Ihr Team sich auf das Produkt konzentrieren kann. Lassen Sie uns Ihren Zeitplan in einem kostenlosen 15-Minuten-Erstgespräch durchgehen.
Häufige Fragen
Wie lange dauert das App Review bei Apple?
Viele Apps werden innerhalb von ein bis zwei Tagen geprüft. Bei Erstveröffentlichungen, Rückfragen oder komplexen Apps kann es länger dauern, deshalb sollten Sie Puffer einplanen.
Muss ich beide Stores gleichzeitig starten?
Nein. Manche Teams starten bewusst zuerst auf einer Plattform, um Erfahrungen zu sammeln. Ein gleichzeitiger Start ist aber gut machbar, wenn beide Wege früh vorbereitet werden.
Wann sollte ich die Entwicklerkonten beantragen?
So früh wie möglich, idealerweise in der ersten Projektwoche. Verifizierungen und D-U-N-S-Nummer können Tage bis Wochen dauern und blockieren sonst den gesamten Zeitplan.