Your signing certificate expired, and the app people already installed kept running.
If you distribute through the App Store, an expired distribution certificate does not reach into anybody's phone. Apple states that while your Apple Developer Program membership is valid, your existing apps on the App Store will not be affected. What stops is the next release. You cannot upload a new app or an update signed with the expired certificate to App Store Connect, so the queue backs up behind a file you cannot sign. There is one real exception, and it is in-house distribution, where Apple says users will no longer be able to run apps signed with that certificate at all. Every fact and screen name on this page comes from Apple's and Android's own documentation, read on 16 October 2026.
What follows is which certificate broke what, why the provisioning profile is a second thing with its own expiry date, why the same event is much milder on Google Play, and the order to do the repair in. The short version of the repair: you do not renew a certificate, you make a new one.
Start hereThe short version
The expiry hits your next release, not the one you already shipped.
A signature is checked when the build is made and when the store accepts it. For an app distributed through the App Store or the Mac App Store, Apple's documented outcome of an expired or revoked distribution certificate is that existing apps are not affected and new uploads signed with it are refused. Nobody has to reinstall anything. Nobody gets an error on launch. The thing that is broken is your ability to ship.
The in-house case is the opposite and is worth naming early, because it is the one that causes a panic that deserves to be a panic. If you distribute an internal app to staff with an enterprise iOS Distribution certificate, Apple says that when it expires or is revoked, users will no longer be able to run apps signed with it, and you must distribute a new version signed with a new certificate. Same word, certificate, entirely different Monday morning.
Did my live app just stop working?
It depends which certificate expired, and the honest answer is that Apple publishes eight or so different answers rather than one. The two store ones are the mild cases. For iOS Distribution used for the App Store, and for the Mac App Distribution and Mac Installer Distribution pair used for the Mac App Store, the published outcome is the same: with a valid Apple Developer Program membership, your existing apps on the store will not be affected, and you simply cannot upload anything new signed with the expired or revoked certificate.
Then there are the certificates that do stop something a customer can see, without stopping the app. An expired Apple Push Notification service certificate means you can no longer send push notifications to your app. An expired Apple Pay payment processing certificate means Apple Pay transactions in your apps and on your websites will fail. In both cases the app launches, looks healthy, and quietly does less than it did last week. These are the ones that get found by a customer rather than by a build.
Expiry and revocation are also different events and Apple words them differently on purpose. A Developer ID Application certificate that expires leaves users able to download, install and run versions of your Mac app already signed with it. The same certificate revoked means users can no longer install applications signed with it. Apple is explicit that it can revoke digital certificates at any time at its sole discretion, so if your situation came from a revocation notice rather than an expiry date, read the stricter line.
One consolation for anyone watching a dashboard: none of this shows up as a review decision. A build refused for a signing problem never reaches a reviewer, so it does not land in the rejection rates that people quote when they argue about how hard the App Store is. Signing failures are invisible in that statistic and common in real life, which is part of why they catch people out.
Apple Developer Support, Certificates, read 16 October 2026
Which one expired
Pick the certificate and read the damage
There is no single answer, because Apple gives a different one for each kind of certificate. Pick the one your email names. Every answer below is Apple's own, from the certificates page cited in this section.
Nothing picked yet. If you are not sure which certificate it is, open Certificates, Identifiers and Profiles in your developer account and read the Type column next to the expiry date.
So what is the provisioning profile, and did that expire too?
These are two files with two clocks, and treating them as one thing is the most common way people spend an afternoon on a ten minute job. The certificate is the signing identity. It says a build came from your team. Apple is clear about the ownership: distribution certificates belong to the team, not to the developer who made them, and only one of each distribution type is allowed per team, with Developer ID certificates excepted. Only the Account Holder or an Admin can create them. If you enrolled as an individual, you are the Account Holder.
The provisioning profile is the other file. It binds a certificate to an app identifier, to the entitlements the app is allowed to use, and, for builds installed directly on hardware, to a list of devices. Apple Developer Account Help, in its page on editing, downloading and deleting provisioning profiles, read on 16 October 2026, gives the repair as its own procedure: if you enable or disable app services, or if a provisioning profile expires, you need to regenerate the provisioning profile. In Certificates, Identifiers and Profiles you click Profiles in the sidebar, select the invalid or expired profile, click Edit, then click Generate.
Two details in that procedure do the real work. The first is that regenerating the profile is not the end of it. Apple tells you to remove the expired profile from all devices in Xcode and re-sign your app using the regenerated profile, which means a build already sitting on a test device does not heal itself when you fix things in the browser. The second is a note that explains why your profile list can look empty while everything is on fire: Xcode managed development and distribution provisioning profiles do not appear in your developer account at all. If Xcode has been handling signing automatically, there is nothing in that list to edit.
The practical order, then. Fix the certificate first, because the profile references it and a profile regenerated against a dead identity is still dead. Then regenerate the profile. Then build. Replacing the certificate does not silently refresh anything that points at it, which is the whole reason these two show up in the same support thread and get confused for one another.
Apple Developer Support, Certificates, on ownership, roles and revocation, read 16 October 2026
Why is the same problem so much smaller on Google Play?
Because with Play App Signing you are not the one signing the copy that reaches a phone. Android's signing documentation describes two keys doing two jobs. You keep the upload key and use it to sign your app for upload to the Play Store. Google uses the upload certificate to verify your identity, then signs the APKs with your app signing key for distribution. The app signing key lives on the same infrastructure Google uses for its own keys, protected by its Key Management Service, and the documentation says it never changes during the lifetime of your app.
That split is what makes an upload key problem survivable. Google says that if you lose your upload key or suspect it was compromised, you can request an upload key reset in the Play Console, and that because the app signing key is secured by Google you can keep uploading new versions as updates to the original app even after you change upload keys. There is an explicit note that resetting the upload key does not affect the app signing key Google uses to re-sign APKs before delivering them. You create a new key, export its certificate, and ask for the swap.
The case that does bite on Android is signing your own release yourself, which is what a standalone APK handed out directly means. Android's documentation says that if you plan to support upgrades, the app signing key's validity period should exceed the expected lifespan of the app, recommends 25 years or more, and warns that when the validity period expires, users will no longer be able to seamlessly upgrade to new versions. Google Play also enforces a floor: a key used to sign an app published on Play must have a validity period ending after 22 October 2033.
One Android expiry is harmless and still manages to ruin a morning. The self signed certificate used for debug builds expires 30 years after it was created, and when it does, Android Studio gives you a build error. The documented fix is to delete the debug keystore file and build and run a debug version again, at which point Android Studio regenerates the keystore and the debug key. If your release signing is fine and only local builds fail, check which keystore the error is actually complaining about before you touch anything real.
Android Developers, Sign your app, last updated 6 March 2026, read 16 October 2026
What do I do now, and in what order?
Start by finding out who can act, because this is a permissions problem before it is a technical one. Creating a distribution certificate needs the Account Holder or an Admin, and the limit of one of each distribution type per team means somebody has to decide to replace the team's certificate rather than quietly add another. Then make the new certificate, regenerate any provisioning profile that referenced the old one, re-sign, and upload. There is no renew action anywhere in this sequence. Replacement is the only shape the fix comes in.
Expect one small administrative snag at the upload. The rebuilt binary is a different build of a version you may already have uploaded, so it needs a build number the store has not seen before. That is a sixty second job if you understand how version numbers and build numbers relate to each other, and a confusing twenty minutes if you do not. Increment the build number, leave the version string alone unless the content changed, and upload again.
If a build you uploaded before all this is now showing as Invalid Binary, do not treat that as a review decision. Apple says builds already uploaded to App Store Connect but not yet submitted for App Review may be marked Invalid Binary when they were signed with a revoked certificate. No reviewer formed an opinion, so the process for appealing a rejection is the wrong door to knock on. Sign a fresh build, bump the build number, upload, carry on.
Last, write the dates down before you close the tab. Certificates, Identifiers and Profiles shows an expiry date beside every certificate, and Play Console shows your certificate details under Manage Play app signing. Put the earliest date in a calendar several people can see, not one developer's. Give the push notification and Apple Pay certificates their own entries, because those two expire without breaking a launch and therefore without telling anybody.
Android Developers, Sign your app, on upload key resets, last updated 6 March 2026
The same expiry, judged by who signs the copy a user installs
Read down the column that matches how your app reaches people. The two store columns are mild because a store holds a key on your behalf. The third column is the one where your own key is the only key, which is the case for an enterprise iOS build and for a standalone Android package you distribute yourself.
| The question | App Store | Google Play, Play App Signing | You sign the install yourself |
|---|---|---|---|
| The copy people already installed | Unaffected while your membership is valid | Unaffected, Google signs what users install | Stops running |
| Your next update | Blocked until it is signed with a valid certificate | Blocked until it is signed with a valid upload key | Ships only as a new version signed with a new certificate |
| The store can hand you a replacement key | A new distribution certificate, one of each type per team | Yes | No |
| A changed key breaks upgrades for existing installs | No | No | Yes |
| Where the expiry date is written down | Certificates, Identifiers and Profiles | Play Console, Manage Play app signing | Only in your own keystore |
Where this lands if a builder generated your app
The certificate is in your developer account either way, and that is the part people get wrong when a tool did the building. On iOS the signing identity, the roles that can replace it and the submission itself all sit with you. App Store Review Guideline 4.2.6 is why no builder can take that over: apps created from a commercialized template or app generation service are rejected unless they are submitted directly by the provider of the app's content. The certificate goes where the submission goes.
Newly is an AI app builder. You describe an app and it writes a real React Native and Expo project you own, with two way GitHub sync, so the code and the signing setup are both yours to inspect. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and can build a standalone Android package. It does not submit to the App Store for you, for the reason in the paragraph above. Pricing starts at $25 a month, with no free tier.
The honest consequence of owning the project is that you own this maintenance too. No builder can renew a certificate on your behalf, because the account and the roles are yours. What does help is that an expired certificate blocks releases and nothing else, so the cost is measured in releases missed. If your app sells anything, that is the bit to put a number on: a price change, a new tier or a fixed paywall that cannot ship is the part of app monetisation that is sitting still while you sort out a signature.
Questions people ask when a certificate expires
On the App Store, no. Apple's certificates page, read on 16 October 2026, says that if your Apple Developer Program membership is valid, your existing apps on the App Store will not be affected by an expired or revoked iOS Distribution certificate. The same sentence appears for the Mac App Store. What you lose is the upload: you can no longer upload new apps or updates signed with that certificate to App Store Connect. The one case where the live app does stop is in-house, internal-use distribution, where Apple says users will no longer be able to run apps signed with the certificate and you must distribute a new version signed with a new one.
Replace the certificate, then ship the release you were holding
New certificate, regenerated profile, fresh build number, upload. Then put the next expiry date somewhere more than one person will see it, and get back to the change you were actually trying to make.
Start building