If your iOS provisioning profile expired, what happens next depends on how the app was distributed, and the fix is to regenerate the profile and rebuild. Your live App Store app does not crash, because Apple re-signs apps distributed through the store, so store users are unaffected even when your local profile has expired. Apps installed through a development, ad-hoc, or enterprise in-house profile do stop launching when their embedded profile expires, because iOS checks that profile at launch. To renew, regenerate the profile, which Xcode does automatically when automatic signing is on, then rebuild and re-upload or redistribute. First confirm whether it is the profile, the underlying certificate, or both that expired.
Short answer
Regenerate the expired profile and rebuild; whether apps crash depends on distribution. Per Apple's provisioning profile documentation, a profile ties your app to a certificate, App ID, and devices and has an expiry. Live App Store apps keep working because Apple re-signs them, but development, ad-hoc, and enterprise builds stop launching when their profile expires. With Xcode automatic signing on, Xcode regenerates the profile for you on rebuild; otherwise regenerate it in the developer portal. On CI, tools like Fastlane and Expo EAS renew credentials. Check whether the profile, the certificate underneath it, or both expired, then rebuild and re-upload.
Will my app crash?
Whether your app crashes on an expired provisioning profile depends entirely on how it was distributed, and for most developers the reassuring answer applies. An app you published to the App Store does not crash when your provisioning profile expires, because Apple re-signs App Store apps with its own signing, so the profile you used to build and upload is not what keeps the installed app running. Your store users are unaffected, and you only need to renew your profile to build and upload future updates.
The apps that do stop working are those distributed outside the store. An app installed through a development profile, an ad-hoc profile, or an enterprise in-house profile embeds that provisioning profile, and iOS checks its validity at launch, so when the profile expires the app stops launching, often appearing to crash or refusing to open. This is why testers and internal users see an app suddenly stop working. TestFlight builds are a separate case with their own ninety-day build expiry. So the crash question comes down to distribution: store apps are safe, and directly-distributed builds need a fresh profile to keep running.
Certificates, profiles, and keys
Before renewing, it helps to know what actually expired, because a provisioning profile depends on a certificate. A signing certificate is your identity, issued by Apple and valid for about a year, and its private key is what signs your app. A provisioning profile bundles a certificate with your App ID, entitlements, and, for development and ad-hoc, a list of devices, authorizing that combination to run. So a profile can expire on its own schedule, and it can also become invalid because the certificate inside it expired or was revoked.
This distinction matters for the fix. If only the profile expired, regenerating it against a still-valid certificate is enough. If the certificate expired or was revoked, you must renew the certificate first, then regenerate the profile that uses it, because a profile is only as valid as its certificate. Keys here refer to the private key backing your signing certificate, which you need to keep, and are separate from the App Store Connect API key used for automation. Identifying whether you are dealing with an expired profile, an expired certificate, or both tells you how much you need to renew.
How to renew via Xcode
The simplest renewal path is Xcode with automatic signing, which regenerates provisioning profiles for you. In your target's Signing and Capabilities settings, with Automatically manage signing enabled, Xcode detects an expired or invalid profile and creates a fresh one against a valid certificate when you build, so often the fix is simply to rebuild and let Xcode refresh the profile. If Xcode shows a signing error, opening that settings pane and letting it resolve the issue usually regenerates what is needed.
For manual signing, you regenerate the profile yourself. In the Apple Developer portal under Certificates, Identifiers and Profiles, recreate or edit the provisioning profile, ensuring it uses a valid certificate, then download it and select it in Xcode, or use the option in Xcode's account settings to download manual profiles. If the certificate also expired, create a new certificate first and rebuild the profile around it. Either way, once Xcode has a valid profile selected, rebuild the app so the new profile is embedded, and you are ready to upload or redistribute.
Renewing on the command line, Fastlane, and Expo EAS
For automated pipelines, renewal is handled by your tooling rather than the Xcode UI. Fastlane provides sigh for creating and renewing provisioning profiles and match for managing certificates and profiles centrally across a team, so running the relevant Fastlane action regenerates the expired profile and updates your CI. If you use match, it stores and syncs the signing assets, and renewing there propagates to every machine that pulls them. Expo EAS manages credentials for you, so its build service can regenerate an expired profile automatically, and its credentials command lets you inspect and manage them.
You can also check expiry from the command line. Decoding a mobileprovision file with the macOS security tool shows its expiration date, and listing your signing identities reveals whether the underlying certificate is still valid, which helps you confirm what expired before regenerating. In a CI context, the safe pattern is to let your credential manager, whether Fastlane match or EAS, renew the assets and then rerun the build, rather than hand-editing profiles on a build server. Automating renewal this way is what turns a yearly expiry from an emergency into a routine step.
The cause matrix
Matching the symptom to the cause tells you what to renew. The table below pairs common causes with their fix.
The causes map to fixes directly. A profile expired while the certificate is still valid shows up as a build-time signing error, and the fix is to regenerate the profile against that valid certificate. A certificate that expired or was revoked makes the profile invalid, so you renew the certificate first and then regenerate the profile. A wrong or old profile selected causes a mismatch at build or upload, fixed by selecting the current profile in Xcode. And an enterprise or ad-hoc profile that expired makes the app stop launching on devices, which needs a regenerated profile and a redistributed build.
Read the matrix by what failed: a build-time signing error usually means the profile or certificate, while an app that stops launching on a device means an embedded profile expired.
A safe retry path
The safe way to recover is to identify, renew, rebuild, and re-ship in order rather than guessing. First identify what expired, the profile, the certificate, or both, using Xcode's signing pane or the command-line checks. Renew the certificate if needed, then regenerate the profile, letting Xcode automatic signing or your credential manager do it where possible. Rebuild the app so the fresh profile is embedded, and confirm the build signs cleanly before going further.
Then re-ship according to your distribution. For the App Store, upload the new build to App Store Connect as usual, remembering your live app was never at risk. For ad-hoc, development, or enterprise distribution, redistribute the rebuilt app to your devices or users so they receive a version with a valid profile. Do not skip the rebuild step, because renewing a profile without rebuilding leaves your app embedding the old, expired one. Following this order avoids the common mistake of renewing credentials but shipping a stale binary.
Expiry impact by distribution
Seeing the impact by distribution clarifies urgency. The table below compares them.
| Distribution | App stops working at profile expiry? | What to do |
|---|---|---|
| App Store | No, Apple re-signs store apps | Renew locally only to build updates |
| TestFlight | Separate 90-day build expiry, not the profile | Upload a fresh build |
| Development | Yes, stops launching on devices | Regenerate the profile and rebuild |
| Ad-hoc or enterprise | Yes, stops launching on devices | Regenerate the profile and redistribute |
Read the table by how you ship: only directly-distributed builds stop working at expiry, while your App Store users are unaffected.
Renewal checklist
Working through these steps renews signing and gets you shipping again. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Identify what expired | Profile, certificate, or both | [ ] |
| Renew the certificate | Only if the certificate expired or was revoked | [ ] |
| Regenerate the profile | Xcode automatic signing or the developer portal | [ ] |
| Rebuild and re-sign | Embed the fresh profile in a new build | [ ] |
| Re-upload or redistribute | Send the new build where it needs to go | [ ] |
| Automate renewal | Use Fastlane match or EAS credentials for next time | [ ] |
The step people skip is rebuilding after regenerating, because a renewed profile does nothing until it is embedded in a fresh build, so the rebuild is what actually applies the fix.
Secure the rebuilt binary
Renewing a provisioning profile means producing a fresh build, which is a natural moment to confirm that build is secure before you upload or redistribute it. A rebuild triggered by an expiry is still a release, and it can carry the same security issues any release can.
A scanner like PTKD.com analyzes your build and reports issues such as leaked keys and secrets, insecure data storage, and over-broad permissions by severity, mapped to OWASP MASVS, so the binary you re-sign and ship is checked, not just re-signed. To be clear about the boundary: PTKD does not manage your certificates, profiles, or signing, which you handle in Xcode or your credential manager. It checks the rebuilt app so a routine signing renewal also confirms the build is sound.
What to take away
- Whether an expired provisioning profile crashes your app depends on distribution: App Store apps are fine because Apple re-signs them, while development, ad-hoc, and enterprise builds stop launching.
- Identify whether the profile, the underlying certificate, or both expired, since a profile is only as valid as the certificate inside it.
- Renew via Xcode by letting automatic signing regenerate the profile on rebuild, or regenerate it manually in the developer portal against a valid certificate.
- On CI, let Fastlane match or Expo EAS renew the credentials and rerun the build, and always rebuild so the fresh profile is embedded.
- Re-upload or redistribute the rebuilt app, and scan it with a tool like PTKD.com so the re-signed build is also secure.
