A provisioning profile is a signed file from Apple that authorizes your app to run on Apple devices. It ties together who may sign, which app, where it can run, when it can run, and which entitlements it may claim. Except on macOS, devices will not run third-party code without one.
Definition
Apple's technote on provisioning profiles explains the idea. Apple platforms, except macOS, do not run arbitrary third-party code. Execution has to be authorized by Apple, and the authorization is a profile. The profile answers five questions:
| Question | Where the answer lives in the profile |
|---|---|
| Who is allowed to sign code? | The developer certificates list |
| What apps may they sign? | The App ID, which can include a wildcard |
| Where can those apps run? | The provisioned devices list, absent for store profiles |
| When can those apps run? | The expiration date |
| How can those apps be entitled? | The entitlements allowlist |
You create profiles on the Apple Developer website, directly or through Xcode. The site signs the profile cryptographically, and a device checks that signature before it checks that the app meets the profile's criteria.
How to read one
Apple shows that a profile is a property list wrapped in a Cryptographic Message Syntax signature. You can remove the wrapper with the security tool to view the contents:
security cms -D -i MyApp.mobileprovision -o payload.plist
Apple adds a caution. The format is not documented and could change, so use these techniques to understand and debug, not to build a product on. It also notes that the plain property list view is no longer the source of truth on modern systems.
The entitlements allowlist
This is the part with a security effect. The entitlements in a profile are an allowlist, which is different from the entitlements your app claims. To use an entitlement, you include it in the app's code signature. Every entitlement the app claims must appear in the profile's allowlist, but the profile may list extras.
Wildcards can appear in the profile, such as a keychain access group with a prefix. Apple says wildcards make no sense in the app's own signature.
For debugging, dump what the app claims with the code signing tool's entitlements display, and compare it to the profile.
Device scope by profile type
Apple's technote says store distribution profiles have no device list because you cannot run a store-signed app locally. Developer ID and in-house profiles have no device list either, in the sense that they apply to all devices. Development profiles list specific devices.
macOS is different
On macOS a profile is not needed to run third-party code. Apple adds that restricted entitlements must still be authorized by a profile, which means other developers cannot impersonate your app to steal its keychain items. A Mac app that uses no restricted entitlements does not need a profile, with TestFlight as the exception.
Practical habits
- Store profiles with the same care as certificates, and track their expiry.
- After a build, compare claimed entitlements to the profile allowlist.
- Avoid broad wildcard App IDs for production apps where you can.
- Re-create profiles when a certificate changes.
Where Safeguard fits
A profile limits what your own signed app can do. It does not describe the libraries inside. Safeguard offers dependency scanning and SBOMs for that, with a free scan at gold.safeguard.sh/scan.
Quick check
Does every Apple platform need a provisioning profile?
Apple says macOS does not require one to run third-party code. Other Apple platforms do.
Can my app claim an entitlement that is not in the profile?
No. Every entitlement the app claims must be in the profile's allowlist. The reverse is fine.
Sources
Last reviewed: 19 October 2026.
