What happens when your Apple certificates expire

Apple's "your certificate will expire in 30 days" email has a special talent for landing when the person who set up signing is on holiday. The panic it triggers comes from not knowing what actually breaks, and the answer is: it depends entirely on the certificate type. Some expirations are a non-event. One of them takes every install of your app down on the same morning.

This guide walks through each certificate type: what stops working the moment it expires, what keeps working and why, and what to do in both the "30 days left" and the "it expired yesterday" situations. If you want the one-line reassurance first: a live App Store app does not stop working when your Apple Distribution certificate expires. If you distribute enterprise in-house apps, skip straight to that section, because your situation is the opposite.

The short answer

Why live App Store apps do not break

Your distribution certificate's job ends at the App Store's front door. It proves to Apple that the upload came from your team. Once the build passes review, Apple re-signs it with Apple's own keys before delivering it to users' devices. What is on your customers' iPhones is not carrying your signature at all, which is why your certificate expiring (or being revoked, or the private key being lost) has zero effect on the app people already installed or on new downloads from the store.

What an expired distribution certificate does break is your ability to produce new signed builds: CI pipelines fail at the signing step, and Ad Hoc builds installed on registered test devices stop launching once their profile lapses. TestFlight has its own clock: builds already uploaded stay installable until their own 90-day TestFlight expiry, independent of your certificate.

Two clocks: certificates and profiles

Every signed install outside the App Store is governed by two expiry dates. The certificate has one, and the provisioning profile embedded in the app has its own, capped at whichever comes first: one year from the profile's creation, or the expiry of the certificate it references. iOS checks the profile at launch. That detail decides most of the scenarios below: an installed app dies when its embedded profile expires, and the profile can never outlive the certificate.

Scenario by scenario

Apple Development certificate expired

Impact: developers only. Xcode refuses to sign new debug builds with the expired identity, and debug builds already on test devices stop launching when their profile goes. With automatic signing enabled, Xcode quietly creates a fresh Development certificate and moves on; the main cost is the flurry of confused "failed to launch" moments across the team that morning. Teams on manual signing create one replacement certificate, share the .p12, and regenerate the shared development profile.

Apple Distribution certificate expired

Impact: your release pipeline, not your users. The live App Store app keeps working and stays downloadable. What stops is everything that needs a new signature: release builds in CI, TestFlight uploads, Ad Hoc distribution. The fix is a new certificate, and because Apple allows a small number of active distribution certificates per team (three for most teams), you can create the replacement while the old one is still valid and switch over without a gap.

• Create the replacement early. Reusing the stored CSR keeps the same public key, which lets existing pinning and long-lived references survive rotation.
• Regenerate the App Store and Ad Hoc profiles against the new certificate.
• Swap the .p12 in CI secrets (or your signing service) and run one release build end to end before the old certificate lapses.
• Let the old certificate expire on its own. Revoking it early buys you nothing and invalidates any profile still pointing at it.

Enterprise certificate expired

This is the scenario the panic is justified for. Apps distributed in-house through the Apple Developer Enterprise Program are still signed by you (Apple never re-signs them), and iOS validates the embedded enterprise profile at launch. When the certificate or profile expires, every installed copy on every employee device stops launching, simultaneously. The enterprise distribution certificate lasts three years, but the profiles it signs last one, so the annual event teams actually manage is profile renewal.

• Before expiry: regenerate the profile (or rotate the certificate and then regenerate), re-sign the app, and push the updated build through your MDM. Users must receive the update before the old date passes.
• Already expired: nothing on the device is recoverable in place. Re-sign with a valid certificate and profile and redeploy; devices need the new build installed before the app opens again.
• Put the expiry dates in more than one calendar. A three-year certificate outlives job tenures, and "the person who knew left" is the standard enterprise outage story.

Developer ID certificate expired

Impact: surprisingly gentle, if you signed correctly. Mac apps distributed outside the App Store keep launching after the certificate expires, because a Developer ID signature made with a secure timestamp (codesign's --timestamp flag) stays valid forever, and notarization tickets do not expire either. Gatekeeper honors both. What you lose is the ability to sign anything new: no updates, no new releases, until you create a replacement certificate. Developer ID certificates last five years, long enough for the renewal to be nobody's remembered responsibility.

Push certificate expired

Impact: invisible until users complain. The app works, the store listing works, but APNs rejects your server's connection and notifications silently stop. Renewal is downtime-free because Apple allows two active push certificates per app: create the new one, install it on the sender, verify delivery, revoke the old one. If this is the second time you are renewing one, take the hint and migrate to an APNs auth key, which never expires and covers every app on the team.

Expiry is not revocation

The two get conflated in a way that causes real damage. Expiry is the gentle path: it happens on a known date, already-shipped App Store and timestamped Developer ID apps are unaffected, and you fix it by creating a replacement. Revocation is immediate and retroactive: every profile referencing the certificate becomes invalid now, in-flight CI builds fail now, and a revoked Developer ID certificate can get shipped Mac apps blocked by Gatekeeper. Revoke when a private key leaks or a machine holding it is compromised. Do not revoke as a cleanup step while rotating, and be careful with tools whose reset flow revokes everything as a side effect (fastlane match's nuke command is the famous one).

If your whole membership lapses

Letting the Apple Developer Program membership itself expire is a different tier of problem. Your apps are removed from the App Store (existing installs keep working on users' devices, but nobody can download the app), TestFlight builds stop being available, and you cannot sign or submit anything. For Enterprise Program members it is worse: certificates tied to the lapsed membership stop validating, which takes in-house apps down. Renewal restores App Store listings, but plan for days, not minutes, and for the case where the renewal payment or the account holder's ID needs verification. The membership renewal date belongs on the same watchlist as the certificates.

How long everything lasts

The rotation playbook

Every scenario above has the same happy-path version: the replacement existed before the deadline, and nobody outside the platform team noticed anything. Getting there is a repeatable five-step routine.

1. 1

   Know your dates

   List every certificate, profile, and the membership itself with expiry dates, and get alerts flowing to a channel people read, not to the inbox of whoever created the account four years ago.

2. 2

   Map what depends on each certificate

   Which profiles reference it, which CI systems hold its .p12, which teammates' Macs have the key. Rotation goes wrong at the dependency nobody listed.

3. 3

   Create the replacement while the old one still works

   Apple's per-type caps exist precisely to allow overlap. Reuse the CSR where you want the same public key to persist.

4. 4

   Regenerate profiles and update every consumer

   Profiles first, then CI secrets, then developer machines. Run one full release build through the new identity as the proof.

5. 5

   Let the old certificate expire quietly

   No revocation unless the key is compromised. Expired-but-not-revoked is the state that keeps timestamped signatures and old profiles' history intact.

The manual version of this routine lives in the help center: rotate an expiring certificate and configure expiration alerts cover the step-by-step.