Pour distribuer des applications iOS aux testeurs, utilisez TestFlight (testeurs internes instantanément, testeurs externes après une brève évaluation de l'application Beta) ou une build ad hoc pour des appareils enregistrés. Pour Android, utilisez une piste de test Google Play (intérieure, fermée ou ouverte), une partage d'application interne Play pour des liens uniques, ou partagez un APK signé à l'aide de Firebase App Distribution ou un téléchargement direct.
Cette guide compare toutes les options, montre comment configurer chaque option pour une application Capacitor et liste les erreurs auxquelles les testeurs tombent généralement.
Choisir une méthode
| Méthode | Plateforme | Max testeurs | Évaluation avant que les testeurs l'aient | Les testeurs ont besoin de | Meilleur pour |
|---|---|---|---|---|---|
| TestFlight interne | iOS | 100 membres d'équipe | Non | Utilisateur App Store Connect, application TestFlight | Votre équipe |
| TestFlight externe | iOS | 10,000 | Examen de l'application bêta (première build d'une version) | Examen bêta d'application (première version d'une version) | Utilisateurs bêta, clients |
| Ad hoc | iOS | 100 appareils par type d'appareil par an | Non | Identifiant UDID enregistré, Mode développeur | Petite équipe QA, pas de revue Apple |
| Test interne sur Play | Android | 100 | Pas de revue complète, disponible généralement en quelques minutes | Compte Google sur liste de courriel | Votre équipe |
| Testez la version fermée | Android | Listes d'emails ou Google Groups | Oui | Compte Google, lien d'opt-in | Utilisateurs bêta, la limite de 12 utilisateurs |
| Testez la version ouverte | Android | Sans limite ou limité | Oui | Opt-in sur la liste | Bêta publique |
| Partage d'applications internes | Android | Tout le monde avec le lien | Non | Compte Google, paramètres activés | Construits de QA rapides, toute version code |
| Firebase App Distribution | Both | Gros | Non | Invitation par courriel; iOS nécessite un UDID enregistré | QA cross-plateforme |
| Lien direct APK | Android | N'importe qui | Non | Autoriser les sources inconnues | Tests internes rapides |
Règles de doigté :
- Same build you will ship to the store? Utilisez TestFlight et les pistes Play. Le binaire que les testeurs utilisent est le binaire qui sera promu.
- Des builds de QA quotidiens ? Tests internes sur les deux magasins, ou Firebase App Distribution.
- Need to test a web-layer change in minutes? Envoyez un live update vers un canal de test au lieu d'un nouveau binaire.
Avant de distribuer : signature
Tout build de test doit être signé.
- IOS Les builds de test utilisent soit un App Store Connect profil (TestFlight) ou un Ad Hoc profil (installation directe). Les deux utilisent un certificat de distribution Apple. Consultez IOS certificats et profils de provisionnement expliqués.
- Android Les builds pour Play sont des AAB signés avec votre clé de téléchargement. Pour les installations directes, vous avez besoin d'un APK signé avec n'importe quelle clé de publication. Un APK de débogage s'installe également, mais il se comporte différemment (débogable, signature différente) et ne peut pas être mis à jour par votre build Play ultérieur.
IOS : TestFlight
Charger une build
À partir de Xcode : Produit > Archivage, puis Distribuer l'application > App Store Connect > ChargerExportez depuis la ligne de commande ou CI un .ipa et le charger avec une clé App Store Connect API, ou laisser un service de build cloud s'en charger.
Depuis avril 2026, les chargements doivent être effectués avec Xcode 26 ou ultérieur.
Ajoutez cette clé à ios/App/App/Info.plist Si votre application utilise uniquement l'encodage HTTPS standard, App Store Connect ne pose donc pas la question de conformité à l'exportation pour chaque build.
<key>ITSAppUsesNonExemptEncryption</key>
<false/>Le traitement peut prendre entre quelques minutes et une heure. Vous recevez un courrier électronique lorsque la build est prête.
Testage interne
- Ouvrez votre application dans App Store Connect, TestFlight > Testage interne, et créez un groupe.
- Ajoutez des membres d'équipe. Ils doivent avoir un rôl’App Store Connect (Administrateur, Gestionnaire d'application, Développeur, Marketing…). Jusqu'à 100 personnes.
- Activer la distribution automatique afin que chaque nouvelle build se rende dans le groupe.
- Les testeurs installent l' TestFlight l'application depuis l'App Store et accepter l'invitation.
Aucune revue n'est nécessaire. C'est la voie la plus rapide de l'upload au téléphone.
Testage externe
- TestFlight > Testage externe > + pour créer un groupe.
- Ajouter des testeurs par courriel, ou activer un lien public avec une limite optionnelle de testeurs.
- Ajouter la build au groupe et renseigner les Informations de test (what to test, feedback email, beta app description, and demo login if needed).
- Soumettre à Examen de l'Application Bêta. La première build de chaque version est examinée, généralement dans un jour. Les builds ultérieurs de la même version sont souvent envoyés sans examen complet.
La mise en ligne publique supporte jusqu'à 10 000 testeurs. Les testeurs peuvent envoyer des captures d'écran avec des commentaires directement depuis TestFlight, que vous voyez dans App Store Connect.
Connaître les limites de TestFlight
- Les builds expirent après 90 jours.
- Les testeurs nécessitent des versions iOS prises en charge par votre build (Capacitor 8 nécessite iOS 15 ou ultérieur).
- TestFlight construit utilise la signature de l'App Store de production, donc les notifications push utilisent le mode de production environnement APNs.
- Les achats en application dans TestFlight utilisent le sandbox et ne sont pas facturés.
iOS : distribution ad hoc
Les builds ad hoc s'installent directement sur les appareils que vous avez enregistrés dans le portail Apple Developer, sans TestFlight ou examen Apple.
- Collectez l'ID de chaque appareil de testeur. Les testeurs peuvent l'obtenir sur leur propre téléphone avec le Trouvez l'ID UDID d'iOS, ou vous pouvez le lire à partir de Finder ou Xcode lorsque le périphérique est connecté.
- Inscrivez les appareils dans Certificats, Identifiants et Profils > Appareils.
- Créez un Ad Hoc profil de provisionnement qui inclut ces appareils et le télécharger.
- Construisez un
.ipaavec ce profil (Xcode:) Distribute App > Test de version, qui est le nom plus récent pour Ad Hoc). - Installez-le :
- Glissez le
.ipasur l’appareil dans Finder ou Xcode > Fenêtre > Dispositifs et Simulateurs. - Ou le héberger avec un
itms-servicesmanifeste sur HTTPS afin que les testeurs puissent cliquer sur un lien. Des services comme Firebase App Distribution s'en chargent pour vous.
- Glissez le
- On iOS 16 et ultérieur, l'installation du
.ipaà partir d'un Mac (Xcode ou Apple Configurateur) nécessite Mode Développeur sur l'appareil (Réglages > Confidentialité et Sécurité). Les installations à partir d'unitms-servicesne le nécessitent pas. Consultez comment activer le Mode Développeur sur iOS.
L'ajout d'un nouveau testeur implique l'enregistrement de son UDID, la régénération du profil et la reconstruction. Les emplacements de dispositifs (100 par famille de dispositifs) ne se réinitialisent qu'à la renouvellement de votre abonnement annuel, n'enregistrez donc pas les appareils sans réfléchir.
Android : Suivi de tests Google Play
Le Console de Play compte trois pistes de test plus la production. Toutes nécessitent un AAB signé avec votre clé de téléversement.
Test interne
- Test > Test interne > Testeurs: Créez une liste d'emails (jusqu'à 100 adresses).
- Créer une nouvelle version, téléversez l'AAB, ajoutez des notes de version, enregistrez et déployez.
- Copiez le lien d'adhésion et envoyez-l’aux testeurs. Ils acceptent et installent depuis Google Play.
Les versions internes sont généralement disponibles en quelques minutes et ne nécessitent pas une revue complète. La première version d'une nouvelle application peut prendre plus de temps pendant que Google traite l'application.
Test fermé
Les pistes fermées sont examinées et les listes de courriel de support ou les groupes Google. C'est la piste dont vous avez besoin pour le 12 testeurs pendant 14 jours règle qui s'applique aux comptes développeurs personnels créés après le 13 novembre 2023, avant l'accès à la production. Utiliser un groupe Google facilite l'adhésion des testeurs. Les détails sont dans comment créer des comptes développeurs Apple et Google Play.
Test ouvert
Quiconque peut rejoindre à partir de votre liste de Play. L'utiliser pour une bêta publique une fois votre liste de magasin complète. Les commentaires des testeurs ouverts sont privés et n'affectent pas votre notation publique.
Notre guide de test de bêta Android compare les pistes en détail.
Android : Partage d'applications internes
Le partage d'applications internes est la façon la plus rapide de mettre n'importe quel APK ou AAB sur un appareil via le magasin Play, sans règles de version code et sans examen.
- In Play Console, open Partage d'applications internes (en cours de test) et ajoutez des téléchargeurs.
- Téléchargez un APK ou un AAB. Vous obtenez un lien.
- Testeurs ouvrent l'application Google Play, accèdent aux paramètres, appuient sur Version de l'application Google Play sept fois pour révéler les paramètres de développement, et l'activer Partage d'applications internes.
- Les testeurs ouvrent le lien et installent.
Cela est utile pour la QA des builds de demande de tirage car les codes de version ne doivent pas augmenter.
Android : APK direct et Firebase App Distribution
APK direct
Créez un APK de version de production signé. Un nouveau projet Capacitor n'a pas release config de signature, donc assembleRelease produirait un APK non signé qui ne s'installera pas. Ajoutez un signingConfigs.release bloc (chemin de clé de magasin et mots de passe, généralement lus à partir de key.properties) à android/app/build.gradle et point buildTypes.release.signingConfig Essayez d'abord.
bun run build
bunx cap sync android
cd android && ./gradlew assembleReleaseShare 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 Comment activer les options de développeur sur 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 config de signature, donc
Distribution Firebase de l'application
Firebase App Distribution fonctionne pour les deux plateformes, envoie des invitations par email et suit qui a installé quelle version.
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"- Les testeurs Android installent à partir du lien du courriel ou de l'application App Tester.
- Les testeurs iOS doivent toujours être dans un profil ad hoc (ou de développement). La distribution Firebase collecte leurs UDIDs lorsqu'ils acceptent l'invitation, mais vous les inscrivez et les rebâtissez vous-même.
- La distribution AAB nécessite de lier le projet Firebase à Google Play.
Les builds Cloud qui remettent aux testeurs un lien
Si vous ne souhaitez pas maintenir des Macs et la signature sur chaque exécuteur CI, Construire Capgo Construit des applications Capacitor dans le cloud. Pour les builds de test, il peut sauter la soumission au magasin et télécharger le binaire vers un lien de téléchargement temporaire avec 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"Ajouter --output-record build.json et lire le lien dans CI avec bunx @capgo/cli@latest build last-output --path build.json --field outputUrl pour le poster dans une demande de tirage ou un chat. Le Capgo Documentation Lister toutes les options.
Éviter la reconstruction pour les modifications web.
Most changes in a Capacitor app are in the web layer. Rebuilding and redistributing a binary for a text fix wastes a day of TestFlight processing and review. With Capgo mises à jour en directLes testeurs gardent la build qu'ils ont installée, et vous envoyez de nouveaux paquets JavaScript vers un canal de test.
bunx @capgo/cli@latest bundle upload --channel betaVous pouvez même attribuer à chaque demande de tirage son propre canal et laisser la QA passer d'un à l'autre dans la même application installée. Voir Convertir chaque demande de tirage en une prévisualisation installable..
Troubleshooting
« Impossible d'installer » sur iOS ad hoc. L’UDID du dispositif n'est pas dans le profil, ou le profil a expiré. Vérifiez avec security cms -D -i profile.mobileprovision.
L'application s'ouvre et se ferme immédiatement sur iOS. Le mode développeur est désactivé (builds ad hoc/developpement), ou le profil a expiré.
La build TestFlight est bloquée dans « Traitement ». Attendez jusqu'à une heure. Si cela échoue, l'e-mail liste la raison, souvent une chaîne de description d'utilisation manquante.NSCameraUsageDescription TestFlight « Manque de conformité ».
TestFlight « Manque de conformité ». Répondez à la question de conformité d'exportation dans App Store Connect ou ajoutez ITSAppUsesNonExemptEncryption context Info.plist.
Android « Application non installée ». Une version avec une signature différente est déjà installée, ou l'APK n'est pas signée ou est corrompue. Supprimez l'application existante.
Tester does not see the app in Play Store after opting in. 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 déjà utilisée” sur l'upload. Bump versionCode dans android/app/build.gradlel'application partagée interne constitue l'exception.
Les notifications push ne sont pas reçues dans TestFlight. TestFlight utilise l'environnement APNs de production. Vérifiez le aps-environment Configuration recommandée pour une petite équipe
Configuration recommandée pour une petite équipe
- TestFlight groupe interne avec distribution automatique, plus une piste de test interne Play, pour chaque fusion à
main. - Un groupe externe TestFlight et une piste de test fermée Play pour les utilisateurs bêta, mise à jour hebdomadaire.
- Live updates on a
betacanal pour les correctifs web uniquement entre les builds. - Lorsque la bêta est stable, promouvez la même version sur les deux magasins et suivez le guide de revue d'applications pour débutants.
