TestFlight: was ist das, Beta-Testing und Arbeit mit Builds

Was ist TestFlight

TestFlight ist die legitime und einzige offizielle Möglichkeit, iOS-Apps zum Testen zu verteilen, ohne sie im App Store zu veröffentlichen. Der Dienst wurde 2014 von Apple nach der Übernahme des gleichnamigen Unternehmens eingeführt. Vor TestFlight nutzten Entwickler die Ad-Hoc-Verteilung mit einem Limit von 100 Geräten pro Saison — TestFlight hob diese Beschränkung auf und vereinfachte den Prozess auf wenige Klicks.

Warum TestFlight notwendig ist

iOS hat eine strenge Sicherheitsrichtlinie: Eine App kann nur über den App Store oder mit speziellen Zertifikaten auf einem Gerät installiert werden. TestFlight löst das Problem des Beta-Testens, indem es als Proxy zwischen Entwickler und Tester fungiert: Apple prüft den Build auf grundlegende Anforderungen, wonach die Tester die App über die TestFlight-App aus dem App Store erhalten, was kein Vertrauen in unsignierte Dateien erfordert.

TestFlight vs. Ad Hoc vs. Enterprise

Es gibt drei Möglichkeiten, iOS-Apps außerhalb des App Store zu verteilen: Ad Hoc (Limit von 100 Geräten, erfordert die UDID jedes Geräts), Enterprise (interne Verteilung ohne Limits, erfordert ein Apple-Enterprise-Zertifikat für 299 $/Jahr) und TestFlight (bis zu 10.000 Tester, kostenlos, erfordert keine UDID-Erfassung). TestFlight ist die optimale Wahl für Beta-Tests, Ad Hoc eignet sich für gerätespezifische Tests und Enterprise für Unternehmens-Apps.

Wie TestFlight funktioniert

Der Prozess der Veröffentlichung eines Builds über TestFlight besteht aus fünf Schritten: Erstellen in Xcode, Hochladen in App Store Connect über Archive Organizer, Apple-Verarbeitung, Einladen von Testern und Installieren der App über die TestFlight-App. Jeder Schritt dauert je nach Komplexität des Projekts einige Minuten bis zu einer Stunde.

Anforderungen von Apple an den Build

Der Build muss mit einem Verteilungszertifikat und einem gültigen Provisioning-Profil erstellt werden. Apple prüft: Gültigkeit des Zertifikats, Übereinstimmung der Bundle-ID, Fehlen privater APIs, korrekte Symbole (1024×1024) und Vorhandensein des App Store-Symbols. Wenn der Build die Prüfung nicht besteht, zeigt TestFlight einen Fehler mit einer Beschreibung des Problems an.

Build-Verarbeitung

Nach dem Hochladen durchläuft der Build die automatisierte Prüfung von Apple: statische Analyse des Binärcodes, Überprüfung der digitalen Signatur, Scan auf Nutzung privater APIs und Malware. Die Verarbeitung dauert beim ersten Build zwischen 15 Minuten und 2 Stunden und bei nachfolgenden Builds in der Regel 15 bis 30 Minuten. Der Verarbeitungsstatus wird in Activity in App Store Connect angezeigt.

// TestFlight-Setup im Swift AppDelegate
import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        // Prüfung: Ist die App über TestFlight installiert
        if Bundle.main.appStoreReceiptURL?.lastPathComponent
            == "sandboxReceipt" {
            print("Beta-Version via TestFlight")
        }
        return true
    }
}

Interne und externe Tester

TestFlight unterteilt Tester in zwei Gruppen: Interne Tester (Internal Testers) und Externe Tester (External Testers). Der Unterschied liegt in der Anzahl der Teilnehmer, dem Zugriff auf Builds und der Notwendigkeit einer Apple-Prüfung. Die Wahl der richtigen Gruppe beschleunigt den Testprozess und hält die App Store-Richtlinien ein.

Interne Tester (Internal)

Bis zu 100 Teilnehmer aus dem Apple Developer Program-Team. Um einen internen Tester einzuladen, reicht es aus, seine Apple-ID in App Store Connect hinzuzufügen — er erhält sofort Zugriff auf alle Builds. Keine Apple-Prüfung erforderlich. Ideal für tägliche Smoke-Tests und frühzeitige Funktionsprüfung.

Externe Tester (External)

Bis zu 10.000 Teilnehmer, die nicht zum Entwicklungsteam gehören. Der erste Build für externe Tester durchläuft eine grundlegende Apple-Prüfung (in der Regel 1–2 Tage). Nachfolgende Builds mit Änderungen, die die Kernfunktionalität nicht beeinträchtigen, können ohne erneute Prüfung durchkommen. Externe Tester werden per E-Mail oder öffentlichen Link eingeladen.

Wie man einen Build in TestFlight hochlädt

Das Hochladen eines Builds in TestFlight erfolgt über Xcode, Application Loader oder die Befehlszeile mit xcrun. Die gebräuchlichste Methode ist über den Xcode Archive Organizer nach der Erstellung eines Projektarchivs. Eine alternative Methode ist die Automatisierung über Fastlane für CI/CD-Pipelines.

Manuelles Hochladen über Xcode

Erstellen Sie ein Archiv (Product → Archive), öffnen Sie den Organizer, wählen Sie das Archiv aus und klicken Sie auf Distribute App. Wählen Sie TestFlight als Verteilungsmethode und geben Sie das Zertifikat und das Provisioning-Profil an. Xcode lädt den Build in App Store Connect hoch, wo er nach der Verarbeitung erscheint. Der gesamte Vorgang dauert beim ersten Hochladen 10 bis 20 Minuten.

Automatisierung über Fastlane

Fastlane ist das beliebteste Tool zur Automatisierung des Hochladens von Builds in TestFlight. Der Befehl fastlane pilot lädt den Build hoch und verwaltet die Tester, ohne Xcode zu öffnen. Die Integration von Fastlane mit einem CI/CD-Server ermöglicht die automatische Veröffentlichung von Builds in TestFlight nach Bestehen aller Tests.

# Fastfile — Hochladen des Builds in TestFlight
default_platform(:ios)

lane :beta do
    # Abrufen von Zertifikaten über match
    match(type: "appstore")

    # Build und Signierung
    build_app(
        scheme: "MyApp",
        export_method: "app-store",
        workspace: "MyApp.xcworkspace"
    )

    # In TestFlight hochladen
    pilot(
        skip_waiting_for_build: true,
        distribute_external: false,
        notify_external_testers: false
    )
end

Fastlane pilot lädt automatisch die IPA in App Store Connect hoch, wartet auf die Verarbeitung (wenn skip_waiting_for_build = false) und weist den Build ausgewählten Testergruppen zu. Der Befehl distribute_external: true sendet den Build sofort nach der Verarbeitung an externe Tester.

Hochladen über die Befehlszeile

Ohne Fastlane können Sie xcrun verwenden: xcrun altool --upload-app --file path/to/app.ipa --username YOUR_APPLE_ID --password @keychain:AC_PASSWORD. altool wird von Apple für CI-Umgebungen unterstützt und benötigt keine grafische Oberfläche. Das Passwort wird über die Schlüsselkette oder ein app-spezifisches Passwort übergeben — verwenden Sie keine Klartext-Passwörter.

Feedback-Erfassung und Diagnose in TestFlight

TestFlight bietet mehrere Feedback-Mechanismen: ein integriertes Feedback-Formular, automatische Erfassung von Crash-Logs, Nutzungsmetriken und Screenshots. Das Team erhält alle Daten in App Store Connect, ohne SDKs von Drittanbietern für Beta-Tests integrieren zu müssen.

Integriertes Feedback-Formular

Der Tester öffnet die TestFlight-App, wählt Ihren Build aus und klickt auf Send Feedback. Das Formular ermöglicht das Senden von Text-Feedback, das Anhängen eines Screenshots und die Angabe des Schweregrads. Alle Rückmeldungen werden in App Store Connect unter TestFlight → Feedback gesammelt. Der Entwickler kann auf das Feedback antworten, und der Tester erhält eine Benachrichtigung in der TestFlight-App.

Crash-Logs und Diagnose

Wenn eine App abstürzt, sammelt TestFlight automatisch einen Crash-Bericht: Aufrufstapel, OS-Version, Gerätemodell und Absturzzeit. Crash-Logs sind im Xcode Organizer (Crashes) und in App Store Connect (TestFlight → Crashes) verfügbar. Um symbolisierte Crash-Logs zu erhalten, müssen Sie dSYM-Dateien mit dem Build oder separat über Xcode hochladen.

Nutzungsüberwachung

TestFlight zeigt Metriken: Anzahl der Installationen, aktive Tester, Sitzungen und Abstürze. Analysen werden täglich aktualisiert und helfen, das Engagement der Tester zu bewerten. Wenn innerhalb einer Woche kein Tester die App geöffnet hat, sollten Sie die Kommunikation mit der Gruppe oder die Build-Qualität überdenken.

Von TestFlight zur Veröffentlichung im App Store

TestFlight ist ein integraler Bestandteil des App Store-Veröffentlichungsprozesses. Derselbe Build, der Beta-Tests über TestFlight durchlaufen hat, kann ohne Neuerstellung zur Apple-Prüfung eingereicht werden — einfach auf eine Schaltfläche in App Store Connect klicken. Dies schließt das Risiko aus, dass sich der Produktions-Build vom getesteten unterscheidet.

Zur App-Prüfung einreichen

Wählen Sie in App Store Connect den Build aus, der die Tests bestanden hat, und klicken Sie auf Submit for Review. Apple verwendet denselben Build aus TestFlight — ein erneutes Hochladen ist nicht erforderlich. Die Prüfungszeit beträgt in der Regel 1–3 Tage. Wenn der Build abgelehnt wird, beheben Sie die Probleme, laden Sie einen neuen Build in TestFlight hoch und wiederholen Sie den Vorgang.

Letzter Build vor der Veröffentlichung

Es wird empfohlen, nach der letzten Testrunde in TestFlight 24–48 Stunden zu warten, bevor Sie ihn zur Prüfung einreichen. Diese Zeit ermöglicht es Testern, kritische Fehler zu finden, die automatisierte Tests möglicherweise übersehen. Der Release Candidate (RC)-Build in TestFlight ist eine Standardpraxis für erfahrene iOS-Teams.

Was nach der Veröffentlichung zu tun ist

TestFlight-Builds werden nach der Veröffentlichung der Release-Version im App Store automatisch für neue Installationen deaktiviert. Tester, die die Beta-Version bereits installiert haben, können sie nach der Veröffentlichung noch 30 Tage lang nutzen, danach kann die App nicht mehr geöffnet werden. Stellen Sie sicher, dass die Tester auf die App Store-Version aktualisieren.