Technology

Flutter CI/CD without a build Mac under someone's desk

A single Flutter codebase for iOS and Android is quick to set up. Getting into the stores needs build machines, signatures, certificates and a release process. The platform covers that, macOS included.

Production-ready Flutter template with repository and project structure
iOS and Android builds in GitLab CI, with macOS machines for Apple builds
Publishing to the App Store, Play Store and Microsoft Store through Fastlane

Start for free. No credit card required.

In short

Mobile CI/CD rarely breaks down over application code. It breaks down over build environments and signatures, and those are the parts the platform handles.

The template produces a repository, a project structure and a pipeline covering test through release.
iOS builds run on macOS machines provided by the platform, so no Mac has to live in your office.

Building Flutter CI/CD yourself versus running it on the platform

A look at what a self-built mobile release process involves and how much of it the platform absorbs.

Task	With the Application Platform	Set up yourself
Project structure and repository	Fully covered: Generated from a production-ready Flutter template with settled conventions	Not offered: Create the repository and agree structure and conventions in the team
Build pipeline for both platforms	Fully covered: One GitLab CI pipeline builds iOS and Android from the same codebase	Not offered: Write and maintain two separate build paths yourself
macOS build environment	Fully covered: macOS machines for iOS builds are part of the platform	Not offered: Buy a Mac, maintain it and keep it running as a CI runner
Android signing	Fully covered: Keystore and passwords are managed and handed to the pipeline	Partly covered: Store the keystore somewhere safe, share it, wire it into CI
Apple credentials	Fully covered: Signing credentials are managed centrally rather than kept locally	Not offered: Renew certificates and profiles by hand and share them around
Store metadata and screenshots	Fully covered: Maintained in the project and pushed to the stores	Not offered: Edited by hand in two portals with no version history
Releases and versioning	Fully covered: Version numbers come out of the pipeline and every release takes the same route	Partly covered: Bump versions manually and upload builds by hand
Whitelabel variants	Fully covered: Several brands from one codebase with their own branding and store listings	Not offered: Keep branches or copies around and build each brand separately
Seeing errors from the app	Fully covered: Sentry is fully configured, errors arrive with stack trace, release and context	Partly covered: Integrate error tracking yourself and match releases manually
Backend for the app	Fully covered: NestJS, Laravel or FastAPI run as services in the same project	Partly covered: A separate setup with its own pipeline, server and secrets

Green means fully covered, amber partly, grey still on you. Automating mobile releases yourself is possible, but most of the effort sits outside your app code.

As of 10 August 2026. This comparison describes typical workflows and can differ from project to project.

What you get for Flutter specifically

The pieces between a finished feature and a published app.

One codebase, two platforms

The Flutter template brings structure and conventions. iOS and Android come out of the same codebase and the same repository.

Builds in the pipeline

Test, build, publish and release run through GitLab CI configuration that sits readable in your repository and can be edited.

macOS for iOS builds

Remote workspaces include macOS machines, so Apple builds no longer depend on a laptop someone has to keep awake.

Signing without shared files

One codebase produces several brands, each with its own branding, domains and store listings.

Pipeline for Customer App

test

build

publish

release

iOS and Android builds run in the same pipeline.

Getting your Flutter app into the stores

Four steps from creating the project to your first release.

Create the project from the template

Pick Flutter in the wizard. Repository, project structure and CI/CD pipeline are created alongside the project.
Move your code in

Bring your existing app into the repository and keep environment variables and credentials centrally in the project.
Store the signing credentials

The Android keystore and Apple credentials are managed and made available to the pipeline without ever entering the repository.
Build and publish

The pipeline builds iOS and Android, produces a version and pushes the build, metadata and screenshots to the stores.

Frequently asked questions

Do I need my own Mac for iOS builds?

No. Remote workspaces include macOS machines that run iOS builds, removing the build Mac in an office that needs maintenance and goes offline during updates. You can also use those machines for development over RDP or VNC.

How are signatures and certificates handled?

Signing credentials such as the keystore and Apple credentials are managed and made available to the pipeline, never in the repository or on laptops. A release no longer depends on one person. Access follows from project rights.

Which stores are supported?

A Flutter app can sit in the same project as a NestJS, Laravel or FastAPI backend, each with its own repository and pipeline but shared server connection and credentials. Errors from both land in Sentry with a stack trace and context.

Create a Flutter project and publish it