When should we ask for notification permission?

After the user has done something that makes a future notification obviously useful — placed an order, followed a topic, started a process with a later step. Asking on first launch, before any value has been shown, produces the worst opt-in rates and the refusal is effectively permanent.

What opt-in rate should we expect?

It varies enormously by category and by when you ask. Utility and transactional apps do far better than content apps. Rather than chasing a benchmark, compare against your own baseline after moving the prompt later — that change alone usually produces the largest improvement available.

Can we re-ask if someone declines?

Not through the system dialog on iOS; one refusal is final and the only route back is Settings. This is why the pre-prompt matters: ask your own question first, and only trigger the real dialog for people likely to accept. A no to your own prompt costs nothing.

Do notifications actually increase retention?

Relevant ones do. Irrelevant ones cause uninstalls, and the uninstall is invisible in your notification metrics because the user is simply gone. Judge them on retention and uninstall rate, not on open rate — open rate rewards exactly the behaviour that drives people away.

Mobile7 min

Push Notifications People Do Not Turn Off

Permission is granted once and revoked forever. Most apps spend it in the first thirty seconds and then burn what is left on marketing. Here is how to keep the channel alive.

BunnyDevs2 Sept 2026

Push permission is a one-time grant with a permanent refusal attached. On iOS, if someone declines the system dialog, you do not get to ask again — the only way back is a trip to Settings that almost nobody makes.

Most apps spend that single chance in the first thirty seconds, before the user has any idea what they would be agreeing to receive. Then, having secured permission, they spend it on marketing until the notifications are switched off or the app is deleted.

Both mistakes are avoidable and both are about timing rather than copy.

Ask at the moment the answer is obvious

Do not ask on launch. At that point the honest answer to "may we send you notifications" is "I do not know what this app is yet", and the safe response to an unknown question is no.

Ask immediately after an action that implies a future event:

They placed an order — you will tell them when it ships.
They followed a topic, a seller, a match — you will tell them when something happens.
They started something with a later step — you will remind them.
They set a reminder — that is the entire point.

At that moment the value is self-evident and the acceptance rate is a different number entirely.

Use a pre-prompt

Before triggering the system dialog, ask your own question in your own interface. Explain in one sentence what you will send and roughly how often.

If they say no to yours, nothing is lost — you can ask again next month, in a better moment. If they say yes, you show the system dialog to someone who has already decided.

This single pattern protects the one-shot permission from being wasted on undecided users. It is the highest-return change available in this area and it takes a day to build.

Send things that were expected

The test for any notification: would the user have been disappointed not to receive it?

That standard cleanly separates the two categories.

Passes: your order shipped, your driver is two minutes away, someone replied to you, the thing you asked to be told about happened, your appointment is tomorrow, a payment failed and your service is about to stop.

Fails: we miss you, check out what is new, a 20% weekend sale, someone you might know joined, your weekly summary that nobody asked for.

The second category is where the channel goes to die. Each one costs a fraction of the goodwill that bought the permission, and the cost is not visible in your metrics until it is spent.

Give people controls that are not all-or-nothing

If the only options are everything or nothing, one unwanted notification too many takes all of them.

Categories, in your own settings, with sensible defaults: order updates, replies, reminders, offers. Let people keep what they value and remove what they do not. A user who turns off marketing and keeps delivery alerts is a retained channel. A user who turns off everything at the OS level is gone permanently and you will not know why.

Respect quiet hours. A notification at two in the morning is uninstalled by breakfast, and time zones are a solved problem.

Measure the thing that matters

Open rate is a trap. It rewards notifications that provoke a tap, which is not the same as notifications people are glad to receive. A push saying "your account has a problem" has an excellent open rate and does considerable damage.

Track instead:

Notification-disabled rate. The share of users who turn you off, over time, split by which category you sent. This is the direct measure of whether you are spending the permission faster than you earn it.

Uninstalls following a send. The most honest signal available, and the one that most obviously connects a campaign to its real cost.

Retention among opted-in versus opted-out cohorts. If your notified users are not retaining better, the notifications are not working regardless of open rates.

The details that decide delivery

Deep link to the exact screen. A notification about an order that opens the home screen is a broken promise. This is the most common implementation defect we find, and it destroys trust faster than the content does.

Collapse and replace. Five updates about one delivery should be one notification that updates, not five. Both platforms support this and most apps ignore it.

Handle the tokens properly. They rotate. They become invalid. Sending to dead tokens skews your metrics and, at scale, gets you rate-limited. Clean them up on failure responses rather than accumulating them.

Test on a real device, in the background. Behaviour differs between foreground, background and terminated states, and the terminated case is the one that breaks silently on Android.

If you are asking for permission on launch today

Move the prompt. That one change usually produces a larger improvement than anything else on this list, and it costs a day of work.

Then look at what you have sent over the last three months and count how many would pass the disappointment test. If it is fewer than half, the channel is being spent rather than built, and the bill arrives as a retention problem nobody attributes to notifications.

If you want a review of your notification strategy before it costs you the permission, or you are planning the flow for a new app, tell us what you are building.