Firebase App Distribution on iPhone: device registered but cannot install
· 8 min read
The most common Firebase App Distribution question from iPhone testers goes like this: "I registered my device, the developer says they added it, and I still cannot install the app." The tester sees a friendly message, waits, and nothing happens. Or the build installs and then refuses to open.
Almost every case comes down to one fact from Apple: an Ad Hoc build installs only on devices whose UDID is inside the provisioning profile the build was signed with. Firebase helps collect the UDID, but the developer still has to add it to the Apple account, update the profile, build again and upload again. If any of those steps is missed, the device cannot install. This guide walks through the flow, a checklist of causes with fixes, and how to check a build before sending it. Firebase facts come from the Firebase documentation as read on November 2, 2026.
How the iOS flow works in Firebase App Distribution
- The tester opens the invitation email in Safari and signs in with Google. Firebase says the email must be opened in Safari "to properly install the Firebase profile and register your device" (tester setup).
- The tester installs the Firebase profile. It collects the device UDID and adds the App Distribution web clip to the home screen ("What is the Firebase profile?").
- Firebase emails the developer the UDID. By default every project member with the
firebase.projects.updatepermission gets that email (register additional devices). - The developer adds the device in the Apple Developer portal, either from the email or by exporting all UDIDs as a CSV (Testers and Groups tab, All testers, Export Apple UDIDs) and importing it with Register Multiple Devices.
- The developer adds the device to the provisioning profile, downloads the profile and rebuilds the app.
- The developer uploads the new build. Firebase emails the tester when a build that runs on their device is available.
Steps 4 to 6 are manual unless you automate them. Most "still cannot install" reports mean one of them did not happen, or happened in a way that did not reach the tester.
"Device registered, you're all set!"
This message confuses testers because it sounds finished. Firebase explains that for Ad Hoc builds it "appears when the developer hasn't yet configured their app to run on your test device." In other words, Firebase has the UDID, but no build includes it yet. The tester has nothing more to do. The developer has to complete steps 4 to 6.
Checklist: why a registered iPhone still cannot install
| Symptom | Likely cause | Fix |
|---|---|---|
| Tester never got a "ready to test" email | Device is in the Apple portal but the profile was not updated | Edit the Ad Hoc profile, tick the new device, save, download it and rebuild |
| Profile updated, still nothing | The app was not rebuilt, or was rebuilt with the old profile still cached | Rebuild and export with the new profile; check the UDID is in the built .ipa (see below) |
| Build uploaded, other testers not notified | Same version and build number as an earlier upload | Expected: Firebase only emails newly registered devices in that case |
| Install starts, then "Unable to install" | UDID missing from this particular build, or the profile or certificate expired | Inspect the build's embedded profile; renew the profile or certificate if expired |
| Profile never installed on the phone | Invitation opened in another mail app or browser | Open the invitation in Safari and install the profile again |
| Works on the tester's iPhone, not their iPad | Only one device was registered | Register each device separately; each has its own UDID |
| App installs but will not open: "Developer Mode Required" | Ad Hoc app on iOS 16 or later without Developer Mode | Settings, Privacy and Security, Developer Mode, turn on, restart, then tap Turn On |
| App will not open: "Untrusted Enterprise Developer" | Enterprise build, developer not trusted yet | Settings, Profiles and Device Management, select the developer, trust it |
| Apple refuses to add the device | The yearly device limit for that device type is used up | Remove unused devices at renewal, or use TestFlight for that tester |
The two error fixes come from Firebase's troubleshooting page. Apple allows 100 devices per device type (iPhone, iPad and so on) per membership year, and disabled devices keep their slot until the membership renews. Firebase's own docs warn that "your Apple developer account may only allow you to import a limited number of devices per year."
The build number trap
Firebase gives specific advice here. If you rebuild only to add devices, do not change the build number or version. Then: "If you don't change your version, build number, or your app's code, App Distribution does not create a new release and won't notify testers. If you already distributed a build with the same build number and version, only users of newly-registered devices receive notification emails." That is the intended behavior: existing testers already have a working build and are not bothered. It surprises teams who expect everyone to see the upload.
Xcode automatic signing
With automatic signing, Xcode manages its own profiles. A device added in the portal may not be in the profile Xcode used for the export, especially on a CI machine that cached an older one. If testers report missing devices after you added them, look at the profile embedded in the build rather than the one in the portal.
Check the UDIDs inside a build before you send it
This one check catches most of the cases above. The provisioning profile is inside the app bundle as embedded.mobileprovision. On a Mac:
unzip -q MyApp.ipa -d /tmp/myapp
security cms -D -i /tmp/myapp/Payload/MyApp.app/embedded.mobileprovision | grep -A200 ProvisionedDevicesIf the tester's UDID is not in the list, the build will not install on their phone, whatever the console says. Without a Mac, the free IPA inspector reads the file in your browser (nothing is uploaded) and shows the distribution type, the profile expiry with days left and the full UDID list, with search.
Getting UDIDs out of Firebase
- Console: Testers and Groups tab, All testers, Export Apple UDIDs. The CSV goes straight into Apple's Register Multiple Devices.
- fastlane: the
firebase_app_distribution_get_udidsaction writes the same list to a file in a lane. - Email: each registration email contains the UDID if you prefer one at a time.
Firebase also describes a way to automate the rest: write a Cloud Function that catches the new device alert, adds the UDID to the profile, rebuilds and redistributes. That needs the Blaze plan and your own code (register additional devices).
Tester side: what to ask for when it fails
Ask the tester for three things: the exact message on screen, the device model and iOS version, and the UDID. The free UDID finder gives them the UDID in a few taps without a Mac or a cable. With the UDID you can check the build's list directly instead of guessing.
How AppForShare handles the same steps
Apple's rules apply to every tool outside TestFlight, so AppForShare cannot remove the registration step either. What it does is cut the manual work between "the tester sent a UDID" and "the tester has a build":
- UDID finder (free, no account) and an onboarding link per iOS project (Pro and Team), where testers enter an email and install the UDID profile. No Google account.
- Import the Firebase file (Free). The Devices page takes Firebase's Export Apple UDIDs CSV, Apple's bulk file or one UDID per line. With an API token,
appforshare devices import <file>does the same from a script. - Register on Apple in one step (Pro and Team, with an App Store Connect connection). An Admin registers saved UDIDs, up to 20 at a time, sees used and remaining slots per device type, and remakes the Ad Hoc profile with every enabled device. See iOS device registration.
- Hands free device setup (Team, opt in by an Admin per project). When testers enroll through the onboarding link, AppForShare registers the devices on the Apple account, remakes the Ad Hoc profile where it manages it, and starts the project's iOS build on GitHub Actions if you set one up. Up to 10 devices a run and 20 a day. When the new build is uploaded, each tester gets one email with the install link.
- Every account upload is checked. The store readiness check flags a profile that is about to expire, and "what changed" compares the provisioned devices with the previous build of the app.
AppForShare does not re-sign builds: you or your CI still build the app. For the full Apple side, read registering devices for Ad Hoc builds. For the wider comparison, see AppForShare vs Firebase App Distribution.
Common questions
How long after registering can a tester install?
As long as it takes the developer to add the device, update the profile, rebuild and upload. Firebase emails the tester when that build is available. There is no automatic step in between unless you build one.
Do I need to bump the build number after adding devices?
Firebase recommends not changing it when you rebuild only for new devices. Newly registered devices are notified; testers who already have the build are not.
Does the Firebase profile install the app?
No. It registers the device and adds the web clip. The app comes later, from a build that includes the UDID.
Can I skip UDIDs entirely?
Only with TestFlight, which needs App Store Connect and beta review for external testers, or with an Apple Enterprise account for internal staff. Ad Hoc and Development builds always need the UDID.
