When an iOS distribution certificate for the App Store expires, apps already on the store are unaffected, but you cannot upload new builds signed with it. For in-house (enterprise) distribution, users can no longer run apps signed with the expired certificate. Renew before the date, and track every expiry.
What Apple says
Apple's certificates page describes the consequences type by type. Two matter here.
| Certificate use | If it expires or is revoked |
|---|---|
| iOS Distribution for the App Store | Existing App Store apps are unaffected. You cannot upload new builds signed with it. |
| iOS Distribution for in-house distribution | Users can no longer run apps signed with it. |
The page also gives a related example: if a Pass Type ID certificate expires, passes already installed keep working, but you cannot sign new passes or send updates.
The pattern is useful. An expiry rarely breaks software already in users' hands for store distribution. It breaks your ability to ship the next build. For in-house apps, the signature is checked on devices, so the break is immediate and visible to every user.
Why store apps survive
Apple's technote on provisioning profiles describes the store flow. When you submit to the App Store, it re-signs the app as part of distribution, after checking that the app is signed and provisioned correctly. Because of that check, individual devices do not need to repeat it, and the final app has no provisioning profile.
That is why an expired store certificate blocks new uploads, which pass through that check, but does not disable apps already distributed.
Profiles expire too
Every provisioning profile has an expiration date. Apple's technote says the validity varies by profile type but is typically not more than a year, and that Developer ID profiles are the exception with expiration far in the future. A profile you forgot about can block a build just as an expired certificate can.
Certificates and profiles are linked, since a profile lists the certificates of developers who may sign code covered by it. Renewing one without the other is a common cause of a broken build.
Build a renewal routine
- Inventory. List every certificate and profile, its type, its owner and its expiry date.
- Alert early. Set reminders well before expiry so there is time for approvals.
- Name an owner. Apple notes that distribution certificates belong to the team and that only an Account Holder or Admin can create them, so make sure one of those people is reachable.
- Rehearse. Practice a renewal in a quiet week, including updating CI secrets.
- Record it. Keep a short log of what was renewed and when.
Apple also states that only one of each distribution certificate type is allowed per team, so replacing a certificate can mean revoking the old one first. Check what depends on the old certificate before you do.
In-house apps need extra care
Because an expired in-house certificate stops the app on user devices, treat its renewal as an incident-grade deadline. Test the renewed build on a spare device before you roll it out to staff.
Where Safeguard fits
Certificates control who may sign a build. Safeguard covers the dependencies inside it, with dependency scanning and SBOMs, and offers a free scan at gold.safeguard.sh/scan.
Quick check
Do my live App Store apps stop working if the certificate expires?
Per Apple, no. Existing App Store apps are unaffected, but you cannot upload new builds signed with the expired certificate.
What about in-house apps?
Apple states that users can no longer run apps signed with an expired in-house distribution certificate.
How long does a provisioning profile last?
Apple says it varies by type but is typically not more than a year. Developer ID profiles are the exception.
Sources
Last reviewed: 19 October 2026.
