TestFlight: iPhone-App vor der Einreichung testen

Was ist TestFlight und wofür brauchst du es?

TestFlight ist der Dienst von Apple, mit dem du deine App vor dem Release im App Store auf echten iPhones installieren kannst. Du lädst einen Build in App Store Connect hoch, lädst Tester ein, und sie installieren ihn mit der TestFlight-App, die im App Store kostenlos ist. Es gibt zwei Arten von Testern: interne, bis zu 100 Mitglieder deines Teams, ohne Review durch Apple; und externe, bis zu 10.000 Personen, eingeladen per E-Mail oder öffentlichem Link, nach einem Beta-Review deines ersten Builds. Jeder Build bleibt 90 Tage testbar.

Kriterium	Interne Tester	Externe Tester
Maximale Anzahl	100	10.000
Zugriff auf deinen Account	Ja, mit einer Rolle	Nein
Einladung	Hinzufügen zur internen Gruppe	E-Mail oder öffentlicher Link
Beta-Review von Apple	Keins	Beim ersten Build
Für wen	Du, ein Partner, jemand aus deinem Umfeld	Freunde, erste Nutzer

Für TestFlight brauchst du einen kostenpflichtigen Apple-Developer-Account: Mit einem kostenlosen Account ist der Dienst nicht verfügbar. Der ganze Rest dieses Guides geht davon aus, dass du einen hast, und zwar im Standardprogramm: Das Enterprise-Programm von Apple gibt keinen Zugang zu TestFlight.

Bei meinen Apps geht jeder Build, den ich per EAS Submit hochlade, über TestFlight und über mein iPhone, bevor er ins Review geht. Genau da finde ich die Probleme, die man in der Entwicklung nicht sieht.

Einen Build zu TestFlight hochladen

Ein Build ist eine kompilierte und signierte Version deiner App: Ist er falsch signiert, lehnt Apple ihn beim Hochladen mit ITMS-90034 ab. Damit er in TestFlight erscheint, musst du ihn an App Store Connect senden. Mit Expo heißt das eas build --platform ios und dann eas submit --platform ios, mit einem ausreichend aktuellen Build-Image, um ITMS-90725 zu vermeiden. Laut der Expo-Dokumentation erscheint der Build in TestFlight, nachdem Apple ihn verarbeitet hat, meist nach 10 bis 15 Minuten. Das alles geht auch von einem PC aus: Der Guide iOS-App ohne Mac veröffentlichen beschreibt die komplette Kette.

Zwei Details blockieren beim ersten Mal oft:

• Die Build-Nummer muss sich bei jedem Upload ändern. Apple lehnt zwei Builds mit derselben Nummer für dieselbe Version ab. Mit EAS aktivierst du das automatische Hochzählen und musst nicht mehr daran denken.
• Die Frage zur Verschlüsselung. Solange du die Frage zur Nutzung von Verschlüsselung nicht beantwortet hast, bleibt der Build mit dem Status „Missing Compliance“ hängen. Du kannst sie jedes Mal in App Store Connect beantworten oder sie ein für alle Mal in der Konfiguration deiner App angeben.

Interne Tester: dein Team, ohne Wartezeit

Interne Tester sind Nutzer deines App-Store-Connect-Accounts mit einer zugewiesenen Rolle. Apple erlaubt bis zu 100, und jeder kann die App auf mehreren Geräten installieren, bis zu 30.

Ihr großer Vorteil: kein Beta-Review. Sobald der Build fertig verarbeitet ist, ohne automatischen Fehler wie ITMS-90717, fügst du ihn deiner internen Gruppe hinzu und er ist verfügbar. Das ist die richtige Gruppe für dich und für einen Partner oder jemanden aus deinem Umfeld, dem du Zugriff auf deinen Account gibst.

Ihre Grenze: Du musst sie als Nutzer deines App-Store-Connect-Accounts hinzufügen. Für Fremde ist das nicht geeignet.

Externe Tester und Beta-Review

Externe Tester brauchen keinen Zugriff auf deinen Account. Du kannst bis zu 10.000 einladen, per E-Mail oder öffentlichem Link. Das ist die richtige Gruppe für Freunde, erste Nutzer, eine Community.

Im Gegenzug prüft Apple den Build, bevor er für sie freigegeben wird. Wenn du den ersten Build einer Version zu einer externen Gruppe hinzufügst, geht er ins Beta-Review. Die folgenden Builds derselben Version brauchen nicht unbedingt ein vollständiges Review.

Vor diesem Schritt fragt App Store Connect nach Testinformationen:

• eine Beschreibung der Beta, die den Testern sagt, worauf sie achten sollen;
• eine E-Mail-Adresse für Feedback;
• deine Kontaktdaten, damit Apple dich erreichen kann.

Das Beta-Review ist nicht das App-Store-Review. Ein in TestFlight akzeptierter Build kann bei der Veröffentlichung trotzdem noch abgelehnt werden.

Das Beta-Review prüft, ob der Build die Regeln einhält, aber das finale Review schaut sich auch deine Produktseite, deine Abos, deine Rechtstexte und das gesamte Nutzungserlebnis an. Behalte die klassischen Ablehnungsgründe im Kopf, die ich in warum Apple eine App ablehnt beschreibe.

Tester per öffentlichem Link einladen

Der öffentliche Link ist der einfachste Weg, deine App von Leuten testen zu lassen, die du noch nicht kennst. Hier ist Apples Anleitung, mit den englischen Bezeichnungen der Oberfläche:

1. Öffne in App Store Connect deine App und dann den Tab TestFlight.
2. Wähle unter External Testing deine externe Gruppe aus.
3. Klicke auf Create Public Link.
4. Wähle Open to Anyone, um den Link für alle zu öffnen, oder Filter by Criteria, um ihn auf bestimmte Geräte und iOS-Versionen zu beschränken.
5. Wenn du willst, legst du mit Set Limit eine Testerobergrenze fest.

Den Link teilst du dann, wo du willst: Nachricht, soziales Netzwerk, E-Mail. Die Person installiert die TestFlight-App, öffnet den Link und nimmt die Einladung an.

Zwei Dinge solltest du wissen, bevor du ihn breit streust:

• Leg eine Obergrenze fest. Falls dein Link weiter herumgeht als geplant, behältst du die Kontrolle über die Zahl der Tester.
• Tester über den öffentlichen Link sind anonym. App Store Connect zeigt für sie nur das Installationsdatum, die Sessions und die Abstürze. Wenn du wissen willst, wer was getestet hat, lade lieber per E-Mail ein.

Wie lange ist ein TestFlight-Build gültig?

Ein Build bleibt 90 Tage lang für Tester verfügbar. Danach läuft er ab und deine Tester können ihn nicht mehr öffnen. Wenn deine Beta länger dauert, lade einfach vor Ablauf einen neuen Build hoch.

In der Praxis lädst du ohnehin viel öfter neue Builds hoch: bei jedem wichtigen Fix. Jeder neue Build, den du der Gruppe hinzufügst, wird deinen Testern angeboten, und sie holen ihn sich in der TestFlight-App.

Feedback der Tester einsammeln

TestFlight hat ein eingebautes Feedback-System: Der Tester macht in deiner App einen Screenshot, kann ihn markieren und schickt ihn dir. Stürzt die App ab, bekommst du einen Absturzbericht, und der Tester kann Kontext ergänzen. Du findest alles in App Store Connect.

Das ist nützlich, reicht aber nicht, um einen konkreten Absturz zu verstehen. Bei meinen Apps baue ich Sentry ein, das den Fehler mit der verantwortlichen Codezeile meldet, und PostHog, das zeigt, wo Nutzer abspringen. Beide funktionieren in einem TestFlight-Build genauso wie in Produktion.

Abos in TestFlight testen

Wenn deine App ein Abo verkauft, ist TestFlight der Ort, an dem du prüfst, ob es wirklich funktioniert. Käufe in einem TestFlight-Build laufen über Apples Testumgebung: Deinen Testern wird nichts berechnet. Verlängerungen laufen beschleunigt: Jedes Abo verlängert sich einmal pro Tag, höchstens sechsmal innerhalb einer Woche, unabhängig von seiner tatsächlichen Laufzeit.

Prüf mindestens, dass die angezeigten Preise stimmen, dass der Kauf die App wirklich freischaltet und dass der Wiederherstellen-Button das Abo nach einer Neuinstallation wiederfindet. Ich nutze RevenueCat, um die Abos meiner Apps zu verwalten; das komplette Setup, von den Produkten in App Store Connect bis zur Paywall, beschreibe ich auf der Seite In-App-Abos unter iOS.

Was du vor der Einreichung bei Apple testen musst

Das ist die Liste, die ich vor jeder Einreichung zum Review abarbeite. Jeder Punkt entspricht einem Ablehnungsgrund oder einem vermeidbaren Absturz.

Der erste Start

• Lösch die App, installier sie neu aus TestFlight, öffne sie. Genau das macht der Reviewer.
• Geh das Onboarding komplett durch, ohne etwas zu überspringen.
• Lehne jede Berechtigung ab (Mitteilungen, Kamera, Standort) und prüf, ob die App weiter funktioniert.

Das Geld

• Die Paywall zeigt die Preise, die Laufzeit und die Links zu den Nutzungsbedingungen und zur Datenschutzerklärung.
• Der Kauf funktioniert, die Wiederherstellung auch.
• Alle konfigurierten Produkte sind für den Reviewer sichtbar: Guideline 2.1 verlangt, dass In-App-Käufe vollständig, sichtbar und funktionsfähig sind.

Schwierige Bedingungen

• Flugmodus und langsames Netz: eine klare Meldung, kein weißer Bildschirm.
• Das kleinste iPhone, das du unterstützt, und das größte: nichts abgeschnitten, nichts von der Tastatur verdeckt. Ein abgeschnittener Bildschirm auf einem kleinen iPhone hat mir bei Solys eine Ablehnung eingebracht.
• Lange Texte, wenn deine App übersetzt ist.

Die Unterlagen für den Reviewer

• Wenn deine App ein Login verlangt: ein Demo-Account in den Review-Notizen, mit laufendem Backend. Guideline 2.1 verlangt das ausdrücklich.
• Review-Notizen, die in zwei Sätzen erklären, was die App macht und wo die Hauptfunktion zu finden ist.

Falls deine App trotzdem abgelehnt wird, erklärt die Seite von Apple abgelehnte App, wie du antwortest, ohne eine Woche zu verlieren. Und für den Gesamtüberblick über die Veröffentlichung, von der Produktseite bis zum Release, lies eine App im App Store veröffentlichen.

Eine Testtabelle zum Ausfüllen für deinen Build

Lade die Tabelle mit 16 Szenarien im CSV-Format herunter. Sie unterscheidet Vorbereitung, auszuführende Aktion, erwartetes Ergebnis und beobachteten Nachweis. Importier sie in Numbers, Excel oder Google Sheets und trag dann Version, Gerät und Ergebnis jedes Tests ein.

Für ein fiktives Lesetagebuch reicht „eine Seite speichern“ nicht: Notier Seite 24, schließ die App komplett, starte sie neu und finde den Wert wieder. Ein Test, der nicht ausgeführt wurde, bleibt „Zu testen“. Wenn deine App kein Abo hat, trag bei den Kaufszenarien „Nicht zutreffend“ ein, mit genau dieser Begründung.

Die Tabelle ist ein Ausgangspunkt zum Anpassen, keine Zertifizierung. Du findest außerdem die App-Review-Notizen und die anderen kostenlosen Vorlagen, um dem Reviewer den Ablauf zu erklären, den du wirklich geprüft hast.

Von TestFlight in den App Store

TestFlight ist der Schritt, in dem deine App real wird: Sie läuft auf einem echten iPhone, in den Händen echter Menschen. Im Ablauf des iOS Kit ist das der zweite Schritt: den Kern der App bauen und ihn mit TestFlight auf deinem iPhone testen, bevor du die Abos anbindest und dann die Veröffentlichung vorbereitest.

Nach TestFlight kommt das Review von Apple: Das Apple Review Kit enthält meine Checkliste vor der Einreichung und die Notizen für den Tester. Die Startseite zeigt die vier Schritte, um deine mobile App zu erstellen, mit Claude Code.

Niemand kann dir garantieren, dass Apple deine App akzeptiert: Apple entscheidet.

Häufige Fragen

Wie teste ich meine iPhone-App mit TestFlight?

Lade einen Build in App Store Connect hoch und füge ihn dann einer Testergruppe hinzu. Mit Expo kompilierst du ihn mit EAS Build und lädst ihn mit EAS Submit hoch: Er erscheint in TestFlight, nachdem Apple ihn verarbeitet hat, laut Expo meist nach 10 bis 15 Minuten. Deine Tester installieren ihn mit der TestFlight-App, die im App Store kostenlos ist. Du brauchst einen kostenpflichtigen Apple-Developer-Account.

Wie erstelle ich einen TestFlight-Link, um Tester einzuladen?

Öffne in App Store Connect den Tab TestFlight deiner App, wähle unter External Testing deine Gruppe aus und klicke auf Create Public Link. Wähle Open to Anyone oder Filter by Criteria und leg dann mit Set Limit eine Obergrenze fest. Tester über den öffentlichen Link bleiben anonym: Wenn du wissen willst, wer was getestet hat, lade sie lieber per E-Mail ein.

Ersetzt das Beta-Review von TestFlight das App-Store-Review?

Nein. Das Beta-Review prüft, ob der Build die Regeln einhält, aber das finale Review schaut sich auch deine Produktseite, deine Altersfreigabe (Age Rating), deine Abos, deine Rechtstexte und das gesamte Nutzungserlebnis an. Ein in TestFlight akzeptierter Build kann bei der Veröffentlichung also trotzdem noch abgelehnt werden. Nur externe Tester lösen ein Beta-Review aus, beim ersten Build einer Version: Interne Tester durchlaufen keins.

Wie viele Tester kann man bei TestFlight einladen?

Du kannst bis zu 100 interne und bis zu 10.000 externe Tester einladen. Interne sind Mitglieder deines App-Store-Connect-Accounts, ohne Beta-Review, und jeder kann die App auf bis zu 30 Geräten installieren. Externe werden per E-Mail oder öffentlichem Link eingeladen, nach einem Beta-Review des ersten Builds. Jeder Build bleibt 90 Tage testbar.

Kann man ein Abo in TestFlight testen, ohne dass etwas berechnet wird?

Ja, Käufe in einem TestFlight-Build laufen über Apples Testumgebung: Deinen Testern wird nichts berechnet. Verlängerungen laufen beschleunigt: Jedes Abo verlängert sich einmal pro Tag, höchstens sechsmal innerhalb einer Woche, unabhängig von seiner tatsächlichen Laufzeit. Prüf mindestens die angezeigten Preise, das Freischalten der App und die Wiederherstellung nach einer Neuinstallation. Das komplette Setup beschreibe ich unter In-App-Abos unter iOS.

Was sollte ich in TestFlight prüfen, bevor ich die App bei Apple einreiche?

Installier die App neu aus TestFlight, so wie es der Reviewer macht, und geh das Onboarding komplett durch. Lehne jede Berechtigung ab, teste Kauf und Wiederherstellung und probier dann den Flugmodus sowie das kleinste und das größte iPhone aus, das du unterstützt. Wenn die App ein Login verlangt, leg einen Demo-Account in den Review-Notizen an, mit laufendem Backend.