Interne TestFlight-Tester erhalten einen neuen Build in der Regel innerhalb weniger Minuten nach der Verarbeitung, da keine Prüfung durch Apple nötig ist. Externe Tester dagegen müssen die Beta App Review durchlaufen, die für den ersten Build einer Version normalerweise einige Stunden bis 48 Stunden dauert. Apple nennt keine garantierte Zeit. Der Unterschied ist also groß: intern in Minuten, extern oft in Stunden. Wer sofort testen muss, nutzt am besten einen internen Tester.
Kurze Antwort
Der interne Test ist fast sofort verfügbar, weil interne Tester keine Beta App Review durchlaufen. Laut Apples TestFlight-Seite werden Builds für interne Tester direkt nach der Verarbeitung bereitgestellt, meist innerhalb von Minuten. Externe Tester benötigen beim ersten Build einer Version eine Prüfung, die typischerweise einige Stunden bis 48 Stunden dauert. Ein erneutes Hochladen derselben Version setzt die Prüfung zurück. Wochenenden können langsamer sein. Bei über 48 Stunden ohne Bewegung sollten Sie die Angaben prüfen und den Support kontaktieren.
Interner Test: Wie lange dauert die Freigabe?
Der interne Test ist der schnellste Weg, einen Build in die Hände von Testern zu bekommen, weil er keine Beta App Review erfordert. Sobald der Build die Verarbeitung abgeschlossen hat, steht er internen Testern zur Verfügung, in der Regel innerhalb von Minuten.
Interne Tester sind bis zu 100 Personen, die eine Rolle in Ihrem App-Store-Connect-Account haben, etwa aus Entwicklung, Marketing oder QA. Weil sie zu Ihrer Organisation gehören, vertraut Apple ihnen ohne zusätzliche Prüfung. Genau das macht den internen Kanal ideal, wenn Sie unter Zeitdruck stehen und eine Version sofort ausprobieren müssen. In der Praxis reicht der interne Test oft schon aus, um einen dringenden Fehler zu bestätigen oder eine neue Funktion im Team kurz vorzuführen. Sobald Sie jedoch Rückmeldungen von echten Nutzern brauchen, die nicht zu Ihrem Unternehmen gehören, führt kein Weg am externen Test vorbei. Viele Teams arbeiten deshalb zweigleisig: interne Tester für die tägliche Arbeit, externe für die Phase kurz vor dem Launch.
Externer Test: Wie lange dauert die Beta App Review?
Der externe Test dauert länger, weil jeder erste Build einer Version die Beta App Review durchläuft, bevor externe Tester ihn installieren können. Diese Prüfung dauert normalerweise einige Stunden bis 48 Stunden, in vielen Fällen deutlich weniger.
Externe Tester können bis zu 10.000 Personen sein, die nicht zu Ihrem Team gehören. Weil die App damit Menschen außerhalb Ihrer Organisation erreicht, prüft Apple den Build zuerst. Nachfolgende Builds derselben Version benötigen oft keine neue vollständige Prüfung, weshalb spätere Uploads meist schneller freigegeben werden als der erste. Sobald die Prüfung abgeschlossen ist, benachrichtigt Apple Sie per E-Mail, und der Status wechselt in App Store Connect auf "Bereit zum Testen". Erst dann können Sie den Build einer externen Gruppe zuweisen. Rechnen Sie also beim ersten Build einer Version bewusst mit dieser zusätzlichen Wartezeit und planen Sie sie in Ihren Zeitplan ein, statt sie als Fehler zu deuten.
Interner vs. externer Test im Vergleich
Die folgende Tabelle fasst die wichtigsten Unterschiede zusammen, damit Sie den richtigen Kanal für Ihre Situation wählen können.
| Merkmal | Interner Test | Externer Test |
|---|---|---|
| Beta App Review nötig? | Nein | Ja, beim ersten Build einer Version |
| Typische Freigabezeit | Minuten nach der Verarbeitung | Stunden bis 48 Stunden |
| Maximale Testerzahl | Bis zu 100 (mit Rolle im Account) | Bis zu 10.000 |
| Wofür geeignet? | Team, Auftragnehmer, QA | Echte Nutzer vor dem Launch |
| Statusanzeige | Bereit zum Testen | Warten auf Prüfung, dann In Prüfung |
Die Faustregel ist einfach: Nutzen Sie den internen Test für schnelle Iterationen im Team und den externen Test, um vor dem Launch echtes Nutzerfeedback einzuholen. Beide Kanäle lassen sich parallel verwenden. Ein und derselbe Build kann gleichzeitig internen und externen Gruppen zugewiesen sein, sodass Ihr Team ihn sofort erhält, während die externe Gruppe noch auf die Prüfung wartet. So verlieren Sie keine Zeit, nur weil die externe Freigabe noch aussteht.
Was verlangsamt die Freigabe?
Am häufigsten liegt es schlicht daran, dass es sich um den ersten Build einer Version handelt, der immer eine vollständige Prüfung erfordert. Außerdem prüft Apple pro Version nur einen Build gleichzeitig, sodass ein weiterer Upload derselben Version warten muss, bis der erste fertig ist. Es gilt zudem ein Limit von sechs Builds pro 24 Stunden.
Auch die Angaben im Upload spielen eine Rolle. Ein leeres Feld "Was gibt es zu testen", Berechtigungen ohne Begründung oder eine nicht ausgefüllte Exportkonformität können die Prüfung verlängern oder zu einer Ablehnung führen. Diese Felder vor dem Absenden sorgfältig auszufüllen ist der einfachste Weg, den Build in Bewegung zu halten. Hilfreich ist außerdem, im Feld "Was gibt es zu testen" konkret zu beschreiben, welche Bereiche neu sind und worauf die Prüfer achten sollten. Je klarer diese Angaben sind, desto reibungsloser verläuft die Prüfung in der Regel. Unklare oder widersprüchliche Angaben führen dagegen häufiger zu Rückfragen oder einer Ablehnung.
Setzt ein erneutes Hochladen die Prüfung zurück?
Ja. Wenn Sie einen neuen Build derselben Version hochladen, ersetzt er den Build in der Prüfung und startet den Vorgang von vorn. Sie verlieren damit den Fortschritt und Ihren Platz in der Warteschlange. Ein erneutes Hochladen lohnt sich nur, wenn Sie ein echtes Problem behoben haben, das ohnehin zu einer Ablehnung geführt hätte.
In der Regel bringt ein erneutes Hochladen also mehr Verzögerung als Nutzen. Am ruhigsten fahren Sie, wenn Sie den Build an seinem Platz lassen und innerhalb des normalen Bereichs abwarten. Müssen Sie sofort testen, denken Sie an den internen Kanal: Er umgeht die Prüfung und verschafft Ihnen sofortigen Zugriff, ohne Ihr Tageslimit von sechs Builds zu verbrauchen.
Spielen Wochenenden und Feiertage eine Rolle?
Ja, das kann vorkommen. Die Beta App Review ist zwar an sieben Tagen möglich, doch an Wochenenden und Feiertagen kann die Prüfung langsamer verlaufen. Apple garantiert ohnehin keine feste Zeit, daher sollten Sie um solche Termine herum etwas mehr Puffer einplanen.
Wenn Sie einen wichtigen Testtermin am Montag haben, laden Sie den ersten Build lieber schon einige Tage vorher hoch. So bleibt Ihnen genug Spielraum, falls die Prüfung länger dauert oder eine Ablehnung eine Korrektur nötig macht. Dasselbe gilt für größere Feiertage, an denen bei Apple weniger Prüfer verfügbar sein können. Ein kleiner Vorlauf kostet Sie nichts, erspart Ihnen aber im Ernstfall die Hektik, kurz vor dem Termin noch auf eine Freigabe zu warten.
Schritt für Schritt: Was tun beim Warten?
Handeln Sie danach, wie lange Sie schon warten, statt aus Ungeduld neu hochzuladen. Die folgende Tabelle zeigt einen klaren Weg für jede Situation.
| Ihre Situation | Was zuerst tun | Wann eskalieren |
|---|---|---|
| Weniger als 48 Stunden | Warten, das ist normal | Noch nicht |
| Sie müssen sofort testen | Internen Tester hinzufügen | Nicht nötig |
| Anderer Build derselben Version in Prüfung | Auf Abschluss warten | Nein |
| Über 48 Stunden ohne Änderung | "Was gibt es zu testen" und Exportkonformität prüfen | Fall vorbereiten |
| Status "Abgelehnt" | Grund lesen und beheben | Wenn der Grund falsch wirkt |
Bevor Sie eskalieren, prüfen Sie drei Dinge: Ist die Exportkonformität vollständig, ist das Feld "Was gibt es zu testen" ausgefüllt, und blockiert kein anderer Build derselben Version die Warteschlange? Diese drei Punkte lösen einen großen Teil der Fälle, die wie ein Stau aussehen, aber in Wahrheit eine fehlende Angabe sind. Nehmen Sie sich vor dem Absenden kurz die Zeit, jeden Punkt einmal ruhig durchzugehen, statt später auf eine Antwort zu warten, die eine kleine Korrektur schneller gebracht hätte.
Wann sollten Sie den Support kontaktieren?
Kontaktieren Sie den Support, wenn Sie deutlich über 48 Stunden ohne Bewegung liegen, besonders nach mehreren Tagen. Bei einer Ablehnung antworten Sie im Resolution Center (Problemlösungscenter). Fügen Sie die Build-Nummer, das Datum und die Uhrzeit des Uploads sowie einen Screenshot des Status bei, damit sich Ihr Fall nicht wegen fehlender Angaben verzögert.
Bleiben Sie realistisch: Während des Staus im Jahr 2026 reagierte der Support langsamer, wie ein Thread in den Apple Developer Foren zeigt. Eine Eskalation nach mehreren Tagen ist richtig, garantiert aber keine sofortige Freigabe, vor allem wenn die Ursache ein allgemeiner Rückstau ist.
Vor dem Upload den Build prüfen
Der sicherste Weg, keine Zeit zu verlieren, ist, keinen Prüfzyklus für einen Build zu verschwenden, der ohnehin abgelehnt würde. Jede Ablehnung wirft Sie zurück in die Warteschlange, daher kann ein vermeidbares Problem, etwa ein eingebetteter geheimer Schlüssel, eine Berechtigung ohne Begründung oder eine unsichere Netzwerkkonfiguration, einen ganzen weiteren Zyklus kosten, gerade wenn ein Team auf die Beta wartet.
Ein Sicherheitsscanner wie PTKD.com analysiert die .ipa vor dem Upload und liefert einen nach Schweregrad sortierten und an OWASP MASVS angelehnten Bericht, damit Sie beheben, was eine Ablehnung auslösen würde, bevor Sie in die Warteschlange gelangen. Ehrlich gesagt hat das Grenzen: Ein Scanner beschleunigt Apples Beta App Review nicht und ersetzt bei risikoreichen oder regulierten Apps keine manuelle Prüfung. Was er leistet, ist das Vermeiden vorhersehbarer Ablehnungen, die die Wartezeit wiederholen.
Das Wichtigste zusammengefasst
- Interne Tester erhalten Builds meist in Minuten, weil keine Beta App Review nötig ist.
- Externe Tester durchlaufen die Prüfung, die beim ersten Build einer Version typischerweise einige Stunden bis 48 Stunden dauert.
- Ein erneutes Hochladen derselben Version setzt die Prüfung zurück; für sofortiges Testen nutzen Sie einen internen Tester.
- An Wochenenden und Feiertagen kann die Prüfung langsamer sein; planen Sie Puffer ein.
- Prüfen Sie den Build vor dem Upload mit PTKD.com, um keinen Zyklus durch eine vermeidbare Ablehnung zu verlieren.
