Moving off Firebase App Distribution: export UDIDs and testers, keep your CI
· 8 min read
Teams move off Firebase App Distribution for a handful of reasons: testers outside the company keep getting stuck at the Google sign in, an agency is tired of one Firebase project per client, or a release expired after 150 days while a client still needed it. Whatever the reason, the move itself is mostly bookkeeping. You have devices, testers, groups and a CI step, and each needs to land somewhere without breaking the next release.
This guide is the checklist: what to export from Firebase, what to import, how to change the CI step, and what you give up. It uses AppForShare as the destination because that is the tool we make, but the export steps work for any target. Firebase details come from its documentation as read on November 2, 2026. The step by step product guide is on Move from Firebase.
What moves and what does not
| Item | How to get it out of Firebase | Where it goes |
|---|---|---|
| iOS device UDIDs | Testers and Groups tab, All testers, Export Apple UDIDs (CSV); or fastlane firebase_app_distribution_get_udids | Devices page import (Free) |
| Tester emails | REST API projects.testers.list, or copy from the console into a CSV | Tester CSV import with names and groups (Team) |
| Groups | Note each group's members; the REST API also lists groups | Groups column in the same CSV, made on import |
| Builds | Your CI artifacts, or download a release from the console | Upload again only if testers still need it |
| Feedback | REST API feedbackReports list and get | Keep as an archive; new feedback starts fresh |
| CI step | Your pipeline file | AppForShare CLI, GitHub Action, fastlane or Gradle |
| Devices already on Apple | Nothing to do | They stay in your Apple account |
References: register additional devices for the UDID export, and the App Distribution REST API for testers, groups and feedback.
One point that saves worry: devices registered through Firebase were added by you to your own Apple Developer account. They are not held by Firebase. Your Ad Hoc profiles and the builds signed with them keep working the same way in any tool.
Step 1: take stock
Before changing anything, write down for each app: the Firebase app ID, the groups and roughly how many testers each has, which CI jobs call Firebase, and whether the app includes the optional App Distribution SDK for alerts or feedback. The SDK matters most, because it is code in the app, not a setting in the console.
Step 2: export and import UDIDs
- In the Firebase console, open App Distribution, the Testers and Groups tab, select All testers and click Export Apple UDIDs. Firebase gives you a CSV made for Apple's Register Multiple Devices option.
- In AppForShare, open Devices and import that file as it is. The import also takes Apple's own bulk file (Device ID, Device Name, Device Platform) or a plain list with one UDID per line. Duplicates and lines that are not iPhone or iPad UDIDs are skipped and listed with the line number.
- From a script, with an API token:
npx appforshare devices import firebase-udids.csv.
The import is on every account plan, including Free. Registering those devices on Apple from the dashboard is a separate step on Pro and Team, with an App Store Connect connection; devices that are already registered are skipped.
Step 3: move testers and groups
Firebase's own CSV import only reads the email in the first column and ignores the rest (import testers from CSV). The AppForShare import (Team) reads a header row, so you can bring names and groups across in one file:
email,name,groups
[email protected],Ali Khan,QA
[email protected],Bri Lopez,QA;Client
[email protected],Cal Nguyen,ClientThe email column is required. Name can be one column or first and last name. Several groups go in one cell, separated by a semicolon or a pipe, and groups that do not exist yet are created. From the CLI:
npx appforshare testers import testers.csv --project 42Imported testers are not emailed unless you ask (--notify), which lets you set everything up and announce the switch yourself. Testers then open builds from an emailed link. Nobody needs a Google account or a password.
If you used Firebase invite links to let testers add themselves, the replacement is a join link per project (Team): testers enter an email, confirm it, and land in a group, with optional email domain limits, a join cap and pause.
Step 4: change the CI step
The commands map almost one to one. This table covers the Firebase CLI calls teams use most (Firebase CLI distribution).
| Firebase CLI | AppForShare CLI |
|---|---|
appdistribution:distribute app.apk --app ID | appforshare upload app.apk |
--release-notes, --release-notes-file | --notes, --notes-file (Pro) |
--groups "qa-team" | --groups "QA" (Team) |
--testers, --testers-file | --testers, --testers-file (Team) |
appdistribution:testers:add / remove | appforshare testers add / remove (Team) |
appdistribution:group:create / delete | appforshare groups add / delete (Team) |
Service account or FIREBASE_TOKEN | APPFORSHARE_TOKEN from Dashboard, Settings (Pro and Team) |
In GitHub Actions, the change looks like this:
# before
- run: firebase appdistribution:distribute app-release.apk --app "$FIREBASE_APP_ID" --groups "qa-team" --release-notes-file notes.txt
# after
- run: npx --yes appforshare@1 upload app/build/outputs/apk/release/app-release.apk --groups "QA" --notes-file notes.txt --channel beta
env:
APPFORSHARE_TOKEN: ${{ secrets.APPFORSHARE_TOKEN }}The --groups and --testers options need CLI 1.9.0 or later. --channel beta is optional: it puts the build in a channel whose link always opens the newest build, so testers can bookmark one address. There is also appforshare distribute <build> --groups QA to share a build that is already uploaded.
Other tools:
- GitHub Action
appforshare/appforshare-action@v1takes the same inputs, including groups and testers. - fastlane: the
appforshareaction uploads from gym or gradle output. Actions for testers, groups, UDIDs (likefirebase_app_distribution_get_udids) and the latest build are in fastlane-plugin-appforshare 1.2.0 and later. - Gradle: a plugin,
io.appforshare.upload, withappforshareUpload<Variant>for the APK andappforshareUpload<Variant>Bundlefor the .aab, is coming soon to the Gradle Plugin Portal. Until then the CLI runs from any Gradle job. - Other CI: guides for CircleCI, GitLab, Bitbucket, Jenkins, Azure Pipelines, Xcode Cloud, Codemagic, Bitrise and Expo EAS are on the CI docs page.
Step 5: deal with the SDK, if you use it
If the app includes the App Distribution SDK, decide what replaces each part before you remove it:
- New build alerts. AppForShare's update check (Pro) is a public endpoint your test build can call with a few lines of code, no SDK. Like Firebase's full Android SDK, it belongs in test builds only.
- In-app feedback. Firebase's is Android only. The in-app feedback link (Free) is a URL your app opens from a debug menu or a shake, with version, build and screen, on iOS and Android.
Firebase's Android docs warn that the full SDK includes self-update code that may break Google Play policy even if never run, so removing it from all variants is a good cleanup in any case (collecting feedback).
Step 6: run both for one release
There is no reason to switch on a Friday. Send one release to both: Firebase for the testers who are already set up, the new link for everyone else. When the second release goes out only through the new tool, tell testers in the release notes and leave the last Firebase release in place until it expires.
What you give up
Be honest with your team about this list before you switch:
- Price. Firebase App Distribution is no-cost with 2 GB files. AppForShare Free allows 150 MB files and 7 day links; Pro is $12 a month and Team $39 a month. See pricing.
- Crashlytics per build. Keep Crashlytics in the app; it does not depend on App Distribution. AppForShare can show a link to your crash dashboard on each build page (Pro), but it does not collect crashes.
- The App Testing agent. Firebase's Gemini agent runs tests on Android devices (preview, 200 tests a month at no cost). AppForShare does not run devices. Its AI test plan can be exported as Firebase App Testing agent YAML or a Maestro starter flow (Pro), so you can keep running the agent.
- Device specific APKs from an AAB. Firebase uses Play's internal app sharing. AppForShare turns an .aab into one universal APK and does not need a Play link or a published app.
For a full side by side view, read AppForShare vs Firebase App Distribution or when a link is simpler than Firebase.
Common questions
Do iOS testers have to register their devices again?
No. The devices are in your Apple account and in your profiles already. Import the UDID list so AppForShare knows them, and existing Ad Hoc builds install as before.
Will testers get an email when I import them?
Not unless you choose to notify them on import. That gives you time to explain the change first.
Can I keep Firebase for Android and move iOS only?
Yes. The tools do not depend on each other, and many teams split by platform or by audience during a move.
Does AppForShare integrate with Firebase?
No. It reads files Firebase exports, such as the UDID CSV, and writes test plans in the App Testing agent's YAML format, but there is no connection to your Firebase project.
