The mistake almost every first-time app ships with

The default tutorial shows you requestPermissionsAsync() on the first screen. So you add it, and the first time anyone launches your app they get slapped with a native OS prompt.

Opt-in rate collapses. The OS only shows the native prompt once. After No, the user has to go into Settings to change it. Most never do.

The real numbers from a shipped app

I had a fitness app with two release branches that differed only in when the push permission prompt was shown.

• Version A (first launch): 28% opt-in rate.
• Version B (after the first workout logged): 56% opt-in rate.

Same users. Same copy. Two times the opt-in.

Why this matters beyond the number

Push permission is the retention loop for most apps. If only 28% of users can receive a push, your D7 retention is capped from day one. Doubling the opt-in rate doubles the top of your retention funnel.

The fix

1. Do not ask on first launch. Let the user get in and do one thing.
2. Ask after the first meaningful action. For a fitness app, that is the first logged workout. For booking, the first booking confirmation. For ecommerce, the first order placed.
3. Show a pre-prompt in your own UI first. One screen with "We will ping you when your streak is about to break. Allow notifications?" — Allow button, Not now button. Only if they tap Allow do you call the native API.

The pre-prompt screen exists because the OS prompt only happens once. If they decline the pre-prompt, you can ask again later. If they decline the OS prompt, you cannot.

What the pre-prompt looks like in the boilerplate

AI App Factory ships a PushOptInScreen component that you drop in after the first meaningful action. It handles the pre-prompt, the native call, and the state flag so you do not ask twice.

See pricing