Come distribuire le app iOS e Android ai tester

Per distribuire app iOS ai testatori, utilizza TestFlight (testatori interni istantaneamente, testatori esterni dopo una breve revisione Beta App) o un build ad hoc per dispositivi registrati. Per Android, utilizza un tracciato di testing di Google Play (interni, chiusi o aperti), condivisione di app interna di Play per collegamenti uno-a-uno, o condividi un APK firmato tramite Firebase App Distribution o un download diretto. Quale metodo è giusto dipende da chi sono i testatori, quante ce ne sono e se il build deve passare attraverso l'infrastruttura del negozio.

Questa guida confronta ogni opzione, mostra come configurare ogni una per un'app Capacitor, e elenca gli errori che i testatori solitamente incontrano.

Scegliere un metodo

Regole di base:

• Lo stesso build che invierai alla store? Utilizza TestFlight e Play tracks. Il file binario utilizzato dai tester è lo stesso che verrà promosso.
• Costruzioni QA quotidiane? Test interni su entrambe le store, o Firebase App Distribution.
• Need to test a web-layer change in minutes? Invia un live update in un canale di test invece di un nuovo binario.

Prima di distribuire: firma

Ogni build di test deve essere firmato.

• iOS costruiscono test build con o App Store Connect profilo (TestFlight) o un Ad Hoc profilo (installazione diretta). Entrambi utilizzano un certificato di distribuzione Apple. Vedi Certificati iOS e profili di provisioning spiegati.
• Android builds for Play tracks are AABs signed with your upload key. For direct installs you need an APK signed with any release key. A debug APK also installs, but it behaves differently (debuggable, different signing) and cannot be upgraded by your Play build later.

IOS: TestFlight

Inviare un build

Dal Xcode: Prodotto > Archivia, poi Distribuisci App > App Store Connect > Inviare. Dal prompt dei comandi o da CI, esporta un .ipa e invialo con una chiave App Store Connect API, o lascia che un servizio di costruzione cloud lo faccia.

Da aprile 2026, gli upload devono essere costruiti con Xcode 26 o successivo.

Aggiungi questa chiave a ios/App/App/Info.plist se il tuo app utilizza solo l'HTTPS standard, quindi App Store Connect non chiederà la domanda di conformità all'esportazione per ogni build:

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

Il processo richiede da pochi minuti a circa un'ora. Ricevi un'email quando il build è pronto.

Test interni

1. In App Store Connect apri l'applicazione, TestFlight > Test interni, e crea un gruppo.
2. Aggiungi membri del team. Devono avere un ruolo di App Store Connect (Admin, App Manager, Developer, Marketing…). Fino a 100 persone.
3. Abilita distribuzione automatica così ogni nuovo build va al gruppo.
4. Gli tester installano l' TestFlight scarica l'app dall'App Store e accetta l'invito.

Nessuna revisione è necessaria. Questo è il percorso più veloce dall'upload al telefono.

Test di terze parti

1. TestFlight > Test di terze parti > + per creare un gruppo.
2. Aggiungi tester per email, o abilita public link con un limite di tester facoltativo.
3. Aggiungi il build al gruppo e inserisci le informazioni Informazioni di Test (cosa testare, indirizzo email per i feedback, descrizione dell'app beta e accesso demo se necessario).
4. Submit for Valutazione App BetaLa prima build di ogni versione viene revisionata, di solito entro un giorno. Le successive build della stessa versione vengono spesso distribuite senza una revisione completa.

La valutazione esterna supporta fino a 10.000 tester. I tester possono inviare screenshot con feedback direttamente da TestFlight, che si vedono in App Store Connect.

Limiti di TestFlight

• I build scadono dopo 90 giorni.
• I tester necessitano delle versioni iOS supportate dal vostro build (Capacitor 8 richiede iOS 15 o successivo).
• TestFlight costruisce utilizzando la firma di produzione dell'App Store, quindi le notifiche push utilizzano production Ambiente APNs.
• Acquisti in-app in TestFlight utilizzano il sandbox e non sono addebitati.

Distribuzione ad hoc per iOS

Costruisce installazioni ad hoc direttamente sui dispositivi che hai registrato nel portale dello sviluppatore Apple, senza TestFlight o revisione Apple.

1. Raccogli ogni UDID del tester. I tester possono ottenerlo sul proprio telefono con il iOS Finder di UDIDo 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 include quei dispositivi e scaricalo.
4. Crea un .ipa con quel profilo (Xcode: Distribuisci App > Test di rilascio, che è il nuovo nome per Ad Hoc).
5. Installa:
   • Trascina il file .ipa su il dispositivo nel Finder o Xcode > finestra > dispositivi e simulator.
   • O ospitalo con un itms-services manifesto su HTTPS in modo che i testatori possano cliccare su un link. Servizi come Firebase App Distribution lo fanno per te.
6. On iOS 16 e successive, l'installazione del .ipa da un Mac (Xcode o Apple Configurator) richiede Modalità sviluppatore abilitata sul dispositivo (Impostazioni > Privacy e sicurezza). Le installazioni da un itms-services link non ne hanno bisogno. Vedi come abilitare la Modalità sviluppatore su iOS.

L'aggiunta di un nuovo testatore significa registrare il suo UDID, rigenerare il profilo e ricostruire. I slot di dispositivo (100 per famiglia di dispositivi) si resettano solo quando si rinnova l'anno di abbonamento, quindi non registrare dispositivi con leggerezza.

Android: tracce di testing di Google Play

Console di Gioco ha tre piste di testing più la produzione. Tutte richiedono un AAB firmato con la tua chiave di caricamento.

Test interni

1. Testing > Test interni > Testatori: crea una lista di posta elettronica (fino a 100 indirizzi).
2. Crea una nuova versione, caricare l'AAB, aggiungere note sulla versione, salvare e distribuire.
3. Copia il link di opt-in e invialo ai testatori. Essi accettano e installano dallo Store di Play.

I rilasci interni sono di solito disponibili in pochi minuti e non attendono una revisione completa. Il primo rilascio di un'app completamente nuova potrebbe richiedere più tempo mentre Google elabora l'app.

Test chiusi

Le tracce chiuse vengono esaminate e le liste di posta di supporto o i gruppi di Google. Questo è il tracciato che hai bisogno per il 12 tester per 14 giorni regola che si applica ai conti utente sviluppatore creati dopo il 13 novembre 2023, prima dell'accesso alla produzione. Utilizzare un gruppo di Google rende facile per i tester unirsi. I dettagli sono in come creare conti sviluppatore Apple e Google Play.

Azione di testing aperto

Chiunque può unirsi dalla tua lista di pubblicazione Play. Utilizzalo per un beta pubblico una volta che la tua lista di pubblicazione è completa. I feedback dagli tester aperti sono privati e non influiscono sulla tua valutazione pubblica.

Nostra Guida al testing beta Android compara i tracce in modo più dettagliato.

Android: Condivisione di app interna

La condivisione di app interna è il modo più veloce per ottenere qualsiasi APK o AAB su un dispositivo attraverso il Store Play, senza regole di versione code e senza revisione.

1. In Console di Play, apri Condivisione di app interne (in fase di testing) e aggiungi caricatori.
2. Carica un APK o AAB. Otterrai un link.
3. I testatori aprono l'app Store, vanno alle impostazioni, toccano la versione dell'app Store sette volte per rivelare le impostazioni dello sviluppatore, e attivano Condivisione di app interne.
4. I testatori aprono il link e installano.

è utile per la QA dei build di richiesta di pull perché i codici di versione non devono aumentare.

Android: APK diretto e Firebase App Distribution

APK diretto

Costruisci un APK di rilascio firmato. Un nuovo progetto Capacitor non ha release configurazione di firma, quindi assembleRelease produrrebbe un APK non firmato che non si potrà installare. Aggiungi un signingConfigs.release blocco (percorso del keystore e password, di solito letti da key.properties) a android/app/build.gradle e punto buildTypes.release.signingConfig Condividi

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

Share android/app/build/outputs/apk/release/app-release.apk through a link. Testers allow their browser or file manager to install unknown apps and open the file. If they already have a Play Store version installed, they must uninstall it first because the signatures differ. You can also install over USB with adb install -r app-release.apk (see Come abilitare le opzioni dello sviluppatore su Android).

From September 30, 2026, certified Android devices in Brazil, Indonesia, Singapore and Thailand only install apps whose package name is registered by a verified developer, with global rollout planned for 2027. If your testers are in those countries, register the package name in the Android Developer Console or Play Console. Installs through adb non sono interessati.

Distribuzione App Firebase

Distribuzione App Firebase funziona per entrambe le piattaforme, invia inviti via email 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 testatori Android installano dal link email o dall'app App Tester.
• I testatori iOS devono ancora essere in un profilo ad hoc (o di sviluppo). La distribuzione App raccoglie i loro UDIDs quando accettano l'invito, ma è necessario registrare loro e ricostruire da sé.
• La distribuzione AAB richiede di collegare il progetto Firebase a Google Play.

Costruzioni Cloud che consegnano un link ai testatori

Se non si desidera mantenere Mac e firma su ogni esecutore CI Capgo Build builds Capacitor apps in the cloud. For test builds it can skip store submission and upload the binary to a time-limited download link with a 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"

Add --output-record build.json e leggi il link nel CI con bunx @capgo/cli@latest build last-output --path build.json --field outputUrl pubblicarlo in una richiesta di pull o in una chat. Capgo Documentazione di costruzione Elencare tutte le opzioni.

Saltare la ricostruzione per le modifiche web

La maggior parte delle modifiche in un'app Capacitor si trovano nel layer web. La ricostruzione e la redistribuzione di un binario per una correzione di testo sprecano un giorno di elaborazione e revisione di TestFlight. Con Capgo aggiornamenti in tempo realei testatori mantengono l'installazione che hanno fatto, e puoi inviare nuovi pacchetti di JavaScript a un canale di test:

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

Puoi anche dare a ogni richiesta di pull il suo canale e far cambiare la QA tra di loro sull'app installata. Vedi Trasformare ogni richiesta di pull in un'anteprima installabile.

Risolvere i problemi

"Impossibile installare" su iOS ad hoc. Il dispositivo UDID non è presente nel profilo, o il profilo è scaduto. Controlla con security cms -D -i profile.mobileprovision.

L'app si apre e si chiude immediatamente su iOS. Modalità sviluppatore è spenta (build ad hoc/development), o il profilo è scaduto.

Build TestFlight bloccato in “Elaborazione”. Aspetta fino a un'ora. Se fallisce, l'email elenca la ragione, spesso una descrizione di utilizzo mancante.NSCameraUsageDescription TestFlight “Mancanza di conformità”.

TestFlight “Mancanza di conformità”. Rispondere alla domanda di esportazione di conformità in App Store Connect o aggiungere ITSAppUsesNonExemptEncryption context Info.plist.

Applicazione Android non installata. Una versione con un diverso sigla è già installata, o l'APK non è firmato o è danneggiato. Disinstalla l'app esistente.

Il tester non vede l'app nella Play Store dopo aver optato per l'aggiornamento. Wait a few minutes, make sure they are signed in with the invited account, and check that the release is rolled out to the track and their country is available.

“Version code già utilizzata” durante l'upload. Aggiorna versionCode in android/app/build.gradle. La condivisione di app interne è l'eccezione.

Gli avvisi push non arrivano in TestFlight. TestFlight utilizza l'ambiente APNs di produzione. Controlla il aps-environment Configurazione consigliata per un piccolo team

Impostazione consigliata per un piccolo team

1. Un gruppo esterno di TestFlight e un tracciato di testing chiuso di Play per gli utenti beta, aggiornato settimanalmente. main.
2. Un gruppo esterno TestFlight e un percorso di testing chiuso Play per utenti beta, aggiornato settimanalmente.
3. Live updates on a beta canale per correzioni web esclusivamente tra le build.
4. Quando il beta è stabile, promuovi la stessa build in produzione su entrambi i negozi e segui le guida di revisione per utenti nuovi.