TestFlight: co to jest, beta-testowanie i praca z buildami

Czym jest TestFlight

TestFlight — to legalny i jedyny oficjalny sposób rozpowszechniania aplikacji iOS do testowania bez publikacji w App Store. Usługa została uruchomiona przez Apple w 2014 roku po przejęciu firmy o tej samej nazwie. Przed pojawieniem się TestFlight deweloperzy korzystali z dystrybucji Ad Hoc z ograniczeniem do 100 urządzeń na sezon — TestFlight usunął to ograniczenie i uprościł proces do kilku kliknięć.

Po co jest TestFlight

iOS ma ścisłe zasady bezpieczeństwa: aplikacja może być zainstalowana na urządzeniu tylko przez App Store lub przy użyciu specjalnych certyfikatów. TestFlight rozwiązuje problem beta-testowania, działając jako pośrednik między deweloperem a testerem: Apple sprawdza build pod kątem podstawowych wymagań, po czym testerzy otrzymują aplikację przez aplikację TestFlight z App Store, co nie wymaga zaufania do niepodpisanych plików.

TestFlight vs Ad Hoc vs Enterprise

Istnieją trzy sposoby rozpowszechniania aplikacji iOS poza App Store: Ad Hoc (ograniczenie do 100 urządzeń, wymaga UDID każdego urządzenia), Enterprise (dystrybucja wewnątrzfirmowa bez limitu, wymaga certyfikatu Enterprise Apple za 299 USD/rok) i TestFlight (do 10 000 testerów, bezpłatnie, nie wymaga zbierania UDID). TestFlight to optymalny wybór do beta-testowania, Ad Hoc nadaje się do testów specyficznych dla urządzeń, Enterprise — do aplikacji korporacyjnych.

Jak działa TestFlight

Proces publikacji builda przez TestFlight składa się z pięciu kroków: budowanie w Xcode, przesłanie do App Store Connect przez Archive Organizer, przetwarzanie przez Apple, zaproszenie testerów, instalacja aplikacji przez aplikację TestFlight. Każdy krok zajmuje od kilku minut do godziny w zależności od złożoności projektu.

Wymagania Apple wobec builda

Build musi być zbudowany z certyfikatem dystrybucyjnym i poprawnym provisioning profile. Apple sprawdza: ważność certyfikatu, zgodność bundle identifier, brak prywatnych API, poprawność ikon (1024×1024) i obecność ikony App Store. Jeśli build nie przejdzie weryfikacji — TestFlight wyświetla błąd z opisem problemu.

Proces przetwarzania builda

Po przesłaniu build przechodzi przez zautomatyzowaną weryfikację Apple: analiza statyczna kodu binarnego, sprawdzenie podpisu cyfrowego, skanowanie w poszukiwaniu prywatnych API i malware. Przetwarzanie trwa od 15 minut do 2 godzin dla pierwszego builda i zwykle 15–30 minut dla kolejnych. Status przetwarzania jest wyświetlany w Activity w App Store Connect.

// Konfiguracja TestFlight w Swift AppDelegate
import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        // Sprawdzenie: czy aplikacja została zainstalowana przez TestFlight
        if Bundle.main.appStoreReceiptURL?.lastPathComponent
            == "sandboxReceipt" {
            print("Beta version via TestFlight")
        }
        return true
    }
}

Wewnętrzni i zewnętrzni testerzy

TestFlight dzieli testerów na dwie grupy: wewnętrznych (Internal Testers) i zewnętrznych (External Testers). Różnica polega na liczbie uczestników, dostępie do buildów i konieczności recenzji Apple. Właściwy wybór grupy przyspiesza proces testowania i zapewnia zgodność z politykami App Store.

Wewnętrzni testerzy (Internal)

Do 100 uczestników z zespołu Apple Developer Program. Aby zaprosić wewnętrznego testera, wystarczy dodać jego Apple ID w App Store Connect — natychmiast uzyskuje dostęp do wszystkich buildów. Nie wymaga recenzji Apple. Idealne do codziennego smoke-testowania i sprawdzania funkcji na wczesnych etapach.

Zewnętrzni testerzy (External)

Do 10 000 uczestników spoza zespołu deweloperskiego. Pierwszy build dla zewnętrznych testerów przechodzi podstawową recenzję Apple (zwykle 1–2 dni). Kolejne buildu ze zmianami nienaruszającymi kluczowej funkcjonalności mogą przejść bez ponownej recenzji. Zewnętrzni testerzy są zapraszani przez email lub publiczny link.

Jak przesłać build do TestFlight

Przesłanie builda do TestFlight wykonuje się przez Xcode, Application Loader lub wiersz poleceń za pomocą xcrun. Najpopularniejszym sposobem jest Xcode Archive Organizer po utworzeniu archiwum projektu. Alternatywnym sposobem jest automatyzacja przez Fastlane dla potoku CI/CD.

Ręczne przesyłanie przez Xcode

Zbuduj archiwum (Product → Archive), otwórz Organizer, wybierz archiwum i kliknij Distribute App. Wybierz TestFlight jako metodę dystrybucji, wskaż certyfikat i provisioning profile. Xcode prześle build do App Store Connect, gdzie pojawi się po przetworzeniu. Cały proces zajmuje 10–20 minut dla pierwszego przesłania.

Automatyzacja przez Fastlane

Fastlane — to najpopularniejsze narzędzie do automatyzacji przesyłania buildów do TestFlight. Polecenie fastlane pilot przesyła build i zarządza testerami bez otwierania Xcode. Integracja Fastlane z serwerem CI/CD umożliwia automatyczne publikowanie buildów w TestFlight po przejściu wszystkich testów.

# Fastfile — przesyłanie buildu do TestFlight
default_platform(:ios)

lane :beta do
    # Pobieranie certyfikatów przez match
    match(type: "appstore")

    # Budowanie i podpisywanie
    build_app(
        scheme: "MyApp",
        export_method: "app-store",
        workspace: "MyApp.xcworkspace"
    )

    # Przesyłanie do TestFlight
    pilot(
        skip_waiting_for_build: true,
        distribute_external: false,
        notify_external_testers: false
    )
end

Fastlane pilot automatycznie przesyła IPA do App Store Connect, czeka na przetworzenie (jeśli skip_waiting_for_build = false) i przypisuje build do wybranych grup testerów. Polecenie distribute_external: true natychmiast wysyła build do zewnętrznych testerów po przetworzeniu.

Przesyłanie przez wiersz poleceń

Bez Fastlane można użyć xcrun: xcrun altool --upload-app --file path/to/app.ipa --username YOUR_APPLE_ID --password @keychain:AC_PASSWORD. altool jest obsługiwany przez Apple dla środowisk CI i nie wymaga interfejsu graficznego. Hasło jest przekazywane przez keychain lub app-specific password — nie używaj haseł w postaci zwykłego tekstu.

Zbieranie opinii i diagnostyka w TestFlight

TestFlight zapewnia kilka mechanizmów opinii: wbudowany formularz opinii, automatyczne zbieranie logów awarii, metryki użycia i zrzuty ekranu. Zespół otrzymuje wszystkie dane w App Store Connect bez konieczności implementowania zewnętrznych SDK do beta-testowania.

Wbudowany formularz opinii

Tester otwiera aplikację TestFlight, wybiera Twój build i klika Send Feedback. Formularz umożliwia wysłanie opinii tekstowej, dołączenie zrzutu ekranu i wskazanie wagi problemu. Wszystkie opinie są zbierane w App Store Connect w sekcji TestFlight → Feedback. Deweloper może odpowiedzieć na opinię, a tester otrzyma powiadomienie w aplikacji TestFlight.

Logi awarii i diagnostyka

W przypadku awarii aplikacji TestFlight automatycznie zbiera raport awarii: stos wywołań, wersję systemu operacyjnego, model urządzenia i czas awarii. Logi awarii są dostępne w Xcode Organizer (Crashes) i App Store Connect (TestFlight → Crashes). Aby uzyskać symbolicated logi awarii, należy przesłać pliki dSYM wraz z buildem lub osobno przez Xcode.

Monitorowanie użycia

TestFlight pokazuje metryki: liczbę instalacji, aktywnych testerów, sesji i awarii. Analityka jest aktualizowana codziennie i pomaga ocenić zaangażowanie testerów. Jeśli przez tydzień żaden tester nie otworzył aplikacji — warto przemyśleć komunikację z grupą lub jakość builda.

Od TestFlight do publikacji w App Store

TestFlight jest nieodłączną częścią procesu publikacji w App Store. Ten sam build, który przeszedł beta-testowanie przez TestFlight, może zostać wysłany do recenzji Apple bez przebudowy — wystarczy kliknąć przycisk w App Store Connect. Eliminuje to ryzyko, że build produkcyjny różni się od przetestowanego.

Submit to App Review

W App Store Connect wybierz build, który przeszedł testowanie, i kliknij Submit for Review. Apple używa tego samego builda z TestFlight — ponowne przesyłanie nie jest wymagane. Czas recenzji wynosi zwykle 1–3 dni. Jeśli build zostanie odrzucony — popraw uwagi, prześlij nowy build do TestFlight i powtórz proces.

Ostatni build przed wydaniem

Zaleca się po finałowej rundzie testowania w TestFlight odczekać 24–48 godzin przed wysłaniem do recenzji. Ten czas pozwala testerom wykryć krytyczne błędy, które mogą ominąć automatyczne testy. Release candidate (RC) w TestFlight to standard praktyk dojrzałych zespołów iOS.

Co robić po publikacji

Buildu TestFlight automatycznie stają się niedostępne dla nowych instalacji po wydaniu wersji produkcyjnej w App Store. Testerzy, którzy już zainstalowali wersję beta, mogą nadal z niej korzystać przez 30 dni po publikacji wydania, po czym aplikacja przestaje się otwierać. Upewnij się, że testerzy zaktualizowali do wersji z App Store.