UDID
What Is an iPhone UDID?
Understand the physical-device identifier Apple uses for registered-device testing, when developers need it, and what happens after collection.
An iPhone UDID is the device identifier Apple uses to represent a physical Apple device registered to a developer team for testing. In Apple’s device resource, the record is identified by its UDID and device type. For Development or Ad Hoc distribution, that record can be selected in a provisioning profile that authorizes a signed app to run on the device.
A UDID is not an install code and not proof that someone owns the phone. It is one input in a longer authorization chain.
Where the UDID fits
For registered-device delivery, the relationship is:
physical Apple device
→ UDID obtained from that device
→ device record in the correct Apple Developer team
→ device selected in a Development or Ad Hoc profile
→ profile embedded in a correctly signed IPA
→ iOS evaluates that authorization during installation and launchRegistration links the device to one developer team’s testing inventory. The provisioning profile then joins that team, app identity, signing certificates, allowed capabilities, validity period, and—where applicable—the selected devices. The IPA must contain the refreshed profile and a compatible signature.
This is why sending a UDID does not instantly make an old IPA installable. The build produced before registration still contains its earlier authorization state.
Why a developer asks for it
A developer or agency normally requests an iPhone UDID when all of these are true:
- the app is being tested outside the public App Store;
- the chosen method uses Development or Ad Hoc registered-device distribution;
- the physical iPhone is not already authorized by the embedded profile; and
- the team can lawfully register and provision that device for the app owner.
Apple’s current registered-device workflow requires test devices to be registered before a Development or Ad Hoc profile is created. Testers do not need to become Apple Developer team members, but their devices consume the team’s registered-device capacity.
When a UDID is not the onboarding input
TestFlight uses App Store Connect tester invitations and the TestFlight app; developers do not normally collect tester UDIDs for that workflow. Public App Store installs also do not use a developer-managed device list.
Custom Apps, managed apps, proprietary in-house apps, and other organizational distribution paths have their own eligibility and device-management models. Do not assume a UDID collected for Ad Hoc testing is required—or sufficient—for those routes.
If someone only needs to send push notifications, attribute advertising, or identify an app installation to its vendor, the relevant identifier comes from a different API. None of those values should be entered into Apple’s registered-device form as a UDID.
UDID versus other identifiers
Several identifiers can appear on or around an iPhone, but they describe different relationships:
- Serial number: identifies Apple hardware for support, inventory, and service contexts. It is not the UDID field Apple asks for when registering a test device.
- IMEI or EID: relates to cellular hardware or eSIM identity. Apple Support displays these separately from the serial number; neither substitutes for a developer-registration UDID.
- Advertising identifier: Apple documents this for advertising purposes and subjects access to tracking authorization. It is not a provisioning identifier.
- Identifier for vendor: an app-accessible value scoped to apps from the same vendor on one device. Apple documents conditions under which it can change. It is not the developer account’s physical-device record.
- APNs device token: identifies one app on one device to Apple Push Notification service. Each app receives its own token, and Apple tells developers not to treat tokens as permanent.
Apple also exposes other application- or account-scoped identifiers for specific services. A value called “device ID” in analytics, push, mobile networking, or an app database is not automatically a UDID.
Can a website read an iPhone UDID?
An ordinary webpage does not receive the Apple Developer registration UDID through normal JavaScript browser APIs. A page that claims it can silently read the value should be treated skeptically.
Computer-based collection through Finder or Xcode is the clearest supported path. Some remote onboarding services use an explicit configuration-profile or device-enrollment flow that asks for consent and sends selected device attributes to a server. That is a managed server workflow, not passive browser fingerprinting. See Find an iPhone UDID Without a Computer for its privacy and support boundaries.
Do not reduce UDIDs to one guessed format rule
Apple’s current registration workflow is authoritative about whether a device ID is accepted for the selected platform. Avoid promises that every current and historical Apple device identifier has one fixed presentation or length.
A local format check can catch separators, whitespace, non-hexadecimal characters, or obvious truncation. It cannot prove that the value came from the intended phone, belongs to a consenting tester, or is eligible in the selected team. Use Invalid iPhone UDID for rejected values and the browser-local UDID Validator only as a first-pass check.
The safe UDID lifecycle
- Obtain the identifier from the physical device. Use Finder or Xcode, or an approved consented remote workflow. Find an iPhone UDID covers the supported computer paths.
- Validate the handoff. Confirm the value is complete and attached to the expected tester and current phone.
- Explain and capture consent. State which app/team needs it, why, and how long it will be retained.
- Register it in the correct team. The team that owns the app must create or use the device record.
- Refresh the intended profile. Select the registered device in the correct Development or Ad Hoc profile.
- Produce a replacement artifact. Export a new build or perform an authorized re-sign with compatible app-owner assets.
- Verify the final IPA and installation. Inspect the embedded profile and test the exact delivered artifact on an eligible device.
The iPhone UDID registration guide owns the manual account workflow. If registration is correct but the IPA still omits the device, use Device Not in Provisioning Profile.
Privacy, retention, and consent
A UDID is a persistent device identifier, so handle it as controlled operational data even though it is not a password. Collect it only for a stated testing purpose, restrict access to the people managing that release, avoid public tickets and chat logs, and set a retention/deletion policy.
The tester should know which organization receives the value and what happens next. A submitted UDID does not justify collecting an Apple Account password, device passcode, signing certificate, P8 key, P12 file, or IPA from the tester.
For repeated client onboarding, Client Device Onboarding explains the operational system around consent, registration, profile refresh, artifact replacement, and delivery. This reference page defines the identifier; it does not replace those workflow controls.