Wie man iOS- und Android-Apps an Tester verteilt

Um iOS-Apps an Tester zu verteilen, verwenden Sie TestFlight (interne Tester sofort, externe Tester nach einer kurzen Beta-App-Überprüfung) oder einen ad-hoc-Build für registrierte Geräte. Für Android verwenden Sie einen Google Play-Testtrack (interne, geschlossene oder offene), Play-Interne-App-Teilung für einmalige Links oder teilen Sie eine signierte APK über Firebase App Distribution oder einen direkten Download. Welche Option richtig ist, hängt davon ab, wer Ihre Tester sind, wie viele es gibt und ob der Build durch die Store-Infrastruktur gehen muss.

Dieses Leitfaden vergleicht jede Option, zeigt, wie man jede einrichtet, um eine Capacitor-App, und listet die Fehler, die Tester typischerweise antreffen.

Wahl der Methode

Regeln zum Nachahmen:

• Das gleiche Build, das Sie in den Store schicken werden? Verwenden Sie TestFlight und Play-Tracks. Der Binary-Tester verwendet das Binary, das für die Veröffentlichung vorgesehen ist.
• Tägliche QA-Builds? Interne Tests in beiden Stores oder Firebase App Distribution.
• Ein Web-Schicht-Änderung in Minuten testen müssen? Schicken Sie ein live update an einen Testkanal anstatt an ein neues Binärdatei.

Bevor Sie verteilen: Signieren

Jedes Testbuild muss signiert sein.

• iOS Testbuilds verwenden entweder einen App Store Connect Profil (TestFlight) oder einen Ad Hoc Profil (direkte Installation). Beide verwenden ein Apple-Distributionssertifikat. Siehe iOS-Zertifikate und Bereitstellungsprofile erklärt.
• Android Für Play-Tracks sind die Builds AABs, die mit Ihrem Upload-Schlüssel signiert sind. Für direkte Installation benötigen Sie ein APK, das mit einem beliebigen Release-Schlüssel signiert ist. Ein Debug-APK installiert sich auch, verhält sich jedoch anders (Debuggen, unterschiedliche Signierung) und kann später nicht durch Ihre Play-Build aktualisiert werden.

IOS: TestFlight

Eine Veröffentlichung hochladen

Von Xcode: Produkt > Archivieren, dann App verteilen > App Store Connect > Hochladen. Aus der Befehlszeile oder CI aus exportieren Sie ein .ipa und laden Sie es mit einem App Store Connect API-Schlüssel hoch oder lassen Sie einen Cloud-Build-Dienst es tun.

Seit April 2026 müssen Uploads mit Xcode 26 oder später erstellt werden.

Hinzufügen Sie diesen Schlüssel zu ios/App/App/Info.plist Wenn Ihre App nur Standard-HTTPS-Verschlüsselung verwendet, dann fragt App Store Connect nicht bei jedem Build die Exportklausel.

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

Die Verarbeitung dauert von wenigen Minuten bis etwa eine Stunde. Sie erhalten eine E-Mail, wenn das Build fertig ist.

Interne Tests

1. In App Store Connect öffnen Sie Ihre App, TestFlight > Interne Tests, und eine Gruppe erstellen.
2. Hinzufügen Sie Teammitglieder. Sie müssen eine Rolle in App Store Connect haben (Admin, App Manager, Developer, Marketing…). Bis zu 100 Personen.
3. Enable Automatische Verteilung so geht jede neue Build in die Gruppe.
4. Testern installieren Sie die TestFlight App aus dem App Store herunterladen und die Einladung annehmen.

Keine Überprüfung erforderlich. Dies ist der schnellste Weg von der Upload bis zum Telefon.

externe Prüfung

1. TestFlight > externe Prüfung > + um eine Gruppe zu erstellen.
2. Add testers by email, or enable a öffentlicher Link mit einer optionalen Tester-Grenze.
3. Fügen Sie dem Build zur Gruppe hinzu und füllen Sie Testinformation (was zu testen, Feedback-E-Mail, Beschreibung der Beta-App und Demo-Anmeldung falls erforderlich).
4. Einreichen Beta App ReviewDie erste Version jeder Version wird überprüft, meist innerhalb eines Tages. Spätere Builds der gleichen Version gehen oft ohne vollständige Überprüfung raus.

External testing unterstützt bis zu 10.000 Tester. Tester können Screenshot mit Feedback direkt aus TestFlight senden, die Sie in App Store Connect sehen.

TestFlight Einschränkungen

• Builds verfallen nach 90 Tagen.
• Testern sind iOS-Versionen erforderlich, die von Ihrem Build unterstützt werden (Capacitor 8 erfordert iOS 15 oder später).
• TestFlight Builds verwenden die Produktions-App Store-Zertifizierung, daher verwenden Push-Benachrichtigungen den production APNs-Umgebung.
• In-App-Käufe in TestFlight verwenden den Sandbox und werden nicht berechnet.

iOS: Ad-hoc-Verteilung

Direkt auf Geräte installieren, die Sie im Apple Developer Portal registriert haben, ohne TestFlight oder Apple-Überprüfung.

1. Sammeln Sie jeden Testers UDID. Testern können sie es auf ihrem eigenen Telefon mit dem iOS UDID Finder, oder Sie können es aus Finder oder Xcode lesen, wenn das Gerät verbunden ist.
2. Registrieren Sie die Geräte in Zertifikate, Identifikatoren und Profile > Geräte.
3. Erstellen Sie ein Ad-hoc Zertifikat, das diese Geräte enthält und laden Sie es herunter.
4. Build an .ipa mit diesem Profil (Xcode:) Distribute App > Release Testing, das die neue Bezeichnung für Ad-hoc ist.
5. Install it:
   • Ziehen Sie das .ipa auf das Gerät in Finder oder Xcode > Fenster > Geräte und Simulator.
   • Oder hosten Sie es mit einem itms-services über HTTPS, damit Tester auf einen Link klicken können. Dienste wie Firebase App Distribution tun das für Sie.
6. Bei iOS 16 und später ist die Installation des .ipa aus einem Mac (Xcode oder Apple Configurator) nur möglich, wenn Entwicklermodus auf dem Gerät (Einstellungen > Datenschutz & Sicherheit). Installiert von einem itms-services wie Entwicklermodus auf iOS zu aktivieren Wie man den Entwicklermodus auf iOS aktiviert.

Adding a new tester means registering their UDID, regenerating the profile and rebuilding. Device slots (100 per device family) only reset when your membership year renews, so do not register devices casually.

Android: Google Play-Test-Tracks

Die Play Console verfügt über drei Test-Tracks plus Produktions-Track. Alle davon benötigen eine AAB, die mit Ihrem Upload-Schlüssel signiert ist.

Interne Testung

1. Testen > Interne Testung > Tester: Erstellen Sie eine E-Mail-Liste (bis zu 100 Adressen).
2. Neue Version erstellenLaden Sie das AAB hoch, fügen Sie Release Notes hinzu, speichern und verteilen.
3. Kopieren Sie den Opt-in-Link und senden Sie ihn an die Tester. Diese akzeptieren und installieren ihn aus dem Play Store.

Interne Versionen stehen in der Regel innerhalb von Minuten zur Verfügung und warten nicht auf eine vollständige Überprüfung. Die erste Version einer neuen App kann länger dauern, während Google die App verarbeitet.

Abgeschlossene Testung

Schließe sich die Spuren werden überprüft und E-Mail-Listen oder Google-Gruppen unterstützt. Dies ist der Spuren, die Sie benötigen für die 12 Tester für 14 Tage Regel, die auf persönliche Entwicklerkonten angewendet wird, die nach dem 13. November 2023 erstellt wurden, bevor der Zugriff auf die Produktion. Die Verwendung einer Google-Gruppe erleichtert es den Testern, sich anzuschließen. Details finden Sie in wie Sie Apple- und Google Play-Entwicklerkonten erstellen.

Offene Testung

Jeder kann sich von Ihrer Play-Liste aus anschließen. Verwenden Sie sie für eine öffentliche Beta, sobald Ihre Store-Liste abgeschlossen ist. Die Rückmeldung von offenen Testern ist privat und beeinflusst nicht Ihre öffentliche Bewertung.

Unsere Anleitung zur Android-Beta-Testung vergleicht die Spuren in mehr Details.

Android: Internes App-Teilen

Internes App-Teilen ist die schnellste Möglichkeit, jede APK oder AAB auf einem Gerät über den Play Store zu erhalten, ohne Version code-Regeln und ohne Überprüfung.

1. Öffnen Sie in Play Console Interne App-Teilung (unter Test) und fügen Sie Upload-Tools hinzu.
2. Upload an APK or AAB. You get a link.
3. Testern öffnen sie die Play Store App, gehen zu den Einstellungen, tippen auf die Google Play Store-Version sieben Mal, um die Entwickler-Einstellungen zu enthüllen, und schalten sie ein Interne App-Teilung.
4. Die Tester öffnen den Link und installieren.

Es ist nützlich für die QA von Pull-Request-Builds, da die Versionsnummern nicht erhöht werden müssen.

Android: direktes APK und Firebase App Distribution

Direktes APK

Erstellen Sie ein signiertes Release-APK. Ein neues Capacitor-Projekt hat keine release signing-Konfiguration, also assembleRelease would produce an unsigned APK that won’t install. Add a signingConfigs.release Block (Sicherheitsdatenbankpfad und -passwörter, normalerweise aus key.properties) to android/app/build.gradle Teilen buildTypes.release.signingConfig probieren Sie es zuerst.

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

(siehe 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 wie man Entwickleroptionen auf Android aktiviert).

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 betroffen sind.

Firebase App Distribution

Firebase App Distribution funktioniert für beide Plattformen, sendet E-Mail-Einladungen und verfolgt, wer welche Version installiert hat.

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"

• Android-Tester installieren aus der E-Mail-Link oder der App Tester App.
• iOS-Tester müssen sich noch in einem Ad-hoc- (oder Entwicklungs-) Profil befinden. App Distribution sammelt ihre UDIDs, wenn sie die Einladung akzeptieren, aber Sie registrieren sie und bauen sie selbst neu.
• Für die AAB-Verteilung ist die Verknüpfung des Firebase-Projekts mit Google Play erforderlich.

Cloud-Builds, die den Testern einen Link liefern

Wenn Sie nicht wollen, dass Sie Macs und Signieren auf jedem CI-Runner aufrechterhalten müssen Capgo Build Baut Capacitor-Apps im Cloud. Für Testversionen kann es die Store-Submission auslassen und das Binärdatei auf einen zeitbegrenzten Download-Link mit einem QR-Code code hochladen:

# 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"

Hinzufügen --output-record build.json und liest den Link in CI mit bunx @capgo/cli@latest build last-output --path build.json --field outputUrl um ihn in einen Pull-Request oder Chat einzufügen. Die Capgo Build-Dokumentation Alle Optionen auflisten

Für Web-Änderungen Skip-Rebuild

Die meisten Änderungen in einer Capacitor-App finden sich im Web-Schicht. Die Wiederherstellung und Verteilung eines Binärs für einen Text-Fix verschwendet einen Tag der TestFlight-Verarbeitung und -Überprüfung. Mit Capacitor Live-Updates Capgo Live-Updates, die Tester behalten die Installation und Sie pushen neue JavaScript-Bundles in einen Testkanal:

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

Sie können jedem Pull-Antrag sogar seinen eigenen Kanal geben und lassen die QA-Abteilung zwischen ihnen auf dem gleichen installierten App wechseln. Jede Pull-Anfrage in ein installierbares Vorab-Preview umwandeln.

Troubleshooting

“Keine Installation möglich” auf iOS ad hoc. Der Geräte-UDID ist nicht im Profil enthalten oder das Profil ist abgelaufen. Überprüfen Sie mit security cms -D -i profile.mobileprovision.

Die App öffnet und schließt sich sofort auf iOS. Entwicklermodus ist ausgeschaltet (ad-hoc/Entwicklungsbuilds), oder das Profil ist abgelaufen.

TestFlight-Build steckt in „Verarbeitung“. Warten Sie bis zu einer Stunde. Wenn es fehlschlägt, enthält der E-Mail-Bericht den Grund, oft eine fehlende Verwendungsbeschreibung-String ("NSCameraUsageDescription TestFlight „Mangelnde Einhaltung“.

TestFlight „Mangelnde Einhaltung“ Beantworte die Exportklauselfrage in App Store Connect oder füge sie hinzu ITSAppUsesNonExemptEncryption to Info.plist.

Android "App nicht installiert". Eine Version mit einer anderen Signatur ist bereits installiert, oder das APK ist unsigniert oder beschädigt. Entferne die bestehende App.

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 bereits verwendet” bei der Upload. Bump versionCode in android/app/build.gradleInternales App-Teilen ist die Ausnahme.

Benachrichtigungen gelangen nicht in TestFlight. TestFlight verwendet die Produktionsumgebung von APNs. Überprüfen Sie die aps-environment Eigenschaft und die Umgebungsinstellung Ihres Push-Providers.

Empfehlung für ein kleines Team

1. TestFlight-Gruppe mit automatischer Verteilung, plus eine Play-Test-Track, für jede Merge-Operation main.
2. Eine TestFlight-Externgruppe und eine Play-Abgeschlossene-Test-Track für Beta-Nutzer, wöchentlich aktualisiert.
3. Live-Updates auf einem beta Kanal für Web-Only-Fixes zwischen Builds.
4. Wenn die Beta stabil ist, stellen Sie die gleiche Build auf beide Stores um und folgen Sie den Erstes Mal App-Bewertungsleitfaden.