The important thing about this message is where it comes from. The build finished. codesign was happy. The app was copied onto the device, and the device opened the provisioning profile embedded inside it and decided it was not entitled to run this executable. That narrows the search considerably, because everything on the Mac side has already passed.
The profile lives inside the bundle as embedded.mobileprovision. Whatever it said at build time is what the device is reading now, so it is the first and usually only thing worth inspecting.
Read the profile the device is reading
APP=build/MyApp.app security cms -D -i "$APP/embedded.mobileprovision" > /tmp/p.plist /usr/libexec/PlistBuddy -c 'Print :Name' /tmp/p.plist /usr/libexec/PlistBuddy -c 'Print :ExpirationDate' /tmp/p.plist /usr/libexec/PlistBuddy -c 'Print :Entitlements:application-identifier' /tmp/p.plist /usr/libexec/PlistBuddy -c 'Print :Entitlements:get-task-allow' /tmp/p.plist /usr/libexec/PlistBuddy -c 'Print :ProvisionedDevices' /tmp/p.plist 2>/dev/null \ || echo "no device list (App Store or In-House profile)"
That last line is the quickest diagnostic in the whole page. A profile with no ProvisionedDevices array is either an App Store profile or an In-House enterprise one, and those two behave very differently when you try to put the build on a device by hand.
The four things it usually is
- The device is not in the list
- Development and Ad Hoc profiles carry an explicit device list. A phone bought last week, a colleague's iPad, or a replacement device after a repair will not be in a profile generated before it existed.
- The profile has expired
- Profiles carry an expiry independent of the certificate inside them. A profile from a free personal team expires after seven days, which is why a sideloaded build stops working roughly a week after it was installed.
- It is an App Store profile
- App Store profiles have no device list and are not installable by hand. They are for builds that go through App Store Connect. If you want to install directly, you need Development or Ad Hoc.
- The entitlements do not match
- The app requests a capability the profile does not grant, or get-task-allow disagrees with how the build was made. A Debug build carries get-task-allow true and needs a Development profile; an Ad Hoc profile expects it false.
The device list case has its own page, because at build time it surfaces differently: see the device is not registered in the provisioning profile. The difference is timing. Caught during the build you get a named device and a clear message. Caught at install you get this, which tells you nothing about which condition failed.
Fixing it
- 1
Confirm the device UDID
Read it from the device in Xcode's Devices and Simulators window, or from Finder with the device connected. Typing it from memory or from an old spreadsheet is how a wrong UDID gets registered and burns a slot.
- 2
Register the device, then regenerate the profile
Both steps, in that order. The regeneration is the one people skip. A regenerated profile gets a new UUID, so anything pinning the old UUID needs updating too.
- 3
Install the new profile and rebuild
The profile has to be present on the build machine and the build has to pick it up. Clean the build folder first, because derived data holds a copy of the old embedded profile.
- 4
Delete the old app from the device
An existing install signed with a different identity can block the new one. Removing it costs nothing and rules out a whole category of confusing follow-up errors.
# Which profiles on this machine cover the device you care about?
UDID=00008030-000123456789ABCD
PROFILES=~/Library/Developer/Xcode/UserData/Provisioning\ Profiles
for f in "$PROFILES"/*.mobileprovision; do
security cms -D -i "$f" > /tmp/p.plist 2>/dev/null || continue
if /usr/libexec/PlistBuddy -c 'Print :ProvisionedDevices' /tmp/p.plist 2>/dev/null | grep -q "$UDID"; then
/usr/libexec/PlistBuddy -c 'Print :Name' /tmp/p.plist
fi
donePicking the right profile type
- Installing from Xcode onto your own hardware: a Development profile, paired with an Apple Development certificate.
- Handing a build to testers outside TestFlight: an Ad Hoc profile, paired with an Apple Distribution certificate, with every tester's device registered.
- Shipping through TestFlight or the store: an App Store profile, which you upload rather than install.
- Distributing inside an organisation on an Enterprise membership: an In-House profile, which carries ProvisionsAllDevices instead of a device list.
Mixing these up is the second most common cause after the device list. An Ad Hoc build handed to someone whose device was never registered produces exactly this error on their phone and nothing at all on yours, which makes it look like their device is broken.
Related messages
- "Unable to install. Please try again later." A generic wrapper from the install daemon. The Recovery Suggestion line underneath is where the real message lives.
- If the refusal is about the signature format rather than the profile, see the code signature version is no longer supported.
- If the profile is missing at build time rather than rejected at install time, see No profiles for the bundle ID were found.