Technologie

Flutter CI/CD ohne Build-Rechner unter dem Schreibtisch

Eine Flutter-Codebasis für iOS und Android ist schnell aufgesetzt. Bis in die Stores fehlen Build-Maschinen, Signaturen, Zertifikate und ein Releaseprozess. Die Plattform deckt das ab, macOS-Geräte inklusive.

Produktionsreifes Flutter-Template mit Repository und Projektstruktur
Builds für iOS und Android in GitLab CI, mit macOS-Geräten für Apple-Builds
Veröffentlichung in App Store, Play Store und Microsoft Store über Fastlane

Kostenlos registrieren Funktionen ansehen

Kostenlos starten. Keine Kreditkarte nötig.

Kurz gesagt

Mobile CI/CD scheitert selten am Code, sondern an Build-Umgebungen und Signaturen. Genau diese Teile übernimmt die Plattform.

Aus dem Template entstehen Repository, Projektstruktur und eine Pipeline für Test bis Release.
Für iOS-Builds stehen macOS-Geräte bereit, du brauchst keinen eigenen Mac als Build-Rechner.

Flutter CI/CD selbst aufsetzen oder über die Plattform betreiben

Die Gegenüberstellung zeigt, welche Aufgaben ein eigener Mobile-Releaseprozess mit sich bringt und was die Plattform davon abnimmt.

Aufgabe	Mit der Application Platform	Selbst aufgesetzt
Projektstruktur und Repository	Vollständig abgedeckt: Entstehen aus einem produktionsreifen Flutter-Template mit festen Konventionen	Nicht angeboten: Repository anlegen, Struktur und Konventionen im Team festlegen
Build-Pipeline für beide Plattformen	Vollständig abgedeckt: GitLab-CI-Pipeline baut iOS und Android aus derselben Codebasis	Nicht angeboten: Zwei Build-Wege selbst schreiben und getrennt pflegen
macOS-Buildumgebung	Vollständig abgedeckt: macOS-Geräte für iOS-Builds gehören zur Plattform	Nicht angeboten: Eigenen Mac beschaffen, warten und als Runner betreiben
Android-Signing	Vollständig abgedeckt: Keystore und Passwörter werden verwaltet und an die Pipeline übergeben	Teilweise abgedeckt: Keystore-Datei sichern, verteilen und in CI hinterlegen
Apple-Zugangsdaten	Vollständig abgedeckt: Signing-Zugangsdaten werden zentral verwaltet statt lokal gespeichert	Nicht angeboten: Zertifikate und Profile manuell erneuern und im Team verteilen
Store-Metadaten und Screenshots	Vollständig abgedeckt: Werden im Projekt gepflegt und in die Stores übertragen	Nicht angeboten: In zwei Portalen von Hand pflegen, ohne Versionierung
Releases und Versionierung	Vollständig abgedeckt: Versionsstände entstehen in der Pipeline, jedes Release folgt demselben Weg	Teilweise abgedeckt: Versionsnummern von Hand setzen und Builds manuell hochladen
Whitelabel-Varianten	Vollständig abgedeckt: Mehrere Marken aus einer Codebasis, mit eigenem Branding und eigenen Store-Einträgen	Nicht angeboten: Branches oder Kopien pflegen und für jede Marke separat bauen
Fehler aus der App sehen	Vollständig abgedeckt: Sentry, sobald du dein Konto unter Anbindungen verbindest – mit Stacktrace, Release und Kontext	Teilweise abgedeckt: Error-Tracking selbst integrieren und Releases manuell zuordnen
Backend für die App	Vollständig abgedeckt: NestJS, Laravel oder FastAPI laufen als Dienst im selben Projekt	Teilweise abgedeckt: Getrenntes Setup mit eigener Pipeline, eigenem Server und eigenen Secrets

Grün bedeutet vollständig abgedeckt, gelb teilweise, grau offen. Mobile Releases lassen sich selbst automatisieren, der Aufwand liegt aber überwiegend außerhalb des App-Codes.

Stand: 10. August 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.

Was du für Flutter konkret bekommst

Die Bausteine zwischen fertigem Feature und veröffentlichter App.

Eine Codebasis, zwei Plattformen

Das Flutter-Template bringt Struktur und Konventionen mit. iOS und Android entstehen aus derselben Codebasis und demselben Repository.

Builds in der Pipeline

Test, Build, Publish und Release laufen über eine GitLab-CI-Konfiguration, die lesbar im Repository liegt und sich anpassen lässt.

macOS für iOS-Builds

iOS-Builds laufen auf macOS-Geräten der Pipeline. Eigene macOS-Workspaces zum interaktiven Arbeiten folgen; unter Workspaces wählst du aktuell Ubuntu.

Signing ohne Zettelwirtschaft

Android-Keystore und Apple-Zugangsdaten werden verwaltet und an die Pipeline übergeben, statt auf einzelnen Rechnern zu liegen.

Store-Releases inklusive

Über Fastlane gehen Builds, Metadaten, Screenshots und Versionen an App Store, Play Store und Microsoft Store.

Whitelabel aus einer Codebasis

Aus einer Codebasis entstehen mehrere Marken mit eigenem Branding, eigenen Domains und eigenen Store-Einträgen.

Pipeline für Kunden-App

test

build

publish

release

iOS- und Android-Builds laufen in derselben Pipeline.

So kommt deine Flutter-App in die Stores

Vier Schritte vom Projektstart bis zum ersten Release.

Projekt aus dem Template anlegen

Wähle Flutter im Assistenten. Repository, Projektstruktur und CI/CD-Pipeline entstehen gemeinsam mit dem Projekt.
Code übernehmen

Übertrage deine bestehende App in das Repository. Umgebungsvariablen und Zugangsdaten pflegst du zentral im Projekt.
Signing hinterlegen

Android-Keystore und Apple-Zugangsdaten werden verwaltet und stehen der Pipeline zur Verfügung, ohne im Repository zu landen.
Bauen und veröffentlichen

Die Pipeline baut iOS und Android, erzeugt einen Versionsstand und überträgt Build, Metadaten und Screenshots in die Stores.

Häufige Fragen

Brauche ich einen eigenen Mac für iOS-Builds?

Für Pipeline-Builds nicht. iOS-Builds laufen auf macOS-Geräten der Plattform. Eigene macOS-Workspaces, die du selbst startest, folgen – unter Workspaces wählst du aktuell Ubuntu. Ein eigener Mac bleibt sinnvoll für lokale Arbeit.

Wie werden Signaturen und Zertifikate gehandhabt?

Signing-Zugangsdaten wie Keystore und Apple-Credentials werden verwaltet und der Pipeline bereitgestellt, statt im Repository oder auf Laptops. Ein Release hängt damit nicht von einer Person ab, Zugriff steuerst du über Projektrechte.

Welche Stores werden unterstützt?

Die Plattform veröffentlicht im Apple App Store, Google Play Store und Microsoft Store. Metadaten, Screenshots und Versionen pflegst du im Projekt, die Übertragung übernimmt Fastlane. So sind Store-Einträge versioniert statt in mehreren Portalen gepflegt.

Gibt es Whitelabel-Varianten?

Jedes Template hat eine Whitelabel-Variante: mehrere Marken aus einer Codebasis, mit eigenem Branding, Domains und Store-Einträgen. Die Varianten legst du im Projekt fest, Build und Veröffentlichung laufen für jede Marke gleich ab.

Kann die App mit einem Backend im selben Projekt liegen?

Eine Flutter-App kann im selben Projekt liegen wie ein NestJS-, Laravel- oder FastAPI-Backend, mit eigenem Repository und eigener Pipeline, aber gemeinsamer Server-Anbindung und Zugangsdaten. Fehler laufen über Sentry zusammen, mit Stacktrace und Kontext.

Flutter-Projekt anlegen und veröffentlichen

Registriere dich kostenlos, wähle Flutter als Stack und sieh dir an, wie der Weg vom Commit in den Store aussieht.

Kostenlos registrieren Mit uns sprechen