An iPhone runs only code that Apple can trace back to a known developer and that is allowed on that particular device. Code signing is how iOS checks both. It’s also the most common reason a tester writes “the app won’t install”. Once you know the four pieces involved, most of those messages become easy to decode.
The four pieces
1. The signing certificate — who built it
A certificate ties a private key on your machine to your Apple developer team. When you sign a build, the app is stamped with that identity. There are separate certificates for development and for distribution. The private key is the valuable part: whoever holds it can sign apps as your team, so it shouldn’t travel around in email or chat.
2. The App ID — which app
The App ID matches your app’s bundle identifier (for example com.example.inspections) and lists the capabilities it may use, such as push notifications or iCloud. If the build uses a capability the App ID doesn’t allow, signing or installation fails.
3. The provisioning profile — the permission slip
A provisioning profile bundles everything together: the certificate, the App ID, the entitlements and, for some types, a list of devices. It’s embedded in the app. The type of profile decides how the app can be distributed:
| Profile type | Installs on |
|---|---|
| Development | Registered devices of your team, for debugging |
| Ad Hoc | Registered devices listed in the profile — testers, clients, QA |
| App Store | Nothing directly — the build goes to App Store Connect (App Store and TestFlight) |
| In-House (Enterprise) | Employees’ devices, without device registration — Enterprise Program only |
4. The device registration — which iPhone
For development and Ad Hoc builds, each device is registered to your developer account by its unique identifier and then included in the profile. Apple limits this to 100 devices per device family per membership year, and a removed device keeps using its slot until the year renews[1].
Testers can look up their identifier with our guide how to find your iPhone UDID; development-signed builds may also ask them to turn on Developer Mode.
Why a build won’t install: the usual suspects
- The device isn’t in the profile. A new tester’s iPhone was registered after the build was signed. The build has to be signed again with an updated profile.
- The profile or certificate has expired. Both have expiry dates. Once they pass, new installs fail — check the dates in your developer account.
- The certificate was revoked. Revoking a certificate — by your team or by Apple — can stop apps signed with it from launching, not only from installing.
- The bundle ID or entitlements don’t match. The build asks for a capability the App ID doesn’t grant, or its bundle identifier differs from the profile’s.
- The iOS version is too old. The build’s minimum iOS version is higher than what the tester’s device runs.
Why this becomes a job of its own
For one developer and one phone, Xcode handles all of this automatically. It gets harder when a team has dozens of testers, devices change every week, builds arrive daily and someone has to keep track of which profile includes which iPhone. Every new device means re-signing; every lost private key means risk.
That is the work AppSign takes over. You connect your developer account once, upload builds, and AppSign signs them correctly for your registered testers, checks them in moderation, stores them securely and gives your team access. You stay within Apple’s rules — it’s your account and your certificates — without doing the paperwork by hand.
Hit a specific Xcode message? See provisioning profile errors and how to fix them.