Installation errors
Fix “Integrity Could Not Be Verified” on iPhone
Diagnose an iPhone integrity-verification failure by preserving the IPA, inspecting signatures and profiles, and repairing the smallest proven mismatch.
“Integrity could not be verified” means iOS could not accept the app’s delivered authorization or signed contents. The alert is an outcome, not a unique diagnosis. It can follow an altered artifact, invalid signature, incompatible nested code, expired or mismatched signing assets, an unauthorized device, or a delivery path that does not match the build.
Do not delete the only failing IPA and immediately re-sign it. Preserve the exact file, collect evidence, identify the first proven mismatch, and create the smallest authorized replacement.
First response: preserve the failure
Record the full alert text, device model and OS version, install method, timestamp, app version/build, and who supplied the IPA. Save the file without renaming or repackaging it and calculate a checksum:
shasum -a 256 ClientApp.ipaCompare that value with the checksum recorded at export or release. A difference means the device did not receive the same bytes that were approved. Fix the transfer, storage, or packaging path before changing signing.
If no trusted release checksum exists, state that limitation. A signature inspection can reveal technical facts, but it cannot prove where an unknown artifact came from.
Build an evidence folder
Extract a copy and locate the app bundle:
mkdir integrity-evidence
unzip -q ClientApp.ipa -d integrity-evidence
find integrity-evidence/Payload -maxdepth 1 -name '*.app' -printSet the path printed by find, then collect the embedded profile, signing details, and entitlements:
APP_PATH="integrity-evidence/Payload/ClientApp.app"
security cms -D -i "$APP_PATH/embedded.mobileprovision" > embedded-profile.plist
plutil -p embedded-profile.plist
codesign -d --verbose=4 "$APP_PATH"
codesign -d --entitlements :- "$APP_PATH"
codesign --verify --deep --strict --verbose=2 "$APP_PATH"Keep the command output with the checksum. Redact certificate serials or device identifiers before sharing diagnostics publicly; do not upload private keys, P12 files, P8 keys, or provisioning profiles to an untrusted form.
Classification 1: the artifact changed after signing
Code signing protects executable code and sealed bundle resources. Editing the app after its final signature—such as replacing Info.plist, changing an extension, injecting a framework, or copying a different embedded.mobileprovision—can invalidate the signature.
Evidence for this class includes:
- the delivery checksum differs from the approved export;
codesign --verifyreports modified or missing sealed resources;- the IPA was unpacked and repacked after signing;
- a profile or nested component was replaced without signing the whole bundle again.
Repair it by returning to the last trusted archive or IPA and exporting a clean artifact. If an authorized re-sign is truly required, follow the complete IPA re-signing workflow and verify the newly packaged output independently.
Classification 2: the app or nested code has an invalid signature
An iOS app can contain extensions, frameworks, App Clips, and other signed executables. Apple’s code-signing documentation explains that a containing bundle records the signatures of nested code. A valid outer app cannot rescue an incompatible or modified inner component.
List likely nested bundles:
find "$APP_PATH" -type d \
\( -name '*.appex' -o -name '*.framework' -o -name '*.app' \) -printInspect each executable target’s identifier, signing authority, and entitlements. Typical evidence is a nested bundle signed by the wrong team, an extension profile that does not authorize its identifier, or an outer signature created before inner code was finalized.
The minimum repair is a clean build/export that signs every target consistently. Avoid a brittle “sign everything” shell loop: frameworks and extensions have different signing requirements, and signing in the wrong order can hide the original fault while creating another.
Classification 3: profile, App ID, certificate, or entitlements disagree
Decode the embedded profile and compare it with the app’s actual signature and entitlements. Check:
- profile name, UUID, creation date, and expiration date;
- team identifier and authorized application identifier;
- App ID and bundle identifier alignment;
- distribution type and
get-task-allowstate; - permitted entitlements versus the app’s signed entitlements;
- selected developer certificates;
- provisioned devices when the distribution method uses registered devices.
A profile is not a universal permission file. It authorizes a defined combination of team, app, certificate, capabilities, and—where applicable—devices. Route a proven identifier mismatch to the bundle ID guide, and a proven certificate mismatch to the profile/certificate guide.
Repair only the mismatched configuration, then produce a new archive/export. Do not remove a capability just to obtain a green signature unless the app owner has confirmed the app no longer uses it.
Classification 4: the device is not authorized for this build
For Ad Hoc distribution, compare the failing device’s exact UDID with the ProvisionedDevices entries in the profile embedded in the delivered IPA. Seeing the device in the developer portal is not sufficient if the artifact still contains an older profile.
If the device is absent, register it under the correct team, regenerate the Ad Hoc profile with that device selected, and export a compatible replacement. Follow Device Not in Provisioning Profile for the focused workflow.
If the artifact is intended for TestFlight, do not diagnose it as an Ad Hoc device-list problem. Confirm that the tester accepted the correct invitation and installed the assigned build through the TestFlight app.
Classification 5: the delivery path does not match the artifact
An ordinary .ipa download is not itself an installation method. Ad Hoc, Development, TestFlight, App Store, and eligible organizational distribution routes have different authorization and delivery requirements.
Confirm how the build was exported and how the user attempted to install it. A web page or hosting provider cannot transform the build’s distribution type. If the handoff used an OTA manifest, also check the HTTPS URLs, manifest metadata, and artifact availability through the OTA installation guide.
Apply the minimum repair
Once the first mismatch is proven, make one controlled correction:
- regenerate only the profile if the authorized device set or certificate selection changed;
- rebuild if capabilities, bundle identifiers, nested targets, or source inputs are uncertain;
- re-sign only when the app owner authorizes it and compatible inputs are available;
- replace the delivery file if its checksum or packaging differs;
- use the distribution route that matches the exported artifact.
Give the replacement a new filename and checksum. Do not overwrite the evidence that explained the original failure.
Verify the repair on the real path
Before sending another client link:
- extract and inspect the final packaged IPA;
- run signature verification on the app and nested code;
- confirm profile expiry, team, application identifier, entitlements, and target device;
- install the exact checksummed file on a representative eligible device;
- repeat the actual client delivery path, not only a local Xcode install;
- record the result and preserve the release evidence.
If the alert remains, stop rotating certificates and profiles blindly. Compare the new evidence with the old evidence and escalate the exact command or device-install failure.
Use the browser-local iOS Distribution Checklist before delivery. IPAFlow is in Private Beta for authorized device onboarding and artifact handoff; it does not collect Apple signing credentials or ask testers to bypass iOS security controls.