Guideline 4.5.4 Push Notifications: required pushes, marketing consent and the opt-out Apple expects

The first rule now has a twin. On January 25, 2024 Apple added to Guideline 5.1.2(i) that apps may not require users to enable system functionalities such as push notifications “in order to access functionality, content, use the app, or receive monetary or other compensation”. Our 5.1.2 page covers the privacy side.

This is the 4.5.4 rejection developers post most. The wording has barely changed in nine years — from a 2017 case to an April 2026 one:

The 2026 app told users after login that it needed notifications to work, because its job was prompting people to answer questionnaires. An Apple engineer's accepted answer on the forum was blunt: “To satisfy App Review's notes you need to add relevant functionality to your app even if the user does not consent to notifications.” The 2017 case was subtler: phone-number sign-in failed with an error when notifications were off, because the verification flow depended on them.

• Give every notification-driven feature an in-app path. Pending questionnaires, reminders or messages should show up as a list or badge when the app is opened.
• Test sign-in with notifications denied. Phone verification, magic links and two-factor flows are where a hidden dependency usually sits.
• Don't block on the permission prompt. If someone taps “Don't Allow”, the next screen should be the app, not a wall explaining why they must enable notifications.

Tapping Allow on the iOS prompt lets you send notifications. It isn't consent to promotions. Apple's Human Interface Guidelines spell out what 4.5.4 means by “consent language displayed in your app's UI”:

The same page adds that you “must also provide an in-app settings screen that lets people change their choice”, and to “never use the Time Sensitive interruption level to send a marketing notification.” In our Cal AI teardown, the notification permission (primed with a mock dialog at step 9) and the marketing opt-in (a separate choice on the sign-up screen) are two different moments. Copy that split:

import SwiftUI

struct NotificationSettingsView: View {
    // Off until the person turns it on — reminders and marketing are separate choices.
    @AppStorage("notifications.marketingOptIn") private var marketingOptIn = false

    var body: some View {
        Form {
            Section {
                Toggle("Offers and new features", isOn: $marketingOptIn)
            } footer: {
                Text("Occasional notifications about discounts and new features. You can turn this off here at any time.")
            }
        }
        .navigationTitle("Notifications")
        .onChange(of: marketingOptIn) { _, isOn in
            // Tell your server so promotional campaigns only target opted-in devices.
            PushPreferences.setMarketing(enabled: isOn)
        }
    }
}

Your sending side has to respect it too: tag opted-in devices on your server or in your push provider, and send promotions only to that segment. Reminders the person set up themselves — a workout time, a bill due date — are informational, not marketing.

Apple's documentation asks you to “make the request in a context that helps people understand why your app needs authorization” — after someone sets a reminder, not on first launch. If you'd rather not interrupt at all, provisional authorization (iOS 12 and later) sends notifications on a trial basis without a prompt:

import UserNotifications

/// Call right after the person sets their first reminder.
func requestReminderPermission() async -> Bool {
    let center = UNUserNotificationCenter.current()
    return (try? await center.requestAuthorization(options: [.alert, .sound, .badge])) ?? false
}

/// No prompt: notifications go quietly to Notification Center
/// until the person chooses to keep or turn them off.
func startProvisionalNotifications() async {
    _ = try? await UNUserNotificationCenter.current()
        .requestAuthorization(options: [.alert, .sound, .provisional])
}

• Keep private details off the lock screen. Apple's HIG says to “avoid including sensitive, personal, or confidential information in a notification.” “You have a new result” is safer than the result itself.
• Live Activities are covered too. On June 8, 2026 Apple updated Guideline 4.5.3 to say Live Activities “may not be used to spam, phish, or send unsolicited messages to customers.” The Live Activities HIG already said not to use them “to display ads or promotions.”
• Abuse costs more than one app. 4.5.4 ends with “Abuse of these services may result in revocation of your privileges” — your access to the push service itself.

1. 01

   Reproduce with notifications off

   Delete the app, reinstall, tap “Don't Allow” at the prompt, and go through sign-in and the main features. Note every screen that breaks or nags.

2. 02

   Add the fallback

   An in-app list, badge or inbox for whatever the notification would have said. The feature has to be useful without the push.

3. 03

   Separate marketing consent

   If you send promotions, add a clearly worded opt-in that's off by default and a matching switch in Settings.

4. 04

   Upload a new build

   These are code changes, so a metadata edit won't clear the rejection.

5. 05

   Explain the no-notification path

   Tell App Review exactly how the app works with notifications disabled and where the opt-out lives.

Hello App Review team,

Thank you for the feedback on Guideline 4.5.4.

In build [number], push notifications are optional:
- With notifications disabled, [pending questionnaires] appear in
  [Home > Inbox] and as a badge when the app is opened.
- Sign-in no longer depends on notifications.
- Promotional notifications are off by default. Users opt in on
  [screen] and can opt out in Settings > Notifications.

To verify: install, choose "Don't Allow" at the prompt, then [steps].

Thank you,
[Name]