How to Find an iPhone UDID in Finder or Xcode

Find the correct iPhone UDID from a physical device using Finder or Xcode, avoid identifier mix-ups, and hand it off without copy damage.

Updated August 15, 2026

The safest supported ways to find an iPhone UDID are Finder or Xcode on a trusted Mac connected to the physical phone. In Finder, rotate the information label until it explicitly shows UDID, then copy that value. In Xcode, copy the Identifier shown for the connected device in Window → Devices and Simulators.

Finding the identifier proves only what the connected Mac displayed for that physical device. It does not prove that the device is registered in the intended Apple Developer team, included in a provisioning profile, or authorized by the IPA already sent to a tester.

Finder: the clearest path for a tester

Apple’s current registered-device documentation supports Finder for iPhone and iPad device-ID collection. The tester does not need Xcode.

Connect the physical iPhone to a trusted Mac with a data-capable cable.
Unlock the iPhone. If either device presents a trust prompt, review it and approve only when the Mac is trusted.
Open Finder and select the iPhone under Locations in the sidebar.
In the device information pane, click the label below the device name. Finder cycles through several pieces of information.
Continue until Finder labels the value UDID. Do not stop at Serial Number, IMEI, MEID, model, or storage.
Control-click the label and choose Copy UDID or the available copy action.
Paste the value into a plain-text field once, compare its beginning and end with Finder, and attach it to the correct tester and device label.

Apple’s UI can show several identifiers in the same location. The safe check is the label shown by Finder, not a remembered length or the fact that the value looks technical.

What this proves

The copied value came from the phone that was physically connected at that moment.
Finder identified the copied field as the device UDID.
The tester can provide the value without installing Xcode.

What this does not prove

The tester connected the phone they intend to use later unless the handoff records that relationship.
The value arrived unchanged after it was pasted into chat, email, a spreadsheet, or a ticket.
The correct Apple Developer team has registered or enabled the device.
A Development or Ad Hoc profile includes it.
An already exported IPA contains a refreshed profile.

Xcode: the developer-held device path

For a developer who has the device and Xcode:

Connect and unlock the iPhone, then handle the trust prompt if one appears.
In Xcode, choose Window → Devices and Simulators.
Select the Devices tab.
Select the physical iPhone under the connected devices list.
Copy the value labeled Identifier.
Record which physical phone, developer team, and test request the identifier belongs to.

Apple documents automatic registration as a separate action in the signing workflow. When automatic signing is enabled, selecting a connected device as a run destination and building may prompt Xcode to register it and update an Xcode-managed profile. Merely seeing the Identifier field does not establish that any of those later actions happened.

Keep these facts separate:

Xcode can display the Identifier
  != device registered in the intended team
  != device selected in the intended profile
  != refreshed profile embedded in the delivered IPA

An iPhone can also be registered in Team A while the app belongs to Team B. The same accurate UDID does not bridge that team boundary.

Do not submit the wrong identifier

The Apple Developer device form asks for the physical device’s UDID. These other values have different purposes:

Serial number: hardware support and inventory identity. It is not the registered-device UDID.
IMEI or MEID: cellular equipment identity. Finder may display it near the UDID, but it is not interchangeable.
EID: identifies eSIM-related hardware, not the Apple Developer device record used here.
Phone number: identifies a line or account relationship, not a physical-device registration value.
Advertising identifier: an app-accessible advertising value subject to Apple’s tracking rules. It is not a provisioning identifier.
APNs device token: scoped to an app-device-environment relationship for push notifications. It is not a developer-account UDID.
A value from a previous or replacement phone: describes a different physical device even when the same tester, phone number, or iCloud account is involved.

Some Apple platforms and historical device generations present device IDs differently. Do not invent one universal fixed-length rule and do not transform a value merely to make it resemble an example.

Prevent copy and transport damage

Most handoff failures do not require guessing a replacement character. They require comparing the submitted value with the physical-device source.

Common damage includes:

retyping the UDID instead of copying it;
leading or trailing whitespace;
an invisible line break introduced by a form or message;
spreadsheet auto-formatting or formula interpretation;
chat or ticket systems truncating a long value;
copied punctuation surrounding the value;
a tester switching to a replacement phone after the value was collected; or
a developer reading the identifier from a different connected phone.

Preserve the originally submitted value before cleaning presentation whitespace. Never replace uncertain characters, add separators, or remove meaningful characters based on a guessed pattern. If the value and physical-device source disagree, copy it again from Finder or Xcode.

The browser-local UDID Validator can flag plausible formatting issues without uploading the value. It cannot prove device ownership, consent, Apple eligibility, team registration, or the identity of the physical phone. Use Invalid iPhone UDID when a portal or workflow rejects the value.

Use a verifiable handoff

A useful client or tester handoff preserves the evidence chain:

physical iPhone
  → obtain the identifier in Finder or Xcode
  → label the tester and current device
  → perform a basic local format/transport check
  → obtain consent and send through the approved channel
  → register in the correct Apple Developer team

At minimum, record a consented tester label, current device description, collection method, collection date, intended app/project, and exact copied value. Avoid putting persistent identifiers in public issue trackers or broad chat rooms.

For repeated client intake, Client Device Onboarding owns the consent, labeling, team handoff, profile refresh, and replacement-artifact process. This page owns only computer-based retrieval from the physical device.

What happens after you find the UDID

Finding the UDID is the first evidence step, not installation authorization:

Validate the handoff without guessing characters.
Follow How to Register an iPhone UDID in the team that owns the app.
Add the enabled device to the intended Development or Ad Hoc profile.
Export or authorizedly re-sign a replacement IPA with the refreshed profile.
Verify the exact delivered artifact on the intended phone.

If the tester has no Mac, use Find an iPhone UDID Without a Computer to understand the remote-collection support and privacy boundaries. Do not substitute a serial number from Settings or use an unknown website that claims a QR code can silently reveal the UDID.

Related next steps

Next step. Copy the UDID from Finder or Xcode, validate the handoff locally, and give it only to the authorized team managing the test build. Join Early Access.