Codemagic or GitHub Actions for Flutter, and where the build goes next
· 7 min read
For a Flutter team, the CI choice is often Codemagic or GitHub Actions. Codemagic is the one most Flutter developers meet first, because it builds iOS apps without a Mac and has a Flutter setup screen. GitHub Actions is already in the repository. Both can build, sign and ship a Flutter app. This is a fair comparison, not a pitch. AppForShare, the tool we make, is not a CI and does not build on its own machines; we say where it fits at the end. Codemagic facts are as listed on codemagic.io and docs.codemagic.io on November 5, 2026. GitHub facts are from GitHub Actions billing as read on November 4, 2026.
The short answer
- Pick Codemagic if you want Flutter versions preinstalled, signing managed in a UI, a setup screen with no YAML (the Workflow Editor), and fast Apple silicon Macs without managing anything.
- Pick GitHub Actions if your code is on GitHub, you are fine with YAML and some signing setup, and you want builds next to your pull requests with no second CI account.
- Mixing is common. Tests on GitHub Actions for every pull request, iOS release builds on Codemagic, for example.
Setup
Codemagic
Connect the repository, then either use the Workflow Editor (Flutter apps only) or a codemagic.yaml in the repository. If the file exists, it wins. Flutter, Xcode and CocoaPods versions are set per workflow. Node is preinstalled too, so CLI tools run with npx.
GitHub Actions
You write .github/workflows/*.yml. For Flutter that usually means the community action subosito/flutter-action to install Flutter, then flutter pub get and flutter build. For iOS you handle the certificate and profile in secrets yourself, or use fastlane match. More setup, more control, all in one place.
Signing
This is where Codemagic is clearly ahead for most Flutter teams. With an App Store Connect API key, its ios_signing block fetches or makes the certificate and profile, and xcode-project use-profiles applies them. Android keystores are uploaded once and exposed as variables. On GitHub Actions, you import a .p12 into a temporary keychain, install the profile, and pass the right export options. It works, but it is the step that fails most often on a first setup. If you do iOS ad hoc builds on Codemagic, our Codemagic iOS ad hoc guide has the exact YAML.
Price
As listed on November 5, 2026, Codemagic gives a personal account 500 macOS M2 minutes a month and one parallel build. Pay as you go is $0.095 a minute on a Mac mini M2, $0.114 on an M4 and $0.045 on Linux. Codemagic's docs say teams get no free minutes. Details and worked examples are in Codemagic pricing in 2026.
As read on docs.github.com on November 4, 2026, GitHub hosted runners are free in public repositories. Private repositories get included usage each month expressed as money: $12 on GitHub Free, $18 on GitHub Pro and GitHub Team. The macOS rate is $0.062 a minute, about ten times Linux at $0.006.
| Codemagic | GitHub Actions | |
|---|---|---|
| Free macOS time | 500 M2 minutes a month (personal only) | $12 of included usage, about 190 macOS minutes (GitHub Free, private repos); free in public repos |
| macOS per minute | $0.095 (M2), $0.114 (M4) | $0.062 (standard runner) |
| Linux per minute | $0.045 | $0.006 (2-core) |
| Fixed price option | From $3,990 a year, unlimited minutes | Self hosted runners on your own Macs |
| Team members | Unlimited on paid plans | Your GitHub plan's members |
Per minute is only half the story. A Mac mini M4 may finish the same build faster than a standard GitHub macOS runner, so compare cost per build, not per minute. Run the same workflow on both for a week and look at the bills.
Where each one is ahead
Codemagic: Flutter first setup, signing in the UI, Apple silicon Macs including M4 and M4 Max, publishing to App Store Connect, Google Play, Huawei AppGallery, Firebase App Distribution and more, tests on device clouds, over the air updates with Codemagic Patch, and unlimited members on paid plans.
GitHub Actions: no second account, builds and checks in the pull request, free in public repositories, the cheapest Linux minutes of the two, and the option of your own runners at no per minute cost.
Both have the same blind spot: neither gives non developer testers an iPhone install page. Codemagic's download links in emails and dashboards last 24 hours; GitHub Actions artifacts are zip downloads for people with repository access.
A middle way: builds on your own GitHub Actions, set up for you
If the signing setup is what keeps you on Codemagic, AppForShare GitHub builds (Pro up to 2 repositories, Team no limit) writes the GitHub Actions workflow for you and opens it as one pull request you review. It stores the secrets it needs in your repository, signs with your App Store Connect API key, and never merges or pushes to your other branches. Runs use your own GitHub Actions minutes, and on private repositories GitHub counts macOS minutes at 10 times the Linux rate.
For Flutter, a preset detects pubspec.yaml with a flutter: section, installs Flutter with subosito/flutter-action at the version from .fvmrc, .flutter-version or the pubspec (else stable), runs flutter pub get, and then builds. For iOS it runs flutter build ios --config-only and archives ios/Runner.xcworkspace itself, signed with your App Store Connect key or your own distribution certificate; it does not use flutter build ipa, which cannot sign with the key. For Android it runs flutter build apk or appbundle with your upload keystore, which you add as GitHub secrets yourself. Build name and number come from the version and build number fields of the setup, else from pubspec, and a flavor and target file such as lib/main_dev.dart can be set.
The preset is new, so read the pull request and watch the first run of each setup before you rely on it. It does not replace Codemagic's Macs or its Workflow Editor. It is an option for teams who want builds next to their code without writing the signing part. Every Flutter build that reaches AppForShare, from either CI, also shows its build mode and engine or Dart version, and the readiness check warns when a debug or profile build is about to go to testers (every plan with an account). See Flutter builds on GitHub Actions.
Where the build goes next
Whichever CI you pick, testers outside the team need something to install. AppForShare takes the finished file from either one:
- From Codemagic: a publishing script with a
~/SUCCESScheck (Codemagic runs publishing scripts even after a failed build), or Connect Codemagic, which imports finished builds with an API token. See Share a Codemagic build with testers. - From GitHub Actions: the AppForShare GitHub Action after your build step, with an optional pull request comment holding install links and QR codes.
Testers get an install page with an Install button and a QR code, no account, in 13 languages, and every build gets a store readiness check, which is guidance and not a promise of approval.
Common questions
Can I build iOS on GitHub Actions without a Mac?
Yes. GitHub's hosted macOS runners are Macs you rent by the minute. You do not need one on your desk.
Is the Workflow Editor enough for a real project?
For many Flutter apps, yes. Teams that need several workflows or review their CI changes in pull requests usually move to codemagic.yaml.
Does AppForShare build Flutter apps?
No. It sets up builds on your own GitHub Actions and shares builds from any CI.
For the full side by side on sharing and store steps, read AppForShare vs Codemagic. For the Bitrise view of the same question, see Bitrise vs GitHub Actions for mobile. To try either path, create a free account.
