App Store Compliance

ITMS-90078: Missing Push Notification Entitlement — the fix

App Store Connect rejected your build with ITMS-90078. Why it happens even when you didn't add push on purpose, and the exact entitlement + capability fix.

By · · 5 min read

You uploaded a build and got:

ITMS-90078: Missing Push Notification Entitlement — Your app appears
to include API used to register with the Apple Push Notification
service, but the app signature's entitlements do not include the
"aps-environment" entitlement. If your app uses the Apple Push
Notification service, make sure your App ID is enabled for Push
Notification in the Provisioning Portal, and resubmit after signing
your app with a Distribution provisioning profile that includes the
"aps-environment" entitlement.

This is one of the most common “I didn’t even add push” rejections. It fires because your binary links the push-registration API, not because you intentionally use push. This is the fast fix.

For the broader submission picture, see every URL and file Apple requires for an iOS App Store submission.

What ITMS-90078 means

If your app binary contains a call to registerForRemoteNotifications() (from UIApplication / UNUserNotificationCenter’s remote registration path), Apple’s processing pipeline expects the signed .app to carry the aps-environment entitlement. If the entitlement is absent from the code-signing entitlements, you get ITMS-90078.

Two scenarios:

  1. You use push and forgot the capability — straightforward, add it.
  2. You don’t use push but an SDK does — an analytics, marketing, or engagement SDK calls registerForRemoteNotifications() for silent-push delivery. You still need the entitlement (or to remove the SDK behavior).

Apple’s API reference: User Notifications.

The fix (2 minutes if you use push)

Step 1: Add the Push Notifications capability in Xcode

  1. Select your target → Signing & Capabilities.
  2. Click + Capability.
  3. Add Push Notifications.

This adds aps-environment to your .entitlements file:

<key>aps-environment</key>
<string>production</string>

(Xcode writes development for debug builds and substitutes production for distribution at archive time — you don’t hand-edit this.)

Step 2: Confirm the App ID has Push enabled

In the Apple Developer portal → Identifiers → your App ID → enable Push Notifications if it isn’t already. If you use automatically-managed signing, Xcode handles the provisioning profile regeneration. If you use manual signing, regenerate the distribution profile after enabling the capability.

Step 3: Clean, re-archive, re-upload

# In Xcode:
# Product → Clean Build Folder  (⇧⌘K)
# Product → Archive
# Distribute App → App Store Connect → Upload

Entitlements are baked at archive/sign time. Re-uploading with just a build-number bump won’t fix it — you must re-archive after adding the capability.

If you genuinely don’t want push

If an SDK pulls in remote-notification registration and you have no push features:

  1. Add the entitlement anyway. The simplest unblock — having aps-environment doesn’t force you to send notifications, and a silent-push-capable SDK may legitimately need it.
  2. Disable the SDK’s push behavior. Many SDKs have an init flag like disableAutomaticPushRegistration — check the SDK docs and call it before the SDK registers.
  3. Remove the SDK if push registration is unwanted and the SDK is non-essential.

Note: shipping aps-environment with no actual push usage is allowed and does not trigger an App Review rejection — App Review doesn’t penalize unused entitlements here.

Why “bump the build number” doesn’t work

The #1 follow-up question on ITMS-90078: “I added the capability, bumped to build 43, still rejected.” That’s because the already-uploaded archive (build 42) is what’s stuck — you have to produce a fresh archive after the capability was added, then upload that. Adding the capability changes the .entitlements file, which only takes effect when the app is re-signed during a new archive.