You sent a build to a tester, they tapped Install, the icon started filling in on the Home Screen — and then iOS stopped everything with this:
Unable to Install “YourApp”
“This app cannot be installed because its integrity could not be verified.”
Unlike the “Untrusted Enterprise Developer” screen, there is nothing to approve in Settings. iOS checked the build’s code signature before allowing it to run, and something in that chain failed. The check happens on the build, so the fix happens on the build too — and for tester installs it is nearly always one specific thing: the device is not in the provisioning profile.
What iOS is actually checking
Every .ipa installed outside the App Store carries an embedded provisioning profile. At install time iOS checks the build against it: that the signing certificate is valid and has not been revoked, that the profile itself has not expired, that the app’s entitlements — including the Bundle Seed ID in its application-identifier — match the ones the profile grants, and — for ad hoc and development profiles — that this device’s UDID appears in the profile’s ProvisionedDevices list. Fail any one of those and you get the integrity alert.
The alert never says which check failed, which is why it has a reputation for being cryptic. The useful news is that the profile is not a black box: it is a plist you can open and read, so you can see exactly which check is failing before you touch anything else.
The causes, ranked
1. The device’s UDID is not in the profile
This is the cause for tester installs, full stop. An ad hoc build only installs on devices whose UDIDs were registered before the app was signed — the profile is a snapshot of the device list at signing time, so a tester added to the portal yesterday is still missing from a build exported last week.
Prove it instead of guessing: drop the .mobileprovision into the provisioning profile decoder and look at ProvisionedDevices. Use the profile you downloaded from the portal, or pull embedded.mobileprovision straight out of the .ipa (rename it to .zip, unzip, look inside Payload/YourApp.app/). If the tester’s UDID is not in that list, you have your answer.
While you are checking, make sure the UDID itself is right. Hand-typed identifiers, serial numbers pasted where a UDID belongs, and old screenshots of the wrong device account for a surprising share of these failures. Modern iPhones use a 25-character UDID with a dash after the eighth character; older devices use 40 hex characters. Have the tester read it off their own phone with the UDID checker rather than digging through Finder.
2. The provisioning profile has expired
Ad hoc profiles are valid for one year, and an expired profile fails the install even for devices that are correctly listed. The same decoder shows the profile’s expiration date next to the device list, so this takes seconds to rule in or out. The fix is the same regeneration-and-rebuild loop described below, minus the device registration step.
3. The signing certificate is revoked or expired
Rarer, but it happens: the distribution certificate the build was signed with has lapsed, or someone on the team revoked it while cleaning up the account. Check Certificates, Identifiers & Profiles → Certificates in the Apple Developer portal. A build signed with a dead certificate is unfixable as-is; sign a fresh build with a valid one.
4. It is enterprise-signed and the device has not trusted it
An enterprise (in-house) build does not check UDIDs at all, so it does not produce this alert for that reason — it installs and then refuses to launch until the device trusts the signing certificate. If what your tester is actually seeing is an “Untrusted Enterprise Developer” sheet, that is a different problem with a genuinely easy fix, covered in our guide to the untrusted enterprise developer error. Worth asking the tester for a screenshot before you spend an hour on the wrong diagnosis.
5. The build was exported for App Store distribution
An IPA exported with the App Store method is signed for delivery through Apple only. It carries no device list and will never install over the air on any device, registered or not. If the profile decoder shows no ProvisionedDevices list and no ProvisionsAllDevices flag, this is likely what happened — ProvisionsAllDevices set to true means you are holding an enterprise in-house profile instead, which is cause 4 above. Re-export from Xcode’s Organizer choosing Distribute App → Release Testing instead (Xcode 14 and earlier labelled this Ad Hoc; from Xcode 15 on, Ad Hoc itself lives under Custom).
6. The app’s entitlements do not match the profile
The check nobody looks for, because the decoder shows everything as healthy. If the Bundle Seed ID in the signed app’s application-identifier entitlement does not match the one in the embedded profile — a stale App ID, a bundle identifier edited after the profile was cut, a wildcard profile signing an app that needs an explicit one — the signature fails even though the UDID is listed, the profile is current and the certificate is fine. Apple’s Technical Note TN2250 documents the mismatch and how to dump both sides for comparison. Confirm the app’s bundle identifier matches the App ID the profile was generated against, then regenerate and rebuild.
One more thing worth ruling out before you go profile-spelunking: a truncated or re-zipped .ipa. A code-signature check is exactly what catches a damaged archive, so a build that failed to upload cleanly, or that someone unzipped and re-zipped to “look inside”, can produce this alert with a perfectly good profile inside it. Re-upload the original export and try the fresh link before assuming a signing problem.
The fix, step by step
This is the developer’s loop for cause 1, which is almost certainly yours:
- Get the real UDID. Send the tester the UDID checker link to open on the iPhone itself; it reads the identifier off the device so nothing is mistyped.
- Register the device. In the Apple Developer portal, go to Certificates, Identifiers & Profiles → Devices, click (+), and enter a name and the UDID.
- Regenerate the profile. Registering a device does not update existing profiles. Go to Profiles, open your Ad Hoc profile, edit it, tick the new device, and generate it again.
- Rebuild. Archive in Xcode and export with Distribute App → Release Testing (Ad Hoc in Xcode 14 and earlier, or under Custom in Xcode 15 and later); with automatic signing, Xcode fetches the updated profile itself. The profile is baked into the
.ipaat signing, which is why there is no shortcut around re-exporting. - Verify before you share. Run the new build’s profile through the decoder and confirm the tester’s UDID is now in
ProvisionedDevices. Thirty seconds here saves a full round trip with the tester. - Re-share the build. Upload the new IPA to BetaDrop for a fresh OTA install link and QR code. Have the tester delete any stuck placeholder icon, then open the new link in Safari.
If you are the tester: there is no workaround
Nothing you do on the device fixes this alert. No Settings toggle, no restart, no re-download, no changing the date, no “IPA installer” app that keeps the original signature. iOS is enforcing Apple’s signing model exactly as designed: the OS will not run code that was not signed for your specific device or delivered through Apple.
Services that promise to install the app anyway do it by re-signing the binary with a different certificate — usually an enterprise certificate being rented out against Apple’s terms, on borrowed time until it is revoked. That is not a bypass; it is a different build with a stranger’s signature on it. Anyone selling an on-device fix for this alert is selling something else.
The one genuinely useful thing you can do from the tester’s seat: open the UDID checker on your iPhone, send the developer the identifier it shows, and wait for a re-signed build. That is the entire fix, and only they can do their half.
Frequently Asked Questions
Does 'integrity could not be verified' mean the app is unsafe or malware?
No. The alert is about the code signature, not the app's content. Before letting a build run, iOS checks its signing certificate and embedded provisioning profile, and one of those checks failed — most often because the device is not listed in the profile. The same binary can be perfectly safe and still refuse to install on a device it was never signed for.
Why does the same install link work on my colleague's iPhone but not mine?
Because an ad hoc provisioning profile is a list of specific devices. Your colleague's UDID was registered before the app was signed and yours was not, so iOS on their phone finds a match in the embedded profile and iOS on yours does not. The link and the file are identical; the difference is the device list baked into the build.
Will deleting the app and reinstalling fix the integrity error?
Not on its own. The check fails on the build itself, so reinstalling the same file fails the same way every time. Reinstalling only helps after the developer has registered your UDID and shipped a re-signed build: at that point, delete any stuck placeholder icon first, then open the new install link.
Can I find my iPhone's UDID without plugging into a Mac?
Yes. Open a UDID checker in the browser on the iPhone itself. It offers a temporary configuration profile — the mechanism Apple provides for exactly this — and once you install and approve it in Settings, the device reports its UDID back to the page for you to copy and send to the developer. No computer, no iTunes, no Xcode.
Do TestFlight builds ever show this error?
Rarely — and never because of a device list. TestFlight builds are re-signed by Apple, so there is no ad hoc UDID list to fall foul of. When testers do hit this alert on a TestFlight build it is an Apple-side signing or processing failure rather than anything in your project: check Apple's system status page, then upload a fresh build. Everything else here about UDIDs applies only to builds installed directly from a link — ad hoc, development, and enterprise-signed IPAs. Avoiding UDID management is TestFlight's trade, in exchange for Apple's processing time plus Beta App Review on the first build of each version for external testers; internal testers on your App Store Connect team skip review entirely.
In short
“Integrity could not be verified” means a signing check failed on the build, and the build is where it gets fixed. Decode the profile to see which check it was — usually a missing UDID, an expired profile, a dead certificate, or an App Store export that was never installable OTA, and failing all four, an entitlements mismatch the decoder will not flag for you. Then register the device, regenerate the profile, rebuild, and share the re-signed IPA with a fresh install link. The tester’s only job is handing over a correct UDID; everything else is yours.
