Auth key vs certificate: use the auth key

Apple offers two ways to authenticate with Apple Push Notification service (APNs):

Unless you're maintaining an old integration that specifically requires certificates, set up the auth key. It's less setup work, it doesn't expire, and it works for every app in your account with the same key — no more "push notifications stopped working" surprises every 12 months when a certificate silently lapses.

Setting up an APNs Auth Key

  1. Go to the Apple Developer portal → Certificates, Identifiers & Profiles → Keys.
  2. Create a new key and enable the "Apple Push Notifications service (APNs)" capability.
  3. Download the .p8 file immediately. This is the only time Apple lets you download it — there's no re-download later, only revoke-and-recreate. Store it somewhere durable (a secrets manager, not just a laptop).
  4. Note the Key ID (shown after creation) and your Team ID (top-right of the developer portal, or Membership page).
  5. Upload the key to your push provider. Firebase Cloud Messaging: Project Settings → Cloud Messaging → APNs Authentication Key, paste the Key ID, Team ID, and upload the .p8. For a custom server, you'll use the key to sign a JWT per-request per Apple's APNs provider documentation.

Setting up an APNs Certificate (legacy path)

If you specifically need the certificate-based approach:

  1. In Xcode or the Developer Portal, create an App ID with Push Notifications enabled as a capability.
  2. Generate a Certificate Signing Request (CSR) via Keychain Access on your Mac (Certificate Assistant → Request a Certificate from a Certificate Authority).
  3. Upload the CSR in the Developer Portal to generate a push certificate — separately for development and production environments. This is the step people most often mix up: a dev certificate won't authenticate against the production APNs endpoint, and vice versa.
  4. Download the certificate, double-click to install it in Keychain Access, then export it as a .p12 file (right-click the certificate → Export).
  5. Upload the .p12 (and its export password, if set) to your push provider.

Remember: this certificate expires in one year and must be regenerated and re-uploaded everywhere it's used. Calendar-remind yourself, or migrate to the auth key to skip this entirely.

Client-side setup (your app code)

Certificates and keys authenticate your server to APNs — your app still needs to request permission and register for a device token:

  1. Enable the Push Notifications capability in Xcode (Signing & Capabilities tab) and enable Background Modes → Remote notifications if you need silent/background pushes.
  2. Request authorization with UNUserNotificationCenter.current().requestAuthorization(options:), then call UIApplication.shared.registerForRemoteNotifications().
  3. Capture the device token in application(_:didRegisterForRemoteNotificationsWithDeviceToken:) and send it to your backend — this is what your server uses to target a specific device.
  4. Handle the failure delegate too — didFailToRegisterForRemoteNotificationsWithError tells you immediately if something's wrong (usually a provisioning profile without the push entitlement, or running on the Simulator, which can't receive real remote pushes).

Why pushes fail silently — the actual checklist

When "the code looks right but nothing arrives," it's almost always one of these:

Fastest diagnosis: confirm you're on a real device (not Simulator), confirm the device token you're sending matches the build's environment (dev build → sandbox APNs, TestFlight/App Store build → production APNs), and check your push provider's delivery logs for the actual APNs error code rather than guessing from your own app's silence.

If you're using Firebase or another push provider

Most teams don't talk to APNs directly — they go through Firebase Cloud Messaging, OneSignal, or a similar service that handles the APNs connection for you. In that case, your setup work is the same auth key steps above, just uploaded into that provider's dashboard instead of your own server code. The provider still needs a correctly generated auth key or certificate — it can't skip that requirement, it just abstracts the request-signing away from you.

Where this connects to your App Store submission

If your app requests push permission, make sure your App Store screenshots and description don't overpromise what notifications actually do — a common metadata rejection pattern is describing notification features that aren't implemented yet, or showing a mocked notification banner that doesn't match the real UI. If notifications are a core feature, show the real permission prompt or notification content in at least one screenshot rather than describing it only in text.

Once the feature works and you're ready to show it off, ezscreenshots makes it quick to turn a real notification screenshot into a polished, correctly-sized App Store asset — drop the capture, pick your device presets, add a caption, export the full set in minutes. No account, no export limit, all in the browser.

Got push working? Show it in your listing.

A real notification screenshot builds more trust than description text alone — and keeps you clear of accuracy-based metadata rejections. ezscreenshots exports a polished, correctly-sized set in minutes. Free, browser-based, no account.

Try ezscreenshots →

Summary