Come distribuire app iOS e Android ai tester

Per distribuire app iOS ai tester, usa TestFlight (tester interni subito, esterni dopo una breve Beta App Review) o una build ad hoc per dispositivi registrati. Per Android, usa una Google Play testing track (interna, chiusa o aperta), Play internal app sharing per link singoli, o condividi un APK firmato tramite Firebase App Distribution o un download diretto. La scelta dipende da chi sono i tuoi tester, da quanti sono e se la build deve passare dall'infrastruttura dello store.

Questa guida confronta tutte le opzioni, mostra come configurarle per un'app Capacitor e descrive gli errori che i tester incontrano più comunemente.

Scegliere un metodo

Regole generali:

• Stessa build che pubblicherai sullo store? Usa TestFlight e le track di Play. Il binario che usano i tester è quello che viene promosso.
• Build QA quotidiane? Test interni su entrambi gli store, oppure Firebase App Distribution.
• Devi testare una modifica al web layer in pochi minuti? Pubblica un live update su un canale di test invece di un nuovo binario.

Prima di distribuire: la firma

Ogni build di test deve essere firmata.

• iOS le build di test utilizzano un App Store Connect profilo (TestFlight) o un Ad Hoc profile (installazione diretta). Entrambi usano un certificato Apple Distribution. Vedi Certificati iOS e provisioning profile spiegati.
• Android I build per le track Play sono AAB firmati con la tua upload key. Per le installazioni dirette serve un APK firmato con una release key qualsiasi. Anche un APK di debug si installa, ma si comporta diversamente (debuggable, firma diversa) e in seguito non potrà essere aggiornato dal tuo build Play.

iOS: TestFlight

Carica un build

Da Xcode: Prodotto > Archivio, poi Distribuisci App > App Store Connect > Upload. Da riga di comando o da CI, esporta un .ipa e upload con una chiave API di App Store Connect, oppure lascia che un servizio di cloud build lo faccia.

Da aprile 2026, gli upload devono essere compilati con Xcode 26 o versioni successive.

Aggiungi questa chiave a ios/App/App/Info.plist se la tua app utilizza solo la crittografia HTTPS standard, in modo che App Store Connect non ponga la domanda sull'export compliance per ogni build:

<key>ITSAppUsesNonExemptEncryption</key>
<false/>

L'elaborazione richiede da pochi minuti a circa un'ora. Riceverai un'email quando la build sarà pronta.

Test interno

1. In App Store Connect apri la tua app, TestFlight > Test interni, e crea un gruppo.
2. Aggiungi i membri del team. Devono avere un ruolo in App Store Connect (Admin, App Manager, Developer, Marketing…). Fino a 100 persone.
3. Abilita distribuzione automatica così ogni nuova build finisce nel gruppo.
4. I tester installano l' TestFlight app dall'App Store e accettano l'invito.

Non serve alcuna revisione. È la via più rapida dall'upload al telefono.

Testing esterno

1. TestFlight > External Testing > + per creare un gruppo.
2. Aggiungi i tester via email, o abilita un link pubblico con un limite opzionale di tester.
3. Aggiungi la build al gruppo e compila Informazioni sul test (cosa testare, email per il feedback, descrizione dell'app beta e login demo se necessario).
4. Invia per la Revisione dell'app beta. La prima build di ogni versione viene revisionata, di solito entro un giorno. Le build successive della stessa versione spesso vengono pubblicate senza revisione completa.

Il test esterno supporta fino a 10.000 tester. I tester possono inviare screenshot con feedback direttamente da TestFlight, che vedrai in App Store Connect.

Limiti di TestFlight da conoscere

• Le build scadono dopo 90 giorni.
• I tester devono avere versioni iOS supportate dal tuo build (Capacitor 8 richiede iOS 15 o successivo).
• I build TestFlight usano la firma di produzione dell'App Store, quindi le notifiche push usano l' produzione ambiente APNs.
• Gli acquisti in-app su TestFlight usano la sandbox e non vengono addebitati.

iOS: distribuzione ad hoc

I build ad hoc si installano direttamente sui dispositivi che hai registrato nel portale Apple Developer, senza TestFlight né revisione Apple.

1. Raccogli l'UDID di ciascun tester. I tester possono ottenerlo da soli sul proprio telefono con il Trova UDID iOS, oppure puoi leggerlo da Finder o Xcode quando il dispositivo è collegato.
2. Registra i dispositivi in Certificati, identificatori e profili > Dispositivi.
3. Crea un Ad Hoc profilo di provisioning che includa quei dispositivi e scaricalo.
4. Compila un .ipa con quel profilo (Xcode: Distribute App > Release Testing, che è il nuovo nome di Ad Hoc).
5. Installalo:
   • Trascina il .ipa sul dispositivo in Finder o Xcode > Window > Devices and Simulators.
   • Oppure ospitalo con un itms-services manifest tramite HTTPS per permettere ai tester di cliccare un link. Servizi come Firebase App Distribution lo fanno al posto tuo.
6. Su iOS 16 e versioni successive, installare il .ipa da un Mac (Xcode o Apple Configurator) richiede Modalità sviluppatore sul dispositivo (Impostazioni > Privacy e sicurezza). L'installazione tramite itms-services link non lo richiede. Vedi come attivare la Modalità sviluppatore su iOS.

Aggiungere un nuovo tester significa registrarne l'UDID, rigenerare il profilo e fare il rebuild. Gli slot dispositivo (100 per famiglia di dispositivi) si azzerano solo al rinnovo annuale dell'iscrizione, quindi non registrare dispositivi con leggerezza.

Android: i canali di test di Google Play

La Play Console ha tre canali di test oltre alla produzione. Ognuno richiede un AAB firmato con la tua upload key.

Test interno

1. Test > Test interno > Tester: crea una lista email (fino a 100 indirizzi).
2. Crea nuova release, carica l'AAB, aggiungi le note di rilascio, salva e avvia il rollout.
3. Copia il link di opt-in e invialo ai tester. Accettano e installano dal Play Store.

I rilasci interni sono di solito disponibili in pochi minuti e non attendono la revisione completa. Il primo rilascio di un'app nuova di zecca può richiedere più tempo mentre Google la elabora.

Test chiuso

I canali chiusi vengono revisionati e supportano liste email o Google Groups. Questo è il canale che ti serve per la regola dei 12 tester per 14 giorni che si applica agli account developer personali creati dopo il 13 novembre 2023, prima dell'accesso alla produzione. Usare un Google Group facilita l'adesione dei tester. I dettagli sono in come creare account developer Apple e Google Play.

Test aperto

Chiunque può partecipare dalla tua scheda sul Play Store. Usalo per una beta pubblica quando la scheda dello store è completa. Il feedback dei tester open è privato e non incide sulla tua valutazione pubblica.

Il nostro guida al beta testing Android confronta i track in modo più dettagliato.

Android: condivisione interna dell'app

L'internal app sharing è il modo più veloce per portare qualsiasi APK o AAB su un dispositivo tramite il Play Store, senza regole sul version code e senza revisione.

1. In Play Console, apri Condivisione interna dell'app (sotto Testing) e aggiungi gli uploader.
2. Fai l'upload di un APK o AAB. Otterrai un link.
3. I tester aprono l'app Play Store, vanno nelle impostazioni e toccano la versione del Play Store sette volte per sbloccare le impostazioni sviluppatore e attivare Condivisione interna dell'app.
4. I tester aprono il link e installano.

È utile per il QA delle build delle pull request, perché i version code non devono aumentare.

Android: APK diretto e Firebase App Distribution

APK diretto

Crea un APK di rilascio firmato. Un nuovo progetto Capacitor non ha release nessuna configurazione di firma, quindi assembleRelease genererebbe un APK non firmato che non può essere installato. Aggiungi un signingConfigs.release blocco (percorso del keystore e password, di solito letti da key.properties) a android/app/build.gradle e punta buildTypes.release.signingConfig su di esso prima.

bun run build
bunx cap sync android
cd android && ./gradlew assembleRelease

Condividi android/app/build/outputs/apk/release/app-release.apk tramite un link. I tester devono autorizzare il browser o il file manager a installare app sconosciute e aprire il file. Se hanno già installata una versione da Play Store, devono prima disinstallarla perché le firme sono diverse. Puoi anche installare via USB con adb install -r app-release.apk (vedi come abilitare le opzioni sviluppatore su Android).

Dal 30 settembre 2026, i dispositivi Android certificati in Brasile, Indonesia, Singapore e Thailandia installeranno solo app il cui nome del pacchetto è registrato da uno sviluppatore verificato, con rollout globale previsto per il 2027. Se i tuoi tester si trovano in quei paesi, registra il nome del pacchetto nella Android Developer Console o nella Play Console. Le installazioni tramite adb non sono interessati.

Firebase App Distribution

Firebase App Distribution funziona su entrambe le piattaforme, invia email di invito e traccia chi ha installato quale build.

bun add -g firebase-tools
firebase login

firebase appdistribution:distribute android/app/build/outputs/apk/release/app-release.apk \
  --app 1:1234567890:android:abc123def456 \
  --groups "qa-team" \
  --release-notes "Fix checkout crash"

• I tester Android installano dall'email link o dall'app App Tester.
• I tester iOS devono comunque essere in un profilo ad hoc (o di sviluppo). App Distribution raccoglie i loro UDID quando accettano l'invito, ma li registri e rifai la build tu.
• La distribuzione AAB richiede di collegare il progetto Firebase a Google Play.

Cloud build con link per i tester

Se non vuoi mantenere Mac e firma su ogni runner CI, Build Capgo fa la build delle app Capacitor nel cloud. Per le build di test può saltare l'invio allo store e caricare il binario su un link di download a tempo limitato con un QR code:

# Android APK/AAB for testers, no Play upload
bunx @capgo/cli@latest build request com.example.app \
  --platform android --no-playstore-upload --output-upload --output-retention 2d

# iOS ad hoc build (no App Store submission)
bunx @capgo/cli@latest build request com.example.app \
  --platform ios --ios-distribution ad_hoc --output-upload

# iOS build uploaded to TestFlight for external groups
bunx @capgo/cli@latest build request com.example.app \
  --platform ios --ios-testflight-groups "Beta Testers"

Aggiungi --output-record build.json e leggi il link in CI con bunx @capgo/cli@latest build last-output --path build.json --field outputUrl per condividerlo in una pull request o in una chat. Il Capgo Documentazione build elenca tutte le opzioni.

Evita il rebuild per modifiche web

La maggior parte delle modifiche in un'app Capacitor si trova nel layer web. Ricompilare e ridistribuire un binario per una correzione di testo sprecare un giorno di elaborazione e revisione su TestFlight. Con Live updates di Capgo, i tester mantengono la build installata e tu invii nuovi bundle JavaScript a un canale di test:

bunx @capgo/cli@latest bundle upload --channel beta

Puoi persino assegnare un canale dedicato a ogni pull request, permettendo al QA di passare da uno all'altro sulla stessa app installata. Vedi trasforma ogni pull request in una preview installabile.

Risoluzione problemi

“Unable to install” su iOS ad hoc. L'UDID del dispositivo non è nel profilo o il profilo è scaduto. Controlla con security cms -D -i profile.mobileprovision.

L'app si apre e si chiude subito su iOS. Developer Mode è disattivato (build ad hoc/development) o il profilo è scaduto.

Build TestFlight bloccata in “Processing”. Attendi fino a un'ora. Se fallisce, l'email indica il motivo, spesso una stringa di descrizione dell'utilizzo mancante (NSCameraUsageDescription e simili) o un problema con le icone.

“Missing Compliance” su TestFlight. Rispondi alla domanda sulla compliance di esportazione in App Store Connect o aggiungi ITSAppUsesNonExemptEncryption a Info.plist.

Android: “App non installata”. È già installata una versione con una firma diversa, oppure l'APK non è firmato o è corrotto. Disinstalla l'app esistente.

Il tester non vede l'app sul Play Store dopo l'opt-in. Attendi qualche minuto, assicurati che abbiano eseguito l'accesso con l'account invitato e verifica che il rilascio sia distribuito sul track e che il loro paese sia disponibile.

“Versione code già utilizzata” durante l'upload. Incrementa versionCode nella android/app/build.gradle. L'internal app sharing è l'eccezione.

Le notifiche push non arrivano in TestFlight. TestFlight utilizza l'ambiente APNs di produzione. Controlla l' aps-environment entitlement e l'impostazione dell'ambiente del tuo provider push.

Configurazione consigliata per un piccolo team

1. Gruppo interno TestFlight con distribuzione automatica e canale di test interno Play per ogni merge su main.
2. Gruppo esterno TestFlight e canale di test chiuso Play per gli utenti beta, aggiornati settimanalmente.
3. Live updates su un beta canale per fix web-only tra un build e l'altro.
4. Quando la beta è stabile, promuovi lo stesso build in produzione su entrambi gli store e segui la guida alla prima revisione dell'app.