You can't ship an app without signing it, and you can't sign it without a certificate. Most of us just blindly follow the steps in Xcode without really knowing why they work. That method is fine right up until an expired file or a missing intermediate certificate breaks your deployment pipeline and gives you an error message that makes absolutely no sense.
A certificate is basically a file that binds your public key to your identity, signed by someone we all inherently trust. In our ecosystem, trust flows in a chain. Apple runs a root certificate authority. That root signs an intermediate certificate, and that intermediate signs your personal developer certificate. Every Apple device and Mac knows to trust Apple's root, so it can just walk down that cryptographic chain to verify whatever code you signed.
When you request a certificate, you are actually generating a brand new public and private key pair on your Mac. The private key stays locked in your local Keychain. It never leaves. Your public key gets packaged with your identity data into a Certificate Signing Request and shipped to Apple. Apple verifies who you are, stamps your public key with their digital signature, and hands it back. That stamped file is your certificate. Your private key proves you signed the code, and your certificate proves Apple vouches for you.
The Certificate Signing Request
This all starts in Keychain Access. The Certificate Assistant tool spins up a key pair, grabs your identity details, and dumps the public half into a .certSigningRequest file. That file is what you upload to the Developer portal.
It contains absolutely zero private key material. Apple doesn't need your private key because they are just taking your public key and signing it with their own credentials. Your local private key just serves as mathematical proof that you actually own the certificate.
This is why losing a certificate means different things depending on what actually got lost. If you delete the certificate file but keep the private key in your Keychain, you can usually just redownload the certificate from Apple. But if you wipe your Mac or lose your Keychain without exporting a .p12 backup file, that certificate is completely dead. You need both halves to sign anything.
The WWDR intermediate certificate
Between Apple's root authority and your personal certificate sits a middleman. That is the Apple Worldwide Developer Relations Certification Authority, usually just called WWDR. Your developer certificate is actually signed by WWDR, not the root authority. The root signs WWDR.
Why add the extra step? Because root keys are locked in isolated offline hardware vaults. Intermediate authorities handle the daily signing load. If an intermediate gets compromised, Apple can just revoke it and spin up a new one without having to replace the root keys physically embedded in every iPhone on the planet.
WWDR certificates expire. Back in February 2023, a common version of WWDR dropped dead. Developers suddenly found their builds failing even though their personal certificates were perfectly valid. If you ever hit weird signing errors that mention intermediate certificates, the very first step is checking developer.apple.com/certificationauthority to make sure you have the current WWDR installed in your System keychain.
Development certificates
A development certificate is what lets you run your unpublished code on a physical piece of hardware. Without it, your iPhone will literally reject the installation.
These are strictly personal. Every developer gets their own certificate tied to their Apple ID. Sharing them is pointless. Unless you manually export it, the private key lives exclusively on the machine that generated it. If your team has five developers, you should have exactly five development certificates.
Just having the certificate isn't enough to run the app. It works alongside your provisioning profile. The certificate proves who you are, and the profile lists exactly which testing devices are allowed to run the code.
They expire after exactly one year. Any app you already installed on your phone will keep running because the signature was valid the day it was installed. But you won't be able to build or push new updates onto the device until you renew.
Distribution certificates
When your code is ready to leave your desk, you switch to a distribution certificate. We use these for App Store submissions, TestFlight builds, and enterprise archives. Unlike personal development certificates, a distribution certificate belongs to the entire team.
When you pair one with a distribution provisioning profile, you get a build Apple will actually accept for review. The certificate proves your team built it, and the profile proves you own the bundle identifier.
Sharing these across a team is usually where things break down. The person who generated the certificate has to manually export a .p12 file from their Keychain and send it to everyone else. If that original developer quits and wipes their laptop without backing up the .p12 file, you are stuck. You have to revoke the team certificate and start over. Old builds won't break, but you won't be able to ship anything new until the fresh certificate propagates.
Cloud managed certificates
Cloud managed certificates completely eliminate that .p12 sharing nightmare. If you let Xcode manage signing automatically, Apple's infrastructure holds the private keys securely in the cloud.
This is a massive relief for continuous integration servers. You don't have to leave sensitive identity files sitting on a CI machine anymore. Xcode Cloud or any properly authenticated Xcode instance can just pull what it needs and sign the build dynamically.
The only real tradeoff is auditability. When you handle keys locally, you know exactly whose laptop has them. Cloud management hands that control entirely to Apple. That is perfectly fine for almost everyone, but strict security compliance teams sometimes push back.
Developer ID certificates
Developer ID is a totally separate beast. We use it exclusively for macOS software distributed outside the Mac App Store.
When you download a Mac app from the web, Gatekeeper blocks it by default unless it is properly signed and notarized. Generating the signature that Gatekeeper demands is exactly what Developer ID certificates do.
These certificates last much longer than an iOS App Store certificate, but the real durability comes from the notarization process. When you sign a Mac app, Apple's notary service attaches a permanent timestamp ticket. Even if your Developer ID certificate expires five years from now, your app will still launch. Gatekeeper looks at the timestamp ticket and sees that your signature was perfectly valid on the day you shipped.
Enterprise distribution certificates
The Enterprise Program exists for companies that need to deploy apps internally at scale without touching the App Store. Think of a hospital rolling out an intake app to three thousand nurses, or a logistics company putting proprietary inventory software on warehouse scanners.
An enterprise distribution certificate lets you compile an IPA file that employees can download straight from an internal link. The device just requires the user to manually trust the corporate certificate in their settings.
Apple watches this program like a hawk. You are strictly forbidden from distributing enterprise apps to the general public. We have all seen the news stories where big tech companies tried to use enterprise certificates to bypass App Store rules for public beta tests. Apple simply revokes the certificate, and suddenly every internal app across the entire company instantly crashes on launch.
App license delivery certificates
These certificates handle the plumbing for Apple Business Manager and Apple School Manager.
When a corporate network needs to silently install a licensed app onto an employee phone, the MDM server has to authenticate with Apple. The app license delivery certificate is literally just the server handshake credential that makes that happen. You will never encounter one writing Swift code, but an IT administrator relies on them to keep corporate phone fleets running.
WatchKit Services certificates
If you want to send remote push notifications directly to an Apple Watch, you need a WatchKit Services certificate.
Apple treats the Watch as a completely isolated notification target. Your main iOS push certificate only covers the iPhone. To route a payload directly to the watchOS application, you have to configure a separate push certificate for that specific bundle identifier.
VoIP Services certificates
Voice over IP apps need to wake up a sleeping phone even when the app is totally closed. PushKit gives VoIP notifications special OS level privileges. The phone wakes up, launches your app in the background, and lets CallKit draw a native incoming call screen before the user even touches their phone.
Standard push certificates cannot do this. Apple deliberately audits and walls off VoIP capabilities, which is why your server needs a dedicated VoIP Services certificate to talk to the PushKit endpoint.
If this certificate expires, the failure mode is completely silent. Your server sends the push, Apple rejects it, and the user's phone never rings. To the user, it just looks like your calling infrastructure is broken.
MDM vendor CSR signing certificate
Mobile Device Management has layers upon layers of certificates.
Companies that build MDM software hold this specific certificate. They use it to sign requests on behalf of their corporate customers, so those customers can get the push certificates needed to actually manage their fleets. You will probably never see one of these in your career unless you are building a new MDM platform from scratch.
What happens when you revoke a certificate
When you revoke a certificate in the developer portal, you are just telling Apple to permanently blacklist it. What actually happens next depends entirely on the certificate type.
Killing a development certificate instantly stops you from building new binaries. But the apps already sitting on your test devices will keep running just fine. Apple only checks development signatures at installation time.
The same goes for standard App Store distribution certificates. Binaries that are already live in the store stay perfectly valid. You just will not be able to ship your next update until you cut a fresh certificate.
Enterprise certificates are the dangerous exception. Because users have to manually establish trust on their devices, revoking an enterprise certificate forces iOS to immediately reject the signature. Every single app signed with that certificate breaks instantly across the entire company fleet. It is a catastrophic operational event.
The operational reality
Every certificate in this ecosystem is a ticking clock. Tracking those expiration dates, keeping backups of private keys, and renewing before the deadline drops is just the cost of doing business in Apple's ecosystem. A single successful Xcode archive build rests on a dozen invisible cryptographic handshakes. When one of those handshakes fails, the error message is almost never going to tell you the truth. You just have to know how the chain works.