Firebase App Distribution alternative: when a link is simpler
· 7 min read
Firebase App Distribution is a sensible default for a lot of mobile teams. It is part of the Firebase console many apps already use, it covers iOS and Android, and it plugs into the Firebase CLI, Fastlane and the Android Gradle plugin. So when people search for a Firebase App Distribution alternative, it is usually not because the product is bad. It is because one part of the flow does not suit the people who have to install the build.
This article goes through what Firebase App Distribution does well, where teams run into friction, and when a plain install link is the simpler choice.
What Firebase App Distribution does well
- One console for both platforms. Android APKs and AABs and iOS IPAs are managed per app inside the same Firebase project.
- Good tooling. Uploads work from the console, the Firebase CLI, a Fastlane plugin and the Gradle plugin, so most CI setups can add it in a few lines.
- Tester groups and invites. You add testers by email or into groups, and each release goes to the groups you pick.
- Optional SDK. Basic distribution needs no SDK. If you add the App Distribution SDK, the app can alert testers when a new build is out, and on Android testers can send in-app feedback.
- UDID help on iOS. During onboarding, iOS testers install a Firebase profile that registers their device, so you can collect UDIDs for your Ad Hoc profile.
- Reasonable retention. Releases stay available in the console for 150 days.
If your app already uses Firebase, your testers all have Google accounts and you send builds to the same group every week, it works well and you probably do not need to change anything.
Where teams hit friction
Testers must sign in with Google
To accept an invitation, a tester signs in with a Google account. For an internal team on Google Workspace that is invisible. For a client on Microsoft 365, a tester who does not want to link a personal Gmail to your project, or a stakeholder who just wants to tap a link before a meeting, it is one more step that someone has to explain. Firebase also notes that an invitation can be accepted once and with any Google account, which surprises people who expected it to be tied to the invited address.
Invitations, expiry and the tester app
Invitations expire if they are not accepted within 30 days, and you renew them from the console. On Android, testers use the App Tester app, or the tester web page, to see and install releases. On iOS, the flow is open the email in Safari, sign in, install the Firebase profile, register the device, then install the build from a web clip on the home screen. Each step is reasonable. Together they are a lot for a tester who only needs one build once.
Project setup comes first
Distribution lives inside a Firebase project, with an app registered for each bundle ID and package name. For an agency shipping a dozen client apps, that is a dozen projects or a crowded shared one, plus deciding who in the client's company gets console access. For a one off build, setting up a project can take longer than the test itself.
iOS still needs Ad Hoc signing
This is not a Firebase limit, it is Apple's. Any tool outside TestFlight installs iOS builds the same way: the build must be signed Ad Hoc, Development or Enterprise, and for Ad Hoc and Development the device UDID has to be in the provisioning profile. Firebase helps collect the UDIDs, but you still add them in the Apple Developer portal and rebuild. Switching tools will not remove this step. See Ad Hoc device registration for the full flow.
AAB testing has extra setup
To distribute Android App Bundles, Firebase needs the Firebase project linked to the matching app in Google Play, because it uses Play's internal app sharing to produce installable APKs. If your app is not on Play yet, or the client owns the Play account, uploading an APK is simpler.
When an install link is simpler
An install link service skips the invite and account steps. You upload the build and get one URL and a QR code. The tester opens it on the phone and installs. On Android they allow installs from unknown sources once; on iOS the device must already be in the profile. That fits:
- Client reviews. The person approving the app should not need a Google account or a tester app. See sending app builds to clients.
- Quick one off builds for a designer, a support colleague or a beta user who reported a bug.
- Agencies with many small apps, where one project per app in Firebase is overhead.
- Teams that already use Crashlytics or another tool for crashes and just need the install step.
An install link is not always better. If you want the in-app "new build available" alert, Android in-app tester feedback, or the device registration help built into Firebase's iOS flow, those come from Firebase. A link service without an SDK cannot offer them.
Comparison
| Question | Firebase App Distribution | Install link service |
|---|---|---|
| What the tester needs | Google account, invite email; App Tester app or web page on Android, Firebase profile on iOS | The link or QR code |
| Setup before first upload | Firebase project with the app registered | An account, or none for a quick guest upload on some services |
| iOS signing | Ad Hoc or Enterprise, UDIDs in profile | Same |
| Android formats | APK, or AAB with a Play link | Usually APK |
| In-app update alerts and feedback | Yes, with the optional SDK | Depends on the service |
| Best for | Teams already on Firebase with recurring tester groups | Clients, one off builds, many small apps |
Moving a CI step from Firebase to an install link
If your pipeline calls the Firebase CLI today, the swap is one line. For example, in GitHub Actions:
# before
- run: firebase appdistribution:distribute app-release.apk --app "$FIREBASE_APP_ID" --groups "qa"
# after
- name: Share build
run: npx --yes appforshare@1 upload app/build/outputs/apk/release/app-release.apk --notes "${{ github.event.head_commit.message }}"
env:
APPFORSHARE_TOKEN: ${{ secrets.APPFORSHARE_TOKEN }}Keep both for a sprint if you want: there is no reason a build cannot go to Firebase for the internal group and to a link for the client. More options, including Fastlane and --json output, are on the CI docs page and in uploading builds from CI.
Things to check before you switch
- Who your testers are. If they are all on Google Workspace and already onboarded, the friction above may not apply to you.
- Whether you rely on the SDK. Remove the App Distribution SDK calls only if you no longer need in-app alerts or feedback.
- Your iOS UDID list. Export the registered devices from the Apple Developer portal so nothing is lost. The devices registered through Firebase are already in your Apple account.
- Android format. If you only produce AABs, add a step that builds an APK (or a universal APK with
bundletool) for direct installs.
AppForShare as a Firebase App Distribution alternative
AppForShare is a standalone install link service. It does not integrate with Firebase and has no SDK, so there are no in-app update alerts or in-app feedback. What it does: you upload an .apk or an Ad Hoc, Development or Enterprise signed .ipa, and get a link and a QR code that testers open on the phone. No tester account and no tester app.
- Free accounts get password protected links that last 7 days. Pro ($12 a month) keeps links live while subscribed and adds CI uploads, release notes, webhooks to Slack or Discord and install analytics.
- Team ($39 a month) adds private projects where only invited testers can open builds, emails to testers on new builds and a "who installed" view.
- The free UDID finder helps iOS testers send you their UDID, and the IPA inspector shows which devices a build includes.
See AppForShare vs Firebase App Distribution for a feature by feature view, or sign up free and send your next build as a link.
