Apple Developer Certificate Expired? 2026 iOS Release Fix
📋 Table of Contents
Archive or upload fails, but Xcode only reports a signing error. Fastest fix: identify whether the certificate, Provisioning Profile, private key, or membership is actually invalid, update only that asset, then verify signing on the Mac that builds the release.
Who this is for: Independent developers facing a failed iOS release after a certificate expires.
Small-team release owners syncing replacement certificates and profiles.
Remote build maintainers whose local Mac signs successfully while the remote Mac does not.
Treat the signing error as a symptom, not a diagnosis
An error such as “No signing certificate” does not tell you which part of the signing chain failed. A certificate may be expired or revoked. A Provisioning Profile may be expired or may not include the certificate, App ID, or capabilities your build requires. The Mac may lack the private key, or your developer membership may need attention.
Start with observable status rather than creating replacement assets. Open the developer account’s certificate list and check the exact certificate type and status. In Xcode, inspect the target’s signing settings and the build log for the selected identity and profile. Apple’s certificate overview distinguishes certificate types and their uses; use that distinction before changing a signing setup.
| Observed state | Likely scope | Triage rating | First action |
|---|---|---|---|
| Apple Development certificate expired | Development signing and builds using that identity | High for development; not proof of a distribution failure | Confirm the target and intended build destination, then replace the development signing asset if needed |
| Apple Distribution certificate expired | New release signing with that identity | High for a pending release | Check membership and team access, then use a valid distribution identity |
| Certificate revoked | The revoked identity is no longer a valid signing choice | High | Confirm who revoked it and why; do not treat this as ordinary expiration |
| Provisioning Profile expired or mismatched | The app, capabilities, or included signing identity may not match | High when the build selects that profile | Inspect its status and contents; refresh only if the evidence requires it |
| Developer membership inactive or restricted | Account-level access or distribution may be affected | Stop and investigate | Check membership and team permissions before changing certificates |
The ratings above are troubleshooting priorities, not Apple-defined severity labels. Apple documents certificate purposes and account actions separately; an expired identity, a revoked identity, and a membership issue are not interchangeable. Review Apple’s certificate access and revocation guidance before removing or replacing an identity.
An App Store Distribution certificate expiring is not the same as an already published app immediately becoming unusable. Apple says an expired distribution certificate prevents signing new apps or updates with that certificate, while apps already available in the App Store remain available. A new release still needs a valid signing setup. See Apple’s certificate expiration guidance and apply it to the certificate type you actually use.
Separate expiration from revocation and membership
Expiration means the certificate has reached the end of its validity period. Revocation is a deliberate account action that invalidates the certificate before or after that point. A replacement certificate may be necessary in either case, but the reason matters: revocation can indicate a security response, a team handoff, or cleanup after a migration. Find out why it was revoked before generating more credentials.
Developer membership is another separate state. If the membership is inactive, replacing a certificate may not restore the account capabilities required for release. Check the team’s membership status and renew it through the account process when appropriate; Apple describes the renewal and its effects in its membership renewal guidance. If the account reports a membership or permission problem, stop certificate rotation and resolve that account-level issue first.
Also separate Apple Development from Apple Distribution. The former is used for development signing; the latter is used to sign distribution builds. A development build failing does not prove that your App Store release certificate expired, and a development certificate renewal does not repair a broken distribution profile. Apple’s certificate documentation lists certificate types and their intended uses.
Developer ID is a different signing purpose associated with distributing Mac software outside the App Store. Do not substitute a Developer ID identity when your target is an iOS App Store release. Identify the target platform and distribution route before choosing a certificate.
Check the identity on the Mac that signs
A certificate shown in the developer account is not the whole signing identity. The Mac that signs must have the corresponding private key available in its Keychain. The public certificate and private key work together; downloading or creating a certificate in the account does not automatically put its private key on every Mac.
On the signing Mac, open Keychain Access and locate the intended identity. Confirm that the certificate is paired with its private key and that the build account can access it. If the certificate is present but no matching private key appears, that Mac cannot use the identity to sign. Restore the private key through your team’s approved credential process or create and use a valid replacement identity. Do not assume that repeating the certificate download repairs a missing private key.
Then inspect the project’s signing configuration. Check the build configuration and target used for the release, the selected team, the signing identity, and whether automatic or manual signing is enabled. Read the build log to see which identity and profile Xcode actually selected; do not infer the selection from a setting on a different target or scheme.
| Evidence on the signing Mac | What it tells you | Repair branch |
|---|---|---|
| Identity and matching private key are present | The Keychain has a usable pair, subject to access and build settings | Check the selected team, target, profile, and permissions |
| Certificate is present but private key is absent | The Mac cannot sign with that certificate identity | Restore the matching private key securely or use a valid replacement |
| A valid identity exists, but the build selects another one | The failure may be target, configuration, or signing-setting selection | Correct the build’s selected identity and repeat the Archive |
| Signing assets are correct but the account rejects an action | The issue may be team role, membership, or account access | Verify permissions and membership; do not keep recreating assets |
| Local signing works but the runner does not | The two machines do not have equivalent signing state | Inspect the actual runner’s Keychain, account, Xcode settings, and profile |
Apple explains how teams can manage signing certificates in its team certificate sharing documentation. Use an approved team process for private keys. A certificate appearing in the account is not evidence that a particular build account can access the associated key.
Refresh only a profile that is expired or mismatched
A Provisioning Profile links the app’s signing setup to an App ID, entitlements, and a signing certificate. For development and some other distribution workflows, it can also carry device authorization. If the certificate changes, the profile may need to be refreshed so it includes the identity the build will use. Do not regenerate every profile merely because one certificate expired.
Inspect the selected profile and check its expiration status, App ID, capabilities, and included certificate. Compare those values with the target’s bundle identifier, entitlements, and intended distribution method. If they do not match, use Apple’s profile editing and download steps to update the profile, then install or retrieve it in the environment that signs.
The workflow depends on profile ownership. With Xcode-managed signing, let Xcode refresh the profile after you confirm the right team, target, and identity are selected. With a manually managed profile, regenerate or edit the specific profile in the developer account, download it, and make sure the build selects that updated file. Apple’s Provisioning Profile update guidance describes why profiles need updates and how they relate to signing assets.
Do not use a newly generated profile as a substitute for checking the private key. A profile can include the correct certificate while the actual build Mac still lacks the key needed to sign.
After refreshing the profile, verify that the project is not still selecting an older local copy. Check the profile identifier or the profile shown in the build log, not just the file you most recently downloaded. For a manual-signing project, confirm the updated profile is available to the same macOS user that runs the build.
Use this decision path before rotating more assets
Choose the repair branch that matches the evidence. If the evidence does not support a signing-asset failure, stop and investigate account or service status instead.
- If the developer account shows an expired certificate of the type used for this release, check membership and team access, then create or select a valid identity for that purpose. Otherwise, do not replace a different certificate type just because Xcode reports a generic signing failure.
- If the certificate is revoked, confirm the reason and whether the team intended to invalidate it. Otherwise, treat a still-valid certificate as usable only after confirming its private key is present on the signing Mac.
- If the selected profile is expired or omits the intended certificate, App ID, or capability, refresh that profile and verify the build selects it. Otherwise, leave it unchanged and inspect the identity, key access, and target settings.
- If the local Mac signs but the remote Mac fails, audit the remote runner’s user, Keychain, Xcode configuration, and profile. Otherwise, compare the build log and account state before modifying remote credentials.
- If membership, team permission, or an Apple service issue is indicated, pause certificate and profile changes and resolve that blocker. Otherwise, proceed to a release Archive and verify its signing evidence.
This order reduces the chance of turning one stale profile into several unrelated signing changes. It also gives you a clear stop condition: account-level evidence calls for account-level troubleshooting, not repeated certificate revocation.
Confirm the repair on the actual release path
A green local build is not sufficient if the release is produced by a remote Mac or automated runner. Record which Mac and macOS account perform the Archive. Confirm the same environment has the intended identity and private key, the correct profile, the expected Xcode project settings, and access to the right team.
For a fastlane match workflow, inspect whether the runner received the intended assets and whether the lane is using the expected signing configuration. The official fastlane match documentation describes its certificate and profile synchronization behavior, including read-only use. In a release lane that should consume existing assets rather than create or modify them, check that the lane is configured for that read-only boundary. Do not confuse a successful repository sync with proof that the runner’s Keychain and selected profile are correct.
Run an Archive with the same scheme, configuration, and export method used for the release. Review the build log for the signing identity and profile selected. Then export the archive for the intended distribution route and verify that the exported artifact uses the expected signing assets. A successful Archive alone does not prove that the export or upload path is ready.
Complete the upload step and inspect its result in the relevant release workflow. If signing succeeds but upload fails, preserve the upload error and diagnose that stage separately; do not rotate certificates without evidence that signing assets caused the rejection. If the error points to membership, role permissions, or an Apple service problem, stop. Repeatedly revoking and recreating certificates will not repair an account or platform issue.
When you need a clean environment for this verification, review the available MacDate remote Mac options. If you are comparing recurring access with a dedicated build machine, the Mac mini cost guide can help frame the hardware decision without assuming that rental fits every workload.
Frequently asked questions
Can you upload an App Store update after a distribution certificate expires?
An expired Apple Distribution certificate generally blocks signing and uploading a new build with that certificate; it does not by itself mean an app already published in the App Store immediately stops working. Confirm the certificate status and membership first, then use a valid distribution identity for the new Archive. If the account or service is unavailable, stop before revoking or recreating assets.
Does renewing a distribution certificate require a new Provisioning Profile?
Check the profile's status, App ID, capabilities, and included signing certificate. If it is expired or does not include the certificate you intend to use, edit or regenerate it and install the updated profile on the Mac that performs signing. A profile managed automatically by Xcode may be refreshed through Xcode; a manually managed profile needs an explicit update and download.
Why does signing still fail on a remote Mac after renewal?
The certificate visible in your developer account is not proof that the build Mac has its matching private key. Check the actual runner, macOS account, Keychain, selected signing identity, profile, and Xcode build settings. With fastlane match, verify that the runner received the intended signing assets; a local Keychain update does not synchronize itself to another machine.
How do Apple Development and Apple Distribution expirations differ?
Apple Development identities are for development signing and related testing workflows; Apple Distribution identities are for distributing release builds, including App Store submission. An expired development certificate can block a development build without proving that App Store distribution assets are invalid. Diagnose the certificate type and intended build destination before replacing any identity.
If the signing assets pass local checks but the release still depends on a Mac that is unavailable or inconsistent, the build environment is the next operational risk to address. A self-managed Mac gives you direct control but requires you to maintain the hardware, macOS account, Keychain, and availability; a generic cloud runner may not provide the persistent signing state your workflow expects. For temporary release work, team handoffs, or a remotely accessible signing environment, using a MacDate Mac on a weekly or monthly basis can avoid buying a dedicated machine solely for intermittent builds. If you need that access, review the MacDate remote Mac plans; teams with continuous, heavy signing workloads or a need for physical interfaces should compare that option with owning and maintaining a local Mac.