TestFlight è lo strumento di Apple per distribuire un'app prima che sia sull'App Store. Caricate il binario firmato su App Store Connect, invitate delle persone, e loro lo installano sul proprio iPhone tramite l'app TestFlight. Quello che ricevono non è un'anteprima né un simulatore: è esattamente il build che invierete poi all'App Review, con la sua icona, i suoi permessi e il suo codice nativo.
Tre numeri inquadrano l'intero servizio. Fino a 100 tester interni, membri del vostro team App Store Connect, fino a 10.000 tester esterni invitati via e-mail o tramite un link pubblico, e 90 giorni di validità per ogni build. Tutto il resto, dalla Beta App Review agli screenshot di feedback, deriva dal modo diverso in cui questi due gruppi vengono trattati. Questa guida segue il percorso dal caricamento al telefono di un tester, poi elenca i limiti e gli errori che ritardano un lancio.
TestFlight è una tappa di un percorso più lungo. Se vi serve l'intera sequenza, dall'account sviluppatore all'uscita, leggete la nostra guida su come pubblicare un'app sull'App Store.
Cos'è TestFlight e dove si colloca
TestFlight vive dentro App Store Connect, nella sezione con lo stesso nome, e sui dispositivi dei tester come app gratuita dell'App Store. Richiede un'iscrizione all'Apple Developer Program da parte vostra, e nient'altro che un Account Apple da parte del tester. Copre iOS, iPadOS, macOS, tvOS, watchOS e visionOS, quindi un build per Mac o Vision Pro segue lo stesso percorso di un build per iPhone.
Il suo posto nella catena è tra il build e la revisione. Gli strumenti precedenti mostrano il vostro codice su un telefono più in fretta, ma non come la vostra vera app: Expo Go carica solo il vostro JavaScript dentro un guscio condiviso, e un development build contiene il vostro codice nativo ma con gli strumenti di sviluppo all'interno. TestFlight è il primo momento in cui avete in mano il binario di produzione. La nostra guida su come testare con Expo Go copre quella fase precedente e i suoi limiti.
Dal caricamento al telefono di un tester, passo dopo passo
1. Caricamento ed elaborazione
Un build arriva su App Store Connect da Xcode, dall'app Transporter di Apple, da un servizio di build come EAS Submit, o da una piattaforma come Cadrant che pilota EAS per voi. Una volta caricato, il build passa per un'elaborazione: Apple verifica il pacchetto, indicizza i simboli e lo analizza, il che richiede da pochi minuti a circa un'ora nei momenti di punta. Compare poi nella sezione TestFlight della vostra app con uno stato.
La prima fermata è spesso «Missing Compliance». Apple chiede se l'app usa una cifratura oltre quella fornita da iOS; per la maggior parte delle app che fanno solo chiamate HTTPS la risposta è no, e potete impostare la chiave ITSAppUsesNonExemptEncryption nella configurazione dell'app perché la domanda non blocchi mai più un build. Finché la risposta non è registrata, nessuno può installare il build.
2. Tester interni: il vostro team, senza revisione
I tester interni sono le persone che hanno un ruolo nel vostro team App Store Connect: Admin, App Manager, Developer, Marketing o Customer Support. Potete averne fino a 100 per app, e ricevono ogni build pochi minuti dopo l'elaborazione, senza revisione da parte di Apple. Potete perfino spuntare «distribuisci automaticamente» su un gruppo interno perché ogni nuovo caricamento parta da solo. È il ciclo del vostro team: caricare, testare, correggere, ricaricare, più volte al giorno se serve.
3. Tester esterni: fino a 10.000 persone e una beta review
I tester esterni sono tutti gli altri: clienti, amici, una lista d'attesa. Li organizzate in gruppi, li invitate via e-mail o condividete un link pubblico, e ogni gruppo può ricevere build diversi. Il limite è di 10.000 tester esterni per app, tutti i gruppi compresi. La panoramica di TestFlight di Apple fissa le regole per entrambe le cerchie.
La differenza rispetto al test interno è la Beta App Review. Il primo build che aggiungete a un gruppo esterno viene inviato all'App Review per verificare che rispetti le App Review Guidelines, in pratica un controllo più leggero della revisione di rilascio, che di solito passa entro un giorno. I build successivi della stessa versione partono spesso senza una nuova revisione completa, a meno che non cambiate ciò a cui Apple tiene. Perché questa revisione passi, compilate le informazioni di test: cosa testare, un'e-mail di contatto e un account dimostrativo se l'app richiede l'accesso.
4. Dal lato del tester
Un tester installa l'app TestFlight, apre l'e-mail di invito o il link pubblico, accetta e tocca Installa. L'app compare nella schermata Home con un punto arancione accanto al nome, il segno che si tratta di una beta. Quando caricate un nuovo build, TestFlight lo avvisa e può aggiornare automaticamente. Per inviare un feedback, fa uno screenshot e passa dal foglio di condivisione, oppure scuote il dispositivo se l'avete abilitato; lo screenshot e il commento arrivano in App Store Connect, insieme ai log di crash per ogni crash subito dall'app durante il test.
Limiti, tempi e gli errori che costano una settimana
| Regola | Valore | Conseguenza |
|---|---|---|
| Tester interni | 100 per app, utenti App Store Connect | Aggiungete prima i colleghi al team; serve loro un ruolo, non solo un'e-mail |
| Tester esterni | 10.000 per app, e-mail o link pubblico | Un link pubblico può avere un tetto ed essere chiuso; i criteri sul link riducono chi può entrare |
| Beta App Review | Primo build per gruppo esterno, di solito entro un giorno | Pianificate il primo build esterno un giorno prima di averne bisogno con i tester |
| Validità di un build | 90 giorni | Passato quel termine, l'app smette di aprirsi per i tester finché non viene caricato un nuovo build |
| Elaborazione | Da pochi minuti a circa un'ora | Non ricaricate un build perché «non è ancora arrivato»; aspettate l'e-mail |
| Costo | Gratuito con il Developer Program | L'iscrizione da 99 USD l'anno è l'unico costo |
I ritardi di cui la gente si lamenta vengono raramente da Apple. Vengono da questi errori:
- Lasciare senza risposta la domanda sulla cifratura. Il build resta in Missing Compliance e gli inviti non partono mai. Impostate la chiave di cifratura nella configurazione una volta per tutte.
- Aspettarsi che il test esterno sia immediato. L'interno è immediato; l'esterno aspetta la Beta App Review. Usate un gruppo interno per le prime ore e il gruppo esterno per i primi giorni.
- Niente note di test, niente account dimostrativo. La Beta App Review ha bisogno di una porta d'ingresso, esattamente come la revisione di rilascio. Un login che funziona evita un build rifiutato.
- Invitare l'Account Apple sbagliato. L'invito è legato all'e-mail; se il dispositivo del tester usa un altro Account Apple, l'invito non corrisponde mai. I link pubblici evitano il problema.
- Trattare TestFlight come un canale di distribuzione. Le linee guida vietano di usarlo per consegnare un'app al pubblico al posto dell'App Store, e i build comunque muoiono dopo 90 giorni.
TestFlight con Cadrant
Se la vostra app è stata costruita con il creatore di app mobile di Cadrant, i passi prima di TestFlight sono gestiti per voi: il build iOS gira sul vostro account Expo (il piano gratuito copre 15 build iOS al mese), ed Expo invia il binario finito al vostro account App Store Connect, dove la scheda dell'app e il certificato di distribuzione sono stati creati durante un percorso guidato. Da lì siete nel percorso TestFlight standard: aprite App Store Connect, rispondete alla domanda sulla cifratura se viene posta, aggiungete tester interni o un gruppo esterno, e installate sui vostri dispositivi.
Cosa verificare lì è ciò che l'anteprima nell'editor ed Expo Go non possono mostrare: le API native come fotocamera, notifiche push e selettori di file, i flussi di accesso e di dati verso il vostro progetto Supabase, le prestazioni su un dispositivo reale, e il comportamento con un permesso negato o offline. Trovato un bug? Correggetelo in Cadrant, pubblicate un nuovo build, distribuitelo, e ripetete finché non siete pronti per l'App Review. La documentazione Testare con TestFlight elenca i clic esatti.
In sintesi
- Caricare, aspettare l'elaborazione, rispondere alla domanda sulla cifratura: solo allora qualcuno può installare.
- I tester interni (100 membri del team) ricevono i build all'istante; i tester esterni (10.000) aspettano una Beta App Review sul primo build di una versione.
- Compilate le note di test e un account dimostrativo, invitate tramite link pubblico quando potete, e ricordate la scadenza dei 90 giorni.
- Testate su TestFlight ciò che Expo Go non può mostrare, perché il revisore lo farà.
Usato così, TestFlight non è un passo in più prima del lancio: è il lancio, provato con persone vere su telefoni veri, qualche giorno in anticipo.