Development and Ad Hoc provisioning profiles embed an explicit list of device UDIDs. iOS checks the device it is running on against that list and refuses to launch if it is absent. App Store and TestFlight profiles have no device list at all, which is why this error only ever appears for local and Ad Hoc installs.
The important detail, and the one that costs people an afternoon, is that the list is a snapshot. Adding a device to your team in the portal does nothing to profiles that already exist. Every profile that should include the new device has to be generated again after the registration.
Get the UDID
The error message usually contains it, which saves a step. If you need it independently, Xcode's Devices and Simulators window shows it as Identifier, and xctrace lists connected hardware from the terminal.
# Connected devices and their identifiers xcrun xctrace list devices # What the profile currently allows security cms -D -i ~/Downloads/MyApp_Development.mobileprovision > /tmp/p.plist /usr/libexec/PlistBuddy -c 'Print :ProvisionedDevices' /tmp/p.plist
If PlistBuddy reports that the key does not exist, the profile has no device list, which means it is an App Store profile. Using one of those for a device build is a different mistake with the same symptom, and the fix is to pick the right profile rather than to register anything.
The fix with automatic signing
With automatic signing on, Xcode offers a Register Device button right in the error. Clicking it registers the UDID and regenerates the team profile in one go, and is genuinely the fastest route when it works. It needs an account with permission to register devices, so on a team account a Developer-role user may find the button does nothing useful.
- 1
Click Register Device, or toggle automatic signing
If the button is absent, untick Automatically manage signing in Signing and Capabilities, then tick it again. That forces Xcode to re-resolve against the current device list.
- 2
Check the device is trusted and unlocked
A device that has not accepted the Trust This Computer prompt, or is locked, sometimes reports its identifier oddly and produces confusing variants of this error. Unlock it and reconnect before assuming a provisioning problem.
The fix with manual signing
- 1
Register the UDID in the portal
Certificates, Identifiers and Profiles, Devices, then the plus button. Pick the right platform, paste the UDID, and give it a name you will recognise in a year.
- 2
Edit each profile that needs the device
Profiles, select the Development or Ad Hoc profile, Edit, and tick the new device. Save and download. Apple issues a new file rather than updating the existing one.
- 3
Remove the old profile locally, install the new one
Same name, different content, so a stale cached copy will keep being used. Delete before you install.
- 4
Clean the build folder and rebuild
The previously embedded profile lives in derived data. Shift-Command-K in Xcode, or delete the build directory on CI.
# Xcode 16 and later PROFILES=~/Library/Developer/Xcode/UserData/Provisioning\ Profiles # Xcode 15 and earlier # PROFILES=~/Library/MobileDevice/Provisioning\ Profiles rm -f "$PROFILES"/*.mobileprovision cp ~/Downloads/MyApp_Development.mobileprovision "$PROFILES/"
With fastlane match, registering the device is only half of it: the profiles in the repo are still the old ones. Run match with --force_for_new_devices from a machine that has portal permissions, then commit, so the readonly CI runs pick up regenerated profiles.
fastlane match development --force_for_new_devices
Why registration itself might fail
- You are at the 100-device limit for that device class. iPhones, iPads, Macs, Apple Watches, Apple TVs and Vision Pros are counted separately, 100 each per membership year.
- The device is registered but disabled. Disabled devices still occupy a slot and are excluded from new profiles.
- You pasted a serial number rather than a UDID. They look similar enough to try, and the portal rejects it.
- Your role cannot register devices. Ask an Admin or the Account Holder.
- A free Apple ID is in use, which registers devices automatically but issues profiles that expire after seven days.
If you are hitting the cap because of a wide beta, that is a signal to move the testers to TestFlight rather than to keep fighting Ad Hoc. TestFlight testers do not consume device slots at all.