Google Play Console Review-Dauer (Wie Lange Dauert Ein Update?)

Wenn du planst, wie lange ein Google-Play-Update bis zur Veröffentlichung braucht, rechne mit einigen Stunden bis wenigen Tagen und plane im schlimmsten Fall sieben Tage ein. Google garantiert keine feste Dauer und nennt als Obergrenze nur sieben Tage oder länger in Ausnahmefällen. Für ein Team bedeutet das: Verlass dich nicht auf eine Freigabe in letzter Minute, sondern reiche früh genug ein und halte einen Puffer bereit. Ein erneuter Upload beschleunigt nichts, sondern setzt die Prüfung zurück und kostet dich deinen Platz in der Warteschlange.

Kurze Antwort

Ein Update über die Standard-Veröffentlichung wird meist in einigen Stunden bis wenigen Tagen geprüft. Eine garantierte Frist gibt es nicht; Google nennt als Obergrenze "sieben Tage oder länger in Ausnahmefällen", laut der Google-Play-Hilfe zu Prüfzeiten. Für die Release-Planung heißt das: früh einreichen, sieben Tage als Puffer einplanen und nicht neu hochladen, um die Uhr nicht zurückzusetzen. Ab sieben Tagen ohne Bewegung ist der Kontakt zum Support angebracht, mit Paketname, Datum und Screenshots.

Wie lange solltest du für ein Update einplanen?

Plane für ein normales Update einige Stunden bis drei Tage ein und halte sieben Tage als Puffer bereit. Der Median liegt oft bei wenigen Stunden für etablierte Konten mit sauberer Historie, aber die Streuung ist groß, und genau diese Unberechenbarkeit ist das eigentliche Planungsproblem. Wer eine Veröffentlichung an ein festes Datum bindet, etwa eine Kampagne oder ein Event, sollte das Update mehrere Tage vorher einreichen und nicht am Tag des Launches.

Wichtig für die Planung ist, dass "geprüft" und "veröffentlicht" nicht dasselbe sind. Nach der Freigabe kann die Ausrollung gestaffelt erfolgen, wenn du eine stufenweise Einführung eingestellt hast, sodass nicht alle Nutzer die neue Version sofort sehen. Rechne diese zusätzliche Zeit in deinen Zeitplan ein, statt sie mit einer laufenden Prüfung zu verwechseln. Für wiederkehrende Releases lohnt es sich, diesen Ablauf einmal sauber zu dokumentieren, damit nicht jedes Team-Mitglied die Wartezeit anders interpretiert.

Update oder erste Veröffentlichung: der Unterschied

Eine erste Veröffentlichung dauert fast immer länger als ein Update, weil Google die App komplett zum ersten Mal bewertet. Bei einem Update prüft das System vor allem, was sich geändert hat; bei einer neuen App werden Berechtigungen, Datensicherheit und Altersfreigabe erstmals beurteilt. Die folgende Tabelle hilft bei der Planung.

Für Agenturen und Teams, die mehrere Apps betreuen, lohnt es sich, diese Richtwerte als Standard in die Release-Planung aufzunehmen, statt bei jedem Release neu zu raten. Ein fester Puffer reduziert Stress und verhindert, dass jemand in letzter Minute aus Ungeduld neu hochlädt und damit alles verzögert. Wer regelmäßig veröffentlicht, kann sich zusätzlich notieren, wie lange die letzten Updates tatsächlich gebraucht haben, um ein realistisches Gefühl für das eigene Konto zu bekommen.

Was macht die Prüfung langsamer und unberechenbar?

Am stärksten wirken das Konto und die Art der Änderung, nicht die Qualität des Codes. Neue oder als bestimmt eingestufte Konten werden gründlicher geprüft, ebenso Updates mit neuen sensiblen Berechtigungen wie Standortzugriff, Zugriff auf Nutzerdaten oder geänderten Deklarationen im Datensicherheitsformular. Auch eine geänderte Zielgruppe oder Altersfreigabe kann eine gründlichere Prüfung auslösen, selbst wenn der Code kaum verändert wurde.

Dazu kommt die Auslastung. In Zeiten mit hohem Aufkommen verlängert sich die Warteschlange für alle, unabhängig von deiner App. Diese Faktoren erklären, warum dasselbe Team ein Update mal in zwei Stunden und mal in zwei Tagen freigegeben bekommt. Für die Planung heißt das: Rechne nicht mit dem besten Fall, sondern mit dem oberen Rand der normalen Spanne, und behandle eine schnelle Freigabe als angenehme Ausnahme statt als Regel. Wer mit einem knappen Zeitplan arbeitet, sollte diese Streuung als das größte Risiko behandeln und den Puffer entsprechend großzügig wählen.

Setzt ein erneuter Upload die Uhr zurück?

Ja, ein neuer Upload derselben Version ersetzt den Build in Prüfung und startet die Prüfung von vorn. Aus Planungssicht ist das der teuerste Fehler, weil du damit den bereits gewonnenen Fortschritt verlierst und dich wieder hinten anstellst. Lade nur dann neu hoch, wenn du wirklich einen Fehler behoben hast, der zu einer Ablehnung geführt hätte.

Der ruhigste Weg ist, das Update in Prüfung zu lassen und innerhalb des normalen Zeitrahmens abzuwarten. Wenn ein Datum drängt, ist ein erneuter Upload fast nie die Lösung, sondern verschlimmert das Timing zusätzlich. Sammle stattdessen mehrere kleine Korrekturen in einem sauberen Build, statt in kurzer Folge mehrere Versionen hochzuladen, die sich gegenseitig zurücksetzen.

Managed Publishing und gestaffelte Einführung einplanen

Managed Publishing und die stufenweise Einführung sind zwei Werkzeuge, mit denen du das Timing selbst steuerst, die aber auch für Verwirrung sorgen. Bei aktiviertem Managed Publishing prüft Google dein Update normal, veröffentlicht es aber erst, wenn du es manuell freigibst. Das ist ideal, um eine Veröffentlichung an ein Datum zu koppeln, bedeutet aber, dass eine geprüfte Version auf deinen Klick wartet und nicht auf Google.

Prüfe deshalb in der Veröffentlichungsübersicht, ob Managed Publishing aktiv ist, bevor du von einem Prüfstau ausgehst, denn die Einstellung gilt kontoweit. Plane außerdem die Zeit für eine gestaffelte Einführung ein: Wenn du mit einem kleinen Prozentsatz startest, erreichst du erst nach mehreren Schritten alle Nutzer, und das ist gewollt, kein Fehler. Wer beides bewusst einsetzt, gewinnt Kontrolle über den genauen Veröffentlichungszeitpunkt, muss diese Schritte aber ehrlich in den Zeitplan einrechnen.

Was tun, wenn es zu lange dauert?

Stelle zuerst fest, wie lange du wartest, und handle danach, statt reflexartig neu hochzuladen. Die folgende Tabelle gibt eine klare Route je nach Situation.

Bevor du eskalierst, prüfe drei Punkte: dass Managed Publishing dich nicht selbst blockiert, dass kein Richtlinienhinweis im Richtlinien-Center steht, und dass du keine neue Version hochgeladen hast, die die Prüfung zurückgesetzt hat. Diese drei Punkte erklären einen großen Teil der Fälle, die wie ein Stau aussehen, aber keiner sind, sondern eine Einstellung oder ein offener Hinweis auf deiner Seite. Wenn du den Support kontaktierst, nenne die Version, das Datum und den Track, damit dein Fall nicht wegen fehlender Angaben liegen bleibt.

Wie du eine berechenbare Release-Kadenz aufbaust

Berechenbarkeit entsteht nicht durch eine schnellere Prüfung, sondern durch bessere Planung um sie herum. Lege einen festen Einreichungspuffer fest, etwa sieben Tage vor jedem geplanten Datum, und behandle diesen Puffer als nicht verhandelbar. Trenne außerdem den technischen Release, also das Hochladen und die Prüfung, klar von der geschäftlichen Veröffentlichung, die du mit Managed Publishing selbst steuerst. So entkoppelst du das Marketing-Datum von Googles Warteschlange und musst nie in letzter Minute hoffen.

Zweitens lohnt sich ein kurzer Vorab-Check jeder Version, bevor sie in die Prüfung geht, damit vermeidbare Ablehnungen den Plan nicht sprengen. Und drittens hilft es, die tatsächliche Dauer der letzten Releases festzuhalten: Nach ein paar Zyklen kennst du die typische Spanne deines Kontos genauer als jede allgemeine Faustregel und kannst deinen Puffer entsprechend anpassen. Diese drei Gewohnheiten, fester Puffer, sauberer Build und eine kurze eigene Statistik, machen aus einer unberechenbaren Prüfung einen planbaren Schritt im Zeitplan. Für Agenturen, die mehrere Kunden betreuen, ist genau diese Planbarkeit oft wertvoller als ein einzelner schneller Release, weil sie Zusagen gegenüber Kunden verlässlich macht und wiederkehrende Konflikte vermeidet.

Vor dem Upload: den Build prüfen

Der sicherste Weg zu einem planbaren Release ist, keinen Prüfzyklus mit einem Update zu verschwenden, das ohnehin abgelehnt wird. Jede Ablehnung wirft dich zurück in die Warteschlange, und ein vermeidbares Problem wie ein eingebetteter geheimer Schlüssel, eine nicht deklarierte Berechtigung oder eine unsichere Netzwerkkonfiguration kann deinen Zeitplan um Tage sprengen, gerade wenn ein Datum feststeht.

Ein Scanner wie PTKD.com analysiert deine fertige .aab oder .apk vor dem Upload und liefert einen nach OWASP MASVS geordneten Bericht, damit du genau das behebst, was eine Ablehnung auslösen würde. Dabei sollte man ehrlich über die Grenze sein: Ein Scanner beschleunigt die Prüfung von Google nicht und ersetzt bei risikoreichen oder regulierten Apps keine manuelle Sicherheitsprüfung. Er reduziert aber die vermeidbaren Ablehnungen, die deine Release-Planung am zuverlässigsten sprengen, und macht deinen Zeitplan dadurch berechenbarer. Das ist kein Ersatz für die Prüfung, aber es beseitigt die eine Ursache für Verzögerungen, die vollständig in deiner Hand liegt, nämlich einen vermeidbaren Ablehnungsgrund im eigenen Build.

Das Wichtigste in Kürze

• Plane für ein Update einige Stunden bis drei Tage ein und halte sieben Tage als Puffer bereit; eine feste Frist gibt es nicht.
• Die erste Veröffentlichung dauert länger als ein Update; neue Konten und neue sensible Berechtigungen erhöhen die Streuung.
• Ein erneuter Upload derselben Version setzt die Prüfung zurück und ist aus Planungssicht der teuerste Fehler.
• Prüfe Managed Publishing und die gestaffelte Einführung, bevor du von einem Stau ausgehst.
• Prüfe den Build vor dem Upload mit PTKD.com, damit eine vermeidbare Ablehnung deinen Zeitplan nicht sprengt.