Push notifications: the rules and the RN failures

The permission moment

Explain before you prompt. A short in-app screen saying what you will send and why, with a "not now" that does not fire the system prompt. Then prompt only when they say yes.

This costs one screen and it is the highest-leverage thing in this whole subject, because it converts the one irreversible ask into a reversible one.

Attach it to an action. "Notify me when this is ready" is a request with a purpose. A prompt during onboarding is a tax.

And handle the decline gracefully. The app should be fully usable without notifications, which is both a guideline requirement and the thing that determines whether someone re-enables them later.

The RN failures, all silent

The capability was never declared, so prebuild did not write the entitlement, and registration fails on device with no obvious cause.

// app.json
"ios": { "entitlements": { "aps-environment": "production" } }

Verify after building, not after editing, because the generated ios/ is regenerated:

npx expo prebuild --clean
grep -A2 'aps-environment' ios/*/*.entitlements

The token is registered against the wrong environment. Development tokens do not work in production builds. This is the classic "works in TestFlight, not in the store" symptom, and it produces no error anywhere.

Permission is requested at module load. A requestPermissions() at import time fires the prompt before the user has seen anything. Easy to do accidentally, particularly when a library's example code is copied.

# where the prompt is actually triggered
grep -rn "requestPermission\|getPermissionsAsync\|requestPermissionsAsync" src app | head

If any of those are outside a user-initiated handler, that is the bug. The EAS submission checklist.

For App Review

If notifications are a core feature, a reviewer needs to see one.

They will not wait for a scheduled push and they will not create the conditions that trigger one. Provide a demo path — a debug action on the demo account, or a documented step that sends one immediately — and describe it in the review notes.

Notifications: on the demo account, Settings > Send test
notification triggers one immediately. In production these fire
when a job's status changes.

Without that, a reviewer trying to evaluate a notification feature finds nothing, and it is filed under 2.1 completeness rather than as a notification problem. When a reviewer cannot test your app. · Review notes that work.

Content rules worth internalising

No sensitive personal data in the body. Health, finance, anything a person would not want a colleague reading over their shoulder. Say "you have a new result" and put the result behind the unlock.

No promotional content without consent, and consent means an in-app mechanism, not a checkbox in a policy nobody read.

An opt-out that works. Per category is better than all-or-nothing, and it materially reduces the number of people who turn everything off.

Do not send at unreasonable hours. Not a guideline in itself; it is the fastest route to a user disabling the channel permanently, which is the same outcome as never having had it.

The declaration side

Push involves a device token, which is an identifier, which means it appears in your App Privacy label and your Play Data safety form. Neither updates itself when you add the feature. App privacy labels. · Play Data safety.

shipcheck reports whether the push entitlement is declared where prebuild will write it, whether permission is requested outside a user-initiated path, and whether adding push has changed what your privacy declarations need to say. What it checks. · The first-submission checklist.

Questions and answers