Apple push notification service certificate setup

After users download your app, a missing or misconfigured Apple credential can keep the first push notification from arriving.

A correct Apple Push Notification service (APNs) credential lets your backend prove ownership to Apple. Use a token-based .p8 key unless a specific tool requires a certificate, because it avoids annual renewal and works across all apps on your team.

Why APNs needs a credential at all

APNs needs a valid Apple credential before it will accept remote notifications from your backend. The credential proves the notifications came from you, so a missing or incorrect one stops delivery before the message reaches the device.

APNs is Apple's official gateway for delivering push notifications to iOS, iPadOS, macOS, tvOS, and watchOS devices. For remote notifications, "your company's server generates push notifications, and APNs handles the delivery of those notifications to the user's devices."

A provider server or push service connects to APNs for your app. Your job is to give that backend a valid Apple credential so APNs trusts the messages.

Without that credential, APNs rejects requests. The push flow runs in a few clear steps:

1. Your backend prepares a notification with the device token and message payload.
2. It sends that to APNs over an HTTP/2 connection secured with TLS.
3. APNs validates your credential, then routes the message to the correct device.

If validation fails at step 3, the notification stops before the device can receive it.

The 2 credential types you can choose

Apple supports 2 APNs credential types, and your choice affects renewal work and outage risk, especially when one credential must cover multiple apps.

One approach uses a certificate file with a .p12 extension. The other uses a token-based signing key with a .p8 extension. Each approach changes how you maintain push notifications over time.

The token-based .p8 key uses a stateless method. It is "faster than certificate-based communication" because APNs does not need to look up certificate information for each request. A key can also distribute notifications for all or a subset of your apps.

Certificate-based authentication works differently. You "use a provider certificate" to secure the connection, but it covers a single app only. To support multiple apps, you create a separate certificate for each one.

The two credentials differ in a few key areas:

• Speed: The .p8 key is faster and stateless, while the .p12 certificate is slightly slower.
• Expiration: The .p8 key has no annual renewal, while the .p12 certificate expires annually.
• Multi-app support: One .p8 key works for all your apps, while you need one .p12 certificate per app.
• Push type support: The .p8 key supports all push types, while the .p12 covers only a subset.
• Renewal burden: The .p8 key has none, while the .p12 needs annual renewal and carries outage risk if missed.
• Download limit: The .p8 file can only be downloaded once, while the .p12 can be re-downloaded.

Given those tradeoffs, the .p8 key is usually the better default for simple app setups. Use a certificate only when a specific tool or older integration requires it.

What you need before you start

You need a paid Apple Developer Program membership before you create either credential type. The standard program costs $99 per year, and the enterprise program for private in-house distribution costs $299 per year. A free Apple account lets you test on your own device through Xcode, but it does not include push notifications for released apps.

You also need an explicit App ID with Push Notifications turned on. Wildcard App IDs can not send push notifications. To turn the capability on, open Certificates, Identifiers and Profiles, select your App ID, check Push Notifications under Capabilities, and save. Only explicit App IDs support push.

Finally, your app must register for remote notifications at launch by calling registerForRemoteNotifications(). That call returns a device token your backend stores and uses for each notification. Turning on the capability in Xcode adds the aps-environment entitlement to your app.

With the account, App ID, and entitlement aligned, credential setup becomes much easier to debug.

How to create a .p8 token-based key

Start with the .p8 key when your provider supports it. You generate it once in the Apple Developer portal, download it, and store it somewhere safe. There is no CSR step and no Keychain export involved.

To create the key, sign in at developer.apple.com, go to Certificates, Identifiers and Profiles, and open Keys. Create a new key, select the APNs capability, and download the file.

Apple introduced more granular options in 2025. You can create team-scoped keys restricted to development or production. You can also create topic-specific keys tied to a single bundle ID for more granular control.

The .p8 file can only be downloaded once. If you lose it, you can not re-download it — you have to revoke the key and create a new one. Save it to secure storage the moment it lands in your Downloads folder.

Keep these identifiers ready when you upload the key:

• Key ID: Apple Developer lists this unique alphanumeric identifier under Keys, next to the key name.
• Team ID: Apple Developer lists this in the Membership section.

Most push providers need the .p8 file, Key ID, and Team ID.

How to create a .p12 certificate

Use the .p12 certificate path only when your tool requires it. You need a Mac to complete the workflow: generate a certificate signing request, create the certificate in Apple's portal, install it, then export it paired with its private key.

Start by generating the CSR in Keychain Access. Open Keychain Access, go to Certificate Assistant, then Request a Certificate from a Certificate Authority. Enter your email and a common name like MyApp Push Key, leave the CA email blank, select "Saved to disk," and save the .certSigningRequest file.

Next, create the certificate in the Apple portal. The required role is Account Holder or Admin. Go to Identifiers, select your app's Bundle ID, check Push Notifications under Capabilities, and click Configure. Under Production SSL Certificate, click Create Certificate, upload your CSR, then download the .cer file. Choose the "Apple Push Notification service Sandbox & Production" type so the certificate covers both test and live environments.

The final phases install and export the certificate:

1. Double-click the downloaded .cer file. Keychain Access opens automatically and installs the certificate under My Certificates.
2. Open Keychain Access and go to My Certificates. Find your APNs certificate and click the disclosure triangle. You should see both a certificate and a private key below it.
3. Select both the certificate and the private key together.
4. Go to File → Export Items, and choose Personal Information Exchange (.p12) as the format.
5. Name the file, save it, and set a password. Your push provider will need that password.

The .p12 file stores the certificate and key together. Export both as a pair, or the credential will not work.

How to upload your credential to Firebase

Firebase Cloud Messaging is one common backend for sending notifications, and the .p8 upload path is the cleaner option when your project supports it.

In the Firebase console, open Settings, then General, then the Cloud Messaging tab, and find your iOS app. Under the APNs authentication key section, click Upload and select your .p8 file. Enter your Key ID and Team ID, then save. Firebase also accepts a .p12 certificate upload for teams that need it.

Behind the scenes, Firebase maps your app's APNs device token to an FCM registration token automatically through method swizzling. For Flutter projects, the plugin requires method swizzling, and you can not disable it. In Flutter, confirm the APNs token is available before calling FCM APIs:

final apnsToken = await FirebaseMessaging.instance.getAPNSToken();

That single check helps prevent a class of timing errors where FCM calls run before the device token exists.

Why your notifications are not arriving

When notifications fail, start by checking APNs status codes and environment alignment. That usually points to either configuration or token handling before you chase temporary delivery problems.

APNs returns an HTTP status and an error code. A frequent problem is a sandbox and production environment mismatch. Device tokens used for development testing belong to the sandbox environment, while live app tokens belong to production.

The error you may see is BadDeviceToken. A token from the sandbox environment can not be sent to the production push service. A token is also valid only for the app that received it, so the wrong bundle ID gets rejected. Tokens can change, so your app should request a fresh one at every launch rather than reusing a cached value.

A few other errors show up often enough to recognize on sight:

• BadCertificateEnvironment: the certificate environment does not match the device token environment.
• InvalidProviderToken: the provider authentication token is not valid. Re-upload the key and verify the Key ID and Team ID.
• Unregistered: the device token is no longer active. Remove it from your database and do not retry.
• TooManyRequests: retry with a delay.

Treat those codes as routing instructions. Some errors tell you to fix configuration, while others tell you to stop retrying a stale token.

For retry behavior, the rule is simple. Do not retry BadDeviceToken, Unregistered, or similar permanent errors. Retry TooManyRequests after a delay, and retry server errors after a delay.

How to keep notifications running long-term

A .p8 key avoids annual certificate renewal. A provider certificate is valid for one year and must be renewed. The individual bearer tokens your provider generates are valid for 1 hour and must be regenerated periodically.

When a certificate expires, you can no longer send push notifications to your app. Notifications simply stop without warning to your users. For agencies managing client apps, a missed renewal can silently disable notifications for an entire client base.

If you are on certificate-based auth, build a renewal habit before the deadline arrives. Get a new certificate and deploy it with your service before the current one expires. A practical routine works well:

1. Set a calendar reminder well before the expiry date.
2. Repeat the certificate creation steps to generate a fresh .cer file.
3. Export a new .p12 and upload it to your push provider before the old certificate lapses.
4. Confirm a test notification arrives in production before you consider the swap done.

If your provider supports token-based authentication, migrating to a .p8 key removes that renewal cycle. For builders using an AI app builder or text to app workflow, that single switch is worth making.

Choose .p8 unless a tool requires .p12, store the key securely, verify the Firebase setup, and treat APNs error codes as maintenance signals. If certificates are unavoidable, renew them before expiration and test production delivery after the swap.

If you are building an iOS app and want push notifications working without wrestling infrastructure, get started with Anything and focus on the product instead of the plumbing.