The provisioning profile Apple requires, explained.
A provisioning profile Apple has signed is the one file that lets your app run on an iPhone at all. It ties five facts together: who may sign the code, which app it is, which devices it may run on, until when, and which entitlements it may claim. Every Apple provisioning profile comes from Apple's developer website, either generated for you by Xcode or built by hand in Certificates, Identifiers & Profiles, and every one that can reach other people's phones sits behind Apple Developer Program enrolment, a paid membership listed at 99 US dollars a year on Apple's enrollment page as of September 2026.
This page covers what is inside the file, the difference between development and distribution profiles, how long certificates and profiles last, what actually breaks when they expire, and how to clear "A valid provisioning profile for this executable was not found".
See what is inside a profileThe short version
Five facts, one signed file.
A provisioning profile is a property list, signed by Apple, that Xcode embeds in your app as embedded.mobileprovision. It names the certificates allowed to sign the code, a single App ID, the devices the app may run on, an expiration date, and an allowlist of entitlements. A development profile uses your own Apple Development certificate and lists devices; an App Store Connect profile uses the team's Apple Distribution certificate and lists none. Certificates and profiles are typically valid for about a year, but an app already on the App Store does not care, because Apple re-signs it at submission.
Inside the file
What an Apple provisioning profile actually contains.
Apple's own technote on the subject, TN3125, describes the profile as the authorization every piece of third-party code needs on Apple platforms other than macOS. It answers five questions, and each one maps to a property you can read out of the file:
DeveloperCertificatesThe certificates allowed to sign code covered by this profile. Your build must be signed by one of them, and the matching private key has to be in your keychain.
application-identifierOne App ID: the team prefix plus your bundle identifier, or a wildcard that matches several apps under the same prefix.
ProvisionedDevicesThe device identifiers the app may run on. App Store profiles have no device list at all, because that build is uploaded, never installed directly.
ExpirationDateThe date the profile stops being valid. Typically not more than a year out, and only seven days on a free Personal Team.
EntitlementsAn allowlist of entitlements. Every entitlement the app claims must be in it, so switching on a capability means a regenerated profile.
Read one yourself
The file is a property list wrapped in a CMS signature. On a Mac, strip the wrapper and pull out any of the five properties with the two commands the technote uses:
security cms -D -i Your.mobileprovision -o payload.plist
plutil -extract ExpirationDate raw -o - payload.plistTwo details from the same technote matter later on this page. First, the plist is no longer the source of truth: since iOS 15 the device reads a DER-encoded copy stored inside the profile, and Apple issues profiles carrying both. Second, an app you download from the App Store contains no profile at all. Apple checks that the submitted build was signed and provisioned correctly, then re-signs it, so the device has nothing further to verify. Read TN3125, Inside Code Signing: Provisioning Profiles
Development versus distribution
Development, Ad Hoc, or App Store Connect?
The type of profile is really a question of which certificate signs the build and whether the file carries a device list. Development certificates belong to individuals; Apple appends the computer name so a team can tell them apart. Distribution certificates belong to the team, only one of each type is allowed per team, and only the Account Holder or an Admin can create one. Everything else follows from that split:
| Profile | What it is for | Certificate it names | Device list | Debugger can attach | Who creates it |
|---|---|---|---|---|---|
| Development | Run and debug from Xcode on your own registered devices | Apple Development, one or more, owned by individuals | Yes, the registered devices it may run on | Yes | Xcode with automatic signing, or an Account Holder or Admin in Certificates, Identifiers & Profiles |
| Ad Hoc | Install a build on a fixed list of test devices without Xcode | Apple Distribution, a single one, owned by the team | Yes, up to 100 per product family per membership year | No | An Account Holder or Admin in Certificates, Identifiers & Profiles, or Xcode with automatic signing |
| App Store Connect | Upload to App Store Connect for TestFlight and the App Store | Apple Distribution, a single one, owned by the team | None | No | Xcode when you upload with automatic signing, or an Account Holder or Admin in Certificates, Identifiers & Profiles |
Certificate ownership and roles from the Certificates overview in Apple's Developer Account Help; device limits from its Devices overview. Enterprise in-house profiles and Developer ID profiles exist as well, but neither applies to an iOS app headed for the App Store.
Automatic signing
Xcode provisioning profile: what automatic signing creates
With "Automatically manage signing" on in the Signing & Capabilities pane, Xcode signs in to your team, registers the device you chose as the run destination, and creates the development provisioning profile itself. Archive and upload with the same option and it manages the distribution profile too. Apple's Developer Account Help says as much on every manual page: if you use automatic signing, Xcode manages the profile for you. The by-hand steps further down exist for people who need to sign outside Xcode, for example to feed an external build system.
Try it
Which provisioning profile do you need?
Two answers decide it: how the build reaches a phone, and whether there is a paid membership behind it.
1. How will the build get onto a device?
2. Do you have an Apple Developer Program membership?
You need
Answer both questions to see the profile type, the certificate it needs and who can create it.
Expiry
How long certificates and profiles last, and what actually breaks.
Two different assets expire, and people mix them up. The certificate is the identity that signs the build; the profile is the authorization that names that certificate. Apple's technote on certificates says code-signing certificates are typically valid for a year from the date of issue, with the exact duration depending on the type, and its technote on profiles says a profile's validity varies by type but is typically not more than a year, with Developer ID profiles as the exception. Here is what each expiry does in practice:
| Asset | Typical validity | When it expires |
|---|---|---|
| Apple Development certificate | Typically a year from issue | New development builds cannot be signed until you create another one. Apps already installed keep running; the profile's date is what governs them. |
| Apple Distribution certificate | Typically a year from issue | Existing App Store apps are unaffected while your membership is valid. You cannot upload new builds signed with it, and builds already uploaded but not yet submitted may be marked Invalid Binary if the certificate was revoked. |
| Development profile | Typically not more than a year; 7 days on a free Personal Team | Development builds on devices stop launching. Rebuild with a fresh profile, which automatic signing issues on the next run. |
| Ad Hoc profile | Typically not more than a year | Installed Ad Hoc builds stop launching. Export again with a new profile and reinstall on each device. |
| App Store Connect profile | Typically not more than a year | Nothing changes in production, because Apple re-signed the app at submission. You need a valid profile only for the next upload. |
| Developer ID profile (Mac, outside the App Store) | 18 years, for profiles generated after February 22, 2017 | Only relevant to Mac software that uses a Developer ID profile for capabilities such as CloudKit or push notifications. |
Certificate durations and re-signing from Apple's TN3161; what an expired distribution certificate does to App Store apps from the Certificates overview in Developer Account Help; the 7-day Personal Team limit from Apple's membership comparison page and the 18-year Developer ID figure from its Developer ID certificates page.
The rule that matters
Why App Store apps do not die on a date
When you submit, Apple checks that your distribution certificate is valid right then, re-signs the app with its own credentials, and ships that. TN3161 puts it plainly: your credentials only need to be valid at the time that you submit your app. TestFlight re-signs builds the same way. The only iOS builds that stop on a date are the ones you installed yourself with a development or Ad Hoc profile, and the fix is always the same: a fresh profile and a reinstall.
Apple ties that guarantee to a valid membership, which is why the yearly renewal matters more than any single certificate. The practical checklist for a team is short:
- Put the membership renewal date on a shared calendar, not in one person's inbox.
- Know who the Account Holder and Admins are; only they can create distribution certificates and profiles.
- Keep the distribution certificate's private key backed up and shared securely; a certificate without its key cannot sign anything.
- Expect development and Ad Hoc builds to need a rebuild within a year, and plan test devices around the 100-per-family limit.
Getting one
How to get an Apple developer provisioning profile, three ways.
All three end with the same signed file. They differ in who clicks the buttons and where the private keys live.
Option 1
Let Xcode do it
- 1Sign in with your Apple Developer Program account, or a personal Apple Account, in Xcode Settings under Apple Accounts.
- 2In the project editor, open Signing & Capabilities, turn on Automatically manage signing, choose your team and enter a unique bundle identifier.
- 3Choose the connected iPhone as the run destination. Xcode registers it and creates the development profile; click Register if the button appears.
- 4To distribute, archive the app and keep Automatically manage signing selected in the distribution flow. Xcode creates the App Store Connect profile when it uploads.
Option 2
Create an App Store Connect profile by hand
- 1Have an explicit App ID registered for your bundle identifier and the team's Apple Distribution certificate. You need the Account Holder or Admin role.
- 2In Certificates, Identifiers & Profiles, click Profiles, then the add button.
- 3Under Distribution choose App Store Connect and continue.
- 4Pick the App ID that matches your bundle ID. If you used automatic signing during development, that is the Xcode-managed App ID beginning with XC, or XC Wildcard if it is the only option.
- 5Select the distribution certificate. An App Store profile contains exactly one.
- 6Name it, click Generate, click Download, then download it in Xcode so the build can use it.
Steps from Create an App Store Connect provisioning profile in Apple's Developer Account Help. A development profile follows the same path under Development, adding one or more development certificates and the devices.
Option 3
Let a build service create it
If your app is an Expo project, eas build generates the distribution certificate, the profile and the push key once you sign in with an Apple Developer Program membership. Expo's credentials documentation says they are then stored on EAS servers, so the rest of the team can start builds without access to the Apple team.
The same documentation states the constraint you meet on every path: one distribution certificate per Apple developer account, used for all of your apps, and a separate profile for each app you submit. A service does not remove the paid membership, it just holds the keys.
Troubleshooting
Fixing "A valid provisioning profile for this executable was not found".
This message appears at install time, not compile time: the build is signed, but the device, or Xcode on its behalf, rejected the profile. Since a profile is five checks, the diagnosis is five checks, in the order they usually turn out to be the culprit.
| Check | Likely cause | Why it happens | Fix |
|---|---|---|---|
| Where | The device is not in the profile | Development and Ad Hoc profiles list device identifiers. A new phone, or a colleague's phone, is not in yours until someone registers it. | Register the device (Xcode shows a Register Device button with automatic signing), regenerate the profile, rebuild. A build signed with an App Store profile cannot be installed directly at all: use TestFlight for that one. |
| When | The profile has expired | Every profile carries an ExpirationDate. Free Personal Team profiles run out after 7 days; paid ones typically within a year. | Rebuild with a fresh profile. With automatic signing Xcode issues one; for a manual profile, edit and regenerate it in Certificates, Identifiers & Profiles, then download it again. |
| Who | The signing certificate is not in the profile, or has expired or been revoked | Apple marks a custom profile Invalid the moment its certificate expires or is revoked. A certificate whose private key is missing from your keychain cannot sign at all. | Create or import the certificate with its private key, then edit the profile to point at it and regenerate. Xcode Settings, Accounts, Manage Certificates shows what you actually have. |
| What | The bundle identifier does not match the profile's App ID | The profile names one App ID, team prefix plus bundle ID, or a wildcard. A renamed bundle ID, or a second target with its own ID, is not covered. | Match the bundle identifier to the App ID the profile was made for, or make a profile for the ID you actually ship. Extensions and App Clips each need their own. |
| How | The app claims an entitlement the profile does not allow | Turning a capability on or off changes the App ID, and every custom profile tied to it goes Invalid until it is regenerated. | Enable the capability on the App ID, regenerate the profile, download it again. Xcode-managed profiles update themselves; custom ones do not. |
Same problem, other words
Xcode's other versions of the same complaint
Xcode tends to catch the mismatch before the device does, and names the check that failed. Map the wording back to the table above:
"No profiles for your bundle ID were found"
Xcode has no matching profile on this Mac. Turn on automatic signing, or download the manual profile from Xcode Settings, Accounts.
"Doesn't include the currently selected device"
The Where check again, caught before install. Register the device and regenerate.
"Doesn't include signing certificate"
The Who check. The profile was generated against a different certificate than the one Xcode is about to sign with.
"Doesn't support the capability"
The How check. Enable the capability on the App ID, then regenerate the profile so its entitlement allowlist catches up.
"Invalid, next to the profile in the portal"
Apple's Technical Q&A on this status: the profile's certificate or App ID changed. Edit the profile and click Generate.
Beyond signing
What a valid profile does not get you.
A profile gets a build onto a device or into App Store Connect. It says nothing about whether the app will be approved. The listing is a separate job: screenshots for each required device size, a privacy policy URL, the App Privacy questionnaire, review notes with a demo account if the app needs a login, and the app store age rating questionnaire, which every app answers before it can be submitted.
Build numbers, TestFlight groups, the review itself and what to do with a rejection are their own process, covered in publishing to the App Store.
When it is handled for you
If you never want to see a .mobileprovision file.
Everything above is the manual layer, and plenty of teams never touch it because the tool that builds the app also signs it. Newly is an AI app builder that works this way for iOS: you describe the app, it builds a real native app, and its App Store submission guide describes a one-time connection to your Apple account. You sign in with your Apple ID, complete two-factor authentication, pick your team, and it auto-provisions the keys it needs, with a checkmark for each. Then it compiles the app, typically in 5 to 15 minutes, and submits the build to App Store Connect, where you install it through TestFlight, finish the listing and submit for review. On that path you do not create a certificate or a profile yourself; if you would rather manage your own keys, the guide offers a manual setup instead. Read the App Store submission guide on docs.newly.app
What it does not change: you still need the paid Apple Developer Program membership, a bundle identifier you are happy with (the guide warns that changing it later is a two-step process), and a privacy policy URL. The service costs $25 a month with no free plan, and iOS builds reach phones through App Store Connect, so TestFlight is the first place you see the app on a device.
Sources
Where the specifics came from.
Every duration, role and behaviour on this page comes from one of these four documents, all opened in September 2026:
FAQ
Provisioning profiles, answered.
A provisioning profile is a file signed by Apple that authorizes your app to run. Apple platforms other than macOS refuse third-party code unless a profile says who may sign it, which App ID it belongs to, which devices it may run on, until when, and which entitlements it may claim. Xcode embeds the profile in the app bundle as embedded.mobileprovision. Apps installed from the App Store carry no profile at all, because Apple checks the signing during submission and then re-signs the app itself.
Ship the app, skip the portal.
Signing is a solved problem when the builder does it for you. Describe your app in Newly, connect your Apple account once, and the build lands in App Store Connect ready for TestFlight.