Apple prüft 90 % der Einreichungen in unter einem Tag. Die beschleunigte Prüfung ist nicht das, was die anderen 10 % löst.

Die E-Mail kommt immer in derselben Form. Es sind sechs Tage vergangen, die App steht weiter auf Waiting for Review, der Launch war für morgen geplant, und ob ich nicht jemanden bei Apple anrufen könne.

Kann ich nicht. Kann niemand. Was ich meistens kann, ist herauszufinden, was diese sechs Tage bedeuten, und nach achtzehn Jahren Einreichungen kann ich Ihnen sagen: an der Länge der Schlange liegt es selten.

Dafür gibt es einen Knopf. Apple lässt Sie eine beschleunigte Prüfung beantragen, das kostet nichts, und wenn dem Antrag stattgegeben wird, wirkt er innerhalb von Stunden. Die meisten, die ihn drücken, stecken in einer Lage, bei der er nicht hilft.

Die Zahl, die Apple veröffentlicht, und die darunter

Apple schreibt es klar auf seine App-Review-Seite: „Im Durchschnitt werden 90 % der Einreichungen in weniger als 24 Stunden geprüft."

Die Zahl stimmt. Der Rest ist vermutlich Ihre Gegend. 2025 hat das App-Review-Team mehr als 9,1 Millionen Einreichungen bewertet, rund 25.000 pro Tag, womit das langsame Zehntel bei etwa 900.000 Einreichungen im Jahr liegt, die länger als einen Tag gebraucht haben. Sie sind dort also in großer Gesellschaft, und es kommt darauf an zu wissen, was Sie dorthin gebracht hat.

Ebenso hilfreich ist zu wissen, wie wenig Zeit eine Prüfung kostet. Apple beschrieb den Betrieb ein Jahr zuvor mit knapp 500 spezialisierten Fachleuten, die über 130.000 Apps pro Woche prüfen. Jeff Johnson von Lap Cat Software hat im Mai die Division gemacht: etwa 260 Einreichungen pro Prüfer und Woche, also unter zehn Minuten je Stück. In einer Aussage im Epic-Verfahren bezifferte ein früherer Leiter von App Review die Prüfung einer neuen App auf ungefähr dreizehn Minuten.

Niemand verbringt also sechs Tage damit, Ihre App zu untersuchen. Eine Prüfung sind Minuten an Aufmerksamkeit. Die sechs Tage sind die Zeit, bis jemand sie aufnimmt, oder die Zeit, die Ihre Einreichung auf einem langsameren Weg als der Hauptschlange verbracht hat, und beides hinterlässt Spuren in Ihrem eigenen Dashboard.

Warum eine Einreichung liegen bleibt

Ungefähr in der Reihenfolge, in der mir das begegnet.

• Die erste Einreichung von einem jungen Account ist das Langsamste, was Sie Apple je schicken werden. 2025 hat Apple mehr als 138.000 Entwickleranmeldungen abgelehnt und 193.000 Accounts wegen Betrugsverdacht geschlossen, ein Account ohne Historie hat also ein anderes Risikoprofil als einer mit vierzig ausgelieferten Versionen. Updates einer etablierten App gehen in Stunden durch. Erstenreichungen nicht.
• Manche Kategorien lösen zusätzliche Kontrollen aus: Finanzen, Gesundheit, Kinder, Dating, VPN, Krypto, Glücksspiel und alles mit einer medizinischen Aussage. Apples Review-Seite nennt die Nachweise, die verlangt werden können, darunter die Zulassung medizinischer Hardware, eine Markenfreigabe oder eine Lizenz. Eine Einreichung, die auf ein Dokument wartet, das Apple nicht hat, steht nicht in der Schlange, sie ist geparkt.
• App Review hat Ihnen vielleicht längst geschrieben. Apple gibt an, dass über 40 % der ungelösten Fälle auf Guideline 2.1, App Completeness, entfallen, die Abstürze, Platzhalterinhalte und unvollständige Angaben abdeckt. Die Alltagsvariante ist ein Demo-Account, der nicht mehr funktioniert, oder ein Backend, das Sie nach dem Testen abgeschaltet haben. Diese Art Warten endet in dem Moment, in dem Sie antworten.
• Der Kalender leistet hier einiges. Apple veröffentlicht jeden Dezember einen Hinweis, zeitkritische Einreichungen früh zu schicken, weil die Prüfungen vom 20. bis 26. Dezember länger dauern. Im September kommt das neue OS und alle liefern ihre Kompatibilitäts-Updates in derselben Woche. Und 2026 ist ohnehin ein schweres Jahr für das Volumen: die iOS-Releases lagen im ersten Quartal 80 % über dem Vorjahr, mit fast 560.000 neuen Apps allein im ersten Halbjahr.
• Ein Teil davon ist gar nicht App Review. Verträge, Steuerangaben und Bankdaten liegen außerhalb des Prüfprozesses und blockieren die Auslieferung von sich aus. Eine kostenpflichtige App, deren Paid-Apps-Vertrag nicht unterschrieben ist, kann nicht verkauft werden, ganz gleich, was ein Prüfer entscheidet, und im Dashboard sieht das nach einer Prüfverzögerung aus.
• Ein Teil ist selbst verursacht. Eine Version aus der Prüfung zu nehmen setzt sie auf Developer Rejected, und die Prüfung beginnt von vorn; und alles zu ändern, was außerhalb der kleinen Menge während der Prüfung offener Felder liegt, setzt genau das voraus. Leute tun das an Tag vier und zählen das Warten dann ab Tag eins.

Was eine beschleunigte Prüfung tatsächlich ist

Apple nennt auf seiner App-Review-Seite zwei Fälle. Der eine ist die Behebung eines kritischen Fehlers, wobei Apple darum bittet, „die Schritte zur Reproduktion des Fehlers in der aktuellen Version Ihrer App anzugeben". Der andere ist eine App, die an ein Ereignis gebunden ist, wobei der Antrag „das Ereignis, dessen Datum und den Bezug Ihrer App dazu" enthalten soll. Gestellt wird der Antrag über ein Formular auf der Entwicklerseite, angemeldet, sobald die Einreichung bereits in der Schlange steht.

Er zieht Ihre Einreichung in der Schlange nach vorn. Die Prüfung selbst bleibt dieselbe Prüfung mit demselben Maßstab, nur früher. Eine beschleunigte App wird am Dienstagmorgen für genau das abgelehnt, wofür sie am Freitagnachmittag abgelehnt worden wäre.

Wenn stattgegeben wird, geht es schnell. Die Antwort auf den Antrag kommt meist am selben oder am nächsten Tag, und die Prüfung folgt innerhalb von Stunden nach dieser Antwort. Dieses Tempo ist der ganze Reiz, und es ist der Grund, sorgsam damit umzugehen, wofür Sie es ausgeben.

Lesen Sie Apples Formulierung zum Ereignisfall, sie verrät die Sache. Apple empfiehlt, die Veröffentlichung in App Store Connect zu planen und zu terminieren, und ergänzt erst danach, dass Sie eine Beschleunigung beantragen können, wenn die App noch in Prüfung ist und das Ereignis näher rückt. Apples erste Antwort auf einen Termin ist der Release-Planer. Das Formular kommt an zweiter Stelle.

Wie man einen Antrag schreibt, dem stattgegeben wird

Ein Absatz, konkret, nachprüfbar von jemandem, der Ihr Produkt nie gesehen hat. Für einen Fehler: was kaputt ist, seit welcher Version, für welche Nutzer, die Schritte zur Reproduktion, was der Fix ändert, und eine Zahl, die das Ausmaß zeigt. Eine Absturzrate, die Zahl der Support-Tickets, die Ein-Stern-Bewertungen der letzten 48 Stunden. Für ein Ereignis: das Datum, der Bezug Ihrer App dazu, und warum das Datum nicht verschiebbar ist.

Die Anträge, die scheitern, sind die, deren Dringlichkeit für Sie echt und für Apple unsichtbar ist. Die Kampagne startet Montag. Dem Kunden wurde Freitag zugesagt. Die Investorendemo ist Donnerstag. Wir sind ohnehin spät dran. Jedes davon ist ein reales Problem, und keines ist ein Fehler oder ein Ereignis.

Fragen Sie einmal, über einen Kanal. Ein Formularantrag plus ein Support-Fall plus ein Forumsbeitrag zum selben Build vervielfachen Ihre Chancen nicht, und die Person, die den Antrag liest, sieht alle drei.

Die Grenzen, die Apple nicht aufschreibt

• Es gibt kein veröffentlichtes Kontingent. Apple spricht von außergewöhnlichen Umständen, und jeder Antrag wird für sich beurteilt. Rechnen Sie mit etwa einem pro Jahr, dann liegen Sie nah daran, wie sich der Mechanismus verhält.
• Anträge werden erinnert. Wer oft fragt, dem wird still nicht mehr stattgegeben, ohne Warnung und ohne Mitteilung, und Sie merken es an dem Tag, an dem wirklich etwas kaputt ist und Sie Ihren Antrag für einen Marketingtermin ausgegeben hatten.
• Er macht aus einer Ablehnung keine Freigabe. Findet die beschleunigte Prüfung ein Guideline-Problem, ist der Antrag verbraucht, und Sie korrigieren und reichen erneut ein wie alle anderen. Widersprüche laufen über eine eigene Schiene, das App Review Board, ein Widerspruch je nicht bestandener Einreichung, und Apple bittet darum, offene Informationsanfragen vorher zu beantworten.
• Er erreicht nichts außerhalb von App Review. Eine unbeantwortete 2.1-Nachricht, nicht unterschriebene Verträge, unvollständige Steuer- oder Bankdaten, eine laufende Anmeldung, ein Build, der auf dem Gerät des Prüfers abstürzt. Ein bewilligter Antrag bewegt nichts davon.
• Google Play hat nichts Vergleichbares. Play nennt bis zu sieben Tage für eine Prüfung, in Ausnahmefällen länger, und ein persönlicher Entwickleraccount, der nach dem 13. November 2023 angelegt wurde, muss zusätzlich einen geschlossenen Test mit mindestens 12 durchgehend über 14 Tage angemeldeten Testern führen, bevor er Produktionszugang beantragen kann. Kein Formular kürzt das ab, also lässt es sich nur billig bezahlen, indem man früh anfängt.

Vier Dinge, die besser wirken

Früh einreichen und die Veröffentlichung zurückhalten. Apple lässt Sie eine Version freigeben und dann von Hand oder zu einem gewählten Datum veröffentlichen. Play hat Managed Publishing, das freigegebene Änderungen zurückhält, bis Sie es sagen. Sobald Freigabe und Launch zwei getrennte Ereignisse sind, verlässt die Prüfdauer den kritischen Pfad. Die meisten Beschleunigungsanträge, die ich habe rausgehen sehen, waren die Rechnung für diesen einen ausgelassenen Schritt.

Den Fix so bauen, dass er keine Einreichung braucht. Feature Flags und Remote Configuration legen den Schalter in ein Binary, das Apple bereits geprüft hat, und überlassen Ihrem Server die Stellung. Das ist gewöhnliche Praxis und etwas anderes als das, was Guideline 2.5.2 verbietet, nämlich Code herunterzuladen, der Funktionen einführt oder verändert. Der Haken ist, dass ein Notausschalter in Version 1 ausgeliefert sein muss, nicht in dem Release, auf das Sie gerade warten.

Die App Review Information so ausfüllen, als müsste ein Fremder damit arbeiten, denn genau das passiert, in unter zehn Minuten, auf einem Gerät, das nicht Ihres ist. Ein Demo-Account, der heute funktioniert, das Backend eingeschaltet gelassen, Notizen zu allem, was ein Prüfer nicht erraten würde, ein kurzes Video für einen Ablauf, der Hardware braucht. Guideline 2.1 macht über 40 % der ungelösten Fälle aus und ist die billigste Verzögerung auf dieser Liste, die sich abstellen lässt. Falls Sie schon abgelehnt wurden: über was Apple unter 4.2 und 4.3 ablehnt habe ich separat geschrieben, und es gibt hier eine Seite dazu, eine abgelehnte App doch durchzubekommen.

Oft genug ausliefern, damit kein einzelnes Release alles trägt. Liegen zwischen Ihren Releases zwei Wochen, ist eine zweitägige Prüfung Rauschen. Liefern Sie zweimal im Jahr, trägt jede Einreichung ein Viertel der Roadmap und jede Prüfung ist ein Notfall. Es ist dasselbe Kadenz-Argument wie in meinem Text über frühes Veröffentlichen, und es gilt für Prüfzeiten so direkt wie für das Ranking.

Es gibt ein fünftes, das keine Prüfung verkürzt und das eigentliche Problem trotzdem öfter löst, als man denkt. Bis zu 100 Personen aus Ihrem eigenen Team können einen TestFlight-Build wenige Minuten nach dem Upload installieren, ganz ohne Prüfung. Externe Tester brauchen für den ersten Build einer Version die Beta App Review, eine eigene und kürzere Schlange. Wenn Sie heute Nachmittag echte Menschen brauchen, die den Fix benutzen, führt dieser Weg am Store vorbei.

Der eine Fall, in dem ich nicht zögern würde

Datenverlust. Absturz beim Start. Eine Sicherheitslücke. Zahlungen, die Geld nehmen und nichts liefern. Alles, wo jede Stunde die Nutzer etwas kostet, das sie nicht zurückbekommen. Dafür wurde der Mechanismus gebaut, der Antrag schreibt sich von selbst, und ich würde ihn innerhalb einer Stunde abschicken.

Ich würde außerdem damit rechnen, dass er abgelehnt wird, und alles andere parallel tun: eine serverseitige Abmilderung, wenn die App die Leitungen dafür hat, eine Notiz dort, wo Ihre Nutzer sich ohnehin schon beschweren, und den Fix in der normalen Schlange, damit er so oder so vorankommt.

Das Warten ist ein Planungsproblem

Die beschleunigte Prüfung ist ein Gefallen mit Gedächtnis. Sie ist etwa einen guten Notfall pro Jahr wert, und sie ändert, wann Ihre App geprüft wird, nicht wie.

Die Teams, die nie auf Apple zu warten scheinen, sind nicht die mit einem Kontakt im Haus. Es sind die, die zwei Wochen vor dem Datum eingereicht haben, das ihnen wichtig war, und die eine kaputte Funktion vom eigenen Server abschalten können, während der Fix die gewöhnliche Schlange durchläuft wie die aller anderen.