Push notifications are opt-in and contextual

Requesting notification permission before showing the user any app content is one of the top patterns Apple's guideline 5.1.1 calls out — and one of the highest rates of user denial. Users who see a permission request before understanding the app's value default to "Don't Allow," permanently locking the app out of push on that device. An app that blocks core functionality when notification permission is denied compounds the problem. The correct model — a pre-permission screen explaining specific notification value, followed by a contextual request when the user first enables a notification-powered feature — produces higher grant rates and cleaner review outcomes.

Move the notification permission request behind a pre-permission screen and a feature opt-in, not the app launch sequence.

// src/screens/NotificationOptInScreen.tsx
export function NotificationOptInScreen() {
  async function handleEnable() {
    const { status } = await Notifications.requestPermissionsAsync();
    if (status === 'granted') {
      await registerPushToken();
    }
    navigation.navigate('Home');
  }

  return (
    <View>
      <Text style={styles.headline}>Stay in the loop</Text>
      <Text>Get notified when your orders ship, friends reply, or items go on sale.</Text>
      <Button title="Enable Notifications" onPress={handleEnable} />
      <Button title="Maybe Later" onPress={() => navigation.navigate('Home')} />
    </View>
  );
}

The app must work fully when notification permission is denied — never block navigation to a screen because the user declined notifications.

• ID: app-store-review-blockers.policy-compliance.push-notifications-opt-in
• Severity: info
• What to look for: Count all relevant instances and enumerate each. Check when push notification permission is requested. Look for requestPermissionsAsync() from expo-notifications, requestAuthorization() from UNUserNotificationCenter, getToken() from Firebase Messaging (which implicitly requests permission on some platforms). Determine: (1) Is the permission requested on first launch without context? (2) Is there a pre-permission screen explaining why notifications are useful? (3) If user denies, does the app crash or degrade badly? Also check notification content: are notifications contextual and useful, or are they promotional messages sent at high frequency?
• Pass criteria: Push notification permission is requested at a relevant moment (after user opts into a notification-powered feature), with a pre-permission explanation. Denial is handled gracefully. Notification content is contextual (activity alerts, reminders) not pure promotional spam.
• Fail criteria: Notification permission requested on first launch before user has seen any of the app; app crashes or blocks core functionality if notification permission is denied.
• Skip (N/A) when: App does not use push notifications (no expo-notifications, no Firebase Messaging, no push library detected and no push-related code in source).
• Detail on fail: "expo-notifications requestPermissionsAsync() called in App.tsx root useEffect — fires on first launch before user interaction" or "App blocks access to main content when notification permission is denied"
• Remediation: Requesting notifications on first launch before showing any value is a top user complaint and Apple guideline concern.
  1. Add a pre-permission screen explaining the value of notifications before the OS dialog:

     "Enable notifications to get alerts when your orders ship,
     your friends post, or your items go on sale."
     

  2. Request permission only when user first opts into a notifications-based feature
  3. Handle denial gracefully — the app must work fully without notification permission
  4. Keep notification frequency reasonable — no more than 1-2 per day for most app types