Every iOS push notification integration starts at the same gate: proving to Apple Push Notification service that you are allowed to message your app’s users. Apple gives you two ways to do it — an APNs authentication key (.p8) or an APNs certificate (.p12) — and the difference between them is the difference between a credential you configure once and one you will be renewing every year, often at the worst possible moment.
This guide explains how APNs authentication actually works, when to use a .p8 key versus a .p12 certificate, and the handful of errors that trace back to getting this wrong.
How APNs authentication works
When your push provider — PushEngage, or your own server — sends a notification, it connects to Apple’s APNs provider API and must prove two things: that it is authorized to send on your behalf, and that it is allowed to target your app’s bundle ID (the “topic” in APNs terms). The .p8 key and the .p12 certificate are just two different ways of proving it.
The device side is separate. Your app registers with APNs and receives a device token — that part never changes regardless of which credential your provider uses. Authentication is purely a server-to-Apple concern, which is why you can switch methods without touching your app binary.
The .p8 authentication key (use this one)
The .p8 is a token-signing key. Your provider uses it to mint short-lived JSON Web Tokens that authenticate each connection to APNs. Its properties make it the default choice for almost everyone:
- It never expires. No annual renewal, no push outage on a forgotten date.
- One key covers every app in your developer account. Ship a second app and the same key authenticates it.
- It works for both development and production environments — no sandbox/production certificate pairs.
- It travels as three values: the .p8 file itself, the 10-character Key ID, and your Team ID.
Two things to know before you create one. Apple limits you to two active APNs keys per account, so large organizations should treat key creation as a deliberate act, not a per-project habit. And the .p8 file can only be downloaded once, at creation time — store it somewhere your team can find it, because Apple will not give it to you again.
The .p12 certificate (the legacy path)
The .p12 is a TLS client certificate, exported from Keychain Access after Apple issues it. It authenticates the connection itself rather than signing tokens. It still works, and some enterprise security policies still require it, but its constraints are why Apple steers new integrations toward the key:
- It expires every year. The most common cause of sudden, total push failure is an APNs certificate that quietly lapsed.
- It is scoped to a single app. Every bundle ID needs its own certificate, and every certificate needs its own renewal calendar.
- It requires a Mac. The signing-request-and-Keychain export dance has no browser-only path.
Which should you use?
| .p8 authentication key | .p12 certificate | |
|---|---|---|
| Expires | Never | Every 12 months |
| Scope | All apps in the account | One bundle ID |
| Environments | Development + production | Separate or combined per certificate |
| Created from | Any browser | Mac with Keychain Access |
| Account limit | 2 active keys | Per-app pairs |
| Use when | Almost always | Policy requires certificates |
The honest answer: use the .p8 key unless a security policy forces the certificate path. Fewer moving parts, nothing to renew, one credential for your whole portfolio.
Creating a .p8 key in three minutes
- In your Apple Developer account, go to Certificates, Identifiers & Profiles → Keys and register a new key.
- Name it, enable the Apple Push Notifications service (APNs) checkbox, and continue.
- Download the .p8 file (remember: one chance), and note the Key ID shown on the confirmation screen and your Team ID from the account membership page.
- Upload all three values to your push provider. In PushEngage, this is a single screen in your app settings — the APNs credential guide walks through it with screenshots.
The errors this explains
A surprising share of “push is broken” tickets are credential problems wearing a disguise. The usual suspects:
- BadDeviceToken — you are sending a sandbox-built app’s token through the production environment, or vice versa. Debug builds from Xcode talk to the sandbox; TestFlight and App Store builds talk to production.
- TopicDisallowed — the credential does not cover the bundle ID you are targeting. Typical with per-app .p12 certificates and a copy-pasted configuration.
- Sudden 100% delivery failure — an expired .p12. Check the certificate’s expiry date before you check anything else.
- InvalidProviderToken — a revoked .p8 key, or the wrong Key ID/Team ID pair alongside a valid file.
Where this fits in your integration
The APNs credential is step one of exactly one setup session. Upload the .p8 to PushEngage once, and everything downstream — the iOS SDK 1.0 integration, rich media through your notification extension, triggered campaigns, and delivery itself — runs against it without further ceremony. If you are coming from Firebase, the same key you gave FCM works here, which is part of why migrating from FCM on iOS is an afternoon project.
For the strategy layer that comes after setup, start with the app push marketing guide. And when you are ready to send, the full iOS setup guide takes you from credential to first campaign in under an hour.
