iOS- und Android-Apps an Tester verteilen

Um iOS-Apps an Testern 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 (intern, geschlossen oder offen), Play-Interne-App-Teilung für einmalige Links oder teilen Sie eine signierte APK über Firebase App Distribution oder einen direkten Download. Welche Methode richtig ist, hängt davon ab, wer Ihre Tester sind, wie viele es gibt und ob der Build durch die Infrastruktur des Stores gehen muss.

Dieses Leitfaden vergleicht jede Option, zeigt, wie jede aufgesetzt werden kann für ein Capacitor-App, und listet die Fehler, die Tester typischerweise antreffen.

Die Auswahl einer Methode

Regeln der Hand:

• Das gleiche Build, das Sie in den Store liefern werden? Verwenden Sie TestFlight- und Play-Tracks. Der Binär-Tester verwendet ist der Binär, der beworben wird.
• Tagliche QA-Builds? Interne Tests in beiden Stores oder Firebase App Distribution.
• Muss eine Web-Schichts-Änderung in Minuten getestet werden? Verschicken Sie ein live update in einen Testkanal anstatt einer neuen Binärdatei.

Bevor Sie verteilen: Signieren

Jeder Testbuild muss signiert werden.

• iOS Testbuilds verwenden entweder einen App Store Connect Profil (TestFlight) oder einen Ad Hoc Profil (direkter Install). Beide verwenden ein Apple-Distributionssiegel. 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 Installationen 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 (debugbar, unterschiedliche Signierung) und kann später nicht durch Ihren Play-Build aktualisiert werden.

iOS: TestFlight

Ein Build hochladen

Von Xcode: Produkt > Archivieren, dann Verteilen Sie die App > App Store Connect > Hochladen. Aus der Befehlszeile oder CI exportieren Sie ein .ipa und laden Sie es mit einem App Store Connect API-Schlüssel hoch, oder lassen Sie ein Cloud-Build-Service 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 Ihr App nur standardmäßige HTTPS-Verschlüsselung verwendet, damit App Store Connect für jeden Build die Exportklausel nicht ständig fragt:

<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 Testung

1. Öffnen Sie in App Store Connect Ihre App, TestFlight > Interne Testung, und erstellen Sie eine Gruppe.
2. Hinzufügen Sie Teammitglieder. Sie müssen über einen App Store Connect-Rollen (Admin, App Manager, Entwickler, Marketing… ) verfügen. Bis zu 100 Personen.
3. Enable Automatische Verteilung so geht jeder neue Build in die Gruppe.
4. Testern laden das TestFlight App aus dem App Store laden und die Einladung annehmen.

App aus dem App Store und akzeptieren Sie die Einladung.

Außenstehende Testen

1. TestFlight > Außenprüfung > + TestFlight > Außertesten > +
2. um eine Gruppe zu erstellen. öffentlicher Link Die Build zur Gruppe hinzufügen und die
3. Fügen Sie das Build zum Gruppe hinzu und füllen Sie Testinformation (was zu testen, Feedback-E-Mail, Beschreibung der Beta-App und Demo-Anmeldeinformationen, falls erforderlich).
4. Für Beta-App-Überprüfung. Die erste Build jeder Version wird überprüft, meist innerhalb eines Tages. Spätere Builds derselben Version gehen oft ohne vollständige Überprüfung aus.

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

TestFlight beschränkt sich auf

• Builds verfallen nach 90 Tagen.
• Die Tester benötigen iOS-Versionen, die von Ihrer Build unterstützt werden (Capacitor 8 erfordert iOS 15 oder später).
• Testflights-Builds verwenden die Produktions-App-Store-Zertifizierung, daher verwenden sie die production APNs-Umgebung.
• In-App-Käufe in TestFlight verwenden den Sandbox und werden nicht berechnet.

iOS: Ad-hoc-Verteilung

Ad-hoc-Builds installieren direkt auf Geräten, die Sie in der Apple-Entwickler-Portal registriert haben, ohne TestFlight oder Apple-Überprüfung.

1. Erheben Sie die UDID jedes Testers. Testers können es auf ihrem eigenen Telefon mit dem iOS UDID Finder, oder Sie können es aus Finder oder Xcode lesen, wenn das Gerät angeschlossen ist.
2. Registrieren Sie die Geräte in Zertifikate, Identifikatoren & Profile > Geräte.
3. Erstellen Sie ein Ad Hoc -Provisioning-Profil, das diese Geräte enthält, und laden Sie es herunter.
4. Bauen Sie ein .ipa Distribute App > Release Testing Verteilen App > Freigabe-Testen, welches der neue Name für Ad Hoc ist.
5. Install it:
   • Ziehen Sie .ipa Oder hoste es mit einem Xcode > Fenster > Geräte und Simulator.
   • Hosten Sie es mit einem itms-services manifest über HTTPS, damit Tester auf einen Link klicken können. Dienste wie Firebase App Distribution tun das für Sie.
6. Auf iOS 16 und später installieren Sie .ipa vom Mac (Xcode oder Apple Configurator) aus Entwicklermodus auf dem Gerät (Einstellungen > Datenschutz & Sicherheit). Installationen von einer itms-services Link benötigen es nicht. Siehe wie man den Entwicklermodus auf iOS aktiviert.

Bei der Hinzufügung eines neuen Testers bedeutet dies, die UDID des Testers zu registrieren, das Profil neu zu generieren und neu zu bauen. Geräteslots (100 pro Geräefamilie) werden nur dann zurückgesetzt, wenn Ihr Mitgliedsjahr neu beginnt, also Geräte nicht leichtfertig registrieren.

Android: Google Play-Testspuren

Die Google Play Console bietet drei Testspuren plus Produktionsumgebung. Alle benötigen ein AAB, das mit Ihrem Upload-Schlüssel signiert ist.

Interne Testung

1. Testen > Interne Testung > Testerteam: erstellen Sie eine E-Mail-Liste (bis zu 100 Adressen).
2. Neue Version erstellen, das AAB hochladen, die Versionshinweise hinzufügen, speichern und ausrollen.
3. Kopieren Sie den Opt-in-Link und senden Sie es an Tester. Diese akzeptieren und installieren es aus dem Google Play Store.

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

Abgeschlossene Tests

Abgeschlossene Tracks werden überprüft und unterstützende E-Mail-Listen oder Google-Gruppen verwendet. Dies ist der Track, den Sie benötigen für die 12 Tester für 14 Tage Regel, die sich auf persönliche Entwicklerkonten anwendet, die nach dem 13. November 2023 erstellt wurden, bevor der Zugriff auf die Produktion erfolgt ist. Die Verwendung eines Google-Gruppen macht es leicht für Tester, sich anzumelden. Details finden Sie in wie Sie Apple- und Google Play-Entwicklerkonten erstellen.

Offene Tests

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

Unsere Anleitung zur Android-Betaversionstestung vergleicht die Tracks im Detail.

Android: In-app-Teilung

Die In-app-Teilung ist die schnellste Möglichkeit, ein APK oder AAB auf einem Gerät über den Play Store zu erhalten, ohne Version code-Regeln und ohne Überprüfung.

1. In der Play Console öffnen Sie In-app-Teilung (unter Testing) und fügen Sie Upload-Tools hinzu.
2. Upload an APK or AAB. You get a link.
3. Die Tester öffnen die Play Store-App, gehen in die Einstellungen, tippen auf die Play Store-Version sieben Mal, um die Entwickler-Einstellungen zu enthüllen, und aktivieren Sie In-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: direkter APK und Firebase App Distribution

Direkter APK

Bauen Sie eine signierte Release-APK. Ein neuer Capacitor Projekt hat keine release signier-Konfiguration, also assembleRelease would produce an unsigned APK that won’t install. Add a signingConfigs.release block (Sicherheitsdateipfad und -passwörter, normalerweise aus) key.properties) to android/app/build.gradle und Punkt buildTypes.release.signingConfig Direkter APK

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

Ab dem 30. September 2026 installieren nur zertifizierte Android-Geräte in Brasilien, Indonesien, Singapur und Thailand Apps, deren Paketname von einem verifizierten Entwickler registriert ist. Eine globale Rollout-Pläne für 2027. Wenn Ihre Tester in diesen Ländern sind, registrieren Sie den Paketnamen im Android-Entwickler-Konsolen oder im Play-Konsolen. Installationen über adb werden nicht betroffen.

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 über den E-Mail-Link oder die App Tester App.
• iOS-Tester müssen sich immer 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.
• AAB-Verteilung erfordert die Verknüpfung des Firebase-Projekts mit Google Play.

Cloud-Builds, die Testern einen Link übergeben

Wenn Sie nicht wollen, dass Sie Macs und Signieren auf jedem CI-Runner halten Capgo Build Erstellt Capacitor Apps im Cloud. Für Testbuilds kann es die Store-Submission auslassen und das Binärdatei auf eine zeitbegrenzte 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"

Add --output-record build.json und das Link in der CI lesen mit bunx @capgo/cli@latest build last-output --path build.json --field outputUrl um es in einen Pull-Request oder Chat einzuposten. Die Capgo Build-Docs listet alle Optionen auf.

Skip Rebuilding für Web-Änderungen

Die meisten Änderungen in einem Capacitor-App sind im Web-Schicht. Wiederaufbau und Neuverteilung eines Binärs für einen Text-Fix verschwendet einen Tag der TestFlight-Verarbeitung und -Überprüfung. Mit Capgo Live-Updates, Testern bleibt die installierte Version und Sie pushen neue JavaScript-Bundles in einen Testkanal:

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

Sie können sogar jedem Pull-Request seinen eigenen Kanal geben und QA zwischen ihnen auf der gleichen installierten App umschalten. Siehe Jeden Pull-Request in eine installierbare Vorschau 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 sich und schließt sich sofort auf iOS. Der Entwickler-Modus ist aus (ad-hoc/Entwicklerversionen), 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 „Die App wurde nicht installiert“. Aus einer anderen Signatur ist bereits eine Version installiert, oder das APK ist unsigniert oder beschädigt. Entferne die bestehende App.

Der Tester sieht die App im Play Store nicht nach der Opt-in. Warte ein paar Minuten, stelle sicher, dass sie mit der eingeladenen Konto angemeldet sind und überprüfe, ob die Veröffentlichung auf dem Track und in ihrem Land verfügbar ist.

“Version code bereits verwendet” beim Hochladen. Bump versionCode in android/app/build.gradle. Die interne App-Teilung ist die Ausnahme.

Push-Benachrichtigungen gelangen nicht in TestFlight. TestFlight verwendet die Produktionsumgebung von APNs. Überprüfe die aps-environment Zulassung und die Umgebungsinstellung deines Push-Anbieters.

Empfehlung für ein kleines Team

1. TestFlight-Gruppe mit automatischer Verteilung, plus eine Play-Gruppe für interne Tests, für jede Merge zu main.
2. A TestFlight-Gruppe für externe Tester und eine Play-Teststrecke für Beta-User, wöchentlich aktualisiert.
3. Live-Updates auf einem beta Kanal für Web-Fixes zwischen Builds.
4. Wenn die Beta stabil ist, stelle die gleiche Build auf beiden Stores in Produktion um und folge dem Leitfaden für die erste App-Bewertung.