Apple documents twenty certificate types. An iOS app needs two of them.

What certificate types does Apple document, and what is each one for?

The list lives on one page, the Certificates overview in Developer Account Help, in one table with twenty rows. Apple opens it with a sentence worth keeping in mind: the certificate type helps to identify a certificate in your developer account and in Xcode. These names are labels for the job a certificate is allowed to do, so the question to ask is which job you are doing.

For an iOS app the answer is short. Apple Development runs an iOS, iPadOS, macOS, tvOS, visionOS or watchOS app on devices and enables certain app services during development. Apple Distribution puts that app on designated devices for testing or submits it to App Store Connect. Those two are platform wide, which is why the older pair, iOS Development and iOS Distribution, now carry the note that they are for use with Xcode 11 and earlier. If a tutorial tells you to create an iOS Distribution certificate, the tutorial predates the rename.

The Mac rows are where the count doubles, and the reason is the installer. Mac App Distribution signs a Mac app before you submit it to the Mac App Store, and Mac Installer Distribution signs and submits the package that contains it. Outside the store the pair becomes Developer ID Application and Developer ID Installer. A Mac app that ships as a package from your own website therefore needs two certificates rather than one, and people who budget for one find out at the point the installer refuses to build.

The rest of the table is services. Apple Push Services, VoIP Services and WatchKit Services each open a connection between your own server and APNs, for ordinary notifications, for waking a background VoIP app, and for updating ClockKit complication data. Website Push ID does the same for a website. Pass Type ID signs passes in Wallet and sends updates to them. Apple Pay decrypts transaction data, and Merchant Identity authenticates you to the Apple Pay servers. Swift signing covers Swift packages and package collections with Swift Package Manager 5.9 or later. MDM Vendor CSR signing exists for device management vendors and is only available by request, and the App License Delivery signing and encryption pair generates app license requests for eligible apps. One row in a table headed Certificate types is honest about not being a certificate: the APNs Auth Key generates server side tokens as an alternative to certificates for your notification requests.

A certificate says who you are, and it says nothing about which app you are shipping. That part is carried by the bundle identifier in the provisioning profile, so the two can disagree in ways that look like a signing failure when they are really a naming failure. The bundle identifier rules are the other half of the same story. One detail from Apple helps when you are staring at a keychain full of near identical entries: a signing certificate name there contains a hint to the type, and includes the team name and the Team ID.

Apple Developer Account Help, Certificates overview, read 21 October 2026

How many can you hold, and who is allowed to create them?

Apple answers this with a rule first and a number second. Distribution certificates belong to the team, and only one type of each distribution certificate is allowed per team, with Developer ID certificates excepted. Only the Account Holder or Admin role can create a distribution certificate, and if you enrolled as an individual then you are the Account Holder. That single sentence decides a surprising amount. It means a team of four shares one Apple Distribution certificate, and it means the person who needs to create it may not be the person sitting in front of Xcode. Which role can do what is laid out in the app store connect user roles breakdown.

Apple publishes exactly one hard count, and it is for the exception. The Developer ID certificates page in Developer Account Help says you can create up to five Developer ID Application certificates and up to five Developer ID Installer certificates, through your developer account or through Xcode, read on 21 October 2026. The same page gives the required role as Account Holder on its own, which is stricter than the Account Holder or Admin rule that covers the other distribution types. For the Apple Developer Enterprise Program, the Create enterprise distribution certificates page says only that you can create multiple enterprise distribution certificates, and names no figure.

For Apple Development certificates there is no published cap. I read the Certificates overview page, the Developer ID certificates page, the Cloud-managed certificates page and the Create a certificate signing request page on 21 October 2026, and none of them states a number for development certificates. What Apple does say is that they belong to individuals, so the practical ceiling is one per person per machine rather than a figure in a table. If you have seen a limit of two or three quoted for development certificates, it is not on any of those four pages.

Two warnings sit alongside the counts. Apple states that it can revoke digital certificates at any time at its sole discretion, and points at the Apple Developer Program License Agreement for the detail. And a provisioning profile that contains a revoked certificate becomes invalid, so revoking in a hurry to free up the one slot per team has a blast radius past the certificate itself. Apple also asks you not to share certificates outside your organisation at all.

Apple Developer Account Help, Certificates overview, read 21 October 2026

How long does an Apple code signing certificate last?

The commonly repeated answer is a year, and Apple does back it, in a technote rather than in the help pages. TN3161, Inside Code Signing: Certificates, says all X.509 certificates have a valid date range, and that for Apple code signing certificates it is typically a year from the date of issue, although the exact duration varies based on the certificate type. Those two hedges, typically and varies, are Apple's own. The technote carries a revision history: first published 6 February 2024, minor editorial change 13 February 2024. The Certificates overview help page, which is where most people go looking, gives no duration at all.

One other Apple page lets you sanity check the year. The Cloud-managed certificates page says a new cloud-managed certificate is created automatically 90 days before expiration once new signing requests come in, and that manual rotation becomes available when the certificate has less than half of its validity duration left, often 180 days. Half of often 180 days is a validity of around a year, which lines the two pages up. It also tells you something more useful: with cloud signing the renewal is not your job, and the Account Holder or an Admin can force a rotation early if signed software has to keep running on devices for longer than 90 days.

Then the part that takes the fear out of the date. The App Store re-signs your app as part of distribution, and TN3161 is explicit that this happens for all App Store apps on all platforms. The leaf certificate on the copy a customer installs is Apple's, not yours. So App Store apps are signed with credentials that do not expire, and your own certificate only has to be valid at the moment you submit. An expired distribution certificate blocks your next upload. It does not reach down and switch off the version already on the store.

Direct Mac distribution is the case where the date does follow you, and Apple solves it with a timestamp. A secure timestamp is embedded in the signature, recording when the code was signed, and macOS checks that the Developer ID certificate was valid at that moment rather than today. Xcode adds one automatically, and the notary service will catch you if it is missing. The consequence is that you need a working internet connection to sign Developer ID code at all, because codesign talks to Apple's timestamp service. Two longer dates are published and worth knowing: Developer ID provisioning profiles generated after 22 February 2017 are valid for 18 years from creation, and the Apple Worldwide Developer Relations intermediate certificate that developer certificates have been issued from since 28 January 2021 expires on 20 February 2030.

Apple, TN3161: Inside Code Signing: Certificates, revised 13 February 2024, read 21 October 2026

What actually signs your app, the certificate or the private key?

The private key, and this is the distinction that makes the rest of the subject make sense. A certificate is a public document. It holds the subject details, the public key, the valid date range and a set of extensions, and Apple signs the lot. Because it contains only a public key, you cannot sign code with it. Signing needs the certificate and the matching private key together, and Apple calls that pair a digital identity, or a code signing identity when the job is code. TN3161 admits the naming is a mess across the industry and inside Apple too, since Xcode says signing certificate while Keychain Access says My Certificates.

Apple issues code signing certificates in three ways, and the only difference that matters is where the private key ends up. In the manual route, Keychain Access creates the key pair in your login keychain and wraps the public half in a request file you upload. Xcode's own certificate management does the same thing with fewer clicks, and puts the key in the same place. Both routes have the advantage that the private key never leaves your Mac, and both share one trap that Apple names directly: it is easy to miss that your most critical signing asset is tucked away in a keychain, and to lose it when you move to a new Mac. Cloud-managed certificates remove that risk by removing your access, because Apple holds the certificate and the private key and you have direct access to neither.

This is also why signing failures read so strangely. When codesign picks an identity it checks three things about the certificate: that a chain of trust can be built from it to a trusted root, that the current time falls inside the valid date range, and that the certificate carries Code Signing in its Extended Key Usage extension. When it cannot build that chain it reports that it is unable to build a chain to a self signed root, and Apple names the most common cause as a missing intermediate certificate. Xcode installs those intermediates for you, so a build server that does not use Xcode has to download them from the Apple PKI page and install them itself. To see what your Mac believes it has, run the security tool with find-identity and the codesigning policy. Expired entries are listed with a certificate expired error beside them, which is a faster answer than reading dates in Keychain Access.

If a build server does your signing, the certificate becomes an API problem instead of a keychain problem. The certificates resource in the app store connect api creates, lists, downloads and revokes signing certificates, which is how continuous integration gets one without a person at a keyboard. Apple documents a single carve out: Developer ID certificates for macOS can only be created through the Apple Developer website or through Xcode.