Zum Inhalt springen

Anleitung

Die App vor dem Release dem Kunden zeigen

Die zwei Gruppen von TestFlight, dass externes Testen eine eigene Prüfung durchläuft, und warum interne Tests die Closed-Testing-Pflicht stören.

Geschrieben für: Teams, die die App vor dem Livegang zeigen müssenZuletzt aktualisiert: 6 Min. Lesezeit

Kurz gesagt

Wie zeigt man eine App vor der Veröffentlichung?

Vor dem Release zeigt man eine App unter iOS über TestFlight und unter Android über die Testtracks der Play Console. Bei TestFlight läuft der interne Test sofort mit Teammitgliedern; der externe Test durchläuft eine eigene Beta-Prüfung und braucht eine Freigabe. Unter Android verteilt der interne Test sofort, doch wer daran teilnimmt, kann nicht in den geschlossenen Test — bei Konten mit Closed-Testing-Pflicht ist das entscheidend.

Warum unterscheiden sich die Wege bei iOS und Android?

Beide Stores bieten Vor-Release-Verteilung, aber unterschiedlich. Bei Apple ist TestFlight das einzige Werkzeug und teilt sich in zwei Gruppen: Teammitglieder und externe Tester. Bei Google gibt es drei getrennte Testtracks — intern, geschlossen und offen — und sie schließen einander aus.

Praktisch entscheidet die Prüfung. Verteilung außerhalb des Teams verlangt bei TestFlight eine bestandene Beta-Prüfung; bei Play verteilt der interne Test sofort. Die Antwort auf „können wir es heute zeigen“ hängt also von der Plattform ab.

Suchanfragen, die diese Seite beantwortet

  • testflight nutzen
  • app vor veröffentlichung zeigen
  • play console interner test
  • testflight externer test prüfung
  • beta an kunden verteilen
  • app dem kunden vor launch zeigen

Die Android-Falle: interner Test stört den geschlossenen

Plays drei Tracks schließen einander aus: Wer im internen Test Ihrer App angemeldet ist, kann ohne Abmeldung nicht am offenen oder geschlossenen Test teilnehmen. Normalerweise harmlos — bei Konten mit Closed-Testing-Pflicht trifft es Sie direkt.

Die typische Fehlerkette: Das Team trägt sich für einen schnellen Blick in den internen Test ein, lädt dieselben Leute später beim Sammeln der zwölf Tester in den geschlossenen Test — und die Einladungen erscheinen nicht. Die Ursache zu finden dauert Tage. Steht ein geschlossener Test an, nehmen Sie das Team von Anfang an dorthin und nutzen den internen Test nur zur Build-Verifikation.

Welcher Weg wofür
ZweckiOSAndroid
Dem Team heute zeigenTestFlight internInterner Test
Dem Kunden zeigenTestFlight extern (Beta-Prüfung)Geschlossener Test
Breites Beta fahrenTestFlight externOffener Test
12-Tester-Pflicht erfüllenKein ÄquivalentNur geschlossener Test

TestFlight vor einer Übertragung abschalten

Wechselt die App das Entwicklerkonto, muss TestFlight für alle Beta-Versionen vor der Übertragung abgeschaltet sein. Ein laufendes Beta ist eine der Bedingungen, unter denen Apple die Übertragung blockiert — bemerkt wird das meist am Tag des Versuchs.

Dieselbe Reihenfolge gilt bei der Übergabe: Test abschalten, Konto übertragen, Zahlungs-Setup abschließen — nacheinander. Teams, die die Reihenfolge nicht kennen, verbringen den Übergabetag mit drei getrennten Wartezeiten.

Quellen

  1. 01TestFlight — beta testing for App Store appsApple · 2026
  2. 02Set up an open, closed, or internal testGoogle Play Console Help · 2026
  3. 03App transfer criteria — App Store ConnectApple · 2026

Häufige Fragen

Was oft gefragt wird

Ja, und das überrascht. Für die Verteilung an Personen außerhalb des Teams muss der Build bei TestFlight die Beta-Prüfung passieren; sie ist von der Release-Prüfung getrennt, bleibt aber eine Wartezeit. Planen Sie den Schritt ein, bevor Sie einem Kunden „wir zeigen es morgen“ sagen. Der interne Test läuft dagegen sofort mit Teammitgliedern — der richtige Weg, wenn es schnell gehen muss.

Je nach Zweck. Um dem Team schnell etwas zu zeigen: interner Test — sofortige Verteilung, bis zu hundert Personen je App. Für Kunden oder eine ausgewählte Gruppe: geschlossener Test — verwaltet per E-Mail-Liste oder Google-Gruppe. Bei Konten mit Closed-Testing-Pflicht lauert hier aber eine Falle: Wer im internen Test angemeldet ist, kann ohne Abmeldung nicht am geschlossenen teilnehmen — Sie können Ihr Team also nicht intern eintragen und dann auf die Zwölf anrechnen.

Schriftlich und mit definiertem Umfang. „Hab's angeschaut, sieht gut aus“ ist keine Freigabe; welche Abläufe auf welchem Gerät getestet wurden und was abgenommen ist, gehört festgehalten. Praktisch: mit dem Testbuild eine kurze Abnahmeliste schicken — je Punkt ein Nutzerablauf mit Häkchen. Die Liste dokumentiert die Freigabe und bringt den Kunden dazu, die App wirklich zu durchlaufen — spätes Feedback kommt meist aus Screens, die nie geöffnet wurden.

Gehen wir diese Schritte gemeinsam

Wir begleiten Sie, während Sie all das auf Ihr eigenes Projekt anwenden.