◉RORK LABJP
●GPT-6.1 SOL — Added to Rork's model menu (09-29) with Low, Medium and High effort; included on Pro and Max●SONNET 5.5 — Claude Sonnet 5.5 is selectable: strong at UI design and faster than Sonnet 5 (09-28)●SONNET 4.5 — Retires on the Claude API on 11/30, 27 days left. If your app calls it, check the migration target●SDK 58 — Moves to React Native 0.88. R8 is now on by default in Android release builds, and iOS prebuild generates a SceneDelegate●OBSERVE — EAS Observe now records native crashes too (SDK 57.0.21 or later, 10/07)●NEW — My App Open Ad Only Showed When the App…●GPT-6.1 SOL — Added to Rork's model menu (09-29) with Low, Medium and High effort; included on Pro and Max●SONNET 5.5 — Claude Sonnet 5.5 is selectable: strong at UI design and faster than Sonnet 5 (09-28)●SONNET 4.5 — Retires on the Claude API on 11/30, 27 days left. If your app calls it, check the migration target●SDK 58 — Moves to React Native 0.88. R8 is now on by default in Android release builds, and iOS prebuild generates a SceneDelegate●OBSERVE — EAS Observe now records native crashes too (SDK 57.0.21 or later, 10/07)●NEW — My App Open Ad Only Showed When the App…
Articles/Dev Tools
⬡ Dev Tools/2026-06-13Intermediate

You Only Get to Ask Once — Implementing a Notification Soft-Ask in Your Rork App to Lift Opt-In

On iOS, once a user denies the notification prompt you can never show it again. In a Rork (Expo) app, instead of firing the system prompt on launch, we add our own soft-ask screen and only request permission once the value has landed. Built with expo-notifications, covering Android 13 POST_NOTIFICATIONS, a recovery path after denial, and opt-in measurement.

Rork611Expo234Push Notifications9expo-notifications7Onboarding9Retention13

✦ Premium Article

I was lining up the notification opt-in rates across the apps I run when one of them stood out for being far too low. It was a wallpaper app built almost identically to the others, yet the share of users who allowed notifications was less than half of the rest.

The cause was easy to find. That one app was firing the notification permission dialog before the first screen even appeared. From the user's side: "I don't even know what this app is yet, and it's already asking to send me notifications."

iOS notification permissions come with a harsh rule that every indie developer hits at least once. The UNUserNotificationCenter dialog can only be shown automatically once in the app's lifetime. The moment a user taps "Don't Allow," calling requestPermissions() from code does nothing — the dialog never appears again. The only path left is asking them to open the Settings app themselves.

So opt-in is decided by when and how you ask. In this article we stop firing the system prompt on launch and slot in our own soft-ask (pre-permission) screen inside a Rork (Expo) app.

Why "you only get to ask once" governs opt-in

On iOS, notification permission has three states: notDetermined (never asked), authorized (granted), and denied. The key point is that the system prompt can only appear while the state is notDetermined. In any other state, requestPermissions() simply returns the current status without showing anything.

notDetermined is a single, once-per-lifetime chance. Spend it carelessly and there is no getting it back.

A soft-ask, by contrast, is our own UI that we can show as many times as we like. If the user declines it, the iOS state stays notDetermined. That is what makes the two-step pattern work: ask in our own dialog first, and fire the system prompt only for the people who agreed. By placing a cushion in front of the system prompt, we reserve that precious single shot for people who are genuinely likely to allow.

In my own apps, the difference between firing the system prompt on launch and asking only after the value had landed came out to more than a 2x gap in the final OS grant rate.

Decide the flow before writing code

Before implementation, lock down the order of decisions. The code is just this order written out.

  1. On launch, read the current permission state. If authorized, do nothing.
  2. If denied, don't show your own dialog; only surface a "you can turn notifications on in Settings" path where it's relevant.
  3. Only while notDetermined, check whether a trigger to show the soft-ask has occurred.
  4. When the trigger fires, show the soft-ask screen.
  5. If the user taps "Turn on" in the soft-ask, only then fire the system prompt (requestPermissions()).
  6. If they tap "Later," leave the state untouched and wait for the next trigger.

Of these six steps, many apps skip 3 and 4 and jump straight to 5 on launch. The whole value of the cushion lives here.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN
✦Understand why firing the system prompt on launch permanently burns your one chance on iOS, and implement a two-step soft-ask — your own dialog first, the system prompt only for those who agree — with expo-notifications
✦Defer the ask until the value has landed (first save, a completed task, the third launch) using a small TypeScript trigger, and design the three events you need to measure opt-in: shown, accepted, OS-granted
✦Build a recovery path that sends denied users to Settings via Linking.openSettings(), and handle the Android 13 POST_NOTIFICATIONS runtime permission difference, production gotchas included
Secure payment via Stripe · Cancel anytime
✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

or
Unlock all articles with Membership →
Share

Thank You for Reading

Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • ✦Copy-paste ready implementation code
  • ✦New advanced guides published daily
  • ✦$5/mo or $10 for lifetime access
View Membership →

Related Articles

⬡ Dev Tools2026-07-17
Shipping Notifications Without Asking First — Provisional Authorization in Rork Apps, and the Expo Snippet That Quietly Undoes It
iOS lets you start delivering notifications with no permission dialog at all, via provisional authorization. The catch: expo-notifications reports granted as false for provisional devices, so the registration snippet in Expo's own docs re-requests permission and fires the very dialog you were avoiding. Here's why granted lies, a hook that models authorization as five states, how to write notifications for quiet delivery, when to ask for the upgrade, and how to keep provisional out of your CTR.
⬡ Dev Tools2026-10-30
It runs in development but the iOS Release build dies on launch — checking whether a missing scheme is the cause
In an expo-router app, an app.json with no scheme can crash only the iOS Release build at launch. Why Debug and Android survive, the two ways to fix it, how to think about leaving the scheme out on purpose, and a pre-submission check.
⬡ Dev Tools2026-10-19
One Missing Tutorial Image Was Enough to Stop the Whole App from Launching. Moving Nice-to-Have Features Off the Required Startup Path
On some devices the app never launched at all. The cause was a design where a missing tutorial image failed the whole screen build. A small wrapper that takes optional features off the startup path, and a pre-release check.