App ID, provisioning profile, and signing certificate
the code-signing trust chain.
the certificate proves who you are, the App ID identifies the app and its capabilities, and the provisioning profile binds certificate, App ID, and allowed devices so iOS trusts the install.
What's really being asked
This foundational question reveals whether you understand why iOS installs sometimes fail and how Apple establishes that a binary is authentic and authorized for a device.
The full answer
The signing certificate, paired with a private key in your keychain, is your identity: signing the app with it proves the build came from an authorized developer or team. The App ID identifies the application, usually via an explicit bundle identifier, and declares which capabilities or entitlements it may use, such as push notifications or app groups. The provisioning profile is the document, issued and signed by Apple, that binds these together: it references the App ID, lists which signing certificates are valid, encodes the entitlements, and for development and ad hoc distribution enumerates the specific device UDIDs allowed to run the build. At install and launch, iOS checks that the app's signature matches an allowed certificate in the embedded profile, that the bundle ID matches the App ID, that entitlements are authorized, and that the device is permitted, otherwise it refuses to run.
The mistakes people make
Conflating the certificate with the provisioning profile. Thinking the App ID is just a string with no entitlement role. Forgetting that development and ad hoc profiles are device-restricted while App Store profiles are not.
What usually comes next
Why can an ad hoc build only run on registered devices but an App Store build runs anywhere? What happens when a certificate expires or is revoked? Where is the profile stored inside the .app bundle?
A concrete example
You build a development version. Xcode signs the binary with your development certificate. The embedded provisioning profile names your App ID com.example.app, lists that certificate as valid, and includes your iPhone's UDID. On the device, iOS confirms the signature was made by an allowed certificate, the bundle ID matches, the entitlements are sanctioned, and the device UDID is in the profile, so it launches. Install it on an unregistered phone and iOS rejects it because that UDID is absent from the profile.
Interview question
What specifically prevents a development-signed build from launching on an unregistered iPhone?
- a.The signing certificate expires the moment it leaves your Mac
- b.Development builds are encrypted and undecryptable off-device
- c.The App ID forbids running on any physical device
- d.The provisioning profile does not list that device's UDIDCorrect
Why? this is the answer
Development and ad hoc profiles enumerate permitted device UDIDs, so an unlisted device is rejected. Certificates do not expire on transfer, App IDs do not blanket-ban devices, and the build is not undecryptable.
Just read this? Test yourself on what you have been reading.
Read the original → developer.apple.com
- #ios
- #code-signing
- #provisioning-profile
- #certificate
- #app-id
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ios — each one lists the topics its interview covers.
See open roles