iOS gives you exactly one chance to ask for push permission with the native prompt. If the user taps “Don’t Allow,” that decision is buried in the Settings app where almost nobody goes to reverse it. That single fact should shape your entire iOS push notification permission strategy — and it is why the apps with the best opt-in rates almost never show Apple’s prompt cold.
This guide covers how iOS permission actually works, the priming pattern that protects your one shot, and how to implement the whole flow with a few lines of SDK code.
How iOS push permission actually works
Every app sits in one of three permission states: the user has not been asked yet, the user granted permission, or the user denied it. The native system prompt — the one Apple renders, with wording you cannot change — moves the user out of the first state permanently. There is no second native prompt. Once denied, the only road back runs through the Settings app, and recovery rates from Settings are poor enough that you should treat a denial as close to final.
Compare that to Android, where notification permission historically defaulted to on. It is the core reason iOS opt-in rates run near 51% while Android runs near 81%, as we covered in the app push marketing guide. On iOS, the opt-in is earned. The upside: a subscriber who deliberately said yes is worth more, engages more, and churns less than a default-on subscriber. Your job is to stack the deck before the question gets asked.
Why timing beats copy
The most common iOS permission mistake is structural, not verbal: firing the native prompt on first launch, before the user has any idea what the app does or why notifications would help them. At that moment the honest answer to “should I let this app interrupt me?” is no — the user has zero evidence either way, and no is the safe default.
The fix is to ask at a value moment — a point in the session where the benefit of a notification is concrete and obvious:
- An eCommerce shopper saves an item to a wishlist → “want to know when the price drops?”
- A shopper completes a purchase → “want shipping updates for this order?”
- A reader finishes a second article → “want a heads-up when we publish on this topic?”
- A user finishes onboarding and hits their first success → “want us to tell you when X happens?”
Same prompt, same wording from Apple — dramatically different answer, because the question finally has context.
The priming pattern: soft-ask before the real ask
Priming means showing your own in-app screen — a pre-permission dialog you fully control — before triggering Apple’s prompt. The pattern has one rule that makes it work: only fire the native prompt after the user says yes to yours.
If the user accepts your soft-ask, they have already decided; the native prompt is a formality and converts at very high rates. If they decline your soft-ask, you have lost nothing — the native prompt was never shown, the one shot is still live, and you can re-run the soft-ask at a better moment weeks later. The soft-ask is infinitely repeatable; Apple’s prompt is not.
A good soft-ask names the specific value (“price drop alerts on your saved items”), shows what the notification will look like, and offers a genuine decline option that doesn’t guilt-trip. The same principles behind high-converting web push opt-in prompts apply — specificity converts, vagueness doesn’t.
Implementing the flow with the PushEngage SDK
The iOS SDK 1.0 gives you the two calls this flow needs: one to check the current state, one to trigger the native prompt at the moment you choose.
// 1. Check state before deciding what UI to show
let status = PushEngage.getNotificationPermissionStatus()
switch status {
case "notYetRequested":
showSoftAskScreen() // your own UI — the native prompt is untouched
case "denied":
showSettingsNudgeIfEarned() // deep link to Settings, only at a high-value moment
case "granted":
break // already subscribed — get out of the way
default:
break
}
// 2. Only after the user accepts YOUR screen:
PushEngage.requestNotificationPermission { granted, error in
if granted {
// subscribed — thank them with value, not a welcome blast
}
}Note what the code enforces: the native prompt fires from inside your soft-ask’s accept handler and nowhere else. No launch-time surprise, no wasted shot.
Recovering users who said no
For users in the denied state, the native prompt is gone, but the game isn’t over. The recovery play is a Settings deep link — UIApplication.openNotificationSettingsURLString takes the user straight to your app’s notification toggle. Reserve it for moments where the user is actively asking for something notifications would deliver (“get notified when it’s back in stock” → “notifications are off for this app — turn them on in Settings?”). A Settings nudge at a random moment reads as pestering; the same nudge at a want-it-now moment reads as help.
Measure it like the growth metric it is
Opt-in rate is the multiplier on every push campaign you will ever run, which makes it worth instrumenting properly: track soft-ask acceptance and native-prompt conversion separately, segment by the trigger moment that fired the ask, and check subscription state with getSubscriptionNotificationStatus — which verifies both the subscription and the permission — before counting anyone as reachable. Ten points of opt-in improvement compounds across every campaign, every week, for the life of the app.
Permission is the gate. Once a user is through it, everything else — triggered campaigns, segmentation, drip journeys — runs from the PushEngage dashboard without another line of app code. The iOS setup guide gets you from SDK install to your first campaign in an afternoon.
