Von Hand
- Ein Rechner, ein Konto, Metadaten irgendwo.
App-Store-Release ohne den Mac unter dem Schreibtisch
Der Build ist der kleine Teil. Signing, Metadaten, Screenshots, Versionsnummern, zwei oder drei Stores – das ist der Nachmittag. Der soll in derselben Pipeline sitzen wie der Rest.
- App Store, Play Store, Microsoft Store aus dem Projekt, nicht aus einer Tabelle
- iOS-Build auf macOS in der Cloud. Der Büro-Mac darf sterben.
Portal oder Pipeline
Mit dem Commit
- Signing und Upload laufen, wenn die Pipeline grün ist.
-
App StoreApple-Releases mit vorbereiteten Metadaten und Assets.
-
Google PlayPlay-Store-Einträge automatisiert bespielt.
Powered by Fastlane
Ein Store-Release scheitert selten am Compile. Es scheitert an Zertifikaten, Screenshots und an der Person, die gerade im Urlaub ist. Automatisieren heißt, diese Teile in die Pipeline zu legen, die das Repo ohnehin baut.
Store-Releases von Hand oder über die Plattform
Die Gegenüberstellung zeigt, welche Arbeitsschritte bei einem manuell aufgesetzten Mobile-Release anfallen und was die Application Platform davon übernimmt.
| Aufgabe |
Mit der Application Platform
|
Manuell aufgesetzt
|
|---|---|---|
| Build für iOS und Android erzeugen | Vollständig abgedeckt: Pipeline baut Flutter-, Expo- und native Projekte nach denselben Regeln | Nicht angeboten: Lokale Builds auf wechselnden Rechnern, Ergebnisse schwer reproduzierbar |
| macOS-Umgebung für iOS | Vollständig abgedeckt: macOS-Geräte in der Cloud sind Teil der Build-Infrastruktur | Teilweise abgedeckt: Eigener Mac oder gemieteter Runner, Wartung und Xcode-Updates inklusive |
| Signing verwalten | Vollständig abgedeckt: Android Keystore, Apple Credentials und Azure Artifact Signing werden in der Plattform verwahrt | Nicht angeboten: Zertifikate und Keystores liegen bei einzelnen Personen, Verlust ist ein echtes Risiko |
| Store-Metadaten pflegen | Vollständig abgedeckt: Editor mit Sektionsnavigation sowie Sprach- und Plattform-Badges im Projekt | Nicht angeboten: Texte in zwei bis drei Portalen doppelt pflegen |
| Screenshots vorbereiten | Vollständig abgedeckt: Screenshots werden hochgeladen und im Editor auf die geforderten Formate zugeschnitten | Nicht angeboten: Zuschnitt in einem Grafikprogramm, Formate pro Store und Gerät nachschlagen |
| Changelog pro Sprache | Vollständig abgedeckt: Release Notes je Sprache im Projekt hinterlegt und versioniert | Nicht angeboten: Kopieren und Einfügen in Store-Formulare, Versionsstände laufen auseinander |
| Google-Datensicherheit ausfüllen | Vollständig abgedeckt: Die Angaben zur Datensicherheit gehören zum Metadaten-Editor | Nicht angeboten: Formular im Play-Console-Portal manuell pflegen |
| Versionierung und Build-Nummern | Vollständig abgedeckt: Versionierung ist Teil der Pipeline und folgt dem Repository-Stand | Nicht angeboten: Manuell hochzählen, abgelehnte Uploads wegen doppelter Build-Nummer |
| Einreichung und Review | Vollständig abgedeckt: Releases werden aus der Plattform angestoßen, Status ist pro Repository sichtbar | Teilweise abgedeckt: Getrennte Portale, unterschiedliche Zustände, Nachverfolgung per Notiz |
| Microsoft Store parallel bedienen | Vollständig abgedeckt: Als dritter Store aus demselben Projekt bespielbar | Nicht angeboten: Eigener Prozess, meist manuell und selten dokumentiert |
Grün bedeutet vollständig abgedeckt, gelb teilweise, grau nicht vorgesehen. Die Prüfzeiten der Stores selbst bleiben unverändert, automatisiert wird alles davor.
Stand: 9. September 2026. Die Gegenüberstellung beschreibt typische Abläufe und kann je nach Projekt abweichen. Logos sind Marken der jeweiligen Rechteinhaber und dienen nur der Zuordnung.
Grenzen
- Review bleibt Review Apple und Google prüfen weiter selbst. Automatisierung ersetzt nicht die Freigabe, nur das Zusammensuchen der Artefakte.
Kostenmodell
Store-Konten zahlst du bei Apple und Google. Die Plattform übernimmt die Kette, nicht die Store-Gebühren.
Pipeline für Kunden-App
test
build
publish
release
So kommt eine App in die Stores
Vom Projektstart bis zur Einreichung in vier Schritten.
-
Projekt mit Mobile-Template anlegen
Wähle Flutter, Expo oder ein natives iOS- beziehungsweise Android-Projekt. Repository, Struktur und Pipeline entstehen mit.
-
Store-Zugänge hinterlegen
Apple Credentials, Play-Zugang, Android Keystore und bei Bedarf Azure Artifact Signing werden in der Plattform gespeichert.
-
Store-Eintrag pflegen
Titel, Beschreibungen, Keywords, Screenshots, Changelog je Sprache und die Angaben zur Google-Datensicherheit pflegst du im Editor.
-
Release auslösen
Die Pipeline baut, signiert und lädt hoch. Den Stand siehst du pro Repository, die Prüfung übernimmt anschließend der jeweilige Store.
Häufige Fragen
Welche Stores werden unterstützt?
Apple App Store, Google Play Store und Microsoft Store, alle drei aus demselben Projekt. Die Metadaten pflegst du an einer Stelle, mit Badges für Sprache und Plattform. Die eigentliche Prüfung liegt weiterhin beim jeweiligen Anbieter.
Brauche ich einen eigenen Mac für iOS-Builds?
Nein. Die Plattform stellt macOS-Geräte in der Cloud bereit, auf denen iOS-Builds und die Signierung in der Pipeline laufen. Eigene macOS-Workspaces zum interaktiven Arbeiten folgen; unter Workspaces wählst du aktuell Ubuntu.
Wie werden Zertifikate und Keystores verwahrt?
Zentral in der Plattform: Android Keystore, Apple Credentials und Azure Artifact Signing. Der Vorteil ist die Ausfallsicherheit, denn ein Keystore auf dem Laptop einer Person ist ein bekanntes Risiko. Zugriff regeln Rollen und Projektzugehörigkeit.
Kann ich die Pipeline anpassen?
Ja. Die Plattform arbeitet mit GitLab CI, die Konfiguration liegt lesbar in deinem Repository. Du kannst Stufen ergänzen, Bedingungen ändern oder eigene Skripte einbinden. Die vorbereitete Konfiguration ist ein Startpunkt, keine Blackbox.
Werden die Apps dadurch schneller geprüft?
Nein, die Prüfzeiten von Apple, Google und Microsoft bleiben unverändert. Automatisiert wird alles davor: Build, Signierung, Metadaten, Screenshots, Changelogs und Upload. Das verkürzt die Zeit bis zur Einreichung und reduziert Ablehnungen.
Bring dein nächstes Release ohne Handarbeit raus
Registriere dich kostenlos, lege ein Mobile-Projekt an und sieh dir an, wie weit die Pipeline bis zum Store-Eintrag kommt.