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 vorgesehen: 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 vorgesehen: 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 vorgesehen: 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 vorgesehen: 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 vorgesehen: 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 vorgesehen: Branches oder Kopien pflegen und für jede Marke separat bauen
Fehler aus der App sehen	Vollständig abgedeckt: Sentry wird komplett aufgesetzt, Fehler kommen 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.

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

Remote-Workspaces umfassen macOS-Geräte. Apple-Builds brauchen damit keinen Mac, der im Büro unter einem Schreibtisch steht.

Signing ohne Zettelwirtschaft

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?

Nein. Zu den Remote-Workspaces gehören macOS-Geräte für iOS-Builds. Damit entfällt der Build-Mac im Büro, der gewartet werden muss und bei Updates ausfällt. Dieselben Geräte nutzt du auch für die Entwicklung, per RDP oder VNC.

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?

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