An App Store rejection for push notification spam means your app uses push notifications for advertising, promotions, or marketing without the user's explicit opt-in, or requires push notifications to function, which Apple's guidelines do not allow. The relevant rule is guideline 4.5.4, sometimes mislabeled as 4.3.1, but the substance is the same. Transactional or functional notifications, such as a new message or an order update, are fine and need no special consent. Marketing pushes require a clear, explicit opt-in that the user controls, plus a way to opt out. The fix is to separate marketing consent, make push optional, and stop sending promotional notifications to users who have not agreed.
Short answer
The rejection means you sent marketing pushes without explicit opt-in, or made push required to use the app. Per Apple's App Store Review Guidelines, guideline 4.5.4 states that push notifications must not be required for an app to function and should not be used for advertising, promotions, or direct marketing unless users explicitly opt in and can opt out. Transactional notifications, like a message received or an order shipped, are allowed without extra consent, while promotional ones need a dedicated opt-in. Fix it by adding an explicit marketing-notification opt-in the user controls, providing an opt-out, and ensuring the app works fully even if the user declines notifications entirely.
What the push notification spam rejection means
This rejection is Apple telling you that your notifications cross into advertising or marketing without the user's clear agreement, or that your app leans on push in a way the guidelines prohibit. It is governed by guideline 4.5.4, which covers how apps may and may not use the notification system. Despite the number in some search phrases, the push rule sits in section 4.5, and the substance is what matters.
The core of the rule is consent and necessity. Push notifications are a shared system users can disable at any time, so Apple does not allow them to be a channel for unsolicited marketing or a hard requirement for basic app function. When your app uses push for promotion without opt-in, or will not work unless notifications are enabled, that is the behavior the rejection is targeting. The wrong guideline number in the rejection text is worth ignoring; focus on which of the two behaviors, marketing or requirement, actually applies to your app.
Marketing vs transactional pushes
The key distinction is between transactional and marketing notifications. Transactional, or functional, pushes are tied to something the user did or expects: a new direct message, a comment reply, an order update, a reminder they set. These are allowed and do not need a separate marketing opt-in, because they are a normal part of the app's function that the user is implicitly expecting.
Marketing pushes are different. A promotional notification, a sale announcement, a nudge to come back, or any advertising message, requires explicit opt-in and can only go to users who agreed to receive them. The mistake that triggers this rejection is treating the standard system notification permission as consent for marketing, when Apple expects a distinct, clear agreement for promotional messages. So separate the two: send transactional pushes as needed, and send marketing pushes only to users who explicitly chose them. A useful sanity check is to ask, for each notification your app sends, whether the user is expecting it or being sold something, since that question maps almost exactly onto what Apple allows.
The opt-in requirement
For marketing notifications, you need an explicit opt-in that is clearly about promotional messages and is under the user's control, separate from the operating system's notification permission. The user should understand they are agreeing to receive marketing, and they should be able to decline while still using the app and still receiving necessary transactional notifications. Bundling marketing consent into the general permission prompt is not enough.
You also need a way to opt out. Users who agreed to marketing notifications must be able to turn them off later, typically through a setting in your app, so consent is reversible. The combination of a clear, specific opt-in and an accessible opt-out is what makes promotional push notifications compliant. Building that consent flow, rather than sending marketing to everyone who allowed notifications, is the central fix for this rejection. A simple in-app toggle labeled clearly as promotional notifications, defaulted off, is usually all it takes to satisfy the requirement.
Push must not be required to function
Beyond marketing, guideline 4.5.4 requires that push notifications are not necessary for your app to work. A user who declines notifications entirely should still be able to use the app's core features. If your app blocks functionality, gates content, or otherwise does not work without push enabled, that alone can cause a rejection, independent of any marketing concern.
Design the app so notifications are an enhancement, not a dependency. Features that use push should degrade gracefully when notifications are off, and nothing essential should be locked behind enabling them. Confirming that your app is fully usable with notifications disabled is a specific thing to test before resubmitting, since a reviewer may check exactly that. Walk through onboarding and the core flows with the notification permission denied, and make sure nothing dead-ends or repeatedly re-prompts.
How to fix and resubmit
The fix combines consent and independence. Add a dedicated opt-in for marketing notifications that the user controls, with a clear description and an opt-out, and stop sending promotional pushes to anyone who has not opted in. Keep sending transactional notifications as normal, since those are allowed. Then verify the app works fully without any notifications enabled, so push is not required to function.
Once those are in place, resubmit, and if helpful, note in the App Review information what you changed, such as the new marketing opt-in and the fact that the app functions without notifications. Address the specific concern the Resolution Center raised rather than making broad changes, since the rejection points at either the marketing-without-consent issue, the push-required issue, or both, and fixing the cited one is the fastest route back.
Compliant versus non-compliant
Seeing the cases side by side clarifies what is allowed. The table below sorts notification uses into compliant and not.
| Notification use | Allowed without a separate marketing opt-in? |
|---|---|
| Transactional, such as a new message or order update | Yes |
| A reminder or alert the user set up | Yes |
| Marketing, promotions, or advertising | No, requires explicit opt-in |
| Push required for the app to function | No, never allowed |
| Marketing with no way to opt out | No, opt-out is required |
Read the table against what your app sends. Transactional and user-requested notifications are fine, while any promotional message needs a dedicated opt-in and opt-out, and push can never be a requirement for basic function. If a notification does not fit cleanly into the transactional rows, treat it as marketing and gate it behind the opt-in.
Checklist
A short sequence brings your notifications into compliance. The checklist below covers it.
| Check | Action | Done? |
|---|---|---|
| Marketing opt-in | Add an explicit, user-controlled opt-in for promotional pushes | [ ] |
| Opt-out | Provide a way to turn marketing notifications off | [ ] |
| App works without push | Ensure core features function with notifications disabled | [ ] |
| Transactional pushes | Keep sending functional notifications as normal | [ ] |
| No sensitive data | Avoid sending confidential information via push | [ ] |
The two that resolve most cases are adding a real marketing opt-in with an opt-out and making the app fully usable without notifications. Fix the specific issue the Resolution Center cited, keep transactional pushes as they are, and resubmit.
What to take away
- The push notification spam rejection means marketing pushes without explicit opt-in, or push required for the app to function, under guideline 4.5.4.
- Transactional notifications, like a new message or order update, are allowed without a separate marketing opt-in.
- Marketing pushes require a clear, user-controlled opt-in and an accessible opt-out, separate from the system notification permission.
- Push must never be required to use the app; core features should work with notifications disabled.
- This is a policy matter, not app security; scan your build with PTKD.com for the security issues a notification fix does not address.
