Gründer fragen danach, als gäbe es eine feste Zahl. Die gibt es nicht. Apple und Google prüfen Apps; keiner der beiden Anbieter verspricht eine Frist. Beide veröffentlichen einen typischen Zeitraum, den viele dann wie eine vertragliche Zusage behandeln. Ich veröffentliche vier Consumer-Apps in beiden Stores – Luna, Smart Clip, Routina und Callendar – deshalb beschreibe ich hier die Planung, mit der ich 2026 tatsächlich arbeite, und keine aus dem Netz zusammengetragene Grafik zu „durchschnittlichen Prüfzeiten“.
Realistische Zeitspannen, keine Versprechen
Das sind Richtwerte für die Planung. Ein konkreter Build kann schneller oder langsamer geprüft werden. Plane einen Zeitpuffer ein, keine feste Frist.
- Apple, normales Update einer veröffentlichten App: oft 24 bis 48 Stunden. Viele Updates werden innerhalb eines Tages freigegeben. Damit plane ich bei Fehlerbehebungen oder kleinen Funktionen auf einem Apple bereits bekannten Konto.
- Apple, erste Einreichung oder umfangreiche Änderung: Ich plane zwei bis fünf Tage Puffer ein, bei sensiblen Funktionen mehr. Apples Hilfeseite zum Prüfstatus nennt als Prüfziele 50 % innerhalb von 24 Stunden und 90 % innerhalb von 48 Stunden. Das sind Gesamtwerte, keine Frist für deine App.
- Google Play, etablierte App und Produktionsupdate: oft einige Stunden bis ein paar Tage. Google schreibt weiterhin: „einige Stunden bis zu sieben Tage, in Ausnahmefällen länger“. Wichtige Play-Releases reiche ich Tage, nicht Stunden vorher ein.
- Erste Veröffentlichung bei persönlichen Google-Play-Konten, die nach dem 13. November 2023 erstellt wurden: Laut den offiziellen Testanforderungen müssen mindestens 12 angemeldete Tester 14 Tage in Folge teilnehmen. Danach ist ein Antrag auf Produktionszugang erforderlich. Google zufolge dauert dessen Prüfung normalerweise höchstens sieben Tage, manchmal länger. Sie ist getrennt von der Prüfung des Releases.
Stand: 8. Oktober 2026. Apples allgemeine Seite zur App-Prüfung nennt eine andere Gesamtstatistik: 90 % in weniger als 24 Stunden. Die beiden offiziellen Seiten beschreiben unterschiedliche Zielwerte. Keiner davon garantiert die Prüfung einer einzelnen App. Maßgeblich ist der Status in App Store Connect; plane einen Puffer ein.
Der Release für beide Stores dauert so lange wie der langsamere Store
Muss das Produkt am selben Morgen in beiden Stores erscheinen, gilt weder der Apple- noch der Play-Median. Entscheidend ist, welcher Store zuletzt freigibt – zuzüglich der Zeit für eine Ablehnung, die du einkalkulieren solltest.
So plane ich den Ablauf:
- Erstelle den Build, sobald das Produkt wirklich fertig ist. Nicht, sobald die Landingpage fertig ist. Die Store-Prüfung testet deine Website nicht.
- Reiche zuerst bei Apple ein, wenn die Änderung richtlinienrelevant ist. Kinder, Tastaturen, Hintergrundmodi, „es klingelt wie ein Telefonanruf“: Apple diskutiert über das Produkt, nicht nur über den Eintrag.
- Reiche bei Play mit Zeitpuffer ein, nicht auf gut Glück. Ein normales Update geht oft schnell. Änderungen an Richtlinienerklärungen, Zielgruppe oder neuen Berechtigungen können länger dauern.
- Plane bei der ersten Version eine Ablehnung ein. Eine Ablehnung bedeutet einen vollständigen weiteren Prüfzyklus, keine Freigabe am selben Tag. Gibt es einen externen Starttermin, brauchst du Puffer für zwei statt für einen Zyklus.
Was die Prüfung tatsächlich verzögert
Nicht, weil der Reviewer einen schlechten Tag hat. Es sind jedes Jahr dieselben vier Punkte:
- Die App richtet sich an Kinder. Luna ist eine Gute-Nacht-Geschichten-App für Kinder von ungefähr zwei bis neun Jahren. Kinderkategorie, Datenschutz nach COPPA und generierte Texte: Apple prüft hier Inhalte und Sicherheit, nicht nur die Binärdatei. Plane mehr Zeit ein als für das Update einer Wetter-App.
- Die App kann mitlesen, was du tippst. Smart Clip ist eine KI-Tastatur und ein Schreibwerkzeug im Teilen-Menü. „Full Access“ unter iOS wirft Vertrauensfragen auf. Datenschutzhinweise, Aussagen dazu, dass keine Daten verkauft werden, und ein sachliches Demovideo sind hier wichtiger als ein neues Symbol.
- Die App soll bei Angst oder Aufmerksamkeit helfen. Routina ist eine Checkliste für Menschen mit ADHS, die das Haus verlassen: Schloss, Gas, Schlüssel – alles abgehakt. Sie ist kein Medizinprodukt. Der Store-Eintrag muss diese Grenze einhalten. Gesundheitsnahe Formulierungen können ein 24-Stunden-Update zu einer Woche machen.
- Die App macht etwas, das das Betriebssystem bereits kann – nur auffälliger. Callendar löst einen Meeting-Alarm aus, der sich wie ein Telefonanruf verhält, auch bei „Lautlos“ und „Fokus“. Was den Modus „Nicht stören“ zu umgehen scheint, wird von einem Menschen geprüft.
Die Wahl des Frameworks ist fast nie der Grund für eine langsame Prüfung. Nativ vs. Flutter vs. React Native verändert den Build, nicht den Reviewer.
So lief es bei den vier Apps
Ich erfinde keine Stundenzahlen für einzelne Builds. Prüfzeiten sind keine Rangliste, und ein glücklicher Einzelfall lehrt dich das Falsche. Das Muster aus der Veröffentlichung dieser vier Apps:
- Luna – lunastorytelling.kids. Der erste Store-Eintrag für Kinder dauerte am längsten. Spätere Updates für die Story-Engine und Lokalisierung liefen wie normale Updates, solange Altersfreigabe, Datenschutzangaben und Informationen zu generierten Inhalten mit Apples bisheriger Freigabe übereinstimmten.
- Smart Clip – smart-clip-app.com. Tastatur und Schreibwerkzeug in 30 Sprachen. Bei der Prüfung geht es um Berechtigungen und Datenschutz, meist nicht um die Codeänderung.
- Routina – routina-app.com. Checkliste, haptisches Feedback und Fotos auf dem Gerät. Updates, die nur Texte und Tippaktionen ändern, werden wie bei einem Dienstprogramm geprüft. Alles, was nach Behandlung klingt, nicht.
- Callendar – callendarmeetings.com. Klingelnde Kalenderalarme. In den Prüfhinweisen zur ersten Version musste der Alarm auf einem Gerät vorgeführt werden. Danach verliefen kleinere Korrekturen an der Kalendersynchronisierung ohne besondere Vorkommnisse.
Bei denselben vier Apps waren routinemäßige Produktionsupdates auf Play schneller. Einmal dauerte es länger, weil ein Store-Eintrag oder Fragebogen nicht aktuell war. Der Build war in Ordnung. Das Formular nicht.
So planst du einen Termin, den du einhalten kannst
- Kündige keinen Store-Starttermin an, bevor der erste Build geprüft wird. Landingpages können online gehen. Presseankündigungen sollten warten.
- Halte einen zweiten, kleineren Build bereit. Lehnt Apple eine Formulierung ab, kannst du ihn noch am selben Nachmittag erneut einreichen, statt einen neuen Sprint abzuwarten.
- Schreibe die Prüfhinweise wie ein Demodrehbuch. „Tippe hier, dann hier; du siehst X.“ Reviewer sind nicht deine Nutzer.
- Stimme die Datenschutzangaben auf den Build ab. Mit einer Tastaturaktualisierung und den Datenschutzangaben vom Vorjahr kaufst du dir eine zusätzliche Woche.
- Starte bei einem neuen Play-Konto den geschlossenen Test mit 12 Testern, sobald ein absturzfreier Build bereitsteht. Die 14 Tage laufen unabhängig davon, ob deine Website fertig ist.
Die Frage an einen Anbieter
Frag nicht: „Weißt du, wie lange die Prüfung dauert?“ Alle werden 24 Stunden sagen.
Frag stattdessen: „Wann reichst du den Build im Verhältnis zu dem Termin ein, den wir dem Vorstand genannt haben, und was passiert, wenn Apple ihn einmal ablehnt?“ An der Antwort erkennst du, ob der Anbieter 2026 schon eine App in einem Store veröffentlicht hat oder einen Blogbeitrag von 2022 zitiert.
Wenn du für deine App einen Umsetzungssprint mit vereinbartem Umfang benötigst, vereinbaren wir Umfang, Zeitplan und Preis vor Beginn. Der vereinbarte Umfang kann die Vorbereitung für beide App-Stores einschließen. Die externe Prüfung liegt außerhalb dieses Zeitplans; Apple und Google bestimmen ihre Dauer.