Apple push notification certificate: .p8 or .p12 with Expo

Apple's push certificate lets a server send notifications to your app through APNs, Apple's notification service. It comes in two forms: a .p12 certificate, valid for one year and tied to a single app, or a .p8 key, which never expires and works for every app on your account. With Expo, you don't need the certificate: EAS offers to create a .p8 key on your first build, and Expo's push service uses it for you.

The guide on the developer certificate and the provisioning profile covers the push key in a few lines. Here, we go all the way: choosing between the two formats, the sandbox and production environments, renewal, and the failures that kill notifications in TestFlight.

I publish my apps with Expo and EAS. Solys and TradaZen declare the expo-notifications plugin in their config: that's what gets the app ready to receive notifications.

Why Apple asks for a certificate or a key

A push notification starts on a server, yours or Expo's, which hands it to APNs, which delivers it to the iPhone. So APNs has to check that this server is allowed to talk to your app. Apple gives you two ways to prove it.

• Token-based connection, with a .p8 key. According to Apple, it's faster, usable from multiple servers, and one key covers all of your team's apps or some of them. Your server uses it to sign a token, which you have to regenerate at least once an hour.
• Certificate-based connection, with a .p12 file. Apple specifies that this certificate is tied to a single app and valid for one year. Several apps, several certificates.

Apple's page on expirations says it plainly: the APNs token signing key never expires.

The .p8 vs .p12 table

Criteria	.p8 key	.p12 certificate
Lifetime	No expiration	One year
Scope	All your apps	A single app
Environment	Chosen at creation	Sandbox and production
Renewal	None, unless revoked	Every year
Download	Only once	Exported from the Mac
Count	Two per environment	One per app
Use with Expo	Created and managed by EAS	Not in the Expo docs

Three details. The .p8 file can only be downloaded once: Apple doesn't keep it in your account. The .p12, on the other hand, is exported from the Keychain of the Mac that created the certificate. And the limit of two keys per environment applies to team keys. For keys limited to specific apps, Apple allows up to 200 per environment.

Expo's page on credentials only mentions the push key, and caps it at two per account, without distinguishing environments or per-app keys. For an Expo app, the .p8 key is the right choice.

Sandbox and production: two environments

APNs has two servers: development, also called sandbox, and production. Apple reserves the first for testing and the second for released apps. The app knows which one to use thanks to the aps-environment entitlement. According to Apple, its value follows the signing profile: development with a development profile, production with a distribution profile and for TestFlight.

So a TestFlight build talks to production, exactly like the App Store.

On the Expo side, two details. The expo-notifications documentation says the entitlement is always written as development in the project, then switched to production in the archive of a release build. And when it's created, the Expo token is tied to the app's environment, detected automatically: you have nothing to choose when sending.

If you create the key yourself, Apple asks for its environment and its scope: the whole team or specific apps. Its developer documentation now describes team keys limited to sandbox or production, with older keys that work everywhere still accepted. The account help, meanwhile, still claims the key works for both environments. Apple contradicts itself: go by the environment you pick at creation. A sandbox-only key won't work for TestFlight or the App Store.

How Expo handles the push key

According to Expo's setup guide, updated on July 28, 2026, your first development build offers to set up push notifications and generate an APNs key. Say yes to both. Without EAS Build, run eas credentials. You need a paid Apple Developer account.

Then:

• EAS stores the key and links it to your app. According to Expo, one key works for as many apps as you want, and uploading a new one doesn't change your users' Expo Push tokens.
• Your server doesn't call APNs. It sends to Expo's push service, which forwards to APNs. Expo asks you to read the receipts about 15 minutes after sending: that's where errors show up.
• The plugin sets the entitlement. Declare expo-notifications in plugins:

{
  "expo": {
    "plugins": ["expo-notifications"]
  }
}

Two traps. Expo's FAQ says Expo Go no longer supports push notifications since SDK 53, while the expo-notifications page only mentions Android. Either way, Expo recommends a development build: test with that. And deleting the key with eas credentials removes it from Expo's servers, not from your Apple account. To free up a slot, revoke it in Apple's portal. Like any secret, the .p8 file must never end up in your repo: the rule is the same as for API keys in an Expo app.

Renewing: what actually expires

The .p8 key has nothing to renew. It only stops working if you revoke it. If you think it's compromised, Apple recommends creating a new key, switching to it, and only then revoking the old one. To replace the key with Expo, the FAQ gives the steps: eas credentials, iOS, your build profile, then remove the push key and generate a new one.

The .p12 certificate expires every year. Apple asks you to update it before the deadline and to keep an eye on its date in Keychain. Once it's expired or revoked, you can no longer send notifications to your app. Apple doesn't describe a separate renewal: you create a new certificate from the app's identifier, install it on your server before the deadline, then remove the old one. The best renewal is still switching to the key.

Managing iPhones with Intune or another fleet management tool? That's not the same certificate. The device management push certificate is created on the Apple Push Certificates Portal and renewed every year. Apple recommends writing down the Apple Account you used: you'll need it to renew.

Typical failures and how to fix them

It works in development, not in TestFlight

1. You're sending to the wrong token. The TestFlight build registers in production and gets a new token. A token from your development build won't work: Apple returns BadDeviceToken when the token doesn't match the environment. Grab the token from the TestFlight app itself.
2. The production app has no push credentials. That's the diagnosis in Expo's FAQ. Check the project's credentials page on expo.dev, or eas credentials.
3. Your key is limited to sandbox. Replace it with a key that works in production.
4. The iPhone doesn't get a token. If you installed the TestFlight build over an Xcode build, Expo suggests restarting the device.

"No valid aps-environment entitlement string found"

According to Expo's FAQ, this error means no push key is configured for your iOS project. Check the credentials page, then run a new build: EAS will offer to generate the key. Also make sure expo-notifications is listed in plugins.

ITMS-90078: Missing Push Notification Entitlement

Apple sends this email after upload: your app seems to register with APNs, but its signature doesn't include the aps-environment entitlement. Expo's note on SDK 51 explains it. Since that SDK, the entitlement is only added if expo-notifications is installed. The warning comes from two Apple checks. The first compares your App ID's capabilities to the app's entitlements. The second spots a notification registration method in the binary, which Expo's code includes in every app.

It's a warning, not a rejection, Expo points out. If you use notifications, add the plugin and rebuild: EAS syncs the capabilities of the App ID on every build. Otherwise, remove the Push Notifications capability from your identifier in Apple's portal. The warning may stick around, with no consequences.

InvalidCredentials, or all your apps go silent at once

InvalidCredentials in a receipt means your push credentials are no longer valid, often because the key was revoked. Every app that used it goes quiet at the same time. Expo's fix: eas credentials, then a new key. If the receipt mentions InvalidProviderToken, Expo recommends rebuilding while regenerating the push key and the profile.

Before turning on notifications

To test notifications on your iPhone before launch, follow TestFlight to test your app. If you send silent notifications to wake up the app, reread guideline 2.5.4 on background modes. The whole pipeline, without a Mac, is in publishing an iOS app without a Mac, and the release steps are on the page publishing an app on the App Store.

Before your first send, run the free diagnostic: it tells you what's blocking in your project and sends you my Apple anti-rejection checklist. To build the app, wire up subscriptions and publish it, the iOS & Android Kit walks you through the four-step path with the starter code from my apps, at your own pace.

Frequently asked questions

Does the Apple push certificate expire?

The .p12 certificate expires after one year, and your notifications stop if it isn't replaced. The .p8 key never expires: it only stops if you revoke it. That's the main reason to prefer the key.

Do you need one push certificate per app?

With a .p12 certificate, yes: each certificate is tied to a single app. A .p8 key works for every app on your account. So with Expo, a single key can cover your whole catalog.

How do you renew an Apple push certificate?

Create a new certificate from your app's identifier, with a new signing request, install it on your server, then remove the old one. Do it before the deadline. The simplest option is still switching to a .p8 key, which never needs renewing.

I lost my .p8 file, what do I do?

Apple only lets you download it once. If EAS created the key, Expo keeps it and your notifications keep working. Otherwise, create a new key, add it with eas credentials, then revoke the old one in Apple's portal. Your users' Expo Push tokens don't change.

Do you need to rebuild after changing the push key?

Usually, no. The key is used by the server that sends, not by the installed app, and Expo says a new key doesn't change the tokens. Exception: if receipts report InvalidProviderToken, Expo recommends rebuilding with a new key and a new profile.