Wenn die TestFlight-Verarbeitung extrem lange dauert, ist der Build in den meisten Fällen nicht dauerhaft blockiert, sondern verzögert. Die Verarbeitung dauert normalerweise wenige Minuten bis etwa eine Stunde, ein paar Stunden sind langsamer als üblich, aber nicht ungewöhnlich, besonders bei einem Serverproblem. Prüfen Sie zuerst die Apple System Status Seite auf einen Ausfall bei TestFlight oder App Store Connect, denn die serverseitige Verarbeitung hängt gelegentlich für alle Entwickler. Wenn kein Ausfall vorliegt und der Build weit über den normalen Bereich hinaus feststeckt, laden Sie einen neuen Build mit einer höheren Build-Nummer hoch, was eine neue Verarbeitung startet. Ein feststeckender Build hat keine Auswirkung auf eine bereits veröffentlichte App im App Store.
Kurzantwort
Eine Verarbeitung über mehrere Stunden ist meist eine Verzögerung, kein dauerhaftes Feststecken, daher prüfen Sie vor dem Handeln einen Ausfall. Laut der Apple System Status Seite werden Probleme mit TestFlight und App Store Connect dort gemeldet, und die serverseitige Verarbeitung kann global hängen, was eine lange Wartezeit erklärt, die Sie nicht beheben können. Laut der TestFlight-Dokumentation ist die Verarbeitung normalerweise nach wenigen Minuten bis etwa einer Stunde abgeschlossen. Liegt kein Ausfall vor und steckt der Build deutlich länger fest, laden Sie einen Build mit höherer Nummer hoch. Brechen Sie nicht in Panik ab, denn ein feststeckender Build beeinflusst keine Live-App.
Wie lange ist die Verarbeitung normal?
Die normale Verarbeitungsdauer liegt bei wenigen Minuten bis etwa einer Stunde, und ein Build, der innerhalb dieses Bereichs bleibt, verhält sich wie erwartet. Zwei bis drei Stunden sind langsamer als üblich, aber noch im Rahmen gewöhnlicher Verzögerungen, besonders wenn viele Entwickler gleichzeitig hochladen. Ein Build in diesem Bereich steckt also nicht zwangsläufig fest, und die richtige Reaktion besteht meist darin, etwas länger zu warten, nachdem Sie geprüft haben, dass kein Ausfall vorliegt.
Ungewöhnlich ist ein Build, der weit über ein paar Stunden hinaus, in Richtung eines ganzen Tages oder mehr, ohne Bewegung und ohne gemeldetes Serverproblem verarbeitet wird. Dann steckt der Build wirklich fest, statt nur langsam zu sein, und dann greift die Lösung mit der neuen Build-Nummer. Diese Unterscheidung ist wichtig, denn bei einem nur langsamen Build verschwenden Sie mit einem erneuten Upload einen Versuch, während Sie bei einem wirklich feststeckenden Build mit endlosem Warten Zeit verlieren. Prüfen Sie den Status, berücksichtigen Sie Ausfälle, und behandeln Sie eine unerklärte Wartezeit von vielen Stunden bis zu einem Tag als Schwelle zum Handeln.
Lösung 1: Apple System Status prüfen
Wenn die Verarbeitung stundenlang dauert, ist der erste und nützlichste Schritt, die Apple System Status Seite auf ein Problem mit TestFlight oder App Store Connect zu prüfen, denn ein Ausfall ist eine häufige Ursache für eine Verarbeitung, die für alle hängt. Apple meldet bekannte Probleme mit seinen Entwicklerdiensten dort. Zeigt TestFlight oder App Store Connect ein Problem, wartet Ihr Build auf Apple, nicht auf etwas, das Sie getan haben, und es gibt außer Warten nichts zu beheben.
Diese Prüfung erspart Ihnen unnötige Aktionen. Läuft ein Ausfall, beschleunigt weder ein neuer Upload noch der Kontakt zum Support etwas, denn der Engpass ist der Dienst selbst, und Sie warten einfach, bis Apple ihn behebt und der Rückstau abgebaut ist. Zeigt der System Status alles als betriebsbereit, ist die Verzögerung eher spezifisch für Ihren Build, was auf die Lösung mit der neuen Build-Nummer hinweist. Die Statusprüfung sagt Ihnen also, ob Sie ein globales Problem aussitzen müssen oder einen feststeckenden Build behandeln können, die unterschiedlich gehandhabt werden.
Lösung 2: Innerhalb des normalen Bereichs warten
Wenn kein Ausfall vorliegt und der Build erst seit Minuten bis zu ein paar Stunden verarbeitet wird, besteht die richtige Lösung schlicht im Warten. Da die Verarbeitung serverseitig und variabel ist, verlassen die meisten Builds diese Phase innerhalb des normalen Bereichs von selbst, und eine Wartezeit von ein bis zwei Stunden ist noch kein Grund zum Handeln. Zu frühes Eingreifen, etwa ein erneuter Upload, kostet Sie unnötig einen Versuch und startet die Uhr neu.
Nutzen Sie diese Zeit sinnvoll, statt den Status ständig zu aktualisieren. Bestätigen Sie, dass der Upload abgeschlossen wurde und der Build in App Store Connect als in Verarbeitung erscheint, und geben Sie ihm dann die kurze, übliche Zeitspanne. Wenn Sie geprüft haben, dass kein Serverproblem vorliegt, ist Geduld innerhalb des normalen Bereichs die passende Reaktion, weil das erneute Hochladen eines Builds, der ohnehin bald fertig geworden wäre, keinen Vorteil bringt und die Arbeit unnötig wiederholt.
Lösung 3: Neue Build-Nummer hochladen
Wenn kein Ausfall vorliegt und Ihr Build deutlich über den normalen Bereich hinaus in der Verarbeitung feststeckt, ist das Hochladen eines Builds mit einer erhöhten Build-Nummer die Standardlösung. Jeder Upload mit einer neuen Build-Nummer, also einer höheren Build-Version, erzeugt einen neuen Verarbeitungsvorgang, sodass ein neuer Upload einen feststeckenden Build häufig löst, weil Apple den neuen statt des hängenden verarbeitet. Dies ist die zuverlässigste Selbsthilfe für einen wirklich feststeckenden Build.
Tun Sie dies bewusst, nicht reflexartig. Erhöhen Sie die Build-Nummer, damit der neue Upload eindeutig ist, denn das erneute Hochladen derselben Build-Nummer erzeugt keinen neuen Build. Der alte, feststeckende Build schadet nicht, er bleibt einfach liegen, und der neue ersetzt ihn, sobald er verarbeitet ist. Reservieren Sie dies für einen Build, der ohne erklärenden Ausfall deutlich über eine angemessene Wartezeit hinaus feststeckt, statt für einen nur langsamen Build, denn ein neuer Upload startet die Uhr neu und ist unnötig, wenn der aktuelle Build ohnehin bald fertig geworden wäre.
Lösung 4: Apple-Support kontaktieren
Kontaktieren Sie den Apple Developer Support, wenn ein Build deutlich über eine normale Wartezeit hinaus feststeckt, kein Ausfall dies erklärt und auch das Hochladen einer neuen Build-Nummer es nicht gelöst hat. Dann ist das Problem weder eine normale Verzögerung noch etwas, das die Standardlösung behebt, sodass es eine Prüfung durch Apple rechtfertigt. Geben Sie Ihre App- und Build-Details an und beschreiben Sie, was Sie bereits versucht haben, einschließlich des neuen Uploads, damit der Support untersuchen kann, statt die Schritte vorzuschlagen, die Sie schon getan haben.
Stellen Sie vor der Eskalation sicher, dass Sie die Grundlagen erledigt haben: bestätigt, dass es kein Serverproblem im System Status gibt, über den normalen Bereich hinaus gewartet und eine neue Build-Nummer probiert. Der Support ist der richtige Schritt für einen wirklich feststeckenden Build, der der Selbsthilfe widersteht, nicht für einen langsamen Build oder einen, der auf einen Ausfall wartet. Eine klare, sachliche Anfrage, nachdem Sie die häufigen Ursachen ausgeschlossen haben, ist wirksamer als eine Kontaktaufnahme, während ein globales Problem noch läuft oder bevor Sie die Standardlösung versucht haben.
Was macht die Verarbeitung langsamer?
Mehrere Faktoren können die Verarbeitung verlangsamen. Ein Serverausfall oder eine hohe Last auf Apples Seite ist der häufigste, und ein solcher Ausfall zeigt sich auf der System Status Seite. Eine große App mit vielen oder großen Assets braucht tendenziell länger für die Verarbeitung als eine kleine, da Apple mehr vorbereiten und validieren muss. Und Zeiten mit hohem Volumen, etwa rund um wichtige Ereignisse oder Fristen, erhöhen den Rückstau und damit die Wartezeit.
Ein kleinerer Faktor sind Konfigurations- oder Metadatenprobleme beim Build, die die Verarbeitung stören können, obwohl diese häufiger zu einer Ablehnung als zu einer reinen Verlangsamung führen. In der Praxis ist die überwiegende Ursache für eine lange Verarbeitung serverseitig, also entweder ein Ausfall oder Last, weshalb die Statusprüfung so nützlich ist. Sie können die Verarbeitungsgeschwindigkeit nicht direkt beeinflussen, aber das Wissen um diese Faktoren hilft Ihnen einzuschätzen, ob eine lange Wartezeit erklärbar ist oder auf einen wirklich feststeckenden Build hindeutet.
Wochenenden und Feiertage
Die Verarbeitung selbst läuft serverseitig durchgehend, also auch an Wochenenden und Feiertagen, sodass ein an einem Samstag hochgeladener Build normalerweise wie an einem Wochentag verarbeitet wird. Die serverseitige Verarbeitung hält nicht für das Wochenende an, weil sie automatisiert ist. In dieser Hinsicht macht der Wochentag für die reine Verarbeitung meist keinen großen Unterschied.
Ein Unterschied betrifft eher die Beta App Review, die für externe Tester erforderlich ist und von Menschen durchgeführt wird, die an Wochenenden und Feiertagen weniger verfügbar sein können. Wenn Ihr Build also auf diese Prüfung wartet, statt nur auf die Verarbeitung, kann sich diese Prüfung an einem Wochenende verzögern. Rund um große Feiertage steigt zudem das Upload-Volumen, weil Entwickler vor freien Tagen Versionen einreichen, was den Rückstau und damit die Verarbeitungszeiten verlängern kann. Planen Sie deshalb einen Puffer ein und laden Sie nicht in letzter Minute vor einem Feiertag hoch.
Setzt erneutes Hochladen die Prüfung zurück?
Ja, ein neuer Upload startet eine frische Verarbeitung für diesen Build, und wenn der Build für externe Tests eine Beta App Review benötigt, durchläuft der neue Build diese Prüfung als neue Einreichung. Ein erneutes Hochladen, um einen feststeckenden Verarbeitungszustand zu lösen, bedeutet also, dass der Ersatz-Build eigenständig verarbeitet und, wo zutreffend, geprüft wird, statt den Platz des feststeckenden Builds zu erben. Für internes Testen, das keine Beta App Review erfordert, wird der neue Build einfach verarbeitet und verfügbar gemacht.
Das sollten Sie wissen, damit der erneute Upload Sie nicht überrascht. Hatte Ihr feststeckender Build die Prüfung bereits bestanden und nur die Verarbeitung hing, benötigt ein neuer Build seine eigene Verarbeitung und, für externe Tester einer neuen Version, seine eigene Prüfung. In der Praxis ist der Neustart mit einer höheren Build-Nummer ohnehin der Weg nach vorn, da der feststeckende Build nie nutzbar wurde. Laden Sie einen nur langsamen Build jedoch nicht wiederholt neu hoch, da dies die Arbeit unnötig neu startet.
Verarbeitungsstatus im Überblick
Die Zuordnung der bisherigen Wartezeit zur wahrscheinlichen Ursache zeigt, ob Sie warten oder handeln sollten. Die folgende Tabelle stellt dies dar.
| Zeit in Verarbeitung | Normal? | Wahrscheinliche Ursache und Reaktion |
|---|---|---|
| Minuten bis etwa eine Stunde | Normal | Standardverarbeitung, warten |
| Ein paar Stunden | Langsamer, aber üblich | Last oder kleine Verzögerung, warten, Status prüfen |
| Stunden während eines Ausfalls | Erklärt | Apple-Dienstproblem, auf Behebung warten |
| Ein Tag oder mehr, kein Ausfall | Feststeckend | Neuen Build mit höherer Nummer hochladen |
Lesen Sie die Tabelle sowohl nach der Zeit als auch danach, ob ein Ausfall gemeldet ist, denn dieselbe Dauer bedeutet Warten während eines Ausfalls und Handeln, wenn alles betriebsbereit ist.
Checkliste zur Behebung
Das Durcharbeiten dieser Schritte löst eine lange Verarbeitungszeit. Die folgende Checkliste deckt sie ab.
| Schritt | Aktion | Erledigt? |
|---|---|---|
| System Status prüfen | Auf ein TestFlight- oder App Store Connect-Problem achten | [ ] |
| Normalen Bereich abwarten | Minuten bis ein paar Stunden Zeit geben | [ ] |
| Bei Ausfall warten | Während eines Ausfalls nicht hochladen oder eskalieren | [ ] |
| Bei echtem Feststecken neu hochladen | Build-Nummer erhöhen und erneut hochladen | [ ] |
| Uploads nicht spammen | Nur einen klar feststeckenden, nicht langsamen Build neu hochladen | [ ] |
| Bei ungelöstem Problem eskalieren | Support nach dem Scheitern der Lösung kontaktieren | [ ] |
Der entscheidende Schritt ist die Prüfung des System Status, denn er sagt Ihnen, ob Sie ein Apple-Problem aussitzen oder einen feststeckenden Build behandeln, die ohne diese Prüfung identisch aussehen.
Die Wartezeit nutzen: den Build prüfen
Ob Ihr Build normal verarbeitet wird oder ein Problem aussitzt, die Zeit ist besser für die Prüfung des Builds als für das Aktualisieren des Status genutzt. Ein Build, der schließlich verarbeitet wird, geht an Tester und später in die Prüfung, sodass es sinnvoll ist, während des Wartens sicherzustellen, dass er solide ist.
Ein Scanner wie PTKD.com analysiert Ihren Build und meldet Probleme wie durchgesickerte Schlüssel und Geheimnisse, zu weit gefasste Berechtigungen und unsichere Datenverarbeitung nach Schweregrad, zugeordnet zu OWASP MASVS, sodass Sie Probleme während des Wartens erkennen. Zur Klarheit über die Grenze: PTKD verarbeitet Ihren Build nicht, kontaktiert Apple nicht und ändert Ihre Verarbeitungszeit nicht. Es hilft Ihnen, die Wartezeit zu nutzen, um sicherzustellen, dass der fertig verarbeitete Build einer ist, den Sie verteilen können.
Das Wichtigste in Kürze
- Eine Verarbeitung über Stunden ist meist eine Verzögerung, kein dauerhaftes Feststecken, und die Verarbeitung ist normalerweise nach Minuten bis etwa einer Stunde abgeschlossen.
- Prüfen Sie zuerst die Apple System Status Seite, denn ein Ausfall bei TestFlight oder App Store Connect kann die Verarbeitung für alle hängen lassen, und dann hilft nur Warten.
- Liegt kein Ausfall vor und steckt der Build deutlich über eine normale Wartezeit hinaus fest, laden Sie einen Build mit erhöhter Build-Nummer hoch, um eine neue Verarbeitung zu starten.
- Ein erneuter Upload startet eine frische Verarbeitung und, für externe Tests einer neuen Version, eine neue Prüfung, tun Sie es also nur bei einem wirklich feststeckenden Build.
- Eskalieren Sie zum Support, nachdem Sie Ausfälle ausgeschlossen und eine neue Build-Nummer probiert haben, und nutzen Sie die Wartezeit, um Ihren Build mit einem Werkzeug wie PTKD.com zu prüfen.
