Eine App nur selbst zu testen, reicht selten. Du kennst deine eigenen Bedienpfade zu gut und übersiehst genau die Stellen, an denen echte Nutzer stolpern. TestFlight, Apples offizielle Plattform für Beta-Verteilung, löst dieses Problem: Du verteilst Vorabversionen an echte Menschen mit echten Geräten und sammelst Feedback und Crash-Logs ein, bevor die App in den öffentlichen Store geht. Dieser Artikel konzentriert sich auf den anspruchsvolleren Teil – das Einladen und Verwalten externer Tester.
Interne vs. externe Tester
TestFlight unterscheidet zwei Gruppen, und der Unterschied ist wichtig:
- Interne Tester sind Mitglieder deines Teams in App Store Connect mit einer zugewiesenen Rolle. Du kannst eine begrenzte Anzahl davon einladen, und sie erhalten neue Builds sofort – ohne separate Prüfung durch Apple. Ideal für das eigene Team und enge Mitarbeiter.
- Externe Tester sind alle anderen: Freunde, Kunden, eine offene Community. Hier erlaubt TestFlight eine deutlich größere Zahl an Personen (bis zu 10.000 pro App). Der entscheidende Unterschied: Bevor externe Tester einen Build bekommen, muss er einmalig eine Beta-App-Review durchlaufen.
Diese Unterscheidung bestimmt deinen Workflow. Für schnelle interne Iterationen nimmst du interne Tester; für ehrliches Feedback von echten Zielnutzern brauchst du externe.
Die Beta-App-Review für externe Builds
Anders als interne Builds, die sofort verfügbar sind, durchläuft die erste Version, die du an externe Tester verteilst, eine vereinfachte Prüfung durch Apple. Diese Beta-App-Review ist weniger streng als das vollständige App-Store-Review, prüft aber grundlegende Anforderungen und stellt sicher, dass keine offensichtlich problematischen Inhalte verteilt werden. Folgebuilds mit kleineren Änderungen werden oft schneller oder ohne erneute vollständige Prüfung freigegeben, größere Änderungen können erneut geprüft werden.
Damit diese Prüfung gelingt, brauchst du einige Pflichtangaben: eine kurze Beschreibung, was getestet werden soll, eine Feedback-E-Mail und – falls die App einen Login erfordert – Demo-Zugangsdaten. Ohne diese Informationen verzögert sich die Freigabe.
Tester-Gruppen: Struktur von Anfang an
Der Schlüssel zu sauberem Beta-Testing sind Gruppen. Statt alle Tester in einen Topf zu werfen, legst du themenbezogene Gruppen an und ordnest Builds gezielt zu. Typische Aufteilungen:
- Frühe Tester für instabile Builds, die experimentelle Funktionen enthalten.
- Stabile Beta für Tester, die nur ausgereifte Versionen sehen sollen.
- Kunden- oder Stakeholder-Gruppen, die bestimmte Features abnehmen.
Der große Vorteil: Du entscheidest pro Gruppe, welcher Build verteilt wird. So bekommt nicht jeder sofort jede halbfertige Version, und du kannst gezielt eine kleine Gruppe einen riskanten Build prüfen lassen, bevor du ihn breiter ausrollst.
Zwei Wege, externe Tester einzuladen
1. Einladung per E-Mail
Du fügst Tester über ihre E-Mail-Adresse hinzu. Sie erhalten eine Einladung, installieren die kostenlose TestFlight-App aus dem App Store und lösen den Code ein. Dieser Weg eignet sich, wenn du eine bekannte, überschaubare Gruppe einladen willst und nachvollziehen möchtest, wer dabei ist. Du kannst Tester einzeln hinzufügen oder eine Liste importieren.
2. Öffentlicher Link
Alternativ erzeugst du einen öffentlichen TestFlight-Link. Jeder, der ihn öffnet, kann der Beta beitreten, solange Plätze frei sind. Das ist perfekt, um über soziale Medien, eine Landingpage oder eine Community möglichst viele Tester zu gewinnen, ohne jede Adresse einzeln zu erfassen. Du kannst die Zahl der verfügbaren Plätze begrenzen und den Link bei Bedarf jederzeit deaktivieren – etwa wenn genug Tester beigetreten sind.
Beide Wege lassen sich kombinieren: Stakeholder per E-Mail in einer privaten Gruppe, die breite Öffentlichkeit über einen Link in einer separaten Gruppe.
Feedback und Crash-Logs auswerten
TestFlight ist nicht nur Verteilung, sondern auch Rückkanal. Tester können direkt aus der TestFlight-App heraus Feedback senden – inklusive Screenshot und einer kurzen Beschreibung. Dieses Feedback erscheint gebündelt in App Store Connect, sodass du es zentral durchgehst, statt verstreute E-Mails zu sammeln.
Noch wertvoller sind die automatisch erfassten Crash-Logs. Stürzt die App bei einem Tester ab, bekommst du den Absturzbericht mit Stack Trace. So findest du Fehler, die nur auf bestimmten Gerätemodellen, iOS-Versionen oder unter ungewöhnlichen Bedingungen auftreten – genau die Bugs, die im eigenen Test nie sichtbar werden. Behandle eingehende Crashes mit Priorität, denn sie sind die häufigste Ursache für schlechte Bewertungen nach dem Launch.
Die 90-Tage-Regel und Build-Verwaltung
Jeder TestFlight-Build hat eine begrenzte Lebensdauer: Er ist ab dem Upload 90 Tage lang testbar. Danach läuft er ab und Tester können ihn nicht mehr starten. Das ist Absicht – es zwingt zu einem regelmäßigen Build-Rhythmus und verhindert, dass veraltete Versionen ewig im Umlauf bleiben. Plane also, vor Ablauf einen frischen Build zu verteilen, wenn die Beta-Phase länger läuft.
Über die Build-Nummer hältst du verschiedene Versionen auseinander. Jeder Upload braucht eine eindeutige, aufsteigende Build-Nummer bei gleicher Versionsnummer – ein klares, konsistentes Schema erspart später viel Verwirrung. Im Beitrag zu App-Veröffentlichung über App Store Connect erfährst du, wie aus einem getesteten Build am Ende die finale Store-Version wird.
Tipps für eine produktive Beta-Phase
- Klare Testanweisungen: Sag deinen Testern konkret, was sie ausprobieren sollen. „Teste mal“ liefert kaum nützliches Feedback; „Versuche, eine Bestellung abzubrechen und prüfe die Bestätigung“ schon.
- Was-ist-neu-Texte pflegen: Beschreibe bei jedem Build, was sich geändert hat. Tester wissen dann, worauf sie achten sollen.
- Gruppen klein und gezielt halten: Lieber mehrere fokussierte Gruppen als eine riesige, in der niemand weiß, welchen Build er gerade nutzt.
- Feedback ernst nehmen und antworten: Tester, die merken, dass ihr Feedback ankommt, bleiben engagiert und melden mehr.
Wenn du Tester über eine eigene Seite oder per Newsletter gewinnst, helfen dir kleine Hilfsmittel beim Vorbereiten – etwa ein QR-Code-Generator aus dem Webtools-Bereich, mit dem du deinen öffentlichen TestFlight-Link bequem zum Scannen bereitstellst.
Häufige Fragen
Wie viele externe Tester sind möglich?
TestFlight erlaubt bis zu 10.000 externe Tester pro App. Damit lässt sich auch eine größere öffentliche Beta organisieren, vor allem über den öffentlichen Einladungslink.
Müssen externe Tester etwas bezahlen?
Nein. Die TestFlight-App ist kostenlos, und die Teilnahme an einer Beta kostet die Tester nichts. Sie brauchen lediglich ein kompatibles Apple-Gerät und die installierte TestFlight-App.
Warum sehen externe Tester einen neuen Build nicht sofort?
Builds für externe Tester können eine Beta-App-Review durchlaufen, bevor sie verfügbar werden – anders als interne Builds, die sofort bereitstehen. Außerdem musst du den Build der jeweiligen Gruppe aktiv zuweisen, damit er dort erscheint.
Was passiert nach 90 Tagen?
Ein Build läuft 90 Tage nach dem Upload ab und ist dann nicht mehr testbar. Lade rechtzeitig einen neuen Build hoch, wenn deine Beta-Phase länger dauert, damit die Tester nahtlos weitermachen können.