Schritt-für-Schritt-Anleitung für das Deployment im iOS App Store und Google Play Store: Konten, Zertifikate, Review-Prozess und Fastlane-Automatisierung.
Release-Pipeline
Xcode Archive oder Gradle bundleRelease. Fastlane Match übernimmt die Zertifikat- und Keystore-Verwaltung.
TestFlight bei iOS, Closed Testing bei Android. Pre-Launch-Reports über Firebase Test Lab, Überprüfung von Abstürzen und ANRs.
Der App Store benötigt 24-48 Std., Google Play 12-24 Std. Die Datenschutz- und Data-Safety-Formulare müssen exakt zu den verwendeten SDKs passen.
Produktions-Rollout 1 % → 5 % → 20 % → 50 % → 100 %, mit Crashlytics-Überwachung, die bei Absturzspitzen einen Stopp auslöst.
Die Entwicklung einer mobilen App ist fertig — das Deployment wirkt hingegen oft schwieriger, als es tatsächlich ist. Eine Verzögerung von 2-3 Wochen beim App Store- / Play Store-Review ist typisch, lässt sich mit der richtigen Vorbereitung aber vermeiden. Dieser Leitfaden führt Sie durch den gesamten Ablauf aus der Perspektive neuer Entwickler: Account-Setup, Zertifikatsverwaltung, Build-Konfiguration, Metadaten-Upload, Review-Prozess und die Fastlane-basierte Automatisierung.
Der Leitfaden spiegelt den Stand von Q1 2026 wider. Die Richtlinien von Apple und Google ändern sich schnell — es lohnt sich, auch die offizielle Dokumentation zu konsultieren, insbesondere zu Datenschutzerklärungen und dem Target API Level.
Bevor Sie starten, müssen einige Dinge geklärt sein. Diese werden oft bis zur letzten Minute aufgeschoben, was zu einer Verzögerung von 1-2 Wochen führt.
Tipp: Die Vorbereitung von Icons und Screenshots ist oft ein 1-2-tägiges Design-Projekt. Planen Sie dafür Zeit außerhalb der eigentlichen Deployment-Woche ein.
Apple Developer Portal → Certificates, Identifiers & Profiles → Identifiers → neue App-ID. Bundle-ID-Konvention: com.firmenname.appname. Reverse-DNS-Notation, Kleinschreibung, Bindestriche erlaubt.
Bundle ID examples:
✓ com.corevanix.partneriapp
✓ hu.cegnev.flotta-mobile
✗ com.corevanix.PartneriApp (Großschreibung nicht erlaubt)
✗ corevanix.app (keine Reverse-DNS-Notation)
Ändern Sie die Bundle-ID niemals nach dem Release — das gilt als neue App, und sämtliche Nutzerdaten gehen verloren.
In der App-ID müssen die verwendeten Capabilities explizit aktiviert werden:
Jede neue Capability erfordert ein eigenes Provisioning Profile — planen Sie das im Voraus ein.
Es werden zwei Zertifikate benötigt:
Provisioning Profile für das Distribution-Zertifikat. Xcode kann das alles automatisch verwalten (Automatically manage signing), in der Produktion ist eine manuelle Verwaltung jedoch besser — in der CI/CD-Umgebung bricht das automatische Signing häufig ab.
# Lokaler Cert-Export aus dem iCloud Keychain
security find-identity -p codesigning -v
# Listet die gespeicherten Zertifikate auf
Xcode → Product → Scheme → Edit Scheme → Run → Build Configuration: Release. Zusätzlich:
Ziel: Das Archive erscheint im Window → Organizer sauber und ohne Warnungen.
App Store Connect → My Apps → neue App:
Dies ist der zeitaufwendige Teil. Jedes Feld ist verpflichtend:
Die App-Privacy-Erklärung ist seit 2020 verpflichtend. Die Kategorien „Data Used to Track You", „Data Linked to You" und „Data Not Linked to You" müssen exakt angegeben werden.
Xcode → Product → Archive → Distribute App → App Store Connect → Upload.
Typische Build-Verarbeitungszeit: 15-60 Minuten. In Extremfällen, vor allem an Release-Tagen, kann es auch 4-6 Stunden dauern.
# Mit Fastlane:
fastlane ios beta
Nach der Build-Verarbeitung können Warnungen auftauchen (Missing Marketing Icon, ITSAppUsesNonExemptEncryption usw.). Diese sehen Sie unter App Store Connect → TestFlight-Tab.
App Store Connect → Version → Build auswählen → Submit for Review.
Checkliste vor der Einreichung:
Typische Review-Dauer: 24-48 Stunden (vor 2025 waren es 3-7 Tage — deutlich beschleunigt). Mögliche Ergebnisse:
Die ersten 24-48 Stunden sind kritisch:
| Ablehnungsgrund | Lösung |
|---|---|
| Absturz beim Start | Auf allen iOS-Versionen testen (min. Target → neueste Version) |
| Privacy-Policy-URL fehlerhaft | Manuell prüfen, auf Ungarisch und Englisch |
| Login verpflichtend, ohne Erklärung | Gast-Modus anbieten oder den Mehrwert erläutern |
| In-App-Purchase nicht relevant, aber Stripe-Flow vorhanden | Apple erlaubt für digitale Leistungen nur IAP |
| Medizinische/finanzielle Aussage ohne Disclaimer | Entsprechenden Disclaimer ergänzen |
| Zu wenig eigenständiger Inhalt (Klon) | Die App muss einen eigenen Mehrwert bieten |
| Unangemessene Inhalte | Content-Policy-Review |
| Fehlende erforderliche Funktionalität | Die App darf kein Platzhalter sein |
Hinweis: Bei einer Ablehnung müssen Sie den Ablauf nicht bei Schritt 0 neu beginnen. Über das Resolution Center können Sie mit dem Reviewer kommunizieren — oft klärt sich die Sache nach 1-2 Antworten.
Konvention: com.firmenname.appname. Die Application-ID ist in der build.gradle festgelegt — ändern Sie sie nach dem Launch niemals.
// app/build.gradle.kts
android {
namespace = "com.corevanix.partneriapp"
defaultConfig {
applicationId = "com.corevanix.partneriapp"
versionCode = 1
versionName = "1.0.0"
minSdk = 26
targetSdk = 35 // 2026: Android 15
}
}
keytool -genkey -v -keystore release.keystore \
-alias upload -keyalg RSA -keysize 2048 -validity 10000 \
-storepass <password> -keypass <password> \
-dname "CN=Corevanix Kft., O=Corevanix, C=HU"
Wenn Sie die Keystore-Datei und das Passwort verlieren, verlieren Sie die App (mit einem neuen Keystore lässt sich nicht mehr publizieren, nur mit einer komplett neuen App). Bewahren Sie beides an einem sicheren Ort auf (1Password, Bitwarden, HashiCorp Vault).
Seit der Umstellung 2021 generiert und verwaltet Google Play selbst einen Signing-Key. Ihr mit dem „Upload-Key" signiertes AAB wird von Google mit dessen eigenem Produktions-Key neu signiert.
Vorteil: Verlieren Sie Ihren Upload-Keystore, kann Google einen neuen Upload-Key generieren — die App geht NICHT verloren.
Play Console → App Signing → Use Google Play App Signing
→ Upload your upload key certificate (or generate new)
Play Console → All apps → Create app:
cd android
./gradlew bundleRelease
Das AAB liegt unter app/build/outputs/bundle/release/app-release.aab. Es ist die moderne Alternative zur APK (kleiner, Google zerlegt es dynamisch in plattformspezifische APKs).
# Bei RN mit Fastlane:
fastlane android beta
Stellen Sie den Release immer zuerst in den Internal Testing Track. Unbegrenzte, kostenlose erneute Einreichungen; innerhalb von 1-2 Stunden auf Beta-Niveau verfügbar.
Play Console → Internal testing → Create release → Upload AAB.
Google führt den Build automatisch in der Firebase Test Lab aus (~30 virtuelle Geräte). Abstürze, ANRs und Sicherheitsprobleme werden markiert.
Der Pre-Launch-Report ist nach 2-6 Stunden fertig. Ergebnisse:
Nach Internal Testing folgt ein Test mit 50-1000 Beta-Nutzern im Closed Testing. Nach positivem Feedback geht es in den Production Track.
Vorteil des Closed Testing: echtes Nutzerfeedback noch vor der Production-Einreichung. Ein Zyklus von 2-4 Wochen ist typischerweise sinnvoll.
Phased Rollout: 1 % → 5 % → 20 % → 50 % → 100 %. Absturz-Analytics-Monitoring auf jeder Stufe. Bei einem Absturzspitzenwert → Rollout stoppen.
Day 1: 1% rollout
Day 2: 5% rollout
Day 4: 20% rollout
Day 7: 50% rollout
Day 14: 100% rollout
Google-Play-Review: 1-3 Tage bei der ersten Einreichung, später 12-24 Stunden. Häufige Probleme:
| Problem | Lösung |
|---|---|
| Zu weitreichende Berechtigungen | Nur tatsächlich genutzte Berechtigungen anfordern |
| Privacy-Policy / Data-Safety-Formular ungenau | Data-Safety-Bereich aktualisieren |
| Datendeklaration unvollständig | Jeden erhobenen Datentyp deklarieren |
| Target API Level zu alt (2026: min. 35) | minSdk und targetSdk aktualisieren |
| Verstoß gegen App-Content-Policy | Google-Play-Richtlinien prüfen |
| Spam- / Klon-App | Die App muss einen eigenständigen Mehrwert bieten |
| Eingeschränkte Inhalte (z. B. Arzneimittel) | Spezielle Freigabe / Disclaimer erforderlich |
Tipp: Das Data-Safety-Formular ist seit 2024 strenger. Die Datenerhebung jedes Drittanbieter-SDKs (Firebase, Mixpanel, OneSignal) muss deklariert werden. Vergessen Sie auch Sentry nicht — auch dieses erhebt Daten.
In einem Projekt führen Sie Builds für zwei Stores gleichzeitig aus. Zur Versions-Synchronisierung:
// package.json (RN-Beispiel)
{
"version": "1.4.2"
}
// Die Build-Skripte verwenden dies für beide Plattformen
// iOS: CFBundleShortVersionString
// Android: versionName
Auch die Build-Nummer sollte synchron gehalten werden — das erleichtert das Debugging, wenn ein Bug-Report eingeht.
Weichen die Features auf den beiden Plattformen voneinander ab (z. B. Live Activity nur auf iOS), sind zwei Dinge wichtig:
Ein Notion- oder Linear-Dokument mit allen Store-Metadaten: Beschreibung, Screenshot-Links, Versionshistorie. Das Onboarding eines neuen Teammitglieds dauert damit 30 Minuten.
Das manuelle Deployment ist ein 2-3-stündiger Ablauf pro Release. Mit Fastlane sind es 5-10 Minuten.
# Auf iOS-Seite
cd ios
fastlane init
# Auf Android-Seite
cd android
fastlane init
# fastlane/Fastfile
default_platform(:ios)
platform :ios do
desc "Push a new beta build to TestFlight"
lane :beta do
increment_build_number(xcodeproj: "MyApp.xcodeproj")
build_app(
scheme: "MyApp",
export_method: "app-store",
output_directory: "./build",
)
upload_to_testflight(
skip_waiting_for_build_processing: true,
changelog: changelog_from_commits,
)
slack(
message: "iOS beta build #{lane_context[SharedValues::BUILD_NUMBER]} uploaded",
)
end
desc "Submit for App Store review"
lane :release do
capture_screenshots
build_app(scheme: "MyApp")
upload_to_app_store(
submit_for_review: true,
automatic_release: false,
)
end
end
platform :android do
desc "Push a new build to Internal Testing"
lane :beta do
gradle(task: "bundleRelease")
upload_to_play_store(
track: "internal",
aab: "app/build/outputs/bundle/release/app-release.aab",
)
end
desc "Production release"
lane :release do
gradle(task: "bundleRelease")
upload_to_play_store(
track: "production",
rollout: "0.05", # 5% phased rollout
)
end
end
# .github/workflows/mobile-beta.yml
name: Mobile Beta
on:
push:
branches: [main]
jobs:
ios-beta:
runs-on: macos-latest
steps:
- uses: actions/checkout@v4
- uses: ruby/setup-ruby@v1
with:
ruby-version: 3.2
bundler-cache: true
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci
- run: bundle exec fastlane ios beta
env:
APPLE_ID: ${{ secrets.APPLE_ID }}
APP_STORE_CONNECT_API_KEY: ${{ secrets.APP_STORE_CONNECT_API_KEY }}
MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
android-beta:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v4
with:
distribution: temurin
java-version: 17
- uses: ruby/setup-ruby@v1
with:
ruby-version: 3.2
bundler-cache: true
- run: npm ci
- run: bundle exec fastlane android beta
env:
PLAY_STORE_JSON_KEY: ${{ secrets.PLAY_STORE_JSON_KEY }}
Mit Fastlane Match wird die Zertifikatsverwaltung deutlich einfacher:
# Matchfile
git_url("git@github.com:corevanix/mobile-certificates.git")
storage_mode("git")
type("appstore")
app_identifier(["com.corevanix.partneriapp"])
username("info@corevanix.com")
Der Befehl match appstore lädt die Zertifikate herunter und installiert sie. In der CI läuft das automatisch, lokal dauert es 30 Sekunden.
Die beiden Beta-Kanäle eignen sich für unterschiedliche Anwendungsfälle:
| Aspekt | TestFlight (iOS) | Closed Testing (Android) |
|---|---|---|
| Max. Nutzer | 10.000 | Unbegrenzt (pro Gruppe) |
| Beta-Zeitraum | 90 Tage | Unbegrenzt |
| Crash-Reports | Ja | Ja (Crashlytics) |
| Beta-Feedback | In-App + E-Mail | E-Mail + Play Console |
| Review erforderlich | Intern: nein; Extern: ja (24 Std.) | Nein |
| Distribution | E-Mail-Einladung oder öffentlicher Link | E-Mail-Einladung oder öffentlicher Link |
| Setup-Zeit | 1 Tag | 2-4 Stunden |
Eine „echte Beta-Phase" dauert 2-4 Wochen. 50-100 Nutzer reichen aus, um größere Bugs zu erkennen, ohne dass das Feedback-Management unüberschaubar wird.
Day 1-2: 5% rollout — Crash-Rate beobachten
Day 3-5: 20% rollout — bei < 0,5% Crashes fortsetzen
Day 6-10: 50% rollout — weiterhin beobachten
Day 11-14: 100% rollout
Der Ablauf aus Stopp und Hotfix dauert 1-2 Tage. Es ist besser zu stoppen, als bis zu 100 % weiter auszurollen.
Auf iOS ist ein Rollback schwierig: Die App kann nicht auf eine „ältere" Version zurückgesetzt werden. Die Lösung: Sie reichen einen neuen Release mit dem alten Build ein (inkrementelle Version).
Auf Android hilft der Button „Halt rollout" in der Play Console, aber bei bereits installierenden Nutzern gibt es kein automatisches Rollback.
Die defensive Strategie: Feature Flags. Das neue Feature ist standardmäßig deaktiviert und lässt sich serverseitig umschalten.
Der Debug-Build ist langsamer, größer und enthält oft nur für die Entwicklung bestimmte Zugangsdaten. Verwenden Sie immer die Release-Konfiguration.
Das ist der häufigste Grund für eine automatische Ablehnung. Die Privacy-Policy-URL muss live erreichbar sein, auf Ungarisch und Englisch (bei mehrsprachigen Apps).
„Best", „top", „guaranteed" — diese können gegen die Marketing-Richtlinien verstoßen. Verwenden Sie sie nur, wenn sie tatsächlich nachweisbar sind.
Der Reviewer schaut sich die Screenshots an, und enthalten sie Platzhaltertext („Lorem ipsum"), führt das automatisch zur Ablehnung.
Werden Tracking-Daten erhoben (Firebase, Google Analytics, Facebook SDK), ist der App-Tracking-Transparency-Prompt verpflichtend. Eine Datenschutzverletzung ist einer der häufigsten Gründe für eine automatische Ablehnung.
Verwandte Artikel von uns: React Native vs. Native 2026 — Plattformwahl. Push-Benachrichtigungen richtig implementieren — Planung des Push-Flows. DSGVO-Konformität für mobile Apps — Datenschutz-Grundlagen vor dem Deployment.
Mobiles Deployment ist 2026 schneller als je zuvor — doch die Einrichtung bleibt anspruchsvoll. Planen Sie für die erste Store-Einreichung 2-4 Wochen ein (Zertifikate, Metadaten, Screenshots, erste Review).
Die Einrichtung einer automatischen Pipeline (Fastlane + GitHub Actions) bedeutet 1-2 Tage Entwicklungsaufwand, danach dauert jeder Release nur noch 5-10 Minuten. Es lohnt sich.
Nach dem ersten Release wird jeder weitere Release einfacher. Beim 3. Release läuft es bereits routiniert, beim 10. Release praktisch automatisch. Die Investition steckt in der ersten Einrichtung — danach verschwindet die Deployment-Reibung so gut wie vollständig.
Wenn Sie ein mobiles App-Projekt planen, besprechen wir gemeinsam die Deployment- und Store-Strategie — die Übernahme des Release-Prozesses ist Teil unseres Build-Pakets. Beim ersten Release prüft unser Partner-Entwickler persönlich jeden Schritt, damit die Übergabe reibungslos verläuft.
Über den Autor
Corevanix Kft.
Technologiepartner
Technologiepartner aus Budapest — SAP/ERP-Integration, Webentwicklung, KI-Automatisierung und Mobile-App-Entwicklung. Wir arbeiten in der eigenen Umgebung des Kunden, und der ausgelieferte Code gehört vollständig dem Kunden.
Performance-Benchmarks, Developer Experience, Ecosystem und 5 Use-Case-Empfehlungen. Entscheiden Sie sich fundiert zwischen React Native und Native.
Push-Benachrichtigungen zählen zu den stärksten Retention-Tools – oder zu den häufigsten Gründen für eine Deinstallation. 10 Fehler, richtig umgesetzt mit Code.
DSGVO-Grundlagen für Mobile Apps, Consent-Management, IDFA-/GAID-Handling, Analytics-Tools und eine Audit-Checkliste für 2026, kompakt zusammengefasst.