For AI agents: llms.txt is a short guide that sends you to the rules your problem needs, and rules.json holds every rule of this playbook as JSON.

How to do it

Apple's App Review Guidelines (4.5.4) say push notifications must not be required for the app to function. Read the permission state, and never block a screen or a sign-up step on it. Every push has a copy in the server inbox, and critical types also use another channel, such as email. When permission is denied, show a short hint where the settings live, once, and never ask again in a loop. Build each feature on what works without extras first, as Build on HTML that already works says.

Examples

Using these examples: they show one way to follow this rule. Keep the behaviour and the check, not the syntax. Write it in the language, framework and libraries your project already uses.

JavaScript example

export function pushState() {
  if (!('Notification' in window) || !('PushManager' in window)) return 'unsupported';
  return Notification.permission; // 'granted', 'denied' or 'default'
}

// The order flow never waits on push. It only offers the button when asking still makes sense.
document.querySelector('#notify-shipping').hidden = pushState() !== 'default';

Plain text example

import UserNotifications

func offerShippingAlerts() async {
    let settings = await UNUserNotificationCenter.current().notificationSettings()
    switch settings.authorizationStatus {
    case .notDetermined: showShippingAlertButton()
    case .denied: showSettingsHintOnce()
    default: break // Push is on. The inbox still gets every item either way.
    }
}

How to check

A browser test denies notification permission and runs sign-up, checkout and the inbox flows. Each one completes, and a new notification shows in the inbox. No permission prompt appears a second time.

Sources

• Apple App Review Guideline 4.5.4

Related rules

• Build on HTML that already works in Website