AppForShare

Register devices for Ad Hoc builds: the full workflow

· 8 min read

Register devices for Ad Hoc builds: the full workflow

Ad Hoc distribution is still the most direct way to put an unreleased iPhone build in front of testers: no review, no extra app, just a link. The catch is the device list. Every iPhone or iPad that installs an Ad Hoc build has to be registered with your Apple Developer account and included in the provisioning profile the build was signed with. With three testers that is a small chore. With thirty testers across a client, a QA vendor and your own team, it becomes the step that delays every release.

This guide is the full workflow, start to finish: collect UDIDs, register them, regenerate the profile, export a new build, and confirm the devices are really in it before you send the link.

The workflow at a glance

  1. Collect each tester's UDID and device name.
  2. Register the devices in Certificates, Identifiers and Profiles.
  3. Edit the Ad Hoc provisioning profile so it includes the new devices, then download it.
  4. Export the build again with the new profile.
  5. Check the device list inside the .ipa, then share the install link.

Each step has one common mistake. The sections below cover them in order.

Step 1: collect UDIDs without a support thread

The UDID is not shown in the iPhone Settings app, which is why asking testers to "send me your UDID" usually turns into a back and forth. The faster route is a page that reads it for them. The free AppForShare UDID finder works in Safari with no account: the tester installs a signed configuration profile, iOS returns the UDID along with the model, iOS version and device name, and the tester can email the result to you or save it to an AppForShare account. Lookups are deleted after one day. Step by step screenshots for testers are in how to find the UDID on iPhone.

A few habits make the next steps easier:

  • Ask for a device name you can recognise later, for example Sara QA iPhone 15 rather than iPhone. You will need it when you clean up the list next year.
  • Collect everything in one shared sheet with columns for UDID, name, owner and date added. This sheet becomes your upload file in step 2.
  • Batch new devices. Each batch means a new profile and a new export, so collecting UDIDs for a few days and registering them together saves rebuilds.

Mac computers with Apple silicon are a special case: Apple asks for the provisioning UDID when you register one for development, which is not the same value as the hardware UUID some tools show.

Step 2: register the devices

Registering devices needs the Account Holder or Admin role. In Certificates, Identifiers and Profiles, open Devices and click the add button. You can register one device at a time (platform, name, UDID) or upload a file with many devices at once.

For bulk registration, Apple accepts a tab delimited .txt file with three columns in this order: device ID, device name, platform. A header row is optional. Apple Configurator can also export a .deviceids file from connected devices.

Device ID	Device Name	Platform
00008110-000A1B2C3D4E5F6A	Sara QA iPhone 15	iOS
00008103-001122AABBCCDD33	Client iPad Air	iOS

Save the sheet from step 1 as tab separated text and you have this file. If the upload rejects a row, the usual cause is a UDID with a stray space, a missing character, or a value that was copied from a different field such as the serial number.

The device limit and how it resets

This is where teams with many testers get stuck. Apple Developer Program and Enterprise Program members can register up to 100 devices per product family per membership year. The families are iPhone, iPad, iPod touch, Mac, Apple Watch, Apple TV and Apple Vision Pro, so 100 iPhones and 100 iPads are separate allowances.

  • Disabling a device does not give the slot back. A device you disable during the year still counts.
  • Slots come back only at the start of a new membership year. The first time an Account Holder, Admin or App Manager signs in to Certificates, Identifiers and Profiles in the new year, Apple offers to remove devices. You can remove specific devices, remove all of them to restore the full 100 per family, or keep the list as it is.
  • Remove before you add. Apple's advice is to clear devices you no longer use during that reset, before registering new ones.

In practice: keep the yearly reset on your calendar, review the sheet from step 1 before it, and remove devices of people who left the project. If you run out of iPhone slots mid year, the options are to wait for the reset, use a separate team for a separate client, or move that group of testers to TestFlight, which does not need UDIDs. The tradeoffs are covered in Ad Hoc distribution challenges.

Step 3: regenerate the provisioning profile

Registering a device does not add it to existing profiles. A profile is a signed file that lists the allowed devices at the moment it was generated. To include new devices:

  1. Open Profiles, select your Ad Hoc profile and click Edit.
  2. Tick the new devices (or select all) and save. Apple generates a new version of the profile.
  3. Download it and double click it, or let Xcode download it under Settings, Accounts, Download Manual Profiles.

With automatic signing, Xcode registers devices that are connected to the Mac and updates its managed profiles for you, but it cannot see a tester's phone in another city. For remote testers, manual registration plus a profile refresh is the normal path. If you sign in CI with Fastlane match or a similar tool, run its profile refresh after adding devices so CI picks up the new profile instead of a cached copy.

Step 4: export the build again

An .ipa carries the profile it was signed with. The old build does not learn about new devices, so you need a new export. You do not always need a new compile:

  • From Xcode: open the existing archive in the Organizer, choose Distribute App, then Release Testing (the current name for Ad Hoc), and pick the updated profile if you sign manually.
  • From the command line or CI: run xcodebuild -exportArchive with an export options plist whose method is release-testing (older Xcode versions used ad-hoc).
xcodebuild -exportArchive \
  -archivePath build/MyApp.xcarchive \
  -exportOptionsPlist ExportOptions.plist \
  -exportPath build/adhoc

AppForShare does not re-sign builds, so this export has to happen on your side before upload. If the build should go out automatically, the upload step for your pipeline is on the CI docs page.

Step 5: verify the devices before you share

This is the step most teams skip, and it is the cheapest one. A build exported with the old profile looks identical to one exported with the new profile until a tester taps Install and gets "Unable to Install".

Drop the .ipa into the IPA inspector. It reads the file in your browser, so the build is not uploaded, and shows:

  • the distribution type (it should say Ad Hoc),
  • the profile name, team, creation date and expiry with days left,
  • the number of provisioned devices and the full UDID list, with search and copy all.

Search for the UDIDs you just added. If one is missing, the export used a stale profile; go back to step 3 or 4. If you upload builds to an AppForShare account, the "what changed" view also compares provisioned devices with the previous build of the same app, so a device that silently dropped out is easy to spot.

Common failures and what they mean

SymptomLikely causeFix
Tester sees "Unable to Install" right after tapping InstallUDID not in the profile inside this buildCheck the UDID list in the IPA inspector, regenerate the profile, export again
Portal refuses to add more iPhones100 device limit for the family reached this membership yearWait for the yearly reset, use another team, or move that group to TestFlight
New device registered but still cannot installProfile was not edited after registration, or CI used a cached profileEdit and save the profile, refresh profiles in Xcode or CI
App installs but will not openDeveloper Mode is off (iOS 16 and later) or the profile expiredSee enable Developer Mode; check expiry in the inspector

For signing problems beyond the device list, see iOS code signing errors that block test installs.

Sharing the build once the devices are in

Once the inspector shows the right devices, upload the .ipa to AppForShare and send the link or QR code. Testers open it in Safari on the registered device and install over the air. The Free plan is enough to start, with password protected links that last 7 days. Pro at $12 a month keeps links live while subscribed and adds CI uploads and release notes, and Team at $39 a month adds private projects that only invited testers can open, with an email to testers on every new build. Plan details are on the pricing page, and you can create a free account to keep each tester's UDID lookup in one place.

Keep reading

App Distribution Platform · · 9 min read

AppForShare.io vs Competitors - A Comparative Analysis

For small teams and startups, selecting a mobile app testing platform is a critical crossroad. This choice is more than a mere selection: it’s a strategic decision that directly impacts the...