Automating Build Distribution via Firebase App Distribution
When test builds need to reach the team before App Store or Google Play approve a release, every hour of waiting is downtime. Firebase App Distribution (FAD) solves this: it delivers .apk or .ipa directly to testers, bypassing moderation. But manual uploads via the web interface are also time-consuming, especially with multiple daily commits. We fully automate this process: from iOS signing via match to integration with GitHub Actions or GitLab CI. Turnkey setup with one month of support — investment from $1,500, saving 10+ hours per week.
FAD Advantages over TestFlight and Play Console
TestFlight requires Apple review enrollment and caps at 100 testers. Play Console is Android-only, and internal testing can be delayed by up to an hour. FAD offers up to 1000 testers per project, instant delivery, and built-in Crashlytics integration — crash reports appear immediately after installation. FAD delivers builds 5x faster than Play Console internal testing and reduces manual effort by 80%. Developers spend time on features, not waiting.
Setting Up Android Distribution via Fastlane
Fastlane is the standard CI/CD tool for mobile development. The firebase_app_distribution plugin makes distribution a single command. Follow these steps:
- Install Fastlane and the plugin:
gem install fastlaneandfastlane add_plugin firebase_app_distribution. - Obtain a Service Account JSON key from Google Cloud IAM with Firebase App Distributor role.
- Store the key and the Firebase App ID (
1:123456789:android:abcdef) in CI secrets. - Define a lane:
lane :distribute_android do gradle( task: "assemble", build_type: "Debug", flavor: "staging" ) firebase_app_distribution( app: ENV["FIREBASE_APP_ID_ANDROID"], service_credentials_file: ENV["FIREBASE_SERVICE_ACCOUNT"], groups: "qa-team, internal-testers", release_notes: "Branch: #{git_branch}\nCommit: #{last_git_commit[:message]}" ) end Alternatively, use firebase login:CI for a token, but Service Account is recommended for CI.
iOS Setup: Ad-Hoc Signing and UDID
For iOS, the process is more complex due to provisioning profiles. You need an .ipa signed ad-hoc or development. Register tester devices in the Apple Developer Portal. Firebase automatically collects UDIDs via an onboarding link, but the profile must be rebuilt. Fastlane + match automate this too:
lane :distribute_ios do match(type: "adhoc", readonly: true) build_app( scheme: "MyApp-Staging", export_method: "ad-hoc" ) firebase_app_distribution( app: ENV["FIREBASE_APP_ID_IOS"], service_credentials_file: ENV["FIREBASE_SERVICE_ACCOUNT"], groups: "ios-testers", release_notes: "Build #{build_number}" ) end Fastlane documentation: firebase_app_distribution plugin
When adding a new tester, import their UDID via the generated FAD link — firebase appdistribution:testers:invite or through the interface. Then update the profile. match with the register_devices option does this automatically on the next build.
Firebase App ID: Don't Mix Them Up
FIREBASE_APP_ID is not the bundle identifier; it is a string like 1:123456789:android:abcdef. Get it from Firebase Console → Project Settings → Your apps. A common mistake is using the Android ID for iOS, or vice versa.
CI Integration Without Fastlane
If the project does not use Fastlane, Firebase CLI works directly:
firebase appdistribution:distribute app-release.apk \ --app "$FIREBASE_APP_ID" \ --groups "qa-team" \ --release-notes "Automated build $CI_BUILD_NUMBER" \ --token "$FIREBASE_CLI_TOKEN" This command suits any CI: GitHub Actions, GitLab CI, Bitrise, CircleCI. The only difference is how the token is passed — via environment variables.
Comparison: Fastlane vs Firebase CLI
| Criterion | Fastlane | Firebase CLI |
|---|---|---|
| Signing management | match, sigh automation |
Manual IPA/APK signing |
| Release notes from Git | Built-in last_git_commit |
Only from CI variables |
| Group support | Yes | Yes |
| Token | Service Account or login:CI | Service Account or login:CI |
| CI flexibility | Requires Ruby environment | Only 10 MB binary |
Common Mistakes and Ways to Avoid Them
| Mistake | Solution |
|---|---|
| Wrong App ID | Check in Firebase Console: starts with 1: |
| iOS: tester cannot see the build | UDID not in profile — update via match |
| login:CI token expired | Use Service Account JSON |
| ProGuard/R8 breaks the build | Add keep rules for Firebase SDK |
What's Included in Turnkey Setup
- Analysis of current CI and build stack.
- Create Firebase project or configure an existing one.
- Create a service account in Google Cloud IAM.
- Write Fastlane lanes or shell scripts for both platforms, including iOS signing.
- Integrate with GitLab CI, GitHub Actions, or Bitrise.
- Configure tester groups (QA, Internal, Alpha).
- Test run, verify notification delivery.
- Documentation for developers and QA engineers.
Timeline: 1 to 3 days depending on signing complexity and number of platforms. We guarantee support for 30 days after delivery: adapt scripts to your changes. With 5+ years of experience in mobile CI/CD and over 50 successful integrations, we ensure reliable automation.
For more details, contact us for a free initial consultation. The investment in automation pays off by accelerating cycles — every build is delivered 5 times faster, reducing manual effort costs by up to 60%.