iOS Provisioning Profiles and Code Signing Explained (2026)

Q: What's the difference between a certificate and a provisioning profile?

A certificate proves who you are — it's the signing identity tied to your Apple Developer account. A provisioning profile ties that certificate to a specific app ID and set of devices, authorizing a signed build to run. You need both: the certificate signs, the profile grants permission.

Q: Why does my build fail code signing?

The usual causes are a missing or expired certificate, a provisioning profile that doesn't include the target device's UDID, a mismatch between the profile's app ID and your bundle identifier, or an expired profile. Regenerate the profile with the right certificate and devices, then rebuild.

Q: What's an ad hoc provisioning profile?

An ad hoc provisioning profile authorizes a build to run on a specific list of registered device UDIDs without going through the App Store. It's what you use to distribute test builds directly to known devices, and every tester's device must be in the profile before you build.

Jan Thalheim

Sep 29, 2026 • 9 min read

iOS code signing is Apple's way of guaranteeing that an app comes from an identified developer and hasn't been altered. It rests on two pieces: a certificate (who you are) and a provisioning profile (which app can run on which devices, signed by which certificate). Get either wrong and the build won't install. This guide explains the building blocks in plain terms, the four profile types, and how to fix the signing errors you'll actually hit.

The building blocks

Certificate — your signing identity, issued by Apple. Two kinds matter: development (for building to your own devices) and distribution (for ad hoc, App Store and enterprise builds).
App ID — identifies your app (the bundle identifier, e.g. com.example.myapp), plus its capabilities.
Devices / UDIDs — the specific iPhones/iPads a build is allowed to run on (for development and ad hoc). See finding and registering a UDID.
Provisioning profile — the glue: it binds a certificate + app ID + devices into a single authorization that ships inside the build (embedded.mobileprovision).

At build time, Xcode signs the app with the certificate and embeds the matching profile. iOS checks both before it will run the app.

The four provisioning profile types

Type	Runs on	Review?	Used for
Development	Registered dev devices	No	Day-to-day building/debugging
Ad Hoc	Registered device UDIDs	No	Direct test distribution to known devices
App Store	Any device (via Store)	Yes	Public release + TestFlight
Enterprise	Any device (in-house)	No	Employees only (Developer vs Enterprise)

For choosing between these when distributing, see the iOS distribution methods matrix.

How signing works at build time

You build/archive the app in Xcode (or CI).
Xcode signs the binary with your certificate.
The matching provisioning profile is embedded.
On install, iOS verifies the signature and that the device is authorized by the profile.

Teams often automate certificate and profile management with fastlane match, which stores and syncs a shared signing identity across machines and CI so everyone signs consistently.

Common signing errors and fixes

"No profiles for 'com.example.app' were found" — no profile matches your bundle identifier → create/download an ad hoc or development profile for that exact app ID.
"A valid provisioning profile for this executable was not found" — the embedded profile is missing, wrong or expired → regenerate it with the correct certificate and devices, then rebuild.
Device not authorized / "Unable to Install" — the device UDID isn't in the profile → register the UDID, regenerate the profile, rebuild.
Expired profile or certificate → renew the certificate, regenerate profiles, rebuild. Distribution certificates and profiles have limited lifetimes.
Re-signing an existing .ipa → possible for ad hoc/enterprise with the right tooling, but rebuilding from source with a correct profile is the reliable route.

Most of these trace back to one of three things: a UDID not in the profile, a bundle-identifier mismatch, or an expired credential. Check those first.

Where this bites in distribution

Every ad hoc install depends on this chain being correct — which is why ad hoc distribution feels fiddly. A distribution tool doesn't remove Apple's signing rules, but it removes the manual parts: Appisto collects UDIDs automatically and manages your builds, so the profile has the right devices and you spend less time chasing "valid provisioning profile not found." See how to install an .ipa and secure mobile app development.

Frequently asked questions

What's the difference between a certificate and a provisioning profile? A certificate is your signing identity (who you are); a provisioning profile binds that certificate to an app ID and devices, authorizing a signed build to run. You need both.

Why does my build fail code signing? Usually a missing/expired certificate, a profile missing the device UDID, a bundle-identifier mismatch, or an expired profile. Regenerate the profile with the right certificate and devices, then rebuild.

What's an ad hoc provisioning profile? One that authorizes a build to run on a specific list of registered UDIDs without the App Store — every tester's device must be in it before you build.

Key takeaways

Code signing needs two things: a certificate (identity) and a provisioning profile (app + devices + certificate).
There are four profile types: development, ad hoc, App Store and enterprise.
Most signing failures come from a missing UDID, a bundle-ID mismatch, or an expired credential.
Appisto automates UDID collection and build management so ad hoc signing is less painful — see finding and registering a UDID and the 100-device limit.