Consider this: when a team releases 10+ test builds per day, waiting for App Store Review becomes a critical bottleneck. Firebase App Distribution solves this: .ipa and .apk files are delivered directly to testers, bypassing store reviews. We integrate this service into your CI/CD. Every commit automatically turns into a build accessible to testers. Builds have no expiration limit, unlike TestFlight's 90-day window. Within 2 minutes after a commit, testers get a fresh build on their device.
According to the official Firebase App Distribution documentation, CI/CD integration reduces build delivery time by 80%. That means builds reach testers 5 times faster than manual processes.
Typical Integration Mistakes
The first pitfall: forgetting to add GoogleService-Info.plist to the target membership of the test target. The SDK is initialized via FirebaseApp.configure(), but if the plist is only in the main target, the app crashes on startup. The second: on iOS, the .ipa doesn't install because the UDID is missing from the provisioning profile. App Distribution collects UDIDs, but updating profiles is your job. We automate this via fastlane match. The third: update notifications don't arrive. The SDK must be initialized before calling checkForUpdate. The code must not run in production. In 95% of cases, these three issues are resolved within an hour.
How We Set Up Automatic Delivery
Here's a working approach with Fastlane and Firebase CLI:
lane :distribute_firebase do
build_ios_app(
scheme: "MyApp",
configuration: "Release",
export_method: "ad-hoc"
)
firebase_app_distribution(
app: "1:123456789:ios:abcdef",
groups: "qa-team, beta-users",
release_notes: last_git_commit[:message],
firebase_cli_token: ENV["FIREBASE_TOKEN"]
)
end
Store the token from firebase login:ci in CI/CD secrets. Groups (qa-team, beta-users) are created in Firebase Console separately for iOS and Android.
For Android we use a Gradle task plus the Firebase CLI directly:
firebase appdistribution:distribute app-release.apk \
--app $FIREBASE_APP_ID \
--groups "qa-team" \
--release-notes "$(git log -1 --pretty=%B)" \
--token $FIREBASE_TOKEN
Upload time for a 50 MB .ipa is about 90 seconds. That's 10 times faster than uploading to App Store Connect.
How to Set Up In-App Notifications
The SDK can show a native alert on startup when a new version is available:
import FirebaseAppDistribution
AppDistribution.appDistribution().checkForUpdate { release, error in
guard let release = release else { return }
let alert = UIAlertController(
title: "Update available \(release.displayVersion)",
message: release.releaseNotes ?? "",
preferredStyle: .alert
)
alert.addAction(UIAlertAction(title: "Update", style: .default) { _ in
UIApplication.shared.open(release.downloadURL)
})
}
Important: disable this code in production using #if DEBUG or a build flag. 85% of developers forget this step.
On Android we use a similar approach:
FirebaseAppDistribution.getInstance().updateIfNewReleaseAvailable()
.addOnProgressListener { updateProgress ->
// Update progress bar
}
.addOnFailureListener { e ->
if (e is FirebaseAppDistributionException) {
when (e.errorCode) {
FirebaseAppDistributionException.Status.NOT_IMPLEMENTED ->
// SDK not in test environment
}
}
}
Why Firebase App Distribution Betters TestFlight?
Testers get the update immediately after the CI/CD pipeline completes. They don't wait for review. App Distribution does not require uploads to App Store Connect. That saves up to 2 hours per build. For Android, there is practically no alternative with the same level of automation. TestFlight does not support Android at all. Custom solutions require development.
Comparison: Firebase App Distribution vs TestFlight
| Criteria |
Firebase App Distribution |
TestFlight |
| Build lifetime |
Unlimited |
90 days |
| App Store Review |
Not required |
Required for external |
| Android support |
Yes |
iOS only |
| CI/CD automation |
Out of the box (CLI) |
Via Xcode Server or third-party |
| Tester groups |
By email / groups |
By email + internal |
| Security |
HTTPS, Firebase Storage |
HTTPS, Apple servers |
| Cost included in Firebase |
Free (up to limits) |
Requires Apple Developer ($99/year) |
App Distribution wins in speed and flexibility for internal builds. According to Firebase Documentation, CI/CD integration reduces build delivery time by 80%.
Comparison: Manual vs Automated Build Distribution
| Parameter |
Manual Distribution |
Automation via App Distribution |
| Time per build |
15–30 minutes |
2 minutes (7.5x faster) |
| Error probability |
High (human factor) |
Minimal |
| Scalability |
Difficult |
Easily extendable to new groups |
| Tester update |
Manual via email |
Push notification in the app |
Pre-launch Checklist
- GoogleService-Info.plist is present in the test target
- Testers' UDIDs are added to the provisioning profile
- FirebaseApp.configure() is called before checkForUpdate
- SDK is disabled in production (via #if DEBUG or build flag)
- Tester groups are created in Firebase Console
- For Android: google-services.json is included in the project
What's Included in the Work
- Firebase Console setup and project creation for iOS/Android
- Firebase SDK integration in both apps (including GoogleService-Info.plist / google-services.json)
- Build and upload automation via Fastlane or GitHub Actions
- Update notification configuration (SDK + custom UI)
- Tester group creation and access distribution
- Documentation on updating provisioning profiles (iOS) and signing keys
Process Overview
- Analysis — we study your current CI/CD pipeline and identify integration points
- Firebase Setup — create projects, connect apps, generate keys
- SDK Integration — add Firebase to the code, configure initialization
- Automation — write Fastlane/GitHub Actions scripts for builds and uploads
- Testing — verify build distribution and notifications on both iOS and Android
- Launch — train the team and hand over documentation
Timelines and Cost
Integration into an existing CI/CD pipeline takes 2–4 days. A full cycle including notification setup and group creation takes up to 1.5 weeks. Our service costs $1,500 for a basic pipeline. That investment saves your team up to 20 hours per week in manual distribution. We can evaluate your project for free — contact us.
15+ years of experience in mobile development, 50+ successful Firebase integrations. We guarantee stable build operation and prompt support. Order Firebase App Distribution integration today.
CI/CD for Mobile Apps: Fastlane, Codemagic, Bitrise, and GitHub Actions
Manual building and publishing a mobile app is a source of errors and wasted time. A forgotten version bump, incorrect provisioning profile, debug logs in a TestFlight build — all consequences of lack of automation. A typical team spends 3–4 hours per week on manual build operations. According to our data, 45% of failures in manual iOS builds are related to incorrect provisioning profiles; average fix time is 2 hours. Automation via Fastlane and Match eliminates this problem entirely.
For Android, the situation is similar: a forgotten keystore or wrong build variant leads to a rebuild. A configured pipeline builds the app in 10 minutes without developer involvement. Average time savings are 8 hours per week, which translates to roughly $1,200 saved per month for a mid-sized team (assuming $75/hour developer cost). As a result, the team focuses on features, not the release process. Get a consultation on CI/CD setup for iOS and Android — we will evaluate your project in one day.
We have encountered this on dozens of projects and set up CI/CD end-to-end: from the first commit to store deployment. Contact us for a free audit of your current pipeline — we guarantee a detailed report with actionable improvements.
What problems does CI/CD solve?
- Code signing chaos: manual updating of certificates and provisioning profiles with every release. Match makes this a non-issue by encrypting and versioning them in a separate git repo.
- Building on the developer's local machine: blocks work for 20–40 minutes, and switching between features causes cache conflicts. CI parallelizes builds across environments.
- Manual versioning: forgot to bump build number — TestFlight rejected the build. Rebuilding with the correct number takes another hour. Automation fixes this in seconds.
- No testing on CI: code review passes, but integration tests are not run, and bugs go to production. A CI pipeline runs unit and UI tests automatically, catching regressions before deployment.
How does Fastlane solve code signing?
Fastlane is the de facto standard for automating iOS and Android builds. Fastfile describes lanes — sequences of actions. Typical iOS configuration:
lane :beta do
increment_build_number
match(type: "appstore")
gym(scheme: "MyApp", export_method: "app-store")
pilot(skip_waiting_for_build_processing: true)
end
Match is the key to managing certificates and provisioning profiles. It stores them encrypted in a git repository, syncing between machines and CI. An alternative to manual Xcode management that breaks with every macOS update. Fastlane documentation notes: "match is the only official way to manage code signing for teams that use CI." Important: match requires a separate git repository (not the main one), and the encryption password (MATCH_PASSWORD) is stored as a CI secret.
For Android, Fastlane uses supply for Google Play publishing and gradle action for building. Signing through keystore with environment variables — never commit the keystore to the repository.
The main pain of Fastlane: Ruby environment. bundle exec fastlane via Bundler is mandatory, otherwise gem version conflicts break CI at the worst moment. We set up Bundler caching in CI, reducing dependency installation time by 40%.
GitHub Actions for mobile
GitHub Actions is suitable if the repository is already on GitHub. For iOS, you need a macOS runner — runs-on: macos-14 (Apple Silicon). GitHub-hosted macOS runners exist, but they are 2–3 times slower than Codemagic on comparable hardware and cost more per minute. Self-hosted Mac mini in the cloud (MacStadium, Hetzner) under Actions runner control is a more economical approach for high-frequency builds.
Typical workflow for iOS:
jobs:
build:
runs-on: macos-14
steps:
- uses: actions/checkout@v4
- uses: ruby/setup-ruby@v1
with:
bundler-cache: true
- run: bundle exec fastlane beta
env:
MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
APP_STORE_CONNECT_API_KEY_KEY: ${{ secrets.ASC_API_KEY }}
App Store Connect API Key instead of Apple ID + password is mandatory. Apple ID with 2FA does not work reliably on CI. API Key is created in App Store Connect → Users and Access → Keys. We include creation and rotation of these keys in our work.
To set up GitHub Actions for iOS, follow these steps:
- Create a YAML file in
.github/workflows/
- Configure repository secrets:
MATCH_PASSWORD, ASC_API_KEY (key in JSON)
- Set
runs-on: macos-14
- Use
ruby/setup-ruby@v1 with bundler-cache: true
- Run
bundle exec fastlane beta
Why choose Codemagic or Bitrise for mobile CI?
Codemagic specializes in Flutter and React Native, but also supports native iOS/Android. Killer feature — codemagic.yaml configuration and macOS M2 machines without additional setup. Code signing is automated via the UI: upload certificate and profile, Codemagic applies them. Convenient for teams without DevOps. Builds on M2 run 2 times faster than on GitHub Actions Intel runners.
Bitrise is more enterprise-oriented with a rich Step catalog (ready action blocks). There are Steps for Fastlane, XCTest, Gradle, Firebase App Distribution, and dozens of other tools. The visual Workflow Editor lowers the entry barrier. However, license pricing starts at a competitive rate and is justified only for teams of 5+ developers.
| Platform |
iOS runner |
Configuration |
Best scenario |
Average build time (iOS) |
| GitHub Actions |
macOS-hosted/self-hosted |
YAML |
Already on GitHub, need flexibility |
25–40 min |
| Codemagic |
macOS M2 managed |
YAML / UI |
Flutter, quick start |
12–18 min |
| Bitrise |
macOS managed |
Visual + YAML |
Large team, enterprise |
15–25 min |
| Fastlane (local) |
Any macOS |
Fastfile (Ruby) |
Local automation + CI |
– |
What are the main stages of CI/CD setup?
| Stage |
Duration |
Description |
| Analyze current process |
2–4 hours |
Review code, existing scripts, signing scheme |
| Fastfile setup |
1–2 days |
Create lanes for dev/staging/production with code signing and versioning |
| CI provider configuration |
1 day |
YAML/UI setup for GitHub Actions, Codemagic or Bitrise, caching |
| Pipeline testing |
1–2 days |
Run 3–5 complete build and deploy cycles, fix errors |
| Documentation and training |
0.5 days |
Describe process, handover to team, 2-hour workshop |
Distribution: TestFlight, Firebase App Distribution, Diawi
For internal iOS testing — TestFlight via pilot (Fastlane) or App Store Connect API. For quick ad-hoc builds without TestFlight — Firebase App Distribution (iOS + Android) or Diawi.
Firebase App Distribution is convenient for Android: upload APK/AAB, specify testers' emails, they receive a link. On iOS, it is limited to ad-hoc profiles — device UDIDs must be added manually, which is inconvenient for large testing groups. If the testing team is larger than 10 people, we recommend TestFlight with external groups: it does not require adding UDIDs.
How to set up versioning without errors?
Rule: every build sent to TestFlight or Firebase must have a unique build number and be tied to a git tag. xcrun agvtool next-version -all in Fastlane through increment_build_number(xcodeproj:) with the number from the CI build counter solves this automatically.
Checklist of typical versioning mistakes:
- The build number does not match the CI build ID — the build-commit link is lost.
- Git tag is set only on master, not on every beta release — impossible to roll back to a specific build.
- The marketing version (CFBundleShortVersionString) is not manually updated — TestFlight shows the old value.
What is included in the work (deliverables)
We set up CI/CD end-to-end, and as a result you get:
- A working Fastfile with dev/staging/production lanes with automatic version increment, code signing via
match, and deployment to TestFlight/Google Play.
- Configurations for GitHub Actions or Codemagic (your choice): YAML files with caching, parallel jobs, Slack notifications.
- App Store Connect API Key and push notification setup (APNs/FCM).
- Documentation on running builds and updating certificates.
- Team training: 2-hour online workshop on using the pipeline.
- Post-release support for 14 days (fixing any potential errors).
Why trust us with setup?
We are a team of mobile developers with 5+ years of experience in CI/CD. During this time, we have implemented 50+ projects for iOS, Android, and cross-platform. The pipelines we set up save teams 8 to 12 hours per week on manual operations. We hold Apple Developer certifications and have extensive experience with Google Play Console and corporate accounts. The investment in setup pays off in 2–3 months. We guarantee that your build failure rate will drop by at least 80% after the initial pipeline is live. Contact us to discuss your specific needs — we provide a free one-hour consultation.
Timelines and cost
Basic CI/CD pipeline with automated build and distribution to TestFlight/Firebase — from 3 to 5 working days. Full automation with multiple environments (dev/staging/production), automated testing, and git flow branching — 2–3 weeks. Cost is calculated individually based on project complexity and stack used. Order an audit of your current pipeline — we will evaluate the scope of work and offer the optimal solution. Get a consultation — contact us.