RORK LABJP
FUNDING — Rork raises $15M, drawing fresh attention to its mobile-first no-code AI positioningMAX-NATIVE — Rork Max reaches native territory React Native can't: AR/LiDAR, Metal 3D, widgets, Dynamic Island, Live Activities, HealthKit, and on-device Core MLMOBILE-FIRST — While Bolt and Lovable focus on web apps, Rork builds mobile apps — production-ready from a plain-language descriptionWWDC — WWDC26 wraps with AI becoming a core OS capability; the iOS 27 generation raises the value of widgets and Live ActivitiesPRICING — Free to start, paid plans from $25/mo, Rork Max at $200/mo — ship fast on Expo, then go native with Max where it pays offALL-APPLE — Rork Max generates pure Swift covering iPhone, iPad, Apple Watch, Apple TV, Vision Pro, and iMessageFUNDING — Rork raises $15M, drawing fresh attention to its mobile-first no-code AI positioningMAX-NATIVE — Rork Max reaches native territory React Native can't: AR/LiDAR, Metal 3D, widgets, Dynamic Island, Live Activities, HealthKit, and on-device Core MLMOBILE-FIRST — While Bolt and Lovable focus on web apps, Rork builds mobile apps — production-ready from a plain-language descriptionWWDC — WWDC26 wraps with AI becoming a core OS capability; the iOS 27 generation raises the value of widgets and Live ActivitiesPRICING — Free to start, paid plans from $25/mo, Rork Max at $200/mo — ship fast on Expo, then go native with Max where it pays offALL-APPLE — Rork Max generates pure Swift covering iPhone, iPad, Apple Watch, Apple TV, Vision Pro, and iMessage
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.

Rork391Expo64Push Notifications5expo-notifications3Onboarding6Retention8

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-04-29
Why Your Rork Android App Shows a White Square Notification Icon (and How to Fix It)
Your Rork or Expo app's notification icon shows up as a white square or blob on Android. Here's the underlying Android spec, the correct transparent icon recipe, the right app.json fields, and the cache traps that make fixes appear to do nothing.
App Dev2026-06-03
Unifying Onboarding Across Six Wallpaper Apps: What One Month of First-Day Retention Showed Me
I folded the onboarding flows of six wallpaper apps scaffolded with Rork into a single config-driven component and watched first-day retention and push opt-in for a month. Here is an honest, operational note on what moved and what didn't.
Dev Tools2026-06-13
Keeping a Rork-Built Expo App Ready for Kotlin Migration — Design Notes After Android Studio's Migration Agent Announcement
Android Studio's new agent can migrate React Native apps to native Kotlin. Here is how I restructured a Rork-built Expo app to stay migration-ready: a native dependency audit script, a portable core layer pattern, and a readiness checklist.
📚RECOMMENDED BOOKS
Build a Large Language Model (From Scratch)
Sebastian Raschka
LLM Dev
Prompt Engineering for LLMs
Berryman & Ziegler
Prompting
AI Engineering
Chip Huyen
AI Eng
* Contains affiliate links
See all →