Die Plattform baut und signiert Release-Builds für iOS und Android, lädt sie zu Apple und Google hoch und pflegt die Store-Texte mit. Das iOS-Code-Signing verwaltet sie über ein verschlüsseltes Repository deiner Organisation.
Was du einmalig bereitstellst
Für Apple brauchst du eine Mitgliedschaft im Apple Developer Program und einen API-Schlüssel aus App Store Connect, für Google ein Konto in der Google Play Console und einen Service Account mit JSON-Schlüssel. Beide hinterlegst du unter Store-Accounts.
In der App wählst du den Store-Account und die Kennung, die du in den Konsolen von Apple und Google angelegt hast: den Bundle Identifier bzw. den Paketnamen.
Für eine bereits im Play Store veröffentlichte Android-App importierst du einmalig den ursprünglichen Upload-Key.
Texte und Screenshots liegen als Store-Metadaten im App-Repository.
Was bei jedem Merge auf main passiert
Mit verknüpftem Store-Account baut die Pipeline nach jedem Push auf main Release-Builds und vergibt die neue Versionsnummer. publish-ios lädt den iOS-Build zu TestFlight hoch und aktualisiert die Store-Metadaten in App Store Connect, ohne die App zur Prüfung einzureichen. publish-android veröffentlicht den Android-Build im Internal Track der Play Console. Zusätzlich verteilt die Pipeline beide Builds über Firebase App Distribution an Tester. Den allgemeinen Ablauf beschreibt Git-Workflow und Deployment.
Freigabe in den Store
Für den Store startest du in GitLab unter CI/CD → Pipelines einen manuellen Job: release-ios reicht die App bei Apple zur Prüfung ein und veröffentlicht sie danach automatisch, release-android befördert den Build in den Production Track. Wie du manuelle Jobs startest, steht unter Was sind Pipelines?.
Was Apple und Google bei der Prüfung erwarten, steht unter Hinweise zur App-Store-Prüfung.