IPAFlow / udid / register iphone udid

UDID

How to Register an iPhone UDID

Register an iPhone in the correct Apple Developer team, verify its state, refresh the profile, and deliver a replacement authorized IPA.

Updated August 15, 2026

Registering the device is not the end of the Ad Hoc delivery process. It creates or enables a device record in one Apple Developer team. The device must then be selected in the relevant provisioning profile, that refreshed profile must be embedded in a newly exported or authorizedly re-signed IPA, and the exact replacement artifact must be delivered and tested.

If you send the old IPA again, the new registration has no effect on that file.

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.

Most “I already registered the UDID” incidents fail between B and E.

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.