iOS- und Android-Apps an Tester verteilen

Um iOS-Apps an Tester zu verteilen, nutzt man TestFlight (interne Tester sofort, externe nach kurzer Beta App Review) oder einen Ad-hoc-Build für registrierte Geräte. Bei Android nutzt man einen Google Play Test-Track (intern, geschlossen oder offen), Play Internal App Sharing für Einmal-Links oder teilt eine signierte APK über Firebase App Distribution oder per direktem Download. Welche Option passt, hängt davon ab, wer eure Tester sind, wie viele es sind und ob der Build über die Store-Infrastruktur laufen muss.

Dieser Guide vergleicht alle Optionen, zeigt, wie man jede Option für eine Capacitor App einrichtet, und listet die Fehler auf, auf die Tester typischerweise stoßen.

Eine Methode wählen

Faustregeln:

• Dasselbe Build, das du in den Store bringst? Nutze TestFlight und Play-Tracks. Das Binary, das Tester verwenden, ist das, das hochgestuft wird.
• Tägliche QA-Builds? Interne Tests in beiden Stores oder Firebase App Distribution.
• Muss eine Web-Layer-Änderung in Minuten getestet werden? Veröffentliche ein live update in einen Test-Kanal statt eines neuen Binaries.

Vor dem Verteilen: Signing

Jedes Test-Build muss signiert sein.

• iOS Test-Builds nutzen entweder ein App Store Connect Profil (TestFlight) oder ein Ad Hoc Profile (Direktinstallation). Beide nutzen ein Apple Distribution-Zertifikat. Siehe iOS-Zertifikate und Provisioning Profiles erklärt.
• Android Builds für Play-Tracks sind AABs, die mit deinem Upload-Key signiert sind. Für die Direktinstallation brauchst du ein APK, das mit einem beliebigen Release-Key signiert ist. Ein Debug-APK lässt sich zwar auch installieren, verhält sich aber anders (debuggbar, andere Signatur) und kann später nicht durch deinen Play-Build aktualisiert werden.

iOS: TestFlight

Einen Build hochladen

In Xcode: Produkte > Archiv, dann App verteilen > App Store Connect > Upload. Über die Kommandozeile oder CI ein .ipa und lade mit einem App Store Connect API Key hoch, oder lass das einen Cloud-Build-Service übernehmen.

Seit April 2026 müssen Uploads mit Xcode 26 oder neuer gebaut werden.

Füge diesen Key hinzu: ios/App/App/Info.plist wenn deine App nur die Standard-HTTPS-Verschlüsselung nutzt, stellt App Store Connect die Frage zur Exportkonformität nicht bei jedem Build:

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

Die Verarbeitung dauert wenige Minuten bis etwa eine Stunde. Du bekommst eine E-Mail, sobald der Build bereit ist.

Internes Testen

1. Öffne deine App in App Store Connect, TestFlight > Internes Testen, und erstelle eine Gruppe.
2. Füge Teammitglieder hinzu. Sie brauchen eine App Store Connect-Rolle (Admin, App Manager, Developer, Marketing…). Bis zu 100 Personen.
3. Aktivieren automatische Distribution damit jeder neue Build in die Gruppe geht.
4. Tester installieren die TestFlight App aus dem App Store und akzeptieren die Einladung.

Keine Prüfung erforderlich. Das ist der schnellste Weg vom Upload zum Handy.

Externes Testen

1. TestFlight > Externes Testen > + um eine Gruppe zu erstellen.
2. Tester per E-Mail hinzufügen oder einen öffentlichen Link mit optionalem Tester-Limit.
3. Füge den Build zur Gruppe hinzu und gib ein Testinformationen (was getestet werden soll, Feedback-E-Mail, Beta-App-Beschreibung und ggf. Demo-Login).
4. Einreichen zur Beta-App-Review. Der erste Build jeder Version wird geprüft, meist innerhalb eines Tages. Spätere Builds derselben Version gehen oft ohne vollständigen Review durch.

Externes Testing unterstützt bis zu 10.000 Tester. Tester können Screenshots mit Feedback direkt über TestFlight senden, die du in App Store Connect siehst.

TestFlight-Limits im Überblick

• Builds laufen nach 90 Tagen ab.
• Tester benötigen iOS-Versionen, die dein Build unterstützt (Capacitor 8 benötigt iOS 15 oder neuer).
• TestFlight-Builds nutzen die Production-Signierung des App Stores, daher verwenden Push-Benachrichtigungen die Produktion APNs-Umgebung.
• In-App-Käufe in TestFlight nutzen die Sandbox und verursachen keine Kosten.

iOS: Ad-hoc-Verteilung

Ad-hoc-Builds lassen sich direkt auf Geräten installieren, die im Apple Developer Portal registriert sind – ohne TestFlight oder Apple-Review.

1. Sammle die UDID jedes Testers. Tester können sie auf ihrem eigenen Smartphone mit dem iOS UDID Finderermitteln, oder du liest sie über Finder oder Xcode aus, wenn das Gerät angeschlossen ist.
2. Registriere die Geräte unter Zertifikate, Identifikatoren & Profile > Geräte.
3. Erstelle ein Ad Hoc Provisioning-Profil, das diese Geräte enthält, und lade es herunter.
4. Erstelle eine .ipa mit diesem Profil (Xcode: App verteilen > Release-Tests, der neuere Name für Ad Hoc).
5. Installieren:
   • Ziehe die .ipa im Finder auf das Gerät oder in Xcode > Fenster > Geräte und Simulatoren.
   • Oder hoste es mit einem itms-services Manifest über HTTPS, damit Tester auf einen Link tippen können. Dienste wie Firebase App Distribution erledigen das für dich.
6. Ab iOS 16 erfordert die Installation der .ipa von einem Mac (Xcode oder Apple Configurator) Entwicklermodus auf dem Gerät (Einstellungen > Datenschutz & Sicherheit). Installationen über einen itms-services Link benötigen ihn nicht. Siehe wie Sie den Entwicklermodus unter iOS aktivieren.

Ein neuer Tester bedeutet, die UDID zu registrieren, das Profil neu zu generieren und einen neuen Build zu erstellen. Device-Slots (100 pro Gerätefamilie) werden erst beim Erneuern des Mitgliedsjahres zurückgesetzt; registrieren Sie Geräte daher nicht einfach so.

Android: Google Play Test-Tracks

Die Play Console bietet drei Test-Tracks plus Produktion. Alle benötigen ein AAB, das mit Ihrem Upload-Key signiert ist.

Internes Testen

1. Testen > Interner Test > Tester: Erstellen Sie eine E-Mail-Liste (bis zu 100 Adressen).
2. Neues Release erstellen, das AAB hochladen, Release Notes hinzufügen, speichern und ausrollen.
3. Kopiere den Opt-in-Link und senden es an Tester. Diese können es dann im Play Store akzeptieren und installieren.

Interne Releases sind meist innerhalb weniger Minuten verfügbar und müssen nicht den vollständigen Review-Prozess durchlaufen. Die erste Veröffentlichung einer ganz neuen App kann länger dauern, während Google die App verarbeitet.

Geschlossener Test

Closed Tracks werden geprüft und unterstützen E-Mail-Verteiler oder Google Groups. Dies ist der Track, den du für die 12 Tester für 14 Tage Regel, die für persönliche Developer-Accounts gilt, die nach dem 13. November 2023 erstellt wurden, bevor der Produktionszugriff gewährt wird, brauchst. Mit einer Google Group können Tester ganz einfach beitreten. Details findest du unter so erstellst du Apple- und Google-Play-Developer-Accounts.

Offener Test

Jeder kann über deinen Play-Store-Eintrag beitreten. Nutze ihn für eine öffentliche Beta, sobald dein Store-Listing fertig ist. Feedback von Open-Testern ist privat und beeinflusst deine öffentliche Bewertung nicht.

Unser Android-Beta-Testing-Guide vergleicht die Tracks genauer.

Android: Internes App-Sharing

Internal App Sharing ist der schnellste Weg, um jede APK oder AAB über den Play Store auf ein Gerät zu bringen – ohne Versions-code-Regeln und ohne Review.

1. Öffne in der Play Console Internal App Sharing (unter Testing) und füge Uploader hinzu.
2. Lade eine APK oder AAB hoch. Du erhältst einen Link.
3. Tester öffnen die Play Store App, gehen zu den Einstellungen und tippen auf die Play Store Version siebenmal, um die Entwickleroptionen freizuschalten, und aktivieren die Option. Internal App Sharing.
4. Tester öffnen den Link und installieren.

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

Android: Direkte APK & Firebase App Distribution

Direkte APK

Erstelle ein signiertes Release-APK. Ein neues Capacitor-Projekt hat keine release Signing-Config, daher assembleRelease würde ein unsigniertes APK erstellt, das sich nicht installieren lässt. Füge einen signingConfigs.release Block (Keystore-Pfad und Passwörter, meist aus key.properties) hinzu android/app/build.gradle und verweise buildTypes.release.signingConfig zuerst darauf.

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

Teilen android/app/build/outputs/apk/release/app-release.apk über einen Link. Tester erlauben ihrem Browser oder Dateimanager, unbekannte Apps zu installieren, und öffnen die Datei. Wenn bereits eine Play-Store-Version installiert ist, müssen sie diese zuerst deinstallieren, da die Signaturen unterschiedlich sind. Du kannst auch per USB installieren mit adb install -r app-release.apk (siehe so aktivierst du die Entwickleroptionen auf Android).

Ab dem 30. September 2026 installieren zertifizierte Android-Geräte in Brasilien, Indonesien, Singapur und Thailand nur noch Apps, deren Paketname von einem verifizierten Entwickler registriert ist; der weltweite Rollout ist für 2027 geplant. Wenn deine Tester in diesen Ländern sind, registriere den Paketnamen in der Android Developer Console oder Play Console. Installationen über adb sind nicht betroffen.

Firebase App Distribution

Firebase App Distribution funktioniert auf beiden Plattformen, sendet E-Mail-Einladungen und trackt, wer welchen Build 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 weiterhin in einem Ad-hoc- (oder Entwicklungs-)Profil sein. App Distribution sammelt ihre UDIDs, wenn sie die Einladung annehmen, aber du registrierst sie und baust selbst neu.
• Die AAB-Verteilung erfordert die Verknüpfung des Firebase-Projekts mit Google Play.

Cloud-Builds mit Link für Tester

Wenn Sie nicht auf jedem CI-Runner Macs und Signing pflegen möchten, Capgo Build erstellt Capacitor Apps in der Cloud. Für Test-Builds kann es die Store-Submission überspringen und die Binary über einen zeitlich begrenzten Download-Link mit einem QR 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"

Füge --output-record build.json und den Link in der CI mit bunx @capgo/cli@latest build last-output --path build.json --field outputUrl auslesen, um ihn in einem Pull Request oder Chat zu posten. Die Capgo Build-Dokumentation listet jede Option auf.

Kein Rebuild bei Web-Änderungen

Die meisten Änderungen in einer Capacitor App liegen im Web-Layer. Das Rebuilden und Neuverteilen einer Binary für einen Textfix kostet einen Tag TestFlight-Processing und Review. Mit Capgo Live Updatesbehalten Tester den Build, den sie installiert haben, und du pushst neue JavaScript-Bundles in einen Test-Channel:

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

Du kannst sogar jedem Pull Request einen eigenen Channel geben, sodass QA zwischen ihnen in derselben installierten App wechseln kann. Siehe Mache jeden Pull Request zu einer installierbaren Preview.

Fehlerbehebung

„Unable to install“ bei iOS ad hoc. Die Geräte-UDID ist nicht im Profil enthalten oder das Profil ist abgelaufen. Prüfe mit security cms -D -i profile.mobileprovision.

App öffnet sich unter iOS und schließt sofort wieder. Developer Mode ist aus (ad hoc/Development Builds) oder das Profil ist abgelaufen.

TestFlight Build hängt bei „Processing“. Warte bis zu einer Stunde. Wenn es fehlschlägt, nennt die E-Mail den Grund, oft ein fehlender Usage-Description-String (NSCameraUsageDescription und Ähnliches) oder ein Icon-Problem.

TestFlight „Missing Compliance“. Beantworte die Export-Compliance-Frage in App Store Connect oder füge ITSAppUsesNonExemptEncryption zu Info.plist.

Android „App nicht installiert“. Eine Version mit anderer Signatur ist bereits installiert, oder die APK ist unsigniert bzw. beschädigt. Deinstalliere die bestehende App.

Tester sieht die App nach dem Opt-in nicht im Play Store. Warte ein paar Minuten, stelle sicher, dass sie mit dem eingeladenen Account angemeldet sind, und prüfe, ob das Release für den Track ausgerollt und in ihrem Land verfügbar ist.

„Version code bereits verwendet“ beim Upload. Erhöhen versionCode in einem android/app/build.gradle. Internal App Sharing ist die Ausnahme.

Push-Benachrichtigungen kommen in TestFlight nicht an. TestFlight nutzt die Produktions-APNs-Umgebung. Prüfe das aps-environment Entitlement und die Umgebungseinstellung deines Push-Providers.

Empfohlenes Setup für kleine Teams

1. Interne TestFlight-Gruppe mit automatischer Verteilung sowie ein interner Play-Testtrack für jeden Merge in main.
2. Eine TestFlight-externe Gruppe und ein Play Closed Testing Track für Beta-Nutzer, wöchentlich aktualisiert.
3. Live Updates auf einem beta Channel für Web-only-Fixes zwischen Builds.
4. Sobald die Beta stabil ist, denselben Build in beiden Stores in die Produktion bringen und den Guide für die erste App-Review.