Lösung

App Store Deployment automatisieren statt Releases von Hand zu klicken

Ein mobiles Release ist selten nur ein Build. Signieren, Metadaten, Screenshots, Changelogs, Versionsnummern und die Einreichung in zwei oder drei Portalen kosten bei jedem Update erneut Zeit.

Apple App Store, Google Play Store und Microsoft Store aus demselben Projekt
Signing-Material und Store-Zugangsdaten zentral verwaltet
macOS-Geräte in der Cloud für iOS-Builds, kein Rechner unter dem Schreibtisch

Kostenlos registrieren Funktionen ansehen

Kostenlos starten. Keine Kreditkarte nötig.

Kurz gesagt

Die Plattform automatisiert die Schritte zwischen fertigem Code und eingereichtem Release.

Ein Projekt, drei Stores: Apple App Store, Google Play Store und Microsoft Store aus einer Projektbasis.
Signing ist geregelt: Keystore, Apple Credentials und Azure Artifact Signing liegen in der Plattform.

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 vorgesehen: 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 vorgesehen: 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 vorgesehen: 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 vorgesehen: 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 vorgesehen: Copy-and-paste in Store-Formulare, Versionsstände laufen auseinander
Google-Datensicherheit ausfüllen	Vollständig abgedeckt: Die Angaben zur Datensicherheit gehören zum Metadaten-Editor	Nicht vorgesehen: 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 vorgesehen: 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 vorgesehen: 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: 10. August 2026. Die Gegenüberstellung beschreibt typische Abläufe und kann je nach Projekt abweichen.

Was du damit gewinnst

Weniger Handarbeit an genau den Stellen, an denen Releases sonst hängen bleiben.

Releases über Fastlane

Upload, Signierung und Store-Kommunikation laufen über Fastlane, eingebettet in die Pipeline deines Projekts.

Signing an einem Ort

Android Keystore, Apple Credentials und Azure Artifact Signing werden zentral verwaltet, statt auf Entwicklerrechnern zu liegen.

Metadaten-Editor

Sektionsnavigation, Sprach- und Plattform-Badges, Screenshots mit Zuschneiden und Changelogs je Sprache in einer Oberfläche.

macOS in der Cloud

Die GitLab-CI-Konfiguration liegt lesbar im Projekt und lässt sich für eigene Release-Regeln anpassen.

Pipeline für Kunden App

test

build

publish

release

Der Store-Release ist der letzte Schritt derselben Pipeline.

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 laufen. Damit entfällt der Rechner im Büro, der gepflegt werden muss. Diese Geräte lassen sich auch als Remote-Workspace nutzen.

Wie werden Zertifikate und Keystores verwahrt?

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.

Kostenlos registrieren Mit uns sprechen