Do you build my Flutter app on your servers?

No. Every build runs on GitHub Actions in your own GitHub account, on your minutes. AppForShare writes the workflow, stores the secrets it needs and receives the result.

Which Flutter version is used?

The one your repository pins in .fvmrc, .fvm/fvm_config.json, .flutter-version or an exact version in pubspec.yaml. With none of those, the latest stable. The form shows which one it found.

Why not flutter build ipa?

It cannot sign with an App Store Connect API key. The workflow runs flutter build ios --config-only and then archives the Xcode workspace with the key or your certificate.

Which plan do I need?

Pro includes builds for up to 2 repositories; the iOS and Android setup of one repository count once. Team has no repository limit.

AppForShare Create a free account

Flutter builds on your own GitHub Actions, without writing the workflow

Pro (up to 2 repositories) and Team (no repository limit)

Many Flutter teams want iOS builds without a Mac on the desk, and builds next to their code instead of in a separate CI. GitHub hosted macOS runners give you the Mac; the hard part is the workflow: the Flutter version, signing, export options and build numbers.

When AppForShare GitHub builds finds a Flutter app in the repository, it offers a Flutter preset. You fill in a short form, AppForShare stores the secrets in your repository and opens one pull request with the workflow. You read it and merge it. Runs use your own GitHub Actions minutes.

Start free See plans

Example

acme/notes-flutter

Flutter3.x from .fvmrc
iOS, testersArchive of ios/Runner.xcworkspace, ad hoc
Android, Play internalflutter build appbundle, flavor prod
Build numberRun number

Runs on your own GitHub Actions minutes.

Made for

Flutter developers who want iOS builds without a Mac of their own
Teams that already keep their Flutter code on GitHub and want the builds there too
Agencies with several Flutter client apps that want the same setup in every repository

What it ends

Copying a Flutter workflow from a blog post and fixing signing errors by hand
Builds that use a different Flutter version than the one on your laptop
Editing pubspec.yaml before every build just to raise the build number

How it works

Step 1
Install the GitHub App
Install "AppForShare Builds" on the repository. When it has a pubspec.yaml with a flutter section and an ios or android folder, the setup offers the Flutter preset.
Step 2
Check the form
The Flutter version is filled in from .fvmrc, .fvm/fvm_config.json, .flutter-version or an exact version in pubspec.yaml, else the latest stable, and shown so you can see it. Add a flavor and a target file such as lib/main_dev.dart if your app has them.
Step 3
Merge one pull request
AppForShare stores the secrets and opens a pull request from its own branch with one workflow file. It never pushes to your other branches and never merges.
Step 4
Start a build
Press Build in the dashboard with release notes and a channel. The build goes to your testers as an install link, to TestFlight or to a Google Play track, as you picked.

What the workflow does

Each run sets up Flutter with subosito/flutter-action at the version shown in the form and runs flutter pub get. For iOS it runs flutter build ios --config-only and then archives ios/Runner.xcworkspace itself, signed with your App Store Connect key or your own distribution certificate. It does not use flutter build ipa, because that command cannot sign with the key.

For Android it runs flutter build apk or flutter build appbundle, signed with your upload keystore, which you add as GitHub secrets yourself. AppForShare never sees the keystore or its passwords.

Version, build number, flavor and target

The build name and build number come from the version and build number fields of the setup (--build-name and --build-number), else from pubspec.yaml. A flavor (--flavor) and a target file (-t) can be set, so one repository can have a dev and a prod setup.

Where the build goes

iOS builds go to testers as an AppForShare install link or to TestFlight. Android builds go to testers as an .apk link, or to a Google Play track as an .aab, uploaded by the runner straight to Google. A Google Play production release is always saved as a draft that you roll out yourself.

Every build that reaches AppForShare also gets the Flutter facts and checks: build mode, engine or Dart version, and a line in the readiness check when a debug or profile build is about to go to testers.

Good to know

Builds use your GitHub Actions minutes. On private repositories GitHub counts macOS minutes at 10 times the Linux rate.
The Flutter preset is new. Read the pull request, and watch the first run of each setup before you rely on it.
Keystore alias and passwords cannot contain commas.
Manual iOS signing covers one app target for now, without app extensions.
It does not replace Codemagic's Workflow Editor or hosted Macs. If you build on Codemagic, keep it and use Connect Codemagic or a publishing script instead.

Questions

Do you build my Flutter app on your servers?: No. Every build runs on GitHub Actions in your own GitHub account, on your minutes. AppForShare writes the workflow, stores the secrets it needs and receives the result.
Which Flutter version is used?: The one your repository pins in .fvmrc, .fvm/fvm_config.json, .flutter-version or an exact version in pubspec.yaml. With none of those, the latest stable. The form shows which one it found.
Why not flutter build ipa?: It cannot sign with an App Store Connect API key. The workflow runs flutter build ios --config-only and then archives the Xcode workspace with the key or your certificate.
Which plan do I need?: Pro includes builds for up to 2 repositories; the iOS and Android setup of one repository count once. Team has no repository limit.