When an iOS distribution certificate expires, you do not renew or extend it, because Apple certificates cannot be extended; instead you create a new certificate and regenerate the provisioning profiles that used the old one. The good news for the common worry is that your apps already on the App Store are not affected by an expired distribution certificate, so they keep running and stay available; you simply cannot upload new builds until you have a valid certificate again. In-house enterprise and ad hoc builds are different: apps signed with the expired certificate stop running, so you must ship a new version signed with a new certificate. You also need the certificate's private key from your Keychain to sign at all, so if that key is missing you create a new certificate.
Short answer
An expired distribution certificate is replaced, not renewed, and it does not take your live apps down. Per Apple's certificates support, an expired certificate cannot be extended, so you create a new one, and apps already on the App Store are unaffected while your membership is valid, though you cannot upload new builds signed with the expired certificate. Enterprise and ad hoc apps signed with it do stop working. To sign, your Keychain must contain the certificate, its private key, and the WWDR intermediate certificate, per Apple's code signing support. The simplest path is to let Xcode automatic signing, Fastlane match, or Expo EAS create the new certificate and profiles for you.
Will my current apps break?
For App Store apps, no, which is the reassurance most people are looking for. An expired distribution certificate does not affect apps already on the App Store, so your published apps keep working and stay downloadable as long as your Apple Developer Program membership is valid. What you lose is only the ability to upload new apps or updates signed with the expired certificate, so the impact is on shipping new builds, not on the apps users already have.
Enterprise and ad hoc distribution are the exception, and there the answer is yes. For in-house apps distributed with an enterprise certificate, and for ad hoc builds, apps signed with an expired certificate stop running for users, because those distribution types validate the signing certificate on the device. So if you distribute outside the App Store, an expired certificate does break installed apps, and you have to distribute a new version signed with a new certificate to restore them. That difference by distribution type is the key thing to know first.
You create a new certificate, not renew it
Because Apple certificates cannot be extended, renewing an expired distribution certificate really means creating a new one, which is where the revoke question comes in. You generate a new certificate, and as part of tidying up you can revoke the old expired one in the developer portal. Revoking is a separate action from expiry: a certificate that has already expired is invalid anyway, but revoking is also how you invalidate a still-valid certificate early, for example if it was compromised, or how you free a slot, since Apple limits how many distribution certificates an account can have.
So think of it as replace, with revoke as a housekeeping step rather than the fix itself. If you are at the certificate limit and need to create a new one, revoking an old certificate makes room. Revoking a distribution certificate used for the App Store does not break your live apps for the same reason expiry does not, but revoking a certificate used for enterprise or ad hoc distribution invalidates the apps signed with it immediately. So revoke deliberately, understanding which distribution type the certificate serves.
Certificates, profiles, and keys
It helps to keep three things straight, because an expiry touches all of them. The certificate is your signing identity, proving builds come from you. A provisioning profile ties together an app ID, one or more certificates, and, for non-App-Store distribution, a set of devices and capabilities. The private key is the secret half of the certificate, held in your Keychain, that actually signs the build. Signing needs the certificate and its matching private key together.
When the certificate changes, the profiles that referenced it are no longer valid for signing, so regenerating the certificate is only half the job; you also regenerate the provisioning profiles so they point at the new certificate. This is why a certificate expiry often surfaces first as a profile or signing error in your build. So after creating the new certificate, refresh your profiles, which automatic tooling does for you, and your build has a consistent certificate and profile pair again.
The private key and Keychain
To use any certificate you need its private key, and that key lives in your login Keychain from when you generated the certificate signing request. Signing fails without it, so your Keychain must contain the certificate, its private key, and the WWDR intermediate certificate that chains your certificate to Apple. If any of those is missing, code signing cannot complete, which is a common cause of signing errors that look like a certificate problem.
This is also why the private key is the thing to protect. If you lose the private key, the certificate is unusable and you simply create a new certificate rather than trying to recover the old one. To move signing to another Mac or to a continuous integration server, export the certificate together with its private key as a .p12 file from the Keychain Access app, and keep that .p12 backed up securely. Managing the key well is what prevents an expiry from becoming a scramble.
How to renew via Xcode
The easiest route is Xcode's automatically managed signing, which handles the replacement for you. With automatic signing enabled for your target, Xcode detects the expired certificate, creates a new distribution certificate under your account, and regenerates the matching provisioning profiles, so you often just build again and Xcode sorts out the identity. This is the least error-prone path for most developers.
If you manage signing manually, you do the same steps by hand in the developer portal: revoke the old certificate if needed, create a new certificate signing request from Keychain Access, use it to create a new Apple Distribution certificate, download and install it, and then regenerate your provisioning profiles to use the new certificate. Either way the outcome is a fresh certificate and refreshed profiles. So unless you have a reason to manage signing manually, letting Xcode manage it turns a certificate expiry into a rebuild.
Fastlane and Expo EAS
If you build in a pipeline, your tooling manages certificates so you do not do it by hand each time. Fastlane match stores your certificates and profiles centrally, typically in an encrypted git repository, and regenerates them across machines; when a certificate expires, match can recreate the certificate and profiles, and its nuke command revokes and recreates them cleanly when you need a fresh start. This keeps every machine and CI runner using the same, current signing identity.
Expo EAS handles credentials for you as well, managing your distribution certificate and provisioning profiles for EAS builds and renewing them as part of the build when they expire, so a managed Expo project often needs no manual certificate work. So in both Fastlane and EAS setups, the certificate expiry is handled by the tool rather than by editing the portal, and your job is to run the build or the credential command and let it produce a valid certificate and profile.
Cause and fix at a glance
Matching the symptom to the fix keeps this quick. The table below maps common cases.
| Symptom | Cause | Fix |
|---|---|---|
| Cannot upload a new build | Distribution certificate expired | Create a new certificate |
| Signing fails, key not found | Private key missing from Keychain | Import the .p12 or make a new certificate |
| Enterprise or ad hoc app stopped | Certificate expired for that build | Ship a new build with a new certificate |
| At the certificate limit | Too many distribution certificates | Revoke an old one, then create a new one |
| Profile invalid after new cert | Profile references the old certificate | Regenerate the provisioning profiles |
Read the last row as a reminder: after a new certificate, refresh the profiles, or signing still fails.
Renewal checklist
Working through these steps restores signing safely. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Confirm the impact | App Store apps are fine; enterprise and ad hoc break | [ ] |
| Create a new certificate | Replace the expired one, revoking if needed | [ ] |
| Check the private key | Ensure the Keychain has the key and WWDR cert | [ ] |
| Regenerate profiles | Point provisioning profiles at the new certificate | [ ] |
| Rebuild and re-sign | Produce a fresh build with the new identity | [ ] |
| Verify and upload | Confirm the signature, then submit | [ ] |
The step teams skip most is regenerating the provisioning profiles, since a new certificate leaves the old profiles invalid and signing keeps failing until they are refreshed.
Where a scan fits
Renewing a certificate is a signing and pipeline task, but the build you re-sign afterward is worth a security check, which is independent of the signing itself.
A scanner like PTKD.com analyzes your app build for security issues such as exposed keys, over-broad permissions, and risky third-party code, mapped to OWASP MASVS. To be clear about the boundary: PTKD does not create or manage your certificates, which are your Apple signing setup. Since a certificate expiry means rebuilding and re-signing, it is a natural moment to scan the resulting binary, so you ship a build that is both correctly signed and checked for security.
What to take away
- You cannot renew or extend an expired iOS distribution certificate; you create a new one and regenerate the profiles that used it.
- Apps already on the App Store are not affected by an expired distribution certificate, so they keep working; you only lose the ability to upload new builds.
- Enterprise and ad hoc apps signed with the expired certificate do stop working, so you must ship a new version signed with a new certificate.
- Signing needs the certificate's private key from your Keychain plus the WWDR intermediate, so back up the private key as a .p12 and create a new certificate if the key is lost.
- Let Xcode automatic signing, Fastlane match, or Expo EAS create the new certificate and profiles, and use a tool like PTKD.com to scan the rebuilt binary.
