TestFlight ist Apples Werkzeug, um eine App zu verteilen, bevor sie im App Store ist. Sie laden das signierte Binary in App Store Connect hoch, verschicken Einladungen, und die Tester installieren es über die TestFlight-App auf ihrem eigenen iPhone. Was sie erhalten, ist weder eine Vorschau noch ein Simulator: Es ist genau der Build, den Sie später beim App Review einreichen, mit seinem Icon, seinen Berechtigungen und seinem nativen Code.
Drei Zahlen stecken den ganzen Dienst ab. Bis zu 100 interne Tester, die Mitglieder Ihres App-Store-Connect-Teams sind, bis zu 10.000 externe Tester, die per E-Mail oder über einen öffentlichen Link eingeladen werden, und 90 Tage Gültigkeit für jeden Build. Alles andere, von der Beta-Prüfung bis zu den Feedback-Screenshots, ergibt sich daraus, wie unterschiedlich diese beiden Gruppen behandelt werden. Dieser Leitfaden folgt dem Weg vom Upload bis auf das Telefon eines Testers und listet anschließend die Grenzen und die Fehler auf, die einen Launch verzögern.
TestFlight ist ein Schritt auf einem längeren Weg. Wenn Sie die ganze Abfolge brauchen, vom Entwicklerkonto bis zur Veröffentlichung, lesen Sie unseren Leitfaden, wie Sie eine App im App Store veröffentlichen.
Was TestFlight ist und wo es steht
TestFlight lebt in App Store Connect, unter dem gleichnamigen Tab, und auf den Geräten der Tester als kostenlose App aus dem App Store. Auf Ihrer Seite setzt es eine Mitgliedschaft im Apple Developer Program voraus, auf Seiten der Tester nichts außer einem Apple-Account. Es deckt iOS, iPadOS, macOS, tvOS, watchOS und visionOS ab, ein Mac- oder Vision-Pro-Build durchläuft also denselben Ablauf wie ein iPhone-Build.
Seinen Platz in der Pipeline hat es zwischen Build und Prüfung. Frühere Werkzeuge zeigen Ihren Code schneller auf einem Telefon, aber nicht als Ihre echte App: Expo Go lädt nur Ihr JavaScript in eine gemeinsame Hülle, und ein Development Build enthält zwar Ihren nativen Code, aber mit den Entwicklerwerkzeugen darin. TestFlight ist der erste Moment, in dem Sie das Produktions-Binary in der Hand halten. Unser Leitfaden zum Testen mit Expo Go behandelt diese frühere Stufe und ihre Grenzen.
Vom Upload bis auf das Telefon eines Testers, Schritt für Schritt
1. Upload und Verarbeitung
Ein Build gelangt aus Xcode, aus Apples Transporter-App, aus einem Build-Dienst wie EAS Submit oder von einer Plattform wie Cadrant, die EAS für Sie steuert, in App Store Connect. Nach dem Upload durchläuft der Build die Verarbeitung: Apple prüft das Paket, indexiert die Symbole und scannt es, was wenige Minuten dauert, zu Stoßzeiten aber bis zu etwa einer Stunde. Danach erscheint er unter dem TestFlight-Tab Ihrer App mit einem Status.
Der erste Halt ist oft „Missing Compliance“. Apple fragt, ob die App Verschlüsselung über das hinaus nutzt, was iOS mitbringt; für die meisten Apps, die nur HTTPS-Aufrufe machen, lautet die Antwort Nein, und Sie können den Schlüssel ITSAppUsesNonExemptEncryption in der App-Konfiguration setzen, damit die Frage nie wieder einen Build blockiert. Solange die Antwort nicht hinterlegt ist, kann niemand den Build installieren.
2. Interne Tester: Ihr Team, ohne Prüfung
Interne Tester sind Personen, die eine Rolle in Ihrem App-Store-Connect-Team haben: Admin, App Manager, Developer, Marketing oder Customer Support. Sie können bis zu 100 davon pro App haben, und sie erhalten jeden Build wenige Minuten nach der Verarbeitung, ohne Prüfung durch Apple. Sie können bei einer internen Gruppe sogar „automatisch verteilen“ ankreuzen, damit jeder neue Upload von selbst hinausgeht. Das ist die Schleife für Ihr eigenes Team: hochladen, testen, korrigieren, erneut hochladen, bei Bedarf mehrmals am Tag.
3. Externe Tester: bis zu 10.000 Personen und eine Beta-Prüfung
Externe Tester sind alle anderen: Kunden, Freunde, eine Warteliste. Sie organisieren sie in Gruppen, laden sie per E-Mail ein oder teilen einen öffentlichen Link, und jede Gruppe kann andere Builds erhalten. Die Grenze liegt bei 10.000 externen Testern pro App über alle Gruppen hinweg. Apples TestFlight-Übersicht legt die Regeln für beide Kreise fest.
Der Unterschied zum internen Test ist die Beta App Review. Der erste Build, den Sie einer externen Gruppe hinzufügen, geht an App Review, damit geprüft wird, ob er die App Review Guidelines einhält, in der Praxis eine leichtere Kontrolle als die Prüfung vor der Veröffentlichung, die meist innerhalb eines Tages durch ist. Spätere Builds derselben Version gehen oft ohne neue vollständige Prüfung hinaus, es sei denn, Sie ändern Dinge, auf die Apple achtet. Damit diese Prüfung durchgeht, füllen Sie die Testinformationen aus: was zu testen ist, eine Kontakt-E-Mail-Adresse und ein Demo-Konto, falls die App eine Anmeldung verlangt.
4. Auf Seiten des Testers
Ein Tester installiert die TestFlight-App, öffnet die Einladungs-E-Mail oder den öffentlichen Link, nimmt an und tippt auf Installieren. Die App erscheint auf dem Home-Bildschirm mit einem orangefarbenen Punkt neben ihrem Namen, dem Zeichen, dass es sich um eine Beta handelt. Wenn Sie einen neuen Build hochladen, benachrichtigt TestFlight die Tester und kann automatisch aktualisieren. Für Feedback macht der Tester einen Screenshot und nutzt das Teilen-Menü, oder er schüttelt das Gerät, falls Sie das aktiviert haben; Screenshot und Kommentar landen in App Store Connect, zusammen mit Crash-Logs für jeden Absturz, den die App während des Tests erleidet.
Grenzen, Zeitpläne und die Fehler, die eine Woche kosten
| Regel | Wert | Folge |
|---|---|---|
| Interne Tester | 100 pro App, App-Store-Connect-Nutzer | Fügen Sie Kollegen zuerst dem Team hinzu; sie brauchen eine Rolle, nicht nur eine E-Mail-Adresse |
| Externe Tester | 10.000 pro App, E-Mail oder öffentlicher Link | Ein öffentlicher Link lässt sich begrenzen und schließen; Kriterien am Link schränken ein, wer hineinkommt |
| Beta App Review | Erster Build pro externer Gruppe, meist unter einem Tag | Planen Sie den ersten externen Build einen Tag, bevor Sie Tester darauf brauchen |
| Gültigkeit eines Builds | 90 Tage | Danach lässt sich die App bei den Testern nicht mehr öffnen, bis ein neuer Build hochgeladen ist |
| Verarbeitung | Minuten bis etwa eine Stunde | Laden Sie einen Build nicht erneut hoch, weil er „noch nicht da“ ist; warten Sie auf die E-Mail |
| Kosten | Kostenlos mit dem Developer Program | Die Mitgliedschaft für 99 USD pro Jahr ist die einzige Gebühr |
Die Verzögerungen, über die sich Leute beschweren, kommen selten von Apple. Sie kommen von diesen Fehlern:
- Die Compliance-Frage unbeantwortet lassen. Der Build bleibt bei Missing Compliance stehen, und die Einladungen gehen nie hinaus. Setzen Sie den Verschlüsselungsschlüssel einmal in der Konfiguration.
- Erwarten, dass externes Testen sofort geht. Intern geht es sofort; extern wartet auf die Beta App Review. Nutzen Sie eine interne Gruppe für die ersten Stunden und die externe Gruppe für die ersten Tage.
- Keine Testnotizen, kein Demo-Konto. Die Beta App Review braucht einen Weg hinein, genau wie die Prüfung vor der Veröffentlichung. Ein Login, der funktioniert, erspart einen abgelehnten Build.
- Den falschen Apple-Account einladen. Die Einladung ist an die E-Mail-Adresse gebunden; nutzt das Gerät des Testers einen anderen Apple-Account, passt die Einladung nie. Öffentliche Links umgehen das Problem.
- TestFlight als Vertriebskanal behandeln. Die Guidelines verbieten, damit eine App anstelle des App Store an die Öffentlichkeit auszuliefern, und Builds sterben ohnehin nach 90 Tagen.
TestFlight mit Cadrant
Wenn Ihre App mit dem Mobile-App-Baukasten von Cadrant gebaut wurde, sind die Schritte vor TestFlight für Sie erledigt: Der iOS-Build läuft auf Ihrem eigenen Expo-Konto (der kostenlose Plan deckt 15 iOS-Builds pro Monat ab), und Expo reicht das fertige Binary bei Ihrem App-Store-Connect-Konto ein, wo der App-Eintrag und das Distributionszertifikat während eines geführten Ablaufs angelegt wurden. Von dort an befinden Sie sich im Standard-TestFlight-Weg: App Store Connect öffnen, die Compliance-Frage beantworten, falls sie gestellt wird, interne Tester oder eine externe Gruppe hinzufügen und auf Ihren Geräten installieren.
Was Sie dort prüfen sollten, ist das, was die Vorschau im Editor und Expo Go nicht zeigen können: native APIs wie Kamera, Push-Benachrichtigungen und Dateiauswahl, Anmelde- und Datenabläufe gegen Ihr Supabase-Projekt, die Leistung auf einem echten Gerät sowie verweigerte Berechtigungen oder das Offline-Verhalten. Einen Fehler gefunden? Beheben Sie ihn in Cadrant, veröffentlichen Sie einen neuen Build, verteilen Sie ihn, und wiederholen Sie das, bis Sie bereit für den App Review sind. Die Dokumentation „Mit TestFlight testen“ listet die genauen Klicks auf.
Die Kurzfassung
- Hochladen, auf die Verarbeitung warten, die Compliance-Frage beantworten: Erst dann kann jemand installieren.
- Interne Tester (100 Teammitglieder) erhalten Builds sofort; externe Tester (10.000) warten beim ersten Build einer Version auf eine Beta App Review.
- Füllen Sie Testnotizen und ein Demo-Konto aus, laden Sie wenn möglich per öffentlichem Link ein, und denken Sie an den Ablauf nach 90 Tagen.
- Testen Sie auf TestFlight, was Expo Go nicht zeigen kann, denn der Prüfer wird es tun.
So eingesetzt ist TestFlight kein zusätzlicher Schritt vor dem Launch: Es ist der Launch, ein paar Tage früher geprobt, mit echten Menschen auf echten Telefonen.