Logo der YuSMP Group
YuSMP Group Editorial Team Redaktion, YuSMP Group
Isometrische Illustration: App-Kacheln auf einem langen Förderband warten vor einer einzelnen Prüfkabine mit einem Timer darüber

Das Wichtigste in Kürze

Die Dauer des App-Store-Reviews ist unberechenbar geworden: Entwickler berichten von Apps und Updates, die drei Wochen oder fast einen Monat warten, obwohl Apple im Schnitt 1,5 Tage angibt. Jedes Team, dessen Launch, Kundendemo oder Hotfix von der Freigabe abhängt, sollte einen Review-Puffer in seine iOS-Entwicklung und Release-Planung einbauen, statt mit 48 Stunden zu rechnen.

Was berichten Entwickler?

The Register verwies am 22. Oktober auf eine Reihe von Threads in den Apple Developer Forums mit Titeln wie „Unusually long Apple ‘waiting for review’ time“ und „Stuck in ‘Waiting for Review’ since October 8“. Ein Entwickler, D1 Tech, gab an, seit dem 19. September zu warten. Ein Reddit-Beitrag beschrieb eine Wartezeit von fast einem Monat. Viele der verzögerten Builds waren keine neuen Apps, sondern Bugfixes für bereits freigegebene Apps.

Zwei Tage zuvor hatte mobilegamer.biz ähnliche Berichte von Spielestudios gesammelt. Ein Studiochef sagte, fünf seiner Apps warteten seit über einer Woche auf das Review; ein anderer Entwickler erklärte, Reviews dauerten selbst beschleunigt oft drei bis fünf Tage, mit häufig vagem Feedback. Auch Tracker von Drittanbietern wie das Review-Times-Dashboard von Runway zeigen steigende Durchschnittswerte.

Was sagt Apple zur Prüfdauer?

Apples veröffentlichte Hinweise besagen weiterhin, dass App Review „in der Regel“ mindestens 50 % der Einreichungen in unter 24 Stunden und 90 % in unter 48 Stunden bearbeitet. In einer Stellungnahme gegenüber mobilegamer.biz nannte Apple eine durchschnittliche Prüfdauer von 1,5 Tagen für alle Apps und 14 Stunden für kleinere Updates; manche neuen Apps bräuchten länger, wenn sie zusätzlich geprüft werden müssen. In den letzten 12 Wochen habe das App-Review-Team im Schnitt 378.000 Einreichungen pro Woche bearbeitet, und man entwickle den Prozess weiter, „um dieses Wachstum zu unterstützen“. Laut The Register hatte Apple bis zur Veröffentlichung nicht auf dessen Anfrage reagiert.

Beides kann zugleich stimmen. Ein Durchschnitt von 1,5 Tagen verdeckt einen langen Ausläufer, und genau dort rutscht ein Launch. Der typische Entwickler merkt vielleicht kaum etwas, während eine Minderheit wochenlang wartet – genau die Unsicherheit, an der Release-Termine scheitern.

Warum staut sich die Review-Warteschlange?

Apple nennt keine Ursache, doch die Mengenentwicklung ist gut belegt. Im April berichtete The Information, von 9to5Mac aufgegriffen, von 84 % mehr neuen Apps im App Store gegenüber dem Vorjahr, weil KI-Coding-Tools die Kosten für eine App senken. Business Insider hatte bereits im März auf die Welle KI-programmierter Apps hingewiesen. Mehr Einreichungen mit geringem Aufwand bedeuten mehr Apps, die genauer geprüft werden müssen, und Apple hat zudem seine Regeln verschärft: Am 16. Oktober kam Richtlinie 2.5.19 hinzu, die versteckte oder schlafende Funktionen verbietet, die nach der Freigabe zugeschaltet werden.

Das Timing erhöht den Druck. Das iPhone Duo kam am 23. Oktober mit iOS 27.1 in den Handel, Xcode 27.1 brachte SDKs und Simulator für das faltbare Layout. Teams, die schnell Duo-optimierte Builds ausliefern wollen, stehen in derselben Warteschlange wie die Flut neuer Einreichungen.

Was das für Softwareteams in den USA und der EU bedeutet

Für Unternehmen, die Apps verkaufen oder von ihnen abhängen, ist App Review vom Verwaltungsschritt zum Terminrisiko geworden. Am stärksten betroffen sind drei Bereiche: Launches, die an einen Marketingtermin oder einen Kundenvertrag gebunden sind, Hotfixes für Produktionsvorfälle und regulierte Apps in FinTech oder HealthTech, bei denen ein Sicherheits- oder Compliance-Fix nicht drei Wochen warten kann.

Die größte Lücke ist das Timing von Hotfixes. Bricht ein Zahlungsablauf oder taucht ein Fehler im Umgang mit Daten auf, erreicht die Korrektur die Nutzer erst nach Apples Freigabe, und das beschleunigte Review liegt in Apples Ermessen. Damit gewinnen serverseitige Gegenmaßnahmen an Wert, etwa das Abschalten eines defekten Ablaufs, der im geprüften Build bereits enthalten ist – solange sie im Rahmen dessen bleiben, was App Review gesehen hat. Neue Funktionen nach der Freigabe zu aktivieren, verbietet Richtlinie 2.5.19 inzwischen ausdrücklich.

Teams in der EU haben mit alternativen App-Marktplätzen und dem Web-Vertrieb nach dem Digital Markets Act eine teilweise Alternative, doch auch diese Apps durchlaufen Apples Notarisierung und sind damit kein sauberer Umweg. Verträge mit App-Entwicklungsdienstleistern sollten zudem keine festen Store-Termine mehr versprechen, sondern die Lieferung als „Build eingereicht und Vorprüfungen bestanden“ definieren.

Was bedeutet das für App-Teams im DACH-Raum?

Im DACH-Markt trifft der Stau vor allem Banken-, Versicherungs- und Mobilitäts-Apps, bei denen Nutzer Fehler sofort bemerken. Für Finanzunternehmen kommt der regulatorische Rahmen hinzu: Seit Januar 2025 verlangt die EU-Verordnung DORA ein belastbares IKT-Risikomanagement, das die BaFin in Deutschland beaufsichtigt. Ein Sicherheits-Hotfix, der wochenlang im Review hängt, gehört deshalb in die Notfall- und Wiederherstellungsplanung – mit dokumentierten serverseitigen Abschaltmöglichkeiten statt der Annahme, Apple gebe in 48 Stunden frei.

In Deutschland und Österreich bleibt der DMA-Vertrieb über alternative Marktplätze eine Option, die aber ebenfalls Apples Notarisierung durchläuft. In der Schweiz gilt der DMA nicht; dort bleibt der App Store der einzige Weg zu iPhone-Nutzern. Für Agenturen und Mittelständler, die Kunden-Apps mit festen Abnahmeterminen ausliefern, heißt das praktisch: Abnahme und Store-Freigabe im Werkvertrag trennen und den Review-Puffer schon im Projektplan ausweisen.

So planen Sie iOS-Releases bei langsamerem Review

  1. Review-Puffer einplanen. Planen Sie ein bis zwei Wochen zwischen Einreichung und jedem öffentlichen Launch oder Kundentermin ein und erfassen Sie die tatsächliche Prüfdauer je Release.
  2. Launch von der Freigabe entkoppeln. Reichen Sie früh ein und nutzen Sie die manuelle Veröffentlichung, damit ein freigegebener Build auf Ihren Termin wartet und nicht Ihr Termin auf die Freigabe.
  3. Beim ersten Mal richtig machen. Arbeiten Sie vor der Einreichung eine Checkliste für Metadaten, Datenschutzangaben, Demo-Zugangsdaten und Review-Notizen ab; jede Ablehnung startet die Wartezeit neu.
  4. Kill Switch statt Feature Switch. Bauen Sie serverseitige Möglichkeiten ein, riskante Abläufe im geprüften Build abzuschalten, und nutzen Sie Flags nicht, um ungeprüfte Funktionen freizuschalten.
  5. Beschleunigtes Review aufsparen. Nutzen Sie es nur für echte kritische Fixes, damit Anträge glaubwürdig bleiben, und rechnen Sie mit Tagen statt Stunden.
  6. TestFlight und stufenweisen Rollout nutzen. Validieren Sie Builds vor der Einreichung mit externen Testern und rollen Sie riskante Updates nach der Freigabe schrittweise aus.

Häufige Fragen

Wie lange dauert das App-Store-Review im Oktober 2026?

Apple sagte gegenüber mobilegamer.biz, die durchschnittliche Prüfdauer liege bei 1,5 Tagen für alle Apps und 14 Stunden für kleinere Updates; manche neuen Apps brauchen länger, wenn sie genauer geprüft werden. Gleichzeitig berichten Entwickler in Apples Foren und auf Reddit von einzelnen Einreichungen, die drei Wochen oder fast einen Monat in „Waiting for Review“ hängen.

Warum dauert das App-Store-Review länger?

Apple nennt keinen Grund. Laut Apple hat das App-Review-Team in den letzten 12 Wochen im Schnitt 378.000 Einreichungen pro Woche bearbeitet und entwickelt den Prozess weiter, um dieses Wachstum zu bewältigen. Anfang 2026 berichtete The Information von einem Plus von 84 % bei neuen Apps gegenüber dem Vorjahr, was die Berichterstattung mit KI-Coding-Tools in Verbindung bringt.

Kann man ein App-Store-Review beschleunigen?

Apple erlaubt einen Antrag auf beschleunigtes Review (Expedited Review) für kritische Bugfixes oder zeitkritische Ereignisse, entscheidet aber im Einzelfall; Entwickler berichten, dass auch beschleunigte Reviews mehrere Tage dauern können. Verlässlicher ist die Planung: früher einreichen, Builds klein halten und unnötige Neueinreichungen vermeiden, weil jeder neue Build eine eigene Wartezeit startet.

Sollten DACH-Teams ihren Release-Prozess wegen der Verzögerungen ändern?

Ja, wenn ein Termin von der Freigabe abhängt. Planen Sie ein bis zwei Wochen Review-Puffer ein, entkoppeln Sie Marketingtermine von der Einreichung, reichen Sie Hotfix-Kandidaten früh ein, nutzen Sie den stufenweisen Rollout für riskante Updates und halten Sie serverseitige Konfiguration im Rahmen dessen, was App Review gesehen hat, denn Richtlinie 2.5.19 verbietet nach der Freigabe zugeschaltete Funktionen. Bei Finanz-Apps gehört die Review-Dauer zudem ins IKT-Risikomanagement nach DORA.

Quellen

The Register — Apple App Store review process hits a traffic jam (October 22, 2026)
mobilegamer.biz — App Store review times are being dragged down by a flood of AI-made apps and games (October 20, 2026)
9to5Mac — App Store sees 84% surge in new apps as AI coding tools take off (April 6, 2026)
Apple Developer — App Review