Why the permission matters so much
Push is one of the highest-converting channels in mobile marketing: it appears outside the app,
directly on the lock screen. Unlike email or in-app messaging, it requires explicit consent.
Since iOS 10 the rule has been that the system dialogue appears exactly once. A refusal means
notifications are unavailable permanently, unless the person enables them in settings. That makes
the moment and the context of the first request one of the most consequential decisions in mobile
onboarding.
Platform differences
| Platform | Default behaviour | When explicit consent is needed |
|---|---|---|
| iOS 10+ | Notifications off | Always, one request |
| Android before 13 | Notifications on | Not required |
| Android 13+ | Notifications off | Yes, on first launch |
On Android 13 and later, apps targeting the current SDK must request permission. Apps on an older
target keep the previous behaviour until they are rebuilt.
The two-step pattern
The best practice is a custom in-app screen before the system dialogue:
- Explain why notifications are useful: we will tell you when something on your wishlist drops in
price. - Offer allow (which opens the system dialogue) and later (which closes without cost).
- The system dialogue is shown only to those who tapped allow.
That way the expensive system dialogue is spent only on motivated users.
Tip: test the moment. A request after the aha moment — a first order, a first save — produces a
materially higher opt-in rate than one at first launch, when the value is still unclear.
What to do with users who declined
A refusal does not mean the channel is lost. For opted-out users there are:
- In-app messages — shown inside the app on open
- A notification centre — an inbox inside the app
- Email — where it was collected at registration
The right strategy is not to ignore the opted-out segment but to switch to the channels that remain.