TestFlight: cos'è, beta testing e lavoro con le build

Cos'è TestFlight

TestFlight è il modo legittimo e unico ufficiale per distribuire applicazioni iOS per test senza pubblicarle sull'App Store. Il servizio è stato lanciato da Apple nel 2014 dopo l'acquisizione dell'omonima azienda. Prima di TestFlight, gli sviluppatori utilizzavano la distribuzione Ad Hoc con un limite di 100 dispositivi per stagione — TestFlight ha rimosso questa limitazione e semplificato il processo in pochi clic.

Perché serve TestFlight

iOS ha una politica di sicurezza rigorosa: un'applicazione può essere installata su un dispositivo solo tramite l'App Store o utilizzando certificati speciali. TestFlight risolve il problema del beta testing fungendo da proxy tra sviluppatore e tester: Apple verifica la build rispetto ai requisiti di base, dopodiché i tester ricevono l'applicazione tramite l'app TestFlight dall'App Store, senza dover fidarsi di file non firmati.

TestFlight vs Ad Hoc vs Enterprise

Esistono tre modi per distribuire applicazioni iOS al di fuori dell'App Store: Ad Hoc (limite di 100 dispositivi, richiede l'UDID di ciascun dispositivo), Enterprise (distribuzione interna senza limiti, richiede un certificato Enterprise Apple a $299/anno) e TestFlight (fino a 10.000 tester, gratuito, non richiede raccolta di UDID). TestFlight è la scelta ottimale per il beta testing, Ad Hoc è adatto per test specifici del dispositivo ed Enterprise per applicazioni aziendali.

Come funziona TestFlight

Il processo di pubblicazione di una build tramite TestFlight si compone di cinque fasi: compilazione in Xcode, caricamento in App Store Connect tramite Archive Organizer, elaborazione Apple, invito dei tester e installazione dell'app tramite l'app TestFlight. Ogni fase richiede da pochi minuti a un'ora a seconda della complessità del progetto.

Requisiti Apple per la build

La build deve essere creata con un certificato di distribuzione e un profilo di provisioning valido. Apple verifica: validità del certificato, corrispondenza del bundle identifier, assenza di API private, icone corrette (1024×1024) e presenza dell'icona App Store. Se la build non supera la verifica, TestFlight mostra un errore con la descrizione del problema.

Elaborazione della build

Dopo il caricamento, la build viene sottoposta alla verifica automatica di Apple: analisi statica del codice binario, verifica della firma digitale, scansione dell'uso di API private e malware. L'elaborazione richiede da 15 minuti a 2 ore per la prima build e solitamente 150 minuti per quelle successive. Lo stato di elaborazione viene visualizzato in Activity in App Store Connect.

// Configurazione di TestFlight in Swift AppDelegate
import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        // Verifica: l'app è installata tramite TestFlight
        if Bundle.main.appStoreReceiptURL?.lastPathComponent
            == "sandboxReceipt" {
            print("Versione beta tramite TestFlight")
        }
        return true
    }
}

Tester interni ed esterni

TestFlight divide i tester in due gruppi: Tester Interni (Internal Testers) e Tester Esterni (External Testers). La differenza sta nel numero di partecipanti, nell'accesso alle build e nella necessità della revisione Apple. Scegliere il gruppo giusto accelera il processo di test e rispetta le policy dell'App Store.

Tester interni (Internal)

Fino a 100 partecipanti del team Apple Developer Program. Per invitare un tester interno, basta aggiungere il suo Apple ID in App Store Connect — ottiene immediatamente l'accesso a tutte le build. Non è richiesta la revisione Apple. Ideale per test smoke giornalieri e verifica anticipata delle funzionalità.

Tester esterni (External)

Fino a 10.000 partecipanti che non fanno parte del team di sviluppo. La prima build per i tester esterni viene sottoposta a una revisione base di Apple (solitamente 1–2 giorni). Le build successive con modifiche che non influiscono sulle funzionalità principali possono passare senza una nuova revisione. I tester esterni vengono invitati tramite email o link pubblico.

Come caricare una build in TestFlight

Il caricamento di una build in TestFlight viene effettuato tramite Xcode, Application Loader o la riga di comando con xcrun. Il metodo più comune è tramite Xcode Archive Organizer dopo aver creato un archivio del progetto. Un metodo alternativo è l'automazione tramite Fastlane per pipeline CI/CD.

Caricamento manuale tramite Xcode

Crea un archivio (Product → Archive), apri Organizer, seleziona l'archivio e fai clic su Distribute App. Seleziona TestFlight come metodo di distribuzione, specifica il certificato e il profilo di provisioning. Xcode caricherà la build in App Store Connect, dove apparirà dopo l'elaborazione. L'intero processo richiede 10–20 minuti per il primo caricamento.

Automazione tramite Fastlane

Fastlane è lo strumento più popolare per automatizzare il caricamento delle build in TestFlight. Il comando fastlane pilot carica la build e gestisce i tester senza aprire Xcode. L'integrazione di Fastlane con un server CI/CD consente di pubblicare build in TestFlight automaticamente dopo il superamento di tutti i test.

# Fastfile — caricamento della build in TestFlight
default_platform(:ios)

lane :beta do
    # Ottenimento dei certificati tramite match
    match(type: "appstore")

    # Compilazione e firma
    build_app(
        scheme: "MyApp",
        export_method: "app-store",
        workspace: "MyApp.xcworkspace"
    )

    # Caricamento in TestFlight
    pilot(
        skip_waiting_for_build: true,
        distribute_external: false,
        notify_external_testers: false
    )
end

Fastlane pilot carica automaticamente l'IPA in App Store Connect, attende l'elaborazione (se skip_waiting_for_build = false) e assegna la build ai gruppi di tester selezionati. Il comando distribute_external: true invia immediatamente la build ai tester esterni dopo l'elaborazione.

Caricamento tramite riga di comando

Senza Fastlane, puoi usare xcrun: xcrun altool --upload-app --file path/to/app.ipa --username YOUR_APPLE_ID --password @keychain:AC_PASSWORD. altool è supportato da Apple per ambienti CI e non richiede interfaccia grafica. La password viene passata tramite portachiavi o una password specifica per l'app — non utilizzare password in testo semplice.

Raccolta feedback e diagnostica in TestFlight

TestFlight fornisce diversi meccanismi di feedback: un modulo di feedback integrato, raccolta automatica di crash log, metriche di utilizzo e screenshot. Il team riceve tutti i dati in App Store Connect senza dover integrare SDK di terze parti per il beta testing.

Modulo di feedback integrato

Il tester apre l'app TestFlight, seleziona la tua build e fa clic su Send Feedback. Il modulo consente di inviare un feedback testuale, allegare uno screenshot e indicare la gravità. Tutti i feedback vengono raccolti in App Store Connect alla sezione TestFlight → Feedback. Lo sviluppatore può rispondere al feedback e il tester riceverà una notifica nell'app TestFlight.

Crash log e diagnostica

Quando un'app si blocca, TestFlight raccoglie automaticamente un crash report: stack delle chiamate, versione del sistema operativo, modello del dispositivo e ora del blocco. I crash log sono disponibili in Xcode Organizer (Crashes) e App Store Connect (TestFlight → Crashes). Per ottenere crash log simbolizzati, è necessario caricare i file dSYM con la build o separatamente tramite Xcode.

Monitoraggio dell'utilizzo

TestFlight mostra metriche: numero di installazioni, tester attivi, sessioni e crash. Le analisi vengono aggiornate quotidianamente e aiutano a valutare il coinvolgimento dei tester. Se nessun tester ha aperto l'app in una settimana, vale la pena riconsiderare la comunicazione con il gruppo o la qualità della build.

Da TestFlight alla pubblicazione sull'App Store

TestFlight è parte integrante del processo di pubblicazione sull'App Store. La stessa build che ha superato il beta testing tramite TestFlight può essere inviata alla revisione Apple senza ricompilazione — basta cliccare un pulsante in App Store Connect. Questo elimina il rischio che la build di produzione differisca da quella testata.

Invia alla revisione dell'App

In App Store Connect, seleziona la build che ha superato i test e fai clic su Submit for Review. Apple utilizza la stessa build da TestFlight — non è necessario ricaricarla. Il tempo di revisione è solitamente di 1–3 giorni. Se la build viene respinta, correggi i problemi, carica una nuova build in TestFlight e ripeti il processo.

Build finale prima del rilascio

Si consiglia di attendere 24–48 ore dopo il round finale di test in TestFlight prima di inviare alla revisione. Questo tempo consente ai tester di trovare bug critici che potrebbero sfuggire ai test automatizzati. La build release candidate (RC) in TestFlight è una pratica standard per i team iOS maturi.

Cosa fare dopo la pubblicazione

Le build di TestFlight diventano automaticamente non disponibili per nuove installazioni dopo il rilascio della versione finale sull'App Store. I tester che hanno già installato la versione beta possono continuare a usarla per 30 giorni dopo la pubblicazione del rilascio, dopodiché l'app smette di aprirsi. Assicurati che i tester passino alla versione dell'App Store.