App Rejection Fix
Menu
App Store Medium Warning / notice

ITMS-90078: Missing Push Notification Entitlement

App Store Connect accepted the upload but emailed ITMS-90078: the app links the Push Notifications framework without carrying the aps-environment entitlement, so the build cannot be submitted as it is.

Typical wording

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.

Common causes

  • The Push Notifications capability is not enabled on the target, so Xcode never added aps-environment to the entitlements file
  • The capability is enabled on the target but not on the App ID, so the provisioning profile does not grant it
  • A stale provisioning profile created before the capability was added is still being used (often on CI)
  • An SDK links the push APIs even though the app itself does not use push — Firebase Messaging, OneSignal, analytics and chat SDKs all do this
  • Manual signing with an entitlements file that was copied from another project

What to check

  • Signing & Capabilities on the app target: is Push Notifications listed?
  • The target's .entitlements file: does it contain aps-environment (development or production)?
  • Apple Developer → Identifiers → your App ID: is Push Notifications enabled?
  • The profile the archive was signed with — regenerate it after any capability change
  • Whether push is actually a feature; if not, remove the SDK or its push component instead

Fix, reply or appeal guidance

  • If the app uses push: enable Push Notifications on the target and on the App ID, regenerate the provisioning profile, archive again and re-upload
  • On CI: refresh the profiles after the capability change; automatic signing with an App Store Connect API key avoids stale profiles
  • If the app does not use push: remove the SDK (or its push module) so the API is no longer linked, rather than adding an entitlement you do not need
  • Remember the server side is separate — an APNs auth key or certificate is what actually sends notifications; the entitlement only makes the build valid

Why the upload succeeds and the email arrives anyway

ITMS-90078 is produced by App Store Connect's post-upload validation, not by App Review. The archive is accepted, processing starts, and then the validator notices that the binary links the push-notification APIs while the signature carries no aps-environment entitlement. The build is left unusable for submission, and TestFlight will not distribute it either.

The three places push has to line up

  1. The target. Signing & Capabilities → Push Notifications. Enabling it writes aps-environment into the target's .entitlements file.
  2. The App ID. Apple Developer → Identifiers → your App ID must have Push Notifications enabled, otherwise no profile can grant the entitlement.
  3. The provisioning profile. A profile generated before the capability was added does not include it. Regenerate the profile and make sure the archive is signed with the new one — this is the step CI usually misses.

A fourth item, the APNs auth key or certificate, is not part of this error at all: it lives on your server and decides whether notifications are delivered. An app can pass validation with the entitlement and still send nothing because the key is missing or belongs to another team.

When the app does not even use push

This is the more common case in Flutter, React Native and Unity projects. Firebase Messaging, OneSignal, analytics SDKs, chat SDKs and some ad SDKs link the push APIs whether or not you call them, and the validator only sees the symbols. Two honest options:

  • Keep the SDK (you probably use its other features) and enable the capability properly. You end up with an entitlement you do not exercise, which is allowed.
  • Remove the push component. In Flutter drop firebase_messaging; in React Native remove the messaging module; in Unity remove the notifications package. Then clean the build folder, delete derived data and archive again — a stale build product keeps the symbols around and the error with them.

Framework-specific notes

  • Flutter: the capability must be added in the iOS runner target in Xcode, not in Dart. flutter clean plus a pod reinstall after changing messaging plugins.
  • React Native: check both the app target and any notification service extension; the extension needs its own App ID and profile.
  • Unity: the generated Xcode project loses capability changes on every rebuild unless they are applied through a post-process build script or a committed entitlements file.
  • CI: if profiles are fetched from a shared repository, refresh them after the capability change; otherwise every pipeline run signs with the old profile.

Rich notifications and extensions

A notification service or content extension is a separate target with its own bundle ID, App ID and provisioning profile. Adding the capability to the app target alone leaves the extension unsigned for push, which produces the same class of error on a different bundle identifier — check each target in the archive.

The wider signing picture — certificates, profiles, entitlements and the errors around them — is on iOS code signing and profiles. If the build is also refused for the SDK version, see legacy app update.

Read the detailed guide: iOS Code Signing & Profiles →