The Flutter Release Pipeline Everyone Converges On

A Flutter release pipeline making the rounds this week has a familiar shape: GitHub Actions runs analysis and tests on Linux for every pull request, and only a version tag — v1.4.2, pushed by a human — triggers the expensive part: signed Android and iOS builds uploaded straight to the Play Store internal track and TestFlight. That shape isn't one blogger's taste. It's the architecture nearly every Flutter team converges on after shipping a few releases and reading a GitHub invoice. The convergence is the story, because understanding why this design keeps winning tells you exactly which parts to copy and which to swap.

The bill designs the pipeline

GitHub-hosted macOS runners cost $0.062 per minute against $0.006 for Linux — GitHub cut both rates this January, but the ratio stayed at roughly 10x. That single number explains most of the architecture. A team running its PR checks on macOS "because we ship iOS" pays the Apple tax on every push: twenty PRs a day with a 15-minute check each is about $560 a month. The identical work on ubuntu-latest costs around $54.

Nothing in the Flutter PR loop needs a Mac. dart format, flutter analyze, and flutter test are fully cross-platform, so the only jobs that genuinely require macOS are the ones that touch Xcode's codesigning machinery — building and signing the IPA. Gating CD on version tags rather than merges to main completes the cost story: you pay the macOS toll per release, not per merge, and a tag doubles as an explicit, auditable "ship it" signal that a green merge never is. If you take one structural decision from the consensus pipeline, take that one.

fastlane won, and nobody's paying for it

The uncomfortable part of this stack is its center of gravity. fastlane handles the two steps no flutter command covers — upload_to_play_store and upload_to_testflight — and it's a Ruby tool with a strange custody history. Felix Krause sold it to Twitter, Google took it over in 2017, then quietly stopped investing, and in late 2023 the project landed at the community-run Mobile Native Foundation. Releases still ship and CVEs still get patched, but velocity has slowed, and new Xcode versions periodically break lanes until a volunteer fixes them. Meanwhile every Flutter repo that adopts it inherits a Gemfile, Bundler, and Ruby version management in a codebase where nobody writes Ruby.

There's a tempting conclusion here — rip it out — and it's wrong, because no credible replacement exists. The App Store Connect and Google Play Developer APIs are public, and you can script the uploads yourself, but you'll reimplement retry logic, dSYM handling, and API-key auth that fastlane already gets right, in more lines than the Gemfile costs you. Proposals for a successor have circulated for years without producing one.

The right move is narrower: treat fastlane as a thin upload shim, not an automation framework. Build with flutter build appbundle and flutter build ipa, and confine your Fastfile to two short lanes that authenticate and upload. Teams that go deeper — screenshot generation, version bumping, changelog lanes — end up maintaining a parallel build system in a foreign language, and that's the fastlane experience people complain about. A two-lane Fastfile survives Xcode churn because there's almost nothing in it to break.

Signing is still the hard 20 percent

Android signing in CI is a solved problem: base64-encode the keystore into a repository secret, decode it to disk in the job, and feed KEYSTORE_PASSWORD, KEY_ALIAS, and friends into Gradle through the environment. Ten lines, done once.

iOS is where pipelines go to die. A fresh macOS runner has an empty keychain, so a bare flutter build ipa --release fails at the signing step every time. The consensus fix is fastlane's match — distribution certificates and provisioning profiles encrypted in a private Git repo, decrypted on the runner with a shared password. It works, and it's showing its age: a Git repository full of signing identities protected by one shared secret is exactly the artifact a security review flags. The genuine improvement of the last few years is App Store Connect API keys, which replaced the old shared-Apple-ID-plus-2FA-cookie hack with a revocable .p8 key. match plus an ASC API key is the current least-bad arrangement. If you want fastlane-free signing, GitHub documents installing Apple certificates into the runner keychain directly — more manual, fewer moving parts, worth it for teams who already distrust the cert repo pattern.

Either way, budget the day. The workflow YAML takes an hour; the eight secrets (KEYSTORE_BASE64, PLAY_STORE_SERVICE_ACCOUNT_JSON, ASC_KEY_ID, ASC_ISSUER_ID, ASC_KEY_CONTENT, MATCH_GIT_URL, MATCH_PASSWORD, plus keystore credentials) and the first successful signed build take the rest.

When to buy instead

The managed alternative is real. Codemagic is Flutter-first and will hold your signing identities for you; Bitrise plays the same role for bigger mobile orgs; Xcode Cloud is fine if you're iOS-only, which a Flutter team by definition isn't. Managed CI earns its fee in two situations: nobody on the team wants to own code signing, or your repos don't live on GitHub. The trade is money and a vendor dependency against roughly 150 lines of YAML you'll touch twice a year.

For a team already on GitHub, DIY wins, and it isn't close. The stack is boring, slightly duct-taped — a community-maintained Ruby tool sits in the critical path of every Dart app release, and that should bother you a little — but it's also battle-tested, vendor-free, and cheap if you respect the cost structure. Pin your Flutter version in the workflow instead of tracking stable, keep every job on Linux except the one that signs the IPA, gate the store uploads behind tags, and keep the Fastfile too small to rot. A half-day release becoming git tag v1.4.2 && git push --tags is not hype. It's just plumbing that most teams still haven't installed.