You signed an app, installed it, used it for a week, and then one day it just stopped opening. No warning, no error, just a gray icon and a refusal to launch. If this has happened to you, your signing certificate was almost certainly revoked by Apple. Certificate revocation is the single biggest frustration in the sideloading world, and understanding how it works is the key to protecting yourself from it.
What is Certificate Revocation?
Every Apple Developer certificate has a lifecycle. It's created, it's used to sign apps, and eventually it expires (usually after one year). But Apple can also forcibly invalidate a certificate before it expires. This is called revocation. When a certificate is revoked, every app that was signed with it stops working on every device.
Apple maintains a revocation list, a database of certificates that have been invalidated. iOS periodically contacts Apple's servers to check this list. If iOS discovers that the certificate used to sign one of your installed apps has been revoked, it disables that app immediately. You'll see the app icon become grayed out, and tapping it will show an error.
Why Does Apple Revoke Certificates?
Apple revokes certificates for several reasons:
Terms of service violations. The most common cause. Apple's developer agreement specifies how certificates can be used. Enterprise certificates, for example, are intended only for distributing apps to an organization's own employees. When Apple discovers an enterprise certificate being used for public app distribution (which is how most free sideloading certificates work), they revoke it.
Abuse detection. Apple has automated systems that detect when a certificate is being used to sign an unusually high number of apps or is being used across too many devices. This triggers an investigation and often a revocation.
Security concerns. If Apple believes a certificate has been compromised or is being used to distribute malware, they'll revoke it immediately.
Developer request. A developer can request revocation of their own certificates, for example, if a team member's laptop is stolen and they need to invalidate the signing keys that were on it.
The Technical Process
Here's what happens under the hood when iOS checks for revocation:
- iOS contacts ppq.apple.com — Apple's provisioning profile query server. This happens periodically in the background (roughly every few days, though the exact timing varies).
- iOS sends certificate identifiers — it tells Apple which certificates signed the apps currently installed on the device.
- Apple responds — if any of those certificates have been revoked, Apple's server says so.
- iOS disables the apps — any app signed with a revoked certificate is immediately flagged. It won't launch until it's re-signed with a valid certificate.
This check happens over the internet, which means it requires an active network connection. If your device is in airplane mode or has no connectivity, it can't check for revocations and your apps will continue to work. This is also why DNS-based protection works.
How Quickly Does Revocation Take Effect?
Not instantly. There's a delay between when Apple revokes a certificate and when your device learns about it. This delay depends on when iOS next performs a revocation check, which isn't on a fixed schedule. In practice:
- Best case: your apps continue working for several days after revocation.
- Typical case: apps stop working within 1-3 days.
- Worst case: apps stop immediately if iOS happens to check right after the revocation.
Opening and closing certain apps, restarting your device, or connecting to a new network can all trigger a revocation check sooner.
Types of Certificates and Revocation Risk
Not all certificates face the same revocation risk:
Free and enterprise certificates (highest risk — not recommended). These are publicly shared, used by thousands of people, and don't require individual UDID registration. This makes them trivial for Apple to detect and revoke. Most free certificates last only days before being shut down, and some get revoked within hours of being published. They are fundamentally unreliable because their broad, open provisioning is exactly what Apple's automated detection systems look for. We do not recommend free certificates for regular use.
Paid certificates from FlareStore (low risk — recommended). When you purchase a certificate from flarestore.vip, your UDID is individually registered on the certificate. This means the certificate is tied specifically to your device rather than being shared publicly. Apple has far less reason (and far less ability) to detect and revoke these certificates. They typically last their full validity period and offer a dramatically better experience than free alternatives.
Your own Apple Developer account (very low risk). If you pay Apple $99/year for a developer account and create your own certificates, revocation is extremely unlikely unless you violate the terms of service. This is the most stable option, but also the most expensive and complex to manage. A paid certificate from flarestore.vip gives you similar stability without the hassle.
Protecting Your Apps from Revocation
There are several strategies to keep your sideloaded apps working:
1. Use a paid certificate (most important). The single best thing you can do is stop using free certificates. A paid certificate from flarestore.vip with your UDID individually registered faces dramatically less revocation risk than any free or enterprise certificate. Free certificates are shared among thousands of users and are specifically what Apple's detection systems target. If you're tired of your apps breaking every few days, switching to a paid certificate solves the root cause.
2. DNS-based anti-revoke (recommended alongside paid certs). By installing a DNS configuration profile that blocks connections to ppq.apple.com, you prevent iOS from ever checking whether your certificates have been revoked. Paired with a paid certificate, this provides near-bulletproof protection. FlareStore offers free DNS profiles at flarestore.app/dns/.
3. Avoid unnecessary revocation checks. Don't factory reset your device unnecessarily. Don't toggle airplane mode on and off repeatedly when you know a revocation is happening. Don't remove and reinstall the DNS profile without reason.
4. Keep backup signing assets. Have your P12 certificate and provisioning profile saved somewhere safe. If your apps do get revoked, you can re-sign them quickly with a new certificate rather than starting from scratch.
5. Use on-device signing tools. Apps like Feather can automatically re-sign your apps when a certificate renewal happens, minimizing downtime.
What to Do When Your Apps Get Revoked
If your apps stop working due to a revocation:
- Don't panic. Your app data is usually preserved. The apps are disabled, not deleted.
- Get a new certificate. If you were using a free certificate, this is the time to upgrade to a paid one from flarestore.vip. Free certificates will just get revoked again.
- Re-sign your apps using FlareStore's Web Signer or an on-device tool.
- Install the DNS profile if you haven't already to prevent it from happening again.
- If this keeps happening to you, you're almost certainly using free certificates. A paid certificate will end the cycle.
The re-signing process takes just a few minutes, and since your app data is stored separately from the app binary, you generally won't lose any saved data or settings.
The Future of Revocation
The sideloading landscape is evolving. The EU's Digital Markets Act forced Apple to allow alternative app marketplaces in iOS 17.4 (in the EU). As regulatory pressure increases globally, Apple may further relax restrictions on sideloading, which could reduce the need for certificate-based signing and the revocation issues that come with it.
Until then, the combination of a paid certificate from flarestore.vip and DNS-based revocation protection is the most practical approach for keeping your sideloaded apps running without interruption. Stop gambling with free certificates that get revoked every few days. Invest in a paid certificate once and enjoy sideloading the way it's meant to work.