How iOS signing actually works
Understand IPAs, signatures, provisioning profiles, device IDs and entitlements as one verification chain.
An IPA is essentially a packaged iOS application. It is not installable merely because its filename ends in .ipa. The device evaluates a chain of related facts before allowing the app to install and launch.
The verification chain
- The app has a cryptographic signature. Its executable code and sealed resources must agree with that signature.
- The signature comes from a signing certificate. The certificate belongs to an Apple development team and has a validity period.
- The app embeds a provisioning profile. The profile connects a team, certificate, App ID, allowed capabilities and, where applicable, registered devices.
- The device is eligible. Ad hoc and development profiles normally contain permitted device UDIDs.
- The identifiers agree. The app's effective application identifier must be covered by the profile.
- The requested entitlements are allowed. The signature cannot grant capabilities absent from the provisioning profile.
Apple describes a provisioning profile as containing a single App ID and a distribution certificate, and notes that profiles authorise app services. See Apple's provisioning profile updates.
What a signing tool changes
A signer commonly:
- unpacks the IPA;
- changes the bundle identifier or display metadata when requested;
- embeds a provisioning profile;
- applies compatible entitlements;
- signs nested frameworks, extensions and the main executable;
- rebuilds the IPA;
- serves it through an installation manifest or transfers it over USB.
Feather documents that it feeds a P12/profile pair to its signing engine and then initiates an over-the-air installation. Its technical overview explains the local server and itms-services portion of that process.
Signing is not scanning
Code signing answers roughly: “Has this package changed since this signer sealed it, and is this signer/profile acceptable here?” It does not answer: “Is this application honest, private or safe?”
Likewise, sandboxing reduces what an app can do by default but does not make every app harmless. An app can still misuse permissions you grant, transmit information you enter into it, exploit platform vulnerabilities, imitate another service or expose your account credentials.
Why errors look vague
iOS often collapses several failures into similar messages. “Integrity could not be verified” can indicate a mismatched profile, ineligible UDID, invalid signature, expired profile, revoked certificate, broken nested component or damaged IPA.
That is why good troubleshooting tests one layer at a time rather than searching for a magical DNS toggle.