IPAFlow / udid / register iphone udid

UDID

How to Register an iPhone UDID and Fix "No Such Phone Registration Entry"

Register an iPhone UDID in the correct Apple Developer team and fix "No Such Phone Registration Entry" by checking the device record, provisioning profile, and delivered IPA.

Updated September 27, 2026

Where did you see “No such phone registration entry with UDID”?

This wording can appear in unrelated products. Identify the product and step before changing an Apple Developer device record.

Viber activation or phone verification

If you saw it while activating Viber, verifying a phone number, reinstalling, or requesting an SMS code, this is not an Apple Developer UDID registration problem. Check the phone number and country code, update Viber, and use its supported activation flow without repeatedly requesting codes. Viber documents activation-attempt limits; if the problem persists, follow Viber’s official activation troubleshooting instead of registering the iPhone in an Apple Developer team.

Apple Developer, Ad Hoc, or IPA installation

If the wording came from Certificates, Identifiers & Profiles, an Apple API response, a provisioning workflow, or an IPA install path, the Apple Developer workflow below applies.

Choose the fix by where the message appeared

Do not use the word UDID alone to choose a solution. Record the app or tool displaying the message and the action immediately before it appeared:

What you were doing	Check first	Do not do this
Activating Viber or requesting a phone verification code	Phone number, country code, supported activation method, and Viber’s official troubleshooting	Register a device in Apple Developer to fix a Viber account error
Registering a tester’s iPhone in Apple Developer	Exact UDID, selected developer team, device status	Repeatedly submit the same identifier without checking the team record
Exporting or installing a Development or Ad Hoc IPA	Device selection in the actual provisioning profile and the profile embedded in the delivered IPA	Assume an already-exported IPA updates after registration

Still unsure which branch applies? Keep the exact error text, the product or screen where it appeared, and the action that triggered it. Avoid posting a full UDID or phone number publicly. If the error is from Viber, use Viber’s activation help; the Apple registration steps below do not apply. If it is from Apple signing or device authorization, continue with the three-minute diagnosis.

3-minute diagnosis

Identify the workflow. Viber activation and phone verification use a phone-number flow; Apple Developer device authorization uses the iPhone’s UDID.
Check the source of the error. Confirm whether it appeared in the Apple Developer portal, an Apple API response, the provisioning profile, or while installing a specific IPA.
Follow the authorization chain. Registering a device is separate from selecting it in the intended profile. Use Add a Device to an Existing Provisioning Profile before rebuilding the IPA.
Verify the replacement artifact. The delivered IPA must contain the refreshed profile; an old export does not change after a device is registered.

If Apple reports “No Such Phone Registration Entry” for a UDID, registering the phone is only the first check. The device must exist in the correct Apple Developer team, be eligible for the intended provisioning profile, and be carried into the exact IPA delivered to the tester.

A common mistake is proving that the UDID was registered, then sending the old IPA again. The new device record does not change an artifact that was already exported.

Registered your UDID but the app still won’t install?

Treat “registered” as the start of the handoff, not the conclusion. Work through this sequence with the exact failing IPA, and stop at the first fact that does not match:

Confirm the device record. Search the intended physical iPhone’s UDID in the Apple Developer team that owns the app’s App ID. A registration in a contractor’s default team or another client team does not authorize this app.
Confirm the profile is the right one. Open the Development or Ad Hoc profile actually used for this build. Check its App ID and certificate, select the now-registered device, then save or regenerate the profile. A device record alone does not update every profile.
Create a replacement IPA. Rebuild from source, or perform an authorized re-sign only with compatible app-owner assets. Updating a .mobileprovision file beside an exported IPA does not change the IPA.
Verify the replacement before delivery. Check that the embedded profile contains the target UDID, that the signature and App ID are compatible, and that the filename or checksum identifies the new artifact rather than the prior download.
Test the installation path. Install that exact replacement on the intended device. If it still fails, preserve the alert text, IPA identifier, install method, iOS version, and result instead of registering the UDID again.

If the device record is present but the embedded profile still omits it, continue with Device Not in Provisioning Profile. If the device is in the profile and the failure is broader than authorization, use Unable to Install App on iPhone to separate signing, expiry, delivery, and device-method checks.

Fix “No Such Phone Registration Entry” first

When the portal, an API response, or an installation workflow reports a missing phone registration entry, check these states in order:

The UDID is correct. Confirm that the value came from the intended physical iPhone and was not confused with a serial number, IMEI, or EID.
The device is in the correct team. Search the Apple Developer device list while signed into the team that owns the app’s App ID.
The device is active and eligible. Check its platform, enabled state, and any processing or eligibility status shown by Apple.
The intended provisioning profile includes it. Registering a device does not automatically change every existing Development or Ad Hoc profile.
The final IPA contains the refreshed profile. A downloaded .mobileprovision file beside the IPA does not modify an already exported app.
The tester receives the replacement artifact. Verify the filename, checksum, and delivery path so the old IPA is not being reused.

Most “I already registered the UDID” incidents fail somewhere between the device record and the delivered artifact. Work down the chain instead of repeatedly registering the same identifier.

The five states are not interchangeable

Track these as separate states:

A. UDID obtained

The identifier was copied from the intended physical iPhone through Finder, Xcode, or an approved consented collection flow. It has been checked for handoff errors, but Apple has not yet confirmed the team record.

B. Device registered in the Apple team

Certificates, Identifiers & Profiles shows the device under the correct team and platform. This consumes team capacity and makes the device eligible for selection when the account is ready.

C. Device selected in the profile

The intended Development or Ad Hoc profile includes that device along with the correct App ID and signing certificate. A different profile or an older revision is not enough.

D. Refreshed profile embedded in the IPA

The packaged app contains the new profile and a compatible signature. A downloaded .mobileprovision file sitting beside the IPA does not change it.

E. Replacement artifact delivered

The client link, filename, and checksum refer to the verified new IPA—not the old build cached under a familiar name.

Before registration

Confirm all of the following:

the tester consented to using this physical device for the named test;
the UDID was obtained from that phone, not from a serial number, IMEI, EID, or another device;
you are signed into the Apple Developer team that owns the app;
you know whether the target is iPhone/iPad or another Apple platform;
the team has capacity for that product family; and
the account performing the manual action has the required role.

Apple’s current portal documentation requires the Account Holder or Admin role to register a single device manually. Do not share the Account Holder’s credentials to work around missing access. Assign an appropriate team role through the supported account workflow.

Use What Is an iPhone UDID? for the identifier’s role, Find an iPhone UDID for retrieval, and Invalid iPhone UDID when the value is rejected.

Manual Certificates, Identifiers & Profiles workflow

Apple’s current steps are:

Sign in to the intended developer team and open Certificates, Identifiers & Profiles.
Select Devices in the sidebar and choose the add action.
Select the platform that matches the physical device.
Enter a useful device name and the exact UDID.
Continue, review the information, and register it.

Use a device name that remains useful months later, such as a consented tester label plus device model or a ticket reference. Do not put unnecessary personal details in the label.

After submission, return to the device list and search for the exact identifier. Confirm the platform, recognizable name, enabled status, and team. A success screen alone is weaker evidence than the resulting device record.

Automatic signing and connected devices

When automatic signing is enabled, Xcode can register or enable the connected device selected as the run destination and update Xcode-managed development profiles. That is convenient for a developer-held device.

It does not mean Xcode silently registers every remote client phone, refreshes an unrelated manually managed Ad Hoc profile, or updates an IPA already exported. Keep the signing model clear: if Xcode owns the profile, refresh through that workflow; if the team manages a manual Ad Hoc profile, edit that specific profile deliberately.

Device already registered

If the portal says the device already exists, do not create a near-duplicate label or change the identifier. Search the team device list for the exact UDID and verify its platform and enabled state.

Then continue at State C: confirm whether the intended profile selects that existing record. “Already registered” often means only that the device has been used for another app or profile in the same team.

If you cannot find it, confirm that the team selector has not changed. Device records are team-scoped operational state; a record in a contractor’s or client’s other team does not authorize an app owned here.

Wrong team

A valid UDID registered under Team A does not authorize an IPA signed and provisioned under Team B. Switch to the team that owns the App ID and repeat the checks there, subject to role and capacity.

Do not solve a wrong-team mistake with pooled certificates, shared Apple Accounts, Enterprise credentials, or someone else’s provisioning assets.

Capacity and membership-year behavior

Apple currently documents a limit of up to 100 registered devices per product family per membership year for program teams. Disabling a device during the year does not restore that slot.

At the start of a new membership year, eligible roles are offered a device-list reset flow in Certificates, Identifiers & Profiles. Review the existing list before adding new devices; do not promise that deleting or disabling a record today creates immediate capacity.

Disabling a device also invalidates provisioning profiles that contain it. Treat disable/enable as a signing-impacting account change, not housekeeping.

The Apple Developer Device Limits page owns capacity planning details.

Processing and eligibility states

Apple documents temporary processing for new Apple Developer Program memberships and memberships renewed after an expiration of one month or more. During that state, a device can be registered but not yet eligible for inclusion in provisioning profiles.

For affected memberships, Apple’s current reference lists 1–10 devices as available upon registration and 11–100 as potentially taking 24–72 hours. It also documents a possible ineligible state for identifiers previously associated with memberships terminated for license violations.

Do not generalize those windows to every team or promise an exact completion time. Preserve the displayed portal or API status and wait for eligibility when Apple reports processing. Repeated duplicate submissions do not accelerate it.

Refresh the relevant profile

Once the device is enabled and eligible, open the exact Development or Ad Hoc profile used by the app. Verify its App ID and certificate, select the new device, save or regenerate it, and download the result where the manual workflow requires it.

Follow Add a Device to an Existing Provisioning Profile for the focused profile workflow. If the profile is Xcode-managed and absent from the portal, use Xcode’s signing workflow rather than creating a second profile with an ambiguous name.

Produce and inspect the replacement IPA

Create a new archive/export with the refreshed profile. If source is unavailable, only consider an authorized re-sign when the app owner controls compatible signing assets and entitlements.

Inspect the profile inside the final packaged file:

unzip -q ClientBuild.ipa -d ClientBuild-unpacked
APP_PATH=$(find ClientBuild-unpacked/Payload -maxdepth 1 -name '*.app' -print -quit)
security cms -D -i "$APP_PATH/embedded.mobileprovision" > /tmp/client-profile.plist
plutil -extract ProvisionedDevices xml1 -o - /tmp/client-profile.plist

Confirm the target UDID is present, the application identifier matches, and the profile is current. Then record the IPA checksum, deliver that exact replacement, and test it through the intended install path.

If the device exists in the portal but not in the packaged profile, use Device Not in Provisioning Profile.

Verification checklist

Identifier: exact physical-device UDID, with consent and a meaningful label.
Team: the App ID owner, not simply the developer’s default team.
Record: correct platform, enabled, and eligible rather than processing.
Profile: correct App ID/certificate and device selected.
Artifact: refreshed profile embedded and signature compatible.
Delivery: replacement filename/checksum behind the tester’s link.
Acceptance: exact artifact installs on the intended device.

Authorized automation can list team devices through Apple’s API, but this page owns the manual workflow. For automation, continue to Automatic UDID Registration or Fastlane Register Device.

When this entire chain repeats for every client, Client Device Onboarding explains the operational design. IPAFlow is in Private Beta for that authorized workflow; it does not collect Apple credentials from testers or bypass device limits.

Related next steps

Next step. Verify every state through the replacement artifact; use IPAFlow Private Beta only when repeated client-device onboarding is the operational problem. Join Early Access.