Dauer des App-Store-Reviews: 64 echte Entscheidungen, Median 73 Stunden

Kurz gesagt: Ich habe jede E-Mail mit einer App-Review-Entscheidung ausgewertet, die mein Entwickler-Account je bekommen hat: 64 Entscheidungen zu 21 iPhone-Apps, vom 10. September bis 12. Oktober 2026, jeweils mit Apples eigenem "Submitted"-Zeitstempel und dem Zeitpunkt, zu dem die Entscheidung eintraf. Die mittlere Wartezeit (Median) lag bei 73 Stunden. Apple schreibt auf seiner Seite, man prüfe "at least 50% of submissions in less than 24 hours and 90% in less than 48 hours" (mindestens 50 % der Einreichungen in unter 24 Stunden und 90 % in unter 48 Stunden). Bei mir: 19 % innerhalb von 24 Stunden, 27 % innerhalb von 48. Updates für Apps, die schon im Store waren, brauchten im Median 64 Stunden, reine In-App-Käufe 12, und 0 von 21 neuen Apps wurden bei der ersten Einreichung freigegeben.

Die kurze Antwort für alle, die danach suchen: Wenn du 2026 einen Launch planst, rechne mit 3 Tagen pro Review-Runde für ein Update, 2 bis 5 Tagen bis zur Freigabe einer brandneuen App und mindestens einer zusätzlichen Runde für eine neue App auf einem neuen Account, weil die erste meist mit einer Rückfrage zurückkommt. Ein Review, das eine Woche lang liegt, ist keine langsame Freigabe. In meinen Daten endete jede Wartezeit über 5,1 Tagen bis auf eine mit einer Ablehnung wegen Spam nach Guideline 4.3.

Wenn du noch in der Phase "Was kostet mich das?" steckst, rechnet dir der kostenlose Kostenrechner für iPhone-Apps Features in Stunden und Dollar um. In diesem Artikel geht es um den Teil, den kein Rechner zeigt: die Kalenderzeit zwischen "Submit" und "Ready for Distribution". Ich baue diese Apps auf einem Windows-PC ohne Mac (hier ist die Pipeline), daher ging jede Einreichung unten aus einem CI-Job oder über die Website von App Store Connect raus, nie aus Xcode.

Wie lange dauert das App-Store-Review 2026?

Hier sind die Zahlen, aufgeteilt so, wie du ihnen tatsächlich begegnen wirst. "Wartezeit" ist die Zeit von der Zeile "Submitted" in Apples E-Mail bis zum Eintreffen der Entscheidungsmail. Sie enthält also die Warteschlange, nicht nur die Minuten, die ein Reviewer mit der App verbracht hat.

Was du einreichst	Entscheidungen	Median Wartezeit	Schnellste	Langsamste	Freigegeben
Nur In-App-Käufe	5	12,2 h	11,7 h	13,4 h	5 von 5
Update einer Live-App	16	64,4 h	6,3 h	203,6 h	11 von 16
Neue App (normale Runden)	21	51,2 h	3,1 h	120,5 h	8 von 21
Neue App (die beiden 4.3-Spam-Batches)	22	187,8 h	167,7 h	223,3 h	0 von 22
Alle	64	73,1 h	3,1 h	223,3 h	24 von 64

Zwei Dinge fallen sofort auf. Ablehnungen und Rückfragen zu neuen Apps kommen schnell zurück (die 13 normalen hatten einen Median von 27,8 Stunden), weil der Reviewer beim ersten Problem aufhört. Freigaben dauern länger: Die 8 Freigaben von Erstversionen hatten einen Median von 69,9 Stunden, und keine kam innerhalb von 48 Stunden. Eine schnelle Antwort ist statistisch gesehen also eine schlechte Nachricht.

Das Experiment: ein Zeitstempel-Paar pro E-Mail

App Store Connect zeigt dir keinen Verlauf der Review-Dauer. Dein Posteingang schon. Jede Entscheidung, die Apple schickt, hat denselben Aufbau: einen Betreff, der entweder "Review of your App (iOS) submission is complete." oder "There's an issue with your App (iOS) submission." lautet, und eine Zeile im Text wie Submitted: Oct 08, 2026 at 03:48 PM Pacific Daylight Time. Der Sendezeitpunkt der E-Mail ist der Entscheidungszeitpunkt. Das ist der gesamte Datensatz.

Ich habe Gmail am 17. Oktober 2026 mit einer einzigen Abfrage per Suchoperator durchsucht: from:no_reply@email.apple.com newer_than:60d. Sie lieferte 69 Threads, davon sind 64 Entscheidungen (die anderen fünf sind die Begrüßung von App Store Connect, die Freigabe des API-Zugangs, zwei "Welcome to the App Store"-Nachrichten und ein "Thank you for submitting"). Der Account wurde am 10. September eröffnet, das hier ist also der vollständige Verlauf, keine Stichprobe. Dann das Parsen:

# media/deepdive/review-time/analyze.py (trimmed)
PT = timezone(timedelta(hours=-7))  # Pacific Daylight Time, as printed in Apple's emails

def sub_dt(s):  # "Oct 08 03:48 PM" from the email body
    return datetime.strptime("2026 " + s, "%Y %b %d %I:%M %p").replace(tzinfo=PT)

for e, app, out, sub, by, kind in ROWS:
    s = sub_dt(sub); d = utc(e)          # e = the email's sent time, UTC
    h = (d - s).total_seconds() / 3600   # hours from Submitted to decision
    recs.append(dict(app=app, outcome=out, kind=kind, hours=round(h, 2), ...))

Jede Zeile ist außerdem danach markiert, was eingereicht wurde: die erste Version einer neuen App, ein Update oder reine In-App-Käufe. Das habe ich den Unterlagen der jeweiligen App entnommen (Commit-Verlauf der Repos und meine Notizen) und den unklaren Batch mit dem E-Mail-Text abgeglichen, der die Elemente auflistet: Chains Einreichung in der Nacht zum 8. Oktober nennt In-App Purchases (6) und keine App-Version. Ablehnungsgründe stehen gar nicht in den E-Mails (im Text steht nur "We noticed an issue"), die stammen deshalb aus den gespeicherten Texten im Resolution Center und meinen Antworten darauf.

Was diese Methode nicht sieht: Einreichungen, die ich vor einer Entscheidung zurückgezogen habe (keine E-Mail, keine Zeile), und den genauen Moment, in dem ein Reviewer die App geöffnet hat. Wenn du "Zeit im Review" statt "Zeit in der Warteschlange" willst: Die App Store Connect API liefert den Status einer Version, aber keinen Verlauf, du müsstest sie also selbst regelmäßig abfragen.

Apples 24-Stunden-Zahl und meine

Apple formuliert vorsichtig: Man prüfe die Hälfte der Einreichungen in unter 24 Stunden. Das kann stimmen und trotzdem nicht zu deinem Eindruck passen, aus drei Gründen, die sich in meinen Daten zeigen.

Erstens: Die Uhr startet in einer Warteschlange. Meine Freigaben ballen sich bei fast exakt derselben verstrichenen Zeit. Sieben der 16 Updates kamen zwischen 63,5 und 64,5 Stunden, weil sie am Samstagmorgen, dem 26. September, gemeinsam eingereicht und spät am Montagabend (pazifische Zeit) innerhalb von 32 Minuten gemeinsam entschieden wurden. Wie lange das Review selbst auch dauerte, die Wartezeit hing davon ab, wann die Warteschlange bei ihnen ankam.

Zweitens: Apple scheint samstags keine neuen Entscheidungen zu treffen, zumindest nicht über meine. Von 64 Entscheidungen, nach pazifischer Zeit: Montag 35, Freitag 10, Donnerstag 7, Mittwoch 5, Sonntag 4, Dienstag 3, Samstag 0. Der Montagsstapel ist durch die beiden Spam-Batches (22 Entscheidungen) aufgebläht, aber auch ohne sie kam nichts an einem Samstag. App Review arbeitet also durchaus sonntags (zwei der vier Sonntagsentscheidungen waren Freigaben), aber eine Einreichung vom Samstagmorgen wartete trotzdem bis Montagabend.

Drittens: Der langsame Ausläufer ist kein Zufall. Ohne die beiden 4.3-Batches liegen meine Zahlen deutlich näher an Apples: 29 % innerhalb von 24 Stunden, 40 % innerhalb von 48. Die 22 Spam-Ablehnungen dauerten jeweils 7 bis 9,3 Tage. Lange Wartezeiten waren ein Signal, kein Pech.

Die Überholspur sind In-App-Käufe. Fünf reine IAP-Einreichungen (neue Themes und Pakete für fünf Live-Apps, spät in der Nacht auf Donnerstag, den 8. Oktober, per API verschickt) kamen alle zwischen 11,7 und 13,4 Stunden später freigegeben zurück, innerhalb von 95 Minuten nacheinander. Wenn du schnell einen neuen Preispunkt oder ein Paket ausliefern musst, reiche es separat ein und lass das Binary in Ruhe.

Neue Apps: 0 von 21 im ersten Anlauf freigegeben

Jede der 21 Apps bekam ihre erste Einreichung zurück. Das klingt alarmierend, bis du die Gründe liest. Zehn der 21 E-Mails aus der ersten Runde betrafen Guideline 2.1 "Information Needed" (die anderen 11 waren der Spam-Batch weiter unten), also die Routinefragen, die ein neuer Entwickler-Account bekommt: eine Bildschirmaufnahme der App auf einem Gerät schicken, die Hauptfunktionen erklären, angeben, ob ein Login nötig ist, externe Dienste auflisten. Apples Richtlinien verlangen das ohnehin vorab, die Reviewer fragen bei neuen Accounts trotzdem noch einmal nach.

Was funktioniert hat: die Review-Notizen nicht mehr als Formalität zu behandeln. Jede App wird jetzt mit einer Store/review-notes.md ausgeliefert, die die Pipeline in die Review-Details von App Store Connect schiebt, geschrieben als Anleitung, der ein Reviewer in unter einer Minute folgen kann, inklusive des Wegs zu jedem kostenpflichtigen Screen:

# chain/Store/review-notes.md (trimmed)
No account, login or network connection is required.

IN-APP PURCHASES (StoreKit 2, all optional, Restore in Settings):
- Chain Unlimited (existing non-consumable): add three habits, tap New habit again; ...
- Streak Repair, $0.99 consumable: when a chain of 2+ days breaks, Today shows a
  "chain broke" banner and the rescue sheet opens. ... To see it on a fresh install:
  add a habit, open Week, tick the two days before yesterday, leave yesterday empty,
  then relaunch.

PRIVACY: no data is collected. No accounts, analytics, ads or third-party SDKs.

Nach der ersten 2.1-Runde wurden Chain, Ironbook und Quiver am 22. September um 4:21 Uhr pazifischer Zeit mit Antworten und einer Bildschirmaufnahme erneut eingereicht, und alle drei wurden 51 bis 67 Stunden später freigegeben. Bei den 8 Apps, die es in den Store geschafft haben, lag der Median von der allerersten Einreichung bis zur ersten Freigabe bei 4,4 Tagen (Spanne 3,75 bis 7,2). Das ist die ehrliche Zahl für den Launch-Plan einer neuen App auf einem neuen Account: nicht 24 Stunden, eher eine Arbeitswoche.

Die übrigen Gründe aus der ersten Runde solltest du kennen, weil sich jeder davon billig vermeiden lässt:

• 5.1.1 Datenschutz, zweimal, dieselbe App. Minder, ein Fokus-Timer, dessen Cartoon-Augen deinem Gesicht folgen können (die Augenanimation steckt in diesem SwiftUI-Artikel), sollte genau angeben, welche Gesichtsdaten die App erfasst, speichert und weitergibt. Die Antwort (eine x/y-Position aus Apples On-Device-Framework Vision, nie gespeichert) musste in der Datenschutzerklärung stehen, nicht nur in der Antwort an Apple. Eine Woche später kam die nächste Ablehnung, weil die URL der Datenschutzerklärung selbst nicht mehr lud. Ich habe das Hosting repariert, sechs Minuten nach der E-Mail erneut eingereicht, und 24,8 Stunden später war die App freigegeben.
• 1.4.1, Gesundheitsangaben brauchen Quellen. Race Fuel gibt Zielwerte für Kohlenhydrate, Flüssigkeit und Natrium bei Ausdauerrennen aus. Guideline 1.4.1 verlangt, dass medizinnahe Zahlen mit Quellen belegt sind. Die Lösung war ein Quellen-Screen mit sieben per DOI verlinkten Studien und einem Link unter jeder Zahl.

Guideline 4.3: eine Woche Stille, dann 11 Ablehnungen in 30 Sekunden

Elf meiner Apps (ein Wartungslog fürs Auto, ein Parkuhr-Timer, ein Hausinventar, ein Preislog für Lebensmittel, ein Tracker für Haustiermedikamente, ein Haushaltsplan, ein Trinkgeld-Tracker, ein Notenrechner, ein Bouldering-Log, ein Pace-Rechner fürs Laufen und ein Koffein-Rechner für die letzte Tasse) wurden am 26. September eingereicht. Sie lagen 8,7 bis 9,3 Tage in der Warteschlange. Dann, am Montag, dem 5. Oktober, trafen alle 11 Ablehnungsmails zwischen 5:29:32 PM und 5:30:02 PM Eastern ein. Derselbe Text für jede App: Guideline 4.3 Spam plus 4.2.6, also Apps, die aus einer Vorlage oder mit einem App-Generator erstellt wurden, dazu neun Fragen zum Beantworten. Im Resolution Center trug jede Nachricht den Zeitstempel 5:29 PM.

Der Ablehnungstext sagte klar, was als Nächstes zu tun ist: Wenn du glaubst, dass die App die Richtlinien bereits erfüllt, reiche nicht erneut ein, sondern antworte auf die Nachricht und beantworte alle neun Fragen. Ich habe auf jede geantwortet (keine öffentliche Beta, getestet über automatisierte Simulator-Läufe; eine gemeinsame StoreKit-Kaufklasse und ein gemeinsamer Testtreiber, offengelegt), für alle 11 Einsprüche beim App Review Board eingelegt und alle 11 am selben Nachmittag zusätzlich erneut eingereicht. Die erneuten Einreichungen waren der Fehler. Sieben Tage später, am Montag, dem 12. Oktober, kamen 11 weitere Ablehnungen innerhalb von 27 Sekunden, jede genau 7,0 Tage nach ihrer erneuten Einreichung.

Was die Daten über 4.3 sagen, wenn du deinen eigenen Launch planst:

• Die Wartezeit verrät es. In meinen Daten war jedes Review, das länger als 5,1 Tage lief, bis auf eines eine 4.3-Ablehnung. Die Ausnahme war Clear the Strait 1.1.1, das ich auf Nachfrage des Reviewers zusammen mit einer langen schriftlichen Erklärung der Spielmechanik erneut eingereicht hatte. Es dauerte 8,5 Tage und wurde freigegeben.
• Entschieden wird pro Entwickler, nicht pro App. Beide Batches kamen innerhalb von 30 Sekunden. Was auch immer das Review war, es waren nicht 11 separate Sitzungen mit 11 Apps.
• Reiche nicht unverändert erneut ein. Apples eigene E-Mail sagte, eine erneute Einreichung ohne wesentliche Änderungen werde wieder abgelehnt. So kam es, im Sieben-Tage-Takt, was pro Runde eine Woche kostete.

Vorher hatte ich gemessen, wie viel Swift-Code diese Apps tatsächlich gemeinsam haben. Die mittlere Überschneidung mit dem Rest des Accounts lag bei 34,5 %, und die beiden ähnlichsten Apps auf dem Account (ein Golf-Journal und ein Tennis-Journal) sind beide live. Code-Ähnlichkeit allein erklärte nicht, wer markiert wurde. Die Zahlen stehen im Artikel über die Kosten einer iPhone-App. Meine Einschätzung, ausdrücklich als Einschätzung: 11 Einzweck-Utilities von einem neuen Account, am selben Morgen eingereicht, sehen aus Sicht der Warteschlange wie eine App-Fabrik aus, egal wie unterschiedlich die Screens sind. Wenn du mehrere kleine App-Ideen hast, veröffentliche eine, lass sie Bewertungen und Updates sammeln und verteile den Rest zeitlich, oder pack alles in eine App mit In-App-Käufen, genau das, was Guideline 4.3(a) vorschlägt.

Der ganze Kalender in einem Bild

Als Kalender betrachtet ist das Muster offensichtlich. Die ersten zwei Wochen bestehen aus kurzen roten Balken (schnelle 2.1-Rückfragen), gefolgt von grünen Balken über zwei bis fünf Tage. Ab dem 26. September teilt sich der Account in zwei Hälften: Apps, die schon live waren, bekommen Updates in etwa 64 Stunden durch, während die 11 neuen Utilities in zwei langen roten Balken festhängen, die jedes Mal im selben 30-Sekunden-Fenster enden.

Nach der Freigabe: in Minuten live

In der E-Mail steht, es könne "bis zu 24 Stunden" dauern, bis ein freigegebenes Element erscheint. Bei meinen 8 Live-Apps kam der öffentliche Veröffentlichungszeitstempel viel schneller. Ich habe ihn aus Apples eigener iTunes Search API gelesen, die für jede App eines Entwicklers im Store ein currentVersionReleaseDate zurückgibt:

# every app on the account, with the release time of its current version
curl -s "https://itunes.apple.com/lookup?id=6810582483&entity=software&country=us"

Verglichen mit den Freigabemails lag dieser Zeitpunkt bei allen 8 Apps 0,7 bis 7,5 Minuten nach der Freigabe, im Median bei 2,5 Minuten. Wenn dein Launch-Datum wichtig ist (Presse, eine Anzeigenkampagne, ein Slot auf Product Hunt), wähle eine manuelle Veröffentlichung, damit eine Freigabe um 2 Uhr nachts nicht vor deiner Ankündigung live geht.

Während du wartest, willst du den Status sehen, ohne App Store Connect zu öffnen. Diesen Statuscheck hat jedes meiner App-Repos dabei. Er fragt die App Store Connect API nach den letzten fünf Versionen und Builds:

# chain/Store/asc.py
def status():
    app = find_app()
    if not app:
        print("no app record for", BUNDLE_ID)
        return
    print(f"{app['attributes']['name']}  ({BUNDLE_ID})  id={app['id']}")
    versions = call(
        "GET", f"/v1/apps/{app['id']}/appStoreVersions", params={"limit": 5}
    )
    for v in (versions or {}).get("data", []):
        a = v["attributes"]
        print(f"  version {a.get('versionString')}: {a.get('appStoreState')}")

Die Einreichung selbst ist ein einziger fastlane-Aufruf am Ende eines CI-Jobs, mit upload_to_app_store. Die drei Antworten in submission_information sind wichtiger, als sie aussehen: Es sind die Fragen zu Exportkonformität, Werbe-ID und Inhaltsrechten, und wenn du sie im Code beantwortest, bleibt eine Einreichung nie hängen, weil jemand erst ein Formular durchklicken muss.

# chain/fastlane/Fastfile, lane :release (trimmed)
upload_to_app_store(
  api_key: asc_key,
  app_identifier: APP_IDENTIFIER,
  ipa: "build/Chain.ipa",
  # Submit, rather than leaving it sitting in Connect for a human to press
  # the button on. This is the last step and it is the irreversible one.
  submit_for_review: true,
  force: true,
  precheck_include_in_app_purchases: false,
  submission_information: {
    add_id_info_uses_idfa: false,
    export_compliance_uses_encryption: false,
    content_rights_contains_third_party_content: false
  }
)

Arbeitet das App-Store-Review am Wochenende?

Teilweise. Vier meiner 64 Entscheidungen kamen an einem Sonntag, pazifische Zeit: die erste Freigabe von Pocket Beings um 4:05 PM am 20. September und drei am Abend des 11. Oktober (zwei 1.2-Updates zurückgeschickt, Chain 1.2 um 10:42 PM freigegeben). Keine kam an einem Samstag. Die 19 Einreichungen vom Samstag, dem 26. September, wurden alle am Montagabend oder später entschieden, und die fünf Updates, die ich am Donnerstag, dem 8. Oktober, verschickt habe, kamen Sonntagabend und früh am Montag zurück. Wenn du die Wahl hast, reiche von Montag bis Mittwoch ein. Bei allem, was ab Donnerstag rausgeht, kannst du davon ausgehen, dass die Antwort erst nach dem Wochenende kommt.

Was ich in deinem Projekt tun würde

1. Plane in Runden, nicht in Tagen. Eine Runde sind etwa 3 Tage für ein Update und 2 bis 5 für eine neue App. Eine neue App auf einem neuen Account braucht zwei Runden: Plane eine Arbeitswoche von der ersten Einreichung bis zur Freigabe ein.
2. Schreib die Review-Notizen wie ein Testskript. Login (oder "kein Login"), wo jeder kostenpflichtige Screen ist, wie man die Sonderfälle auslöst, welche Daten du erfasst. Häng an die erste Einreichung eine Bildschirmaufnahme, damit es bei 2.1 nichts zu fragen gibt.
3. Prüf vor jeder Einreichung, ob die URL deiner Datenschutzerklärung lädt. Ein toter Link hat mich eine komplette Runde gekostet.
4. Reiche In-App-Käufe separat ein, wenn es schnell gehen muss. 12 Stunden, 5 von 5 freigegeben.
5. Werte ein Review über 5 Tage als Warnsignal. Bereite Antworten auf die neun 4.3-Fragen vor, bevor du sie brauchst.
6. Wenn Apple sagt "antworten", reiche nicht erneut ein. Eine erneute Einreichung ohne Änderungen brachte mir eine weitere identische Ablehnung ein, sieben Tage später auf die Stunde genau.
7. Repariere schnell und reiche schnell erneut ein, wenn das Problem konkret ist. Minders kaputter Datenschutz-Link: in 6 Minuten erneut eingereicht, in 25 Stunden freigegeben.
8. Muss es schneller gehen? Apple bietet einen Antrag auf beschleunigtes Review für kritische Bugfixes und zeitkritische Events an. Ich habe ihn nicht genutzt, daher habe ich keine Zahl dazu.
9. Miss selbst. Führ dieselbe Gmail-Abfrage auf deinem Account aus. In zehn Minuten hast du deinen echten Review-Kalender, und der schlägt jeden Durchschnitt, auch diesen hier.

Die Daten, und wie du sie neu berechnest

Alles liegt in einem Ordner: emails.py (die 64 aus den E-Mails übertragenen Zeilen, mit Gmail-Abfrage und Abrufzeit), analyze.py (Mediane, Kategorien, Batches, Verzögerung von Freigabe bis Live), summary.json (jede berechnete Zahl in diesem Artikel) und make_charts.py (die Diagramme). Abgerufen am 17. Oktober 2026 gegen 10:15 PM Eastern, der iTunes-Lookup lief gegen 10:20 PM. Apples Angabe habe ich in derselben Nacht auf developer.apple.com/distribute/app-review gelesen, und der Ablauf der Einreichung ist auf Apples Hilfeseite Submit for review beschrieben. Ein Entwickler-Account, 21 Apps, fünf Wochen: eine kleine Stichprobe, aber eine vollständige, und die einzige Art von Review-Daten, die du tatsächlich überprüfen kannst.

Wenn du unter Windows entwickelst und dieselbe Pipeline (Cloud-Builds, Signierung, Screenshots, Einreichung per fastlane, die Vorlage für Review-Notizen) in deinem eigenen Repo eingerichtet haben willst: Das ist die No-Mac iOS Pipeline für 299 $, dein erster TestFlight-Build von einem Windows-PC in 5 Werktagen. Wenn du lieber die ganze App abgibst, findest du Festpreis-Builds unter /build/.