Was ist TestFlight? Der vollständige Einsteigerleitfaden von der ersten Einladung bis zur erfolgreichen Installation

Stand der Überprüfung: 17. September 2026. Dieser Artikel konzentriert sich auf iPhone und iPad. Apple aktualisiert seine Benutzeroberflächen und Regeln. Maßgeblich sind daher die hier verlinkten offiziellen Hinweise und die Seiten, die dir tatsächlich angezeigt werden.

Du hast eine App entwickelt und möchtest sie zuerst im Freundeskreis ausprobieren lassen, bist aber noch nicht bereit für die Veröffentlichung im App Store. Einfach den Quellcode zu verschicken, hilft nicht weiter. Und auch eine Installationsdatei kann die andere Person nicht unbedingt installieren.

Genau dieses Problem löst TestFlight.

Wenn von „TF“ die Rede ist, ist damit meist TestFlight gemeint. Der Dienst von Apple dient zur Verteilung von Testversionen: Du lädst eine Betaversion hoch, lädst andere zum Installieren ein, sammelst Rückmeldungen und verteilst anschließend eine verbesserte Version. Die Testpersonen installieren eine echte App, die auf ihrem Gerät läuft – keine Screenshots und keine Webdemo.[1][2]

Merke dir zunächst diese 3 Punkte:

• Interne Tests richten sich an Mitglieder mit den entsprechenden Berechtigungen in App Store Connect.
• Externe Tests eignen sich für Freunde, Kunden und Community-Mitglieder. Sie brauchen dafür keinen Zugang zur Entwicklerverwaltung.
• Jeder Build kann höchstens 90 Tage lang getestet werden, gerechnet ab dem Tag des Uploads. Eine bestandene TestFlight-Prüfung ist keine Veröffentlichung im App Store.[1][3]

Wenn du nur einen Einladungslink erhalten hast, kannst du direkt zu Abschnitt 9 „Wie installieren Testpersonen die App?“ springen. Wenn du deine eigene App verteilen möchtest, lies am besten von Anfang an.

1. Was sind TestFlight, App Store Connect und der App Store?

Stell dir eine neue App wie ein Geschäft im Probebetrieb vor: TestFlight hilft dir, Menschen zum Ausprobieren einzuladen. Der App Store ist der Weg zur regulären Eröffnung. Auch ein Probebetrieb hat Fristen und Regeln – er ist kein Hintertürchen, um Prüfungen zu umgehen.

Die 3 Namen klingen ähnlich, erfüllen aber unterschiedliche Aufgaben:

Breite Tabellen lassen sich horizontal scrollen. Mit der Tastatur kannst du die Tabelle fokussieren und die Pfeiltasten verwenden.

Im App Store lädst du das Werkzeug TestFlight herunter. Damit installierst du anschließend Apps, zu deren Test du eingeladen wurdest. Nur weil eine App in TestFlight erscheint, ist sie noch nicht im App Store auffindbar.[1][3]

Apple verbindet damit die Schritte „Version verteilen – zum Testen einladen – Probleme sammeln – Version aktualisieren“. Heute müssen Entwickler für TestFlight weder die Gerätekennungen aller Testpersonen einzeln sammeln noch für jede Person ein eigenes Installationsprofil erstellen.[2]

TestFlight schreibt allerdings nicht deine App, bestätigt nicht die Fehlerfreiheit aller Funktionen und macht eine Betaversion nicht automatisch zur offiziellen Version. Auch eine bestandene TestFlight-Prüfung garantiert weder Fehlerfreiheit noch Schutz vor Datenverlust. Riskiere beim Testen unbekannter Apps nicht die einzige Kopie wichtiger Daten.

2. Die Geschichte von TestFlight: Apple hat es nicht von Grund auf entwickelt

Ein Blick in die Geschichte erklärt, warum ältere Anleitungen andere Namen, Personenzahlen oder Abläufe nennen.

• Januar 2011: Öffentlicher Start als Drittanbieterdienst. Zum Testen unveröffentlichter iPhone-Apps musste man damals häufig Gerätekennungen, Installationsdateien und Bereitstellungsprofile verwalten und die Apps über iTunes am Computer synchronisieren. TestFlight vereinfachte die drahtlose Installation erheblich. Gemeint ist hier der Übergang vom privaten Test zum öffentlich verfügbaren Dienst, nicht das Gründungsdatum des Unternehmens.[H1]
• März 2012: Die Übernahme durch Burstly wird bekannt gegeben. TestFlight war zu diesem Zeitpunkt weiterhin ein Drittanbieterprodukt.[H2]
• Februar 2014: Apple übernimmt Burstly. Zusammen mit dem Mutterunternehmen gelangt TestFlight zu Apple.[H3]
• Oktober 2014: Apple kündigt Testeinladungen per E-Mail über iTunes Connect an. iTunes Connect war der Vorgänger des heutigen App Store Connect. Damals konnten bis zu 1.000 Personen eingeladen werden. Wichtig: Das ist eine historische Zahl.[H4]
• Juli 2017: Das Limit für externe Testpersonen steigt auf 10.000.[H5]
• September 2018: Apple führt öffentliche Einladungslinks ein. Entwickler können nun Testpersonen über geteilte Links gewinnen, ohne zuvor jede E-Mail-Adresse einzeln zu erfassen.[H6]

Heute unterstützt TestFlight mehrere Apple-Plattformen, darunter iPhone, iPad, Mac, Apple Watch, Apple TV und Apple Vision Pro. Die iPhone-Beispiele in diesem Artikel bedeuten weder, dass sich nur iPhone-Apps testen lassen, noch, dass TestFlight Android-Apps verteilen kann.[2][3]

3. Zunächst 5 Begriffe: Betaversion, Version, Build, Gruppe und Prüfung

Betaversion (Beta): Eine App-Version, die noch geprüft und verbessert wird und Fehler enthalten kann.

Version (Version): Zum Beispiel 1.0 oder 1.1. Sie kennzeichnet einen nach außen ausgewiesenen Versionsstand.

Build (Build): Ein konkreter, fertig erstellter Stand der App. 1.0 (12) bedeutet beispielsweise Version 1.0, Build-Nummer 12. Nach einer Fehlerkorrektur kannst du 1.0 (13) hochladen: Die Versionsnummer bleibt gleich, aber der installierte Inhalt ist ein anderer.[7]

Gruppe (Group): Sie legt fest, wer welche Builds erhalten kann. Du kannst etwa die Gruppen „Team“ und „Früher Zugang“ anlegen und ihnen dieselben oder unterschiedliche Builds zuweisen. Eine Gruppe kann mehrere Builds enthalten, und ein gewöhnlicher Build kann mehreren Gruppen zugewiesen werden.[2][5][6]

TestFlight-Prüfung (TestFlight App Review): Apples Prüfung für externe Tests. Sie ist nicht dasselbe wie die Prüfung für die reguläre Veröffentlichung im App Store.[1][6]

Mit diesem Zusammenhang behältst du den Überblick: Die App ist das gesamte Projekt, ein Build ist ein bestimmter installierbarer Stand davon, und die Gruppe entscheidet, wer ihn testen darf. Ein öffentlicher Einladungslink gehört zu einer externen Gruppe und ist nicht dauerhaft an einen bestimmten Build gebunden.

4. Was müssen Anbieter und Testpersonen vor dem Start vorbereiten?

Was du als Anbieter brauchst

1. Eine gültige Mitgliedschaft im Apple Developer Program. Apples regulärer Preis beträgt derzeit 99 US-Dollar pro Jahr. Regionale Preise können abweichen; bestimmte berechtigte Organisationen können eine Gebührenbefreiung beantragen. TestFlight ist in den entsprechenden Mitgliedschaftsleistungen enthalten und kein separat zu kaufendes Tester-Abonnement.[4]
2. Einen passenden App-Eintrag in App Store Connect. App-Kennung, Signierung und hochgeladener Inhalt müssen zusammenpassen. Du kannst nicht einfach die Installationsdatei einer anderen App hinzufügen.[7]
3. Ausreichende, aber nicht übermäßige Kontoberechtigungen. Builds können mit den Rollen Account Holder, Admin, App Manager oder Developer hochgeladen werden. Für die Verwaltung externer Tests ist die Rolle Account Holder, Admin oder App Manager erforderlich. Wer hochladen darf, kann deshalb nicht automatisch alle Einstellungen für externe Tests bedienen.[6][7]
4. Testinformationen. Dazu gehören eine App-Beschreibung, eine E-Mail-Adresse für Rückmeldungen und Hinweise dazu, was getestet werden soll. Für die externe Prüfung werden außerdem Kontaktangaben und ein tatsächlich nutzbarer Zugang zur Anmeldung oder zu den Funktionen benötigt.[6][8]
5. Geeignete Testgeräte und Zeit. Ein erfolgreicher Upload bedeutet nicht, dass die Installation und die wichtigsten Funktionen bereits geprüft wurden.

Gib dein Apple-Passwort nicht an Freunde weiter. Um andere eine App testen zu lassen, verschickst du eine Einladung – du teilst kein Verwaltungskonto.

Was gewöhnliche Testpersonen brauchen

Du brauchst nur einen Apple Account, ein kompatibles Gerät, TestFlight und eine gültige Einladung. Eine kostenpflichtige Mitgliedschaft im Entwicklerprogramm oder Zugang zur Entwicklerverwaltung ist nicht nötig.[1][3]

Zum Überprüfungsdatum dieses Artikels nennt Apples TestFlight-Hilfe für iPhone und iPad iOS 16 beziehungsweise iPadOS 16 oder neuer als Voraussetzung. Die jeweilige App kann jedoch ein neueres Betriebssystem verlangen. Auch öffentliche Einladungen können nach Gerät und Betriebssystemversion filtern. Dass sich TestFlight installieren lässt, bedeutet nicht, dass jede darin angebotene App installiert werden kann.[3][6]

Wenn du einen von Arbeit oder Schule bereitgestellten verwalteten Apple Account verwendest, solltest du die Voraussetzungen besonders genau prüfen: Apples Hilfe zu externen Tests erklärt ausdrücklich, dass diese Accounts nicht zum Testen von Builds verwendet werden können. Die Hilfe zu internen Tests nennt gesondert den Ausschluss verwalteter Accounts, die in reservierten Domains erstellt wurden. Prüfe in solchen Fällen die jeweilige Hilfeseite und die Richtlinien deiner Organisation, statt von einem defekten Einladungslink auszugehen.[5][6]

5. Was unterscheidet interne und externe Tests?

Entscheidend sind die Identität und die Berechtigungen in der Verwaltungsoberfläche – nicht, wie gut du die Person kennst oder ob die Einladung per E-Mail verschickt wurde.

Breite Tabellen lassen sich horizontal scrollen. Mit der Tastatur kannst du die Tabelle fokussieren und die Pfeiltasten verwenden.

Als interne Testpersonen kommen die Rollen Kontoinhaber (Account Holder), Administrator (Admin), App-Manager (App Manager), Entwickler (Developer) und Marketing (Marketing) infrage. Zusätzlich ist Zugriff auf die betreffende App erforderlich.[2][5]

Auch wenn du einen Freund privat per E-Mail einlädst, sind externe Tests meist die richtige Wahl. Extern bedeutet nicht öffentlich: Du kannst nur einige wenige Personen einladen und auf einen öffentlichen Link verzichten.

Gib gewöhnlichen Testpersonen keine Administratorrechte, nur um eine Prüfung zu sparen. Das ist kein Schalter zum Installieren, sondern eine echte Berechtigung zur Verwaltung.

Ein weiteres leicht übersehenes Limit: Mit einem individuellen Entwicklerkonto kannst du höchstens 50 App Store Connect-Benutzer hinzufügen. Das TestFlight-Limit von „100 internen Testpersonen“ bedeutet daher nicht, dass jedes individuelle Konto zusätzlich 100 Verwaltungsbenutzer anlegen kann.[9]

6. Wie fügt man einen Build hinzu? Upload und Gruppenzuweisung unterscheiden

Das sind tatsächlich 2 verschiedene Vorgänge:

• Build hochladen: Die fertig erstellte App aus dem Entwicklungs- oder Build-Werkzeug an Apple übermitteln.
• Build einer Gruppe hinzufügen: Einen bereits hochgeladenen, verfügbaren Build auswählen und dieser Gruppe bereitstellen.

„Builds hinzufügen (Add Builds)“ in einer TestFlight-Gruppe in App Store Connect erstellt keine App aus hineingezogenem Quellcode. Es ist auch keine Schaltfläche zum Hochladen einer lokalen Datei.[5][6][7]

Erste Verteilung: Was tun, wenn es noch keinen App-Eintrag gibt?

Öffne mit der Rolle Account Holder, Admin oder App Manager Apps (Apps) → „+“ → Neue App (New App). Wähle die Plattform und trage die erforderlichen Angaben ein, darunter App-Name, primäre Sprache, App-Kennung (Bundle ID) und eine SKU zur internen Verwaltung. Lege anschließend den Zugriff für Mitglieder fest und erstelle den Eintrag. Die App-Kennung muss zum Projekt passen. Wenn du noch nicht weißt, welche Kennung richtig ist, frage die für den Build zuständige Person, statt willkürlich die Kennung einer anderen App zu wählen.

Lässt sich der Eintrag nicht erstellen, prüfe, ob der Kontoinhaber die neuesten Vereinbarungen akzeptiert hat. Ein App-Eintrag schafft nur den Verwaltungsbereich – die App ist damit weder hochgeladen noch veröffentlicht.[15]

Der grundlegende Upload-Ablauf mit Xcode

Wenn du bereits ein iOS-Projekt hast, kannst du so vorgehen:

1. Prüfe, ob App-Kennung und Signierungsteam zum App-Eintrag in App Store Connect passen.
2. Vergib für diesen Upload eine noch nicht verwendete Build-Nummer, zum Beispiel 1.0 (13) statt 1.0 (12).
3. Wähle ein Ziel für die Verteilung auf echten Geräten und erstelle über Product → Archive ein Archiv. Lade nicht die Simulatorversion hoch.
4. Wähle unter Window → Organizer → Archives das Archiv aus und klicke auf Distribute App. Für reguläres TestFlight und eine spätere Veröffentlichung wählst du TestFlight & App Store; in einem benutzerdefinierten Ablauf entspricht das der Verteilung über App Store Connect. Folge den Schritten zur Signierung und zum Upload.[16]
5. Öffne nach dem Upload App Store Connect → Apps (Apps) → deine App → TestFlight.
6. Warte auf die Verarbeitung durch Apple. Beantworte Fragen zur Exportkonformität wahrheitsgemäß entsprechend der tatsächlich verwendeten Verschlüsselung. Wähle nicht pauschal „Keine Verschlüsselung“, nur um fortfahren zu können.
7. Sobald die Verarbeitung abgeschlossen und der Build verfügbar ist, fügst du ihn einer internen oder externen Testgruppe hinzu.

Auch Werkzeuge wie Xcode Cloud und Transporter können am Upload beteiligt sein. Ein anderes Werkzeug lässt Apples Verarbeitung, Compliance-Anforderungen, Gruppenzuweisung und externe Prüfung nicht entfallen.[7] Die Mindestanforderungen an Upload-Werkzeuge und SDKs ändern sich. Prüfe beim Hochladen Apples aktuelle Upload-Anforderungen. Die zum Erstellen verwendete SDK-Version ist nicht dasselbe wie die niedrigste Betriebssystemversion, auf der sich die App installieren lässt.[18]

Vorsicht bei „Nur für interne Tests“

TestFlight Internal Only ist eine Einschränkung, die durch die gewählte Upload-Art entsteht: Solche Builds können nur internen Gruppen zugewiesen werden. Sie dürfen weder für externe Tests noch für die reguläre Veröffentlichung verwendet werden. Wenn du später externe Tests oder eine Veröffentlichung planst, musst du einen neuen Build auf geeignete Weise hochladen. Den bisherigen Build lediglich einer anderen Gruppe zuzuweisen, reicht nicht.[5][6]

Umgekehrt gilt: Ein gewöhnlicher Build wird nicht automatisch zu einem „Nur für interne Tests“-Build, nur weil du ihn zuerst einer internen Gruppe hinzufügst. Verwechsle „wird gerade intern getestet“ nicht mit „dieser Upload ist ausschließlich für interne Nutzung zugelassen“.

Wenn du deine App in AirBuild entwickelst

AirBuild kann dich dabei unterstützen, verteilbare Builds vorzubereiten, sie zu signieren und hochzuladen sowie Testgruppen und Einladungen einzurichten. Sage zunächst klar, dass du die App „über TestFlight verteilen“ möchtest und ob sie für Teammitglieder oder externe Freunde gedacht ist. Verbinde oder bestätige dann das berechtigte Apple-Entwicklerteam und kläre Testhinweise, Feedback-E-Mail-Adresse, Kontaktperson für die Prüfung und die Frage, ob ein öffentlicher Link angeboten werden soll.

Apples Regeln zur Verarbeitung, externen Prüfung, Personenanzahl und Gültigkeit gelten weiterhin. Bei der Übergabe muss klar sein, um welche Version und Build-Nummer es geht, welche Gruppe bereits Zugriff hat und ob die externe Prüfung noch aussteht. Unterstützung durch AirBuild bedeutet weder, dass sich Apples Prüfung umgehen lässt, noch, dass Tests im Simulator bereits jedes Verhalten auf echten Geräten abdecken.

Das beschreibt die Arbeitsweise von AirBuild und ist keine Vorgabe von Apple, ein bestimmtes Werkzeug zu verwenden. Auch ohne lokales Xcode auf einem Mac musst du nicht zwangsläufig alle Details der Build-Erstellung lernen, um gemeinsam mit anderen eine App zu verteilen.

7. Wie fügt man interne Testpersonen hinzu? Hier gibt es 2 Einladungen

Geeignet für dich selbst und für Teammitglieder, die tatsächlich Zugriff auf die App-Verwaltung benötigen.

Erste Einladung: Zugriff auf die Verwaltungsoberfläche einrichten

Benutzer werden mit der Rolle Kontoinhaber (Account Holder), Administrator (Admin) oder App-Manager (App Manager) hinzugefügt:

1. Öffne Benutzer und Zugriff (Users and Access) → Personen (People).
2. Klicke auf „+“ und gib Name und E-Mail-Adresse ein.
3. Weise eine geeignete Rolle zu. Soweit sich der App-Zugriff für diese Rolle einschränken lässt, gewähre nur Zugriff auf die benötigten Apps. Vergib nicht standardmäßig Administratorrechte. Bei Administratoren, Finanzbenutzern und Benutzern mit Zugriff auf zusätzliche Ressourcen wie Berichte oder Zertifikate lässt sich der Zugriff nicht auf einzelne Apps beschränken. Prüfe den Umfang, bevor du Berechtigungen vergibst.[9]
4. Sende die Einladung. Die andere Person muss sie annehmen, um den Verwaltungszugang zu aktivieren.

Laut Apples aktuellen Angaben läuft diese Einladung zur Verwaltungsoberfläche nach 3 Tagen ab und kann dann erneut gesendet werden. Sie ist weder die spätere TestFlight-Einladung noch die 90-Tage-Frist eines Builds.[9]

Hat die Person bereits eine geeignete Rolle und Zugriff auf die App, kannst du diesen Schritt überspringen.

Zweite Einladung: Person und Build zur internen Testgruppe hinzufügen

1. Öffne Apps → deine App → TestFlight.
2. Klicke neben Interne Tests (Internal Testing) auf „+“ und erstelle eine Gruppe, zum Beispiel „Team“.
3. Öffne die Gruppe und wähle Testpersonen einladen (Invite Testers) oder das „+“ neben der Testpersonenliste.
4. Wähle die berechtigten Verwaltungsbenutzer aus und füge sie der Gruppe hinzu.
5. Klicke auf Builds hinzufügen (Add Builds) und wähle einen fertig verarbeiteten, testbaren Build.
6. Trage unter Was soll getestet werden? (What to Test) die Testhinweise ein und füge den Build hinzu.
7. Bitte die Person, TestFlight auf ihrem Gerät zu installieren, die Testeinladung anzunehmen und anschließend die App zu installieren.[5]

Fertig bist du nicht schon dann, wenn jemand in der Liste steht. Es muss auch einen verfügbaren Build geben, und die Person muss die Einladung tatsächlich annehmen und die App installieren.

Die gewünschte Person ist nicht auffindbar? Prüfe zuerst, ob sie die Verwaltungseinladung angenommen hat, ob ihre Rolle geeignet ist und ob sie auf diese App zugreifen darf. Lade nicht sofort die App erneut hoch.

Für manche internen Gruppen lässt sich die automatische Verteilung aktivieren. Gehe aber nicht davon aus, dass Builds aus allen Quellen automatisch in allen Gruppen landen. Apples aktuelle Hilfe weist ausdrücklich darauf hin, dass mit Xcode Cloud erstellte Builds in App Store Connect manuell einer Gruppe hinzugefügt werden müssen.[5]

8. Wie fügt man externe Testpersonen hinzu?

Geeignet für Freunde, Kunden, frühe Nutzer und Community-Testpersonen. Wenn du eine App zum ersten Mal mit anderen teilst, ist das meist der passendere Weg.

Zuerst eine externe Gruppe für den Build vorbereiten

Diese Schritte erfordern die Rolle Account Holder, Admin oder App Manager:

1. Wenn es noch keine interne Gruppe gibt, erstelle zuerst eine. Apples aktuelle Anleitung für externe Tests nennt eine vorhandene interne Gruppe als Voraussetzung. Das bedeutet weder, dass die App zuvor regulär veröffentlicht sein muss, noch, dass externe Testpersonen zuerst interne Mitglieder werden müssen.[6]
2. Öffne Apps → deine App → TestFlight.
3. Trage unter Testinformationen (Test Information) eine Beschreibung der Betaversion und eine Feedback-E-Mail-Adresse ein. Ergänze die für die Prüfung benötigten Kontaktangaben. Wenn eine Anmeldung nötig ist, stelle einen funktionierenden Prüfzugang und eine Bedienungsanleitung bereit und sorge dafür, dass die zugehörigen Server erreichbar sind. Verwende keine privaten Daten echter Nutzer als Demodaten.[6][8][14]
4. Klicke neben Externe Tests (External Testing) auf „+“ und erstelle eine Gruppe, etwa „Früher Zugang“.
5. Öffne die Gruppe, klicke auf Builds hinzufügen und wähle Plattform, Version und konkreten Build.
6. Fülle Was soll getestet werden? aus. Schreibe beispielsweise „Erstelle einen Eintrag, schließe die App und öffne sie erneut. Prüfe, ob der Eintrag noch vorhanden ist“ statt nur „Probiert einfach mal etwas aus“.
7. Aktiviere bei Bedarf Testpersonen automatisch benachrichtigen (Automatically notify testers).
8. Wähle je nach angezeigtem Status die Einreichung zur Prüfung oder den Teststart und warte, bis alle erforderlichen Prüfungen abgeschlossen sind.
9. Lade Testpersonen per E-Mail, über einen öffentlichen Link oder über beide Wege ein.[6]

Einmal bestanden – danach nie wieder eine Prüfung?

Nein.

Der erste für externe Tests eingereichte Build benötigt eine vollständige Prüfung. Spätere Builds derselben Version benötigen möglicherweise keine vollständige Prüfung; eine dauerhafte Befreiung lässt sich aber nicht zusagen. Apple verlangt außerdem, dass wesentliche Aktualisierungen einer Betaversion vor der Verteilung zur TestFlight-Prüfung eingereicht werden.[6][14]

Die Prüfungsdauer ist nicht festgelegt. Versprich niemandem, dass die App „garantiert wenige Minuten nach dem Upload installierbar“ ist oder „sicher innerhalb von 24 Stunden freigegeben“ wird.

Wenn du beim Hinzufügen des Builds die automatische Benachrichtigung nicht aktiviert hast, musst du nach der Freigabe noch Testpersonen benachrichtigen (Notify Testers) ausführen: Wähle links in TestFlight unter Builds (Builds) die Plattform und Version aus und klicke dann in der Statuszeile des Builds auf die Benachrichtigungsoption. Freigegeben, verteilt und von der anderen Person installiert sind 3 verschiedene Dinge.[6]

Möglichkeit 1: Per E-Mail einladen

Öffne die externe Gruppe und klicke neben Testpersonen (Testers) auf „+“. Du kannst die E-Mail-Adresse einer neuen Testperson eingeben, vorhandene Testpersonen auswählen oder eine Liste importieren.[6]

Die Person erhält eine Testeinladung, aber dadurch keine Verwaltungsberechtigungen in App Store Connect.

Möglichkeit 2: Einen öffentlichen Link erstellen und teilen

Öffne die Testpersonenseite der externen Gruppe und wähle Öffentlichen Link erstellen (Create Public Link):

1. Wähle Für alle offen (Open to Anyone) oder Nach Kriterien filtern (Filter by Criteria).
2. Lege bei Bedarf fest, wie viele Personen über den Link beitreten dürfen. Möglich sind 1–10.000; die Gesamtgrenze für externe Testpersonen dieser App gilt weiterhin.
3. Wenn du filterst, lege die Anforderungen an Geräte und Betriebssystemversionen fest.
4. Bestätige die Einstellungen, kopiere den tatsächlich erzeugten Link und teile ihn mit Freunden, in einer Community, per E-Mail oder auf einer Website.[6]

Der Link beginnt üblicherweise mit https://testflight.apple.com/join/…. Kopiere den echten, von Apple erzeugten Link. Erfinde nicht selbst den Code am Ende und verwende nicht die Adresse der App Store Connect-Verwaltungsseite als Installationslink.

Ein QR-Code kann denselben Link enthalten. Er ist aber keine andere Verteilungsart und umgeht auch keine Prüfung.

Prüfe vor dem Teilen des Links diese 4 Punkte

• Die externe Zielgruppe enthält den Build, den du teilen möchtest.
• Die erforderliche Prüfung ist bestanden und die Verteilung hat begonnen.
• Der Build ist nicht abgelaufen und mit den Zielgeräten kompatibel.
• Der Link ist aktiviert, es gibt freie Plätze und die Filter schließen die gewünschten Personen nicht aus.[3][6]

Ein aufrufbarer Link garantiert nicht, dass sich die neue Version installieren lässt. Auch wenn ein älterer Build verfügbar ist, muss der neueste Build dieser Gruppe noch nicht bereitgestellt worden sein.

Öffentliche Links lassen sich weiterleiten und sind keine vertrauliche Einladungsliste. Wenn du nur einige bestimmte Personen einladen möchtest, nutze vorzugsweise E-Mail-Einladungen und sichere den Zugang zusätzlich über die Kontoberechtigungen deiner App ab.

Bei Personen, die über einen öffentlichen Link beitreten, werden Name und E-Mail-Adresse standardmäßig nicht in der TestFlight-Testpersonenliste angezeigt. Angaben wie Installationsdatum, Nutzungssitzungen und Abstürze sind jedoch weiterhin sichtbar. Wenn die Person aktiv Feedback sendet, kann sie dabei auch ihre E-Mail-Adresse angeben. Das bedeutet keine vollständige Anonymität gegenüber Apple oder dem Anmeldesystem der App selbst.[3][6]

Bei späteren Build-Updates kannst du gewöhnlich denselben Link der externen Gruppe weiterverwenden und musst nicht jedes Mal alle Testpersonen neu einladen. Unter Verwalten (Manage) kannst du außerdem Filter und Personenlimit ändern oder den Link deaktivieren. Das Deaktivieren schließt den Zugang für neue Beitritte. Es löscht weder vorhandene Installationen noch App-Konten oder Serverdaten.[6]

9. Wie installieren Testpersonen die App, beziehen Updates, geben Feedback und steigen aus?

Nachdem du eine Einladung erhalten hast, gehst du auf dem Test-iPhone oder -iPad so vor:

1. Installiere Apples offizielle TestFlight-App aus dem App Store.
2. Öffne die Einladungs-E-Mail oder den öffentlichen Link.
3. Folge den Hinweisen zu TestFlight, wähle Annehmen (Accept) und tippe anschließend auf Installieren (Install).
4. Lies die Testhinweise und beginne mit dem Ausprobieren.
5. Wenn ein neuer Build verfügbar ist, aktualisiere die App in TestFlight. Du kannst auch automatische Updates aktivieren. Bestehende Testpersonen sehen möglicherweise direkt Aktualisieren (Update) oder Öffnen (Open).[3]

Für gewöhnliche externe Tests brauchst du weder das Passwort des Entwicklers noch eine Rolle in der Verwaltungsoberfläche. Du musst auch nicht zuerst einen speziellen Sandbox-Account erstellen.

Ist die offizielle Version schon installiert – habe ich dann 2 Apps?

Normalerweise nicht. Die TestFlight-Betaversion derselben App ersetzt auf dem Gerät die App Store-Version.[3]

Sichere oder exportiere deshalb vorher wichtige Daten. Eine Betaversion kann das Datenformat verändern. Eine ältere Version kann Daten, die eine neuere Version geschrieben hat, möglicherweise nicht mehr lesen. Ein Versionswechsel ist also nicht garantiert verlustfrei.

Wenn der Entwickler noch andere gültige Builds anbietet, kannst du sie unter Frühere Builds (Previous Builds) auswählen. Das ist kein Download-Archiv, das dauerhaft alle historischen Versionen bereithält.[3]

Wie gibst du möglichst hilfreiches Feedback?

Öffne den Eintrag der App in TestFlight und tippe auf Beta-Feedback senden (Send Beta Feedback). Auf unterstützten Systemen kannst du auch in der Test-App einen Screenshot aufnehmen und darüber Feedback senden. Nach einem Absturz kann eine Aufforderung erscheinen, zusätzliche Informationen zu teilen.[3]

Hilfreicher als „Funktioniert nicht“ ist zum Beispiel:

Ich verwende [Gerätemodell] mit [Betriebssystemversion]. Die App hat [Version und Build-Nummer]. Ich öffne die Einstellungen, ändere die Sprache und kehre zur Startseite zurück. Ich erwarte, dass sich dort auch die Sprache ändert. Tatsächlich wird die Startseite weiterhin in der bisherigen Sprache angezeigt. Bei 2 Wiederholungen ist das jedes Mal passiert. Einen Screenshot habe ich beigefügt.

Achte darauf, keine Passwörter, Zahlungsinformationen oder privaten Angaben anderer Personen mit aufzunehmen. Über TestFlight eingereichtes Feedback wird auch Apple zur Verfügung gestellt. Eine eigene Feedback-Funktion der App ist ein separater Kanal.[3]

Was tun, wenn du nicht mehr testen möchtest?

Öffne die Informationsseite der App in TestFlight und wähle Testen beenden (Stop Testing). Wenn es eine reguläre Version gibt, kannst du sie anschließend im App Store herunterladen oder kaufen. Bei einer noch unveröffentlichten App, die nur als Betaversion existiert, gibt es möglicherweise keine offizielle Version, zu der du wechseln kannst.[3]

Das Beenden des Tests löscht nicht dein in der App registriertes Konto. Für Konten und Cloud-Daten gelten die Regeln der jeweiligen App.

10. Wird bei Zahlungen in TestFlight wirklich Geld abgebucht?

Testkäufe über Apples In-App-Käufe in einer über TestFlight installierten App laufen in der Sandbox ab. Dabei wird kein echtes Geld abgebucht. Das gilt auch für Abonnementtests über StoreKit.[3][10]

Die „Sandbox“ ist eine Übungsumgebung für Kaufabläufe: Die App kann Produktinformationen abrufen, Testkäufe starten, Käufe wiederherstellen und Transaktionsbenachrichtigungen verarbeiten. Dadurch entstehen aber keine echten Verkaufserlöse.[10]

Am häufigsten wird missverstanden, wie weit diese Sandbox reicht.

Keine Abbuchung bedeutet nicht, dass die offizielle Version dauerhaft kostenlos bleibt

Apple erklärt ausdrücklich, dass In-App-Käufe aus der Testphase nicht als Käufe in die offizielle App Store-Version übernommen werden. Versprich Testpersonen daher nicht: „Einmal jetzt antippen, und nach der Veröffentlichung hast du für immer Premium.“[3]

Wenn Entwickler unabhängig davon ihrem App-Konto zusätzliche Leistungen schenken, ist das eine eigene geschäftliche Entscheidung und keine automatische TestFlight-Regel.

Die Zeitabläufe bei Testabonnements entsprechen nicht der echten Abrechnung

Für automatisch verlängerbare Abonnements beschreibt Apples aktuelle TestFlight-Hilfe folgenden Ablauf: Unabhängig von der regulären Abonnementdauer wird im Test täglich verlängert, höchstens 6-mal innerhalb einer Woche. Mit den erweiterten Einstellungen eines Sandbox-Accounts lässt sich die Verlängerungsrate zusätzlich anpassen. Übertrage Angaben wie „5 Minuten“ oder „12 Verlängerungen“ aus anderen Sandbox-Szenarien nicht einfach auf gewöhnliche TestFlight-Tests.[3][10]

Diese beschleunigten Abläufe helfen beim Testen von Verlängerung und Ablauf. Sie sind kein Maßstab für die Abrechnungszeiträume regulärer Nutzer.

Nur Apples Kaufkanal wechselt automatisch in die Sandbox – nicht die gesamte App

Eine TestFlight-App kann weiterhin:

• auf produktive Server zugreifen und echte Datensätze ändern;
• echte E-Mails oder Nachrichten versenden;
• echte Konten oder Daten löschen;
• eine Website öffnen, auf der tatsächlich Geld bezahlt wird;
• Zahlungsarten verwenden, die keine Apple In-App-Käufe sind.

Zahlungen im Web, Apple Pay und In-App-Käufe mit StoreKit sind nicht dasselbe. Nur weil eine App aus TestFlight stammt, sind ein Web-Checkout oder reale Geschäftsvorgänge nicht automatisch kostenlos. Entwickler müssen Testdaten, Server und andere Zahlungsumgebungen gesondert einrichten.[10]; Erläuterung der Systemgrenzen einer App

Muss jede Testperson einen Sandbox-Account erstellen?

Nein. Für die gewöhnliche Installation über TestFlight und für Kaufprüfungen kannst du deinen alltäglichen Apple Account verwenden.[10]

Nur wenn Entwickler Funktionen wie das Löschen der Kaufhistorie oder erweiterte Testeinstellungen benötigen, müssen sie gemäß Apples Dokumentation einen Sandbox Apple Account einrichten. Zu diesen erweiterten Schritten kann das Abmelden unter „Medien & Käufe“ gehören. Das kann den Zugriff auf gekaufte Inhalte auf dem Gerät beeinflussen. Es ist keine Voraussetzung für die normale Testinstallation. Erst recht sollte man Testpersonen nicht ohne Weiteres dazu auffordern, das gesamte Gerät von iCloud abzumelden. Apple empfiehlt, ein separates Testgerät in Betracht zu ziehen.[10]

Wenn ein Kauf als erfolgreich angezeigt wird, die App aber keine Funktionen freischaltet, melde das trotzdem dem Entwickler. Produktkonfiguration, Transaktionsprüfung, Freischaltung, Wiederherstellung von Käufen und Verarbeitung von Verlängerungen müssen korrekt umgesetzt sein. Ein erfolgreicher Sandbox-Kauf beweist weder eine funktionierende echte Zahlung noch einen Geldeingang oder die Korrektheit der gesamten Abonnementlogik.

11. Welche Grenzen hat TestFlight?

Breite Tabellen lassen sich horizontal scrollen. Mit der Tastatur kannst du die Tabelle fokussieren und die Pfeiltasten verwenden.

Hilft nach Ablauf der 90 Tage eine neue Einladung?

Nein. Die Frist gilt für den Build, nicht für einzelne Testpersonen. Wer später beitritt, erhält nicht erneut volle 90 Tage. Nach Ablauf lässt sich die Betaversion nicht mehr öffnen. Der Entwickler muss einen neuen gültigen Build bereitstellen.[3]

Wenn der Test ohne Unterbrechung weiterlaufen soll, lade vor Ablauf des alten Builds einen neuen hoch, verteile ihn und erinnere alle an das Update. Der neue Build hat seine eigene Frist und verlängert nicht die Lebensdauer des alten.

Kann man dauerhaft Apps oder Testplätze über TestFlight verkaufen?

Betrachte TestFlight nicht als Verkaufskanal, mit dem sich die reguläre Veröffentlichung umgehen lässt.

Apples Prüfrichtlinie 2.2 verlangt, dass Test-Apps die Prüfregeln einhalten und zur öffentlichen Veröffentlichung bestimmt sind. Außerdem darf die TestFlight-Verteilung nicht gegen irgendeine Form von Gegenleistung angeboten werden, auch nicht als Crowdfunding-Belohnung. Einfach gesagt: „Nur wer für den Gruppenzugang bezahlt, bekommt die Betaversion“ ist kein zulässiges normales TestFlight-Verteilungsmodell.[14]

12. Häufige Probleme: Warum können andere die App nicht installieren?

Breite Tabellen lassen sich horizontal scrollen. Mit der Tastatur kannst du die Tabelle fokussieren und die Pfeiltasten verwenden.

Das sind Ansatzpunkte zur Fehlersuche. Eine einzelne Fehlermeldung reicht nicht immer aus, um die Ursache sicher zu bestimmen.[3][5][6][11]

Besonders wichtig: Der grüne Status „Wird getestet (Testing)“ in der Verwaltung kann sich nur auf eine interne Gruppe beziehen. Um festzustellen, ob externe Personen installieren können, musst du die externe Zielgruppe, den konkreten Build und dessen Verfügbarkeit in dieser Gruppe prüfen.[11]

„Bereit zur Einreichung (Ready to Submit)“, „Warten auf Prüfung (Waiting for Review)“, „In Beta-Prüfung (In Beta Review)“ und „Bereit zum Testen (Ready to Test)“ sind ebenfalls unterschiedliche Phasen. Gerade bei „Bereit zum Testen“ kann es noch nötig sein, Testpersonen hinzuzufügen oder die manuelle Benachrichtigung auszuführen.[11]

13. Wo sehen Entwickler Feedback, und wie verteilen sie die nächste Version?

Unter Apps → deine App → TestFlight → Feedback (Feedback) kannst du Screenshots (Screenshots) und Abstürze (Crashes) ansehen und unter anderem nach Version oder Gerät filtern. Ob Feedback direkt aus der App gesendet werden kann, hängt auch von den Gruppeneinstellungen ab.[12]

Behebe zuerst reproduzierbare Probleme und starte dann die nächste Runde:

1. Korrigiere den Fehler, erstelle einen Build mit neuer Build-Nummer und lade ihn hoch.
2. Warte auf die Verarbeitung und erledige die erforderlichen Compliance-Angaben.
3. Füge den neuen Build der Zielgruppe hinzu und durchlaufe die erforderliche externe Prüfung.
4. Aktualisiere die Testhinweise und benachrichtige die Testpersonen entsprechend den Einstellungen.
5. Bitte Personen aus der Zielgruppe zu bestätigen, welche Version und welchen Build sie tatsächlich installiert haben, und das ursprüngliche Problem erneut zu prüfen.

Upload-Verlauf, Gruppenlisten und Freigaben sind wichtig. Am Ende musst du aber außerdem sicherstellen: Die vorgesehenen Personen haben tatsächlich den vorgesehenen Build installiert.

Ein Screenshot eines internen Tests beweist nicht, dass alle externen Personen installieren können. Und ein erfolgreicher Start im Simulator ersetzt keine Installation auf einem echten Gerät.

14. Wie beendet man einen Test oder veröffentlicht die App regulär?

Überlege zuerst, was du beenden möchtest:

• Keine neuen Personen mehr aufnehmen: Deaktiviere den öffentlichen Einladungslink der externen Gruppe.
• Ändern, wer welche Builds erhält: Verwalte Testpersonen, Gruppen und Build-Zuweisungen.
• Neue Installationen eines Builds stoppen: Öffne die Build-Details und wähle Build ablaufen lassen (Expire Build). Das ist kein Fernlöschen aller installierten Apps und keine Löschung von Cloud-Konten.[6][13]
• Regulär veröffentlichen: Bereite die Informationen für die offizielle App Store-Version vor, wähle einen geeigneten Build und reiche ihn gesondert zur regulären Prüfung ein.[1][2]

Ein geeigneter Build, der bereits auf gewöhnlichem Weg für TestFlight hochgeladen wurde, kann für die reguläre Einreichung ausgewählt werden. Allein wegen der Veröffentlichung muss also nicht unbedingt ein neuer Build erstellt werden. Ändert sich jedoch der Code, ist ein neuer Upload nötig. Uploads „nur für interne Tests“ sind außerdem von der regulären Veröffentlichung ausgeschlossen.[2][5]

Eine bestandene TestFlight-Prüfung veröffentlicht die App nicht automatisch im App Store. Umgekehrt beendet die Veröffentlichung einer offiziellen Version auch nicht automatisch noch gültige Betaversionen. Das Testende und den Wechsel der Nutzer musst du getrennt planen.[1]

15. Diese Nachricht kannst du an deine ersten Testpersonen schicken

Ich würde dich gern bitten, eine frühe Version von [App-Name] auszuprobieren.

Installiere zuerst Apples offizielle TestFlight-App aus dem App Store. Öffne dann auf deinem iPhone [tatsächlicher Einladungslink], nimm die Einladung an und installiere die App.

Bitte teste in dieser Runde vor allem: [1–2 konkrete Aufgaben]. Unterstützte Geräte und Betriebssysteme: [tatsächliche Anforderungen].

Das ist eine Betaversion, die Fehler enthalten kann. Bitte sichere vorher wichtige Daten. Falls etwas nicht wie erwartet funktioniert, kannst du mir in TestFlight über „Beta-Feedback senden“ mitteilen, was du gemacht hast, was du erwartet hast und was tatsächlich passiert ist. Ein Screenshot und die Versionsnummer helfen besonders.

Ersetze die Angaben in eckigen Klammern durch echte Informationen. Sende die Nachricht erst, wenn der Build in der externen Zielgruppe tatsächlich installierbar ist. Verschicke nicht vorab einen noch auf Prüfung wartenden Link an alle und behaupte, er sei bereits nutzbar.

Vor der Verteilung: Diese 10 Punkte zuletzt prüfen

• □ Ich habe interne oder externe Tests anhand der Kontoberechtigungen gewählt und niemandem aus Bequemlichkeit zu viele Rechte gegeben.
• □ Der Ziel-Build ist fertig verarbeitet, und es gibt keine ungelösten Hindernisse für die Verteilung.
• □ Die Zielgruppe enthält tatsächlich diesen Build.
• □ Die erforderliche externe Prüfung ist bestanden, und die nötigen Benachrichtigungen wurden gesendet.
• □ Ich habe den Einladungsweg geprüft: E-Mail-Einladungen gingen an die richtigen Personen; ein verwendeter öffentlicher Link ist aktiviert und hat freie Plätze. Die Zielgeräte und Betriebssysteme erfüllen die Anforderungen.
• □ Testbeschreibung, Feedback-E-Mail-Adresse und Testhinweise sind korrekt und hilfreich.
• □ Die Testpersonen wissen, dass es eine Betaversion ist und dass sie die offizielle Version ersetzen kann.
• □ Ich unterscheide Sandbox-Käufe von produktiven Servern, Webzahlungen und realen Aktionen.
• □ Ich habe das Ablaufdatum des Builds geprüft und Folge-Updates eingeplant.
• □ Jemand aus der Zielgruppe hat bestätigt, den vorgesehenen Build tatsächlich installiert zu haben – nicht nur die Einladungsseite geöffnet zu haben.

Bei deiner ersten App-Verteilung ist „Upload abgeschlossen“ nicht das eigentliche Ziel. Erreicht ist es erst, wenn die richtigen Personen die richtige Version installiert haben, wissen, was sie testen sollen, und dir Probleme zurückmelden können.

Quellen und weiterführende Informationen

Die folgenden Quellen wurden am 17. September 2026 überprüft. Historische Meilensteine stützen sich auf zeitgenössische Berichte oder damalige Apple-Mitteilungen; aktuelle Regeln überwiegend auf Apples offizielle Hilfe. Die Benutzeroberfläche kann je nach Sprache und Version abweichen.