Wie lange das App-Store-Review dauert

Apple veröffentlicht eine Zahl: 90 % der Einreichungen werden in weniger als 24 Stunden geprüft.

Google veröffentlicht eine Spanne: ein paar Stunden bis zu sieben Tage, in Ausnahmefällen länger — und empfiehlt, mindestens eine Woche Puffer zwischen Einreichung und Go-live einzuplanen.

Diese Lücke erklärt die meisten Fehler in der Release-Planung. Leute planen nach Apples Zahl und werden von Googles erwischt.

Was die Status tatsächlich bedeuten

Apples eigene Definitionen, die präziser sind, als irgendwer sie benutzt:

Status	Was er bedeutet
Prepare for Submission	Du hast einen App-Datensatz und füllst ihn noch aus
Ready for Review	Du hast die Metadaten eingetragen und erklärt, dass du einreichen willst. Eingereicht hast du nicht.
Waiting for Review	Apple hat deine Einreichung, aber noch nicht begonnen
In Review	Jemand sieht sie sich an. Du kannst den Build noch zurückziehen
Metadata Rejected	Der Build ist in Ordnung. Etwas im Listing nicht
Rejected	Die Einreichung ist durchgefallen
Accepted	Dieses Element ist durch, aber etwas anderes in derselben Einreichung nicht. Nichts wird veröffentlicht, bevor alles durch ist
Pending Developer Release	Freigegeben. Wartet darauf, dass du den Knopf drückst
Processing for Distribution	Freigegeben und veröffentlicht. Live innerhalb von 24 Stunden
Pending Apple Release	Zurückgehalten, bis die passende OS-Version öffentlich erscheint
Ready for Distribution	Live

Zwei davon stiften die meiste Verwirrung. Ready for Review ist nicht eingereicht. Und Accepted heißt nicht veröffentlicht: Hast du eine App-Version zusammen mit anderen Elementen eingereicht und eines davon ist durchgefallen, warten die angenommenen Teile.

Wann es länger dauert

Apple dokumentiert genau eine Ursache: unvollständige Einreichungen. In eigenen Worten: Ist deine Einreichung unvollständig, können sich die Prüfzeiten verzögern oder die Einreichung fällt durch. Über 40 % der ungelösten Probleme stammen aus Guideline 2.1, App Completeness.

Darüber hinaus nennt Apple Kategorien, die mehr Prüftiefe bekommen — nicht mehr Zeit. Medizin-Apps, die ungenaue Daten liefern oder zur Diagnose genutzt werden könnten, werden genauer geprüft. Gesundheitsforschungs-Apps brauchen die Zustimmung einer Ethikkommission. Apps aus Banking, Gesundheitswesen, Glücksspiel, Cannabis, Luftfahrt und Krypto-Börsen sollen von der juristischen Person eingereicht werden, die den Dienst anbietet, nicht von einer einzelnen Entwicklerin.

Eine strukturelle Grenze, um die man planen sollte: Du kannst pro Plattform eine App-Version gleichzeitig im Review haben, und maximal zwei Einreichungen gleichzeitig. Seit Oktober 2025 lassen sich andere Elemente unabhängig schicken — ein kritischer Bugfix muss also nicht mehr hinter einer Custom Product Page warten, die noch geprüft wird.

Expedited Review

Apple hat es. Google veröffentlicht nichts Vergleichbares.

Apple gewährt Expedited Review bei mildernden Umständen und nennt zwei: einen kritischen Bug beheben, oder ein Release passend zu einem Event, mit dem du direkt verbunden bist.

Was laut Apple hineingehört:

• Bugfix: Schritte zum Reproduzieren des Bugs in der aktuell live stehenden Version. Keine Beschreibung des Fixes. Die Reproduktion.
• Event: das Event, sein Datum und die Verbindung deiner App dazu.

Apple sagt auch, dass für ein Event die bessere Antwort ist, das Release in App Store Connect zu terminieren, statt gegen das Review zu rennen. Das sollte man ernst nehmen: Terminieren kostet nichts, Expedited Review kostet Goodwill.

Wirst du abgelehnt und glaubst, der Reviewer hat deine App falsch verstanden, gibt es einen eigenen Weg: eine Beschwerde beim App Review Board. Eine pro gescheiterter Einreichung — und beantworte offene Rückfragen zuerst.

Vier Dinge, die Leute glauben und kein Store dokumentiert

Alle vier werden als Fakt weitergegeben, auch von Leuten, die es besser wissen sollten.

"Erneutes Einreichen stellt dich hinten in der Warteschlange an." Bei Google stimmt das, und Google sagt es unmissverständlich: Die Bearbeitungszeit zählt ab der zuletzt eingereichten Änderung, und deine App kann ans Ende der Review-Queue rutschen. Apple dokumentiert nichts dergleichen. Die nächstliegende Apple-Aussage ist, dass Einreichungen nicht zwingend in der Reihenfolge geprüft werden, in der du sie einreichst.

"Reine Metadaten-Updates gehen schneller." Apple veröffentlicht keine solche Aussage — und es gibt kaum etwas, das schneller gehen könnte. Die meisten Listing-Änderungen brauchen eine neue Version, die einen Build braucht. Die dokumentierten Ausnahmen sind Werbetext, den du jederzeit ändern kannst, dazu Support-URL, Marketing-URL, Review-Informationen und Release Notes. Alles andere wartet auf eine Version.

"Neue Accounts und Erstsubmissions sind langsamer." Nirgends von Apple dokumentiert. Es mag stimmen. Apple hat es nie gesagt.

"TestFlight-Review geht schneller." Externe TestFlight-Builds durchlaufen tatsächlich ein eigenes Beta App Review, mit eigenen Status und eigener Queue. Apple veröffentlicht dafür keine Zeiten und keinen Vergleich zum App-Store-Review.

Wenn du einen Launch planst, plane nach dem, was dokumentiert ist — und behandle den Rest als Folklore.

Die Feiertagsfrage

Apple hat früher geschlossen. Die letzte tatsächliche Schließung war im Dezember 2020.

Seitdem bleibt Apple offen und veröffentlicht stattdessen Anfang Dezember eine Warnung. Die letzte war am 2. Dezember 2024: Einreichungen werden durchgängig angenommen, zeitkritische Arbeit früh einreichen, vom 20. bis 26. Dezember kann die Prüfung länger dauern. 2025 hat Apple keinen solchen Hinweis veröffentlicht.

Die ehrliche Empfehlung lautet also: Es gibt keine Schließung mehr, um die man planen müsste — aber der Dezember bleibt der schlechteste Monat, um ein Release bis zur letzten Woche liegen zu lassen.

Googles eigenes Tor

Play hat eine Verzögerung, die Apple nicht hat — und sie trifft genau die Leute, die am wenigsten damit rechnen.

Persönliche Play-Console-Accounts, die nach dem 13. November 2023 angelegt wurden, müssen einen geschlossenen Test mit mindestens 12 Testern, durchgehend 14 Tage lang angemeldet, fahren, bevor sie Produktionszugang beantragen können. Dieser Antrag wird eigenständig geprüft, meist innerhalb von sieben Tagen.

Für eine Solo-Entwicklerin beim ersten Mal sind das zwei Wochen Testen plus eine Woche Prüfung, bevor die normale Review-Uhr überhaupt losläuft. Googles eigene Pre-Review-Checks helfen, Probleme vorab zu finden, und sind meist in einer Viertelstunde durch — der einzige Teil des Play-Ablaufs, der schnell ist.

Planungszahlen, die man wirklich benutzen kann

• Apple, Routine-Update: rechne mit einem Tag, plane drei.
• Apple, Erstsubmission: dieselbe Prüfzeit, aber kalkuliere Tage für die Dinge ein, die vorher an 2.1 scheitern.
• Google, etablierter Account: plane eine Woche.
• Google, neuer persönlicher Account, erste App: plane einen Monat, bevor irgendetwas live gehen kann.
• Alles, was an ein Datum gebunden ist: terminiere das Release, statt es zu beschleunigen, und reiche mindestens zwei Wochen vorher ein.

Was Uprate damit macht

Der Submission-Agent fängt die Blocker ab und gibt dir das exakte Feld und die Lösung, bevor du einreichst. Das schnellste Review ist das, das du nicht zweimal machen musst.

Nichts geht live, bevor du es freigibst.