Most push notification best practices articles are lists of copywriting tips. Copy matters, but it is rarely why users switch notifications off. They switch them off because the app asked for permission before showing any value, then sent the same promotional message to everyone at 3am their time.
This guide covers the strategy behind notifications that people keep enabled: how and when to ask for permission on iOS and Android, which messages earn their place, frequency and timing rules, what to measure, and the technical setup that keeps delivery reliable. For the engineering side in more depth, see our push notifications for mobile apps page, which covers APNs, FCM and backend architecture.
Why notification opt-in is harder than it used to be
On Android, permission used to be automatic. Since Android 13 (API 33), notifications are off by default for new installs and apps must request the POST_NOTIFICATIONS runtime permission. Google’s own advice is to ask in context, not at first launch. Media-session notifications and qualifying call notifications are exempt, and apps that already had notification channels are pre-granted when users upgrade.
On iOS, users have always had to opt in, and the system prompt can be shown only once. If someone taps “Don’t Allow”, the only way back is a trip to Settings, which almost nobody makes unprompted.
Apple also sets a hard line in its App Review Guidelines: apps may not require users to enable push notifications to access functionality. Gating features behind a permission is a rejection risk, not a growth tactic.
The result on both platforms is the same. You get one good chance to ask, and the timing of that ask decides most of your long-term reach.
Push notification best practices for asking permission
The sequence we design into onboarding for most consumer apps. Adjust it for your core action, but keep the order.
Deliver value before asking
Let the user finish one meaningful action first: place an order, save a search, book a slot, follow a team. The permission then has an obvious reason to exist.
Show a pre-permission screen
Before the system dialog, explain in one sentence what you will send and why it helps (“We’ll tell you when your driver is 5 minutes away”). Offer “Not now”. If they decline here, you have not burned the one-time system prompt.
Trigger the system prompt from that screen
Only call the OS permission request when the user taps the positive option. On Android 13+, that is the POST_NOTIFICATIONS request. On iOS, it is the standard authorization request.
Consider iOS provisional authorization
Apple’s provisional option grants permission without a prompt, and notifications arrive quietly in Notification Center with Keep and Turn Off buttons. It suits apps whose first messages are useful but not urgent. Users decide based on real messages, not a promise.
Ask again only with a new reason
If they declined, wait for a moment where a notification is clearly useful (tracking an order, a price alert) and offer a deep link to settings. Never nag on every launch.
Provisional notifications: when quiet delivery wins
Apple’s provisional notifications are underused. With the .provisional option, the app can deliver notifications immediately, without a prompt, but only quietly: no sound, banner or lock-screen alert. Each notification carries Keep and Turn Off buttons, so the user makes the choice after seeing real content.
Provisional delivery works well for content apps, marketplaces and anything where the first notifications are informative (a new listing that matches a saved search, a weekly summary). It is the wrong choice for time-critical messages, such as a ride arriving or a security code, because quiet delivery means the user may not see them in time. For those apps, ask for full permission at the moment the first time-critical message is about to matter.
Which notifications earn their place
Sort every planned notification into one of these types before writing a single message. If a message does not fit a row, it probably should not be a push.
| Type | Examples | Push? | Notes |
|---|---|---|---|
| Transactional | Order shipped, driver arriving, payment received, booking confirmed | Yes, always | The reason most users grant permission. Never mix promotions into these. |
| Security | New login, password changed, one-time codes | Yes | Keep copy factual; never include sensitive data in the payload. |
| User-requested alerts | Price drop on a saved item, back in stock, match starting | Yes | Explicit opt-in per alert. The highest-value non-transactional push. |
| Social | New message, reply, follow, mention | Yes, with controls | Batch when volume is high; let users mute per conversation. |
| Re-engagement | Unfinished cart, streak at risk, saved draft | Sparingly | Cap tightly and stop after no response. |
| Promotional | Sale, new feature, seasonal offer | Rarely | Separate channel or category the user can switch off alone. |
| Content digest | Weekly summary, recommended articles | Often better as email or in-app | Good fit for provisional delivery on iOS. |
Users keep notifications on when every message is either something they asked for or something they would be annoyed to miss. Promotions go in their own channel with their own off switch, so one bad campaign does not cost you your transactional reach.
Channels and categories: give users a volume knob
Android notification channels let users switch off one type of notification instead of all of them. Create channels by purpose (orders, messages, offers, account security) with sensible default importance levels. A user annoyed by offers can then mute offers and keep delivery updates. Without channels, the only switch is “off”.
On iOS, use notification categories with actions (reply, mark as done, view order) and thread identifiers so related notifications group together. Then build an in-app notification settings screen that mirrors those types. It costs a few days of work and is the most effective retention feature for notifications we know of, because it turns “turn all off” into “turn some down”.
Frequency and timing rules
Rules we write into the notification spec for most consumer apps. Agree the caps with marketing before launch, not after the first complaint.
- Send in the user’s local time zone, never the server’s; store it on the device registration.
- Set quiet hours (for example, nothing promotional between late evening and morning) unless the user asked for the alert.
- Cap promotional pushes per user per week, and enforce the cap on the server, not in campaign tools alone.
- Never send the same promotional message twice; suppress it for users who already acted on it.
- Stop re-engagement sequences after two or three ignored messages.
- Collapse or replace stale updates (order status) instead of stacking five notifications.
- Batch social notifications when volume spikes (“4 new replies” instead of four pushes).
- Expire time-sensitive messages so a sale alert does not arrive after the sale ends.
Planning notifications for a new app?
Share your user flows. We reply within one business day with a notification map: which events trigger which messages, the permission flow for each platform and the backend it needs.
Writing notifications people read
- Lead with the specific thing. “Your order from Ali’s Kitchen is 5 minutes away” beats “Update on your order”.
- Keep the first line self-contained. Lock screens and watches truncate. The first few words must make sense alone.
- Deep link to the exact screen. A notification about an order should open that order, not the home tab. Test every deep link on cold start, because that is where they usually break.
- Personalise with data you actually have. Saved items, followed teams and past orders are fair game. Guessing at interests is not.
- Use rich content where it helps. An image of the product that dropped in price earns its bytes. A stock image on a password reset does not.
- Never put sensitive data in the payload. Account balances, health details and full codes can appear on a locked screen. Send a prompt to open the app instead. Our mobile app security best practices guide covers the wider data rules.
The technical setup behind reliable delivery
A great strategy fails if messages do not arrive. On iOS, use token-based authentication to APNs with a .p8 key. Apple requires the signing token to be refreshed no more than once every 20 minutes and at least once every 60 minutes, and rejects tokens older than an hour. A backend that caches the token too long fails silently until someone notices delivery dropped.
On Android, Firebase Cloud Messaging is the standard route, and it also delivers to iOS through APNs. FCM’s legacy APIs were deprecated in June 2023 and shutdown began in July 2024, so every server must use the HTTP v1 API. If you inherited an older backend, check this first. Our Firebase app development page covers the wider Firebase setup.
Beyond the transport, store device tokens per user and per device, delete tokens the providers report as invalid, log every send with a message type, and keep the targeting logic on your server so you can enforce caps and quiet hours in one place. If you also run a web app, iOS 16.4 added Web Push for Home Screen web apps, which can share the same event pipeline; our progressive web app development page explains that setup.
What to measure
Track these per notification type, not just overall. A healthy transactional channel can hide a promotional channel that is driving people away.
| Metric | What it tells you | Watch for |
|---|---|---|
| Opt-in rate | How well the permission ask is timed and explained | Drops after onboarding changes |
| Delivery rate | Whether tokens and credentials are healthy | Sudden falls usually mean an auth or token problem |
| Open rate by type | Which messages users value | Promotions far below transactional is normal; near zero is a warning |
| Opt-out or channel mute rate | Which messages annoy people | Spikes after a campaign |
| Uninstalls after a send | The real cost of a bad message | Compare against days with no promotional sends |
| Downstream conversion | Did the user complete the action the push pointed to | Opens with no action mean a weak deep link or landing screen |
Where notifications fit in the wider growth plan
Notifications are a retention tool, not an acquisition tool. They work best alongside a good onboarding flow, in-app messaging and email. Our mobile app UX best practices guide covers onboarding and permission screens from the design side, and our mobile app marketing service covers how push fits into launch campaigns. For the wider plan, see our guide to mobile app retention strategies.
If your revenue depends on subscriptions or repeat purchases, notifications also feed monetisation. Renewal reminders, trial-ending messages and back-in-stock alerts all need the same care. See app monetization models for how those revenue models shape what you send.
Push notification best practices: frequently asked questions
When should an app ask for notification permission?
After the user has done something that makes notifications useful, such as placing an order or saving a search. Show a short pre-permission screen explaining what you will send, and trigger the system prompt only when they agree. Google advises asking in context rather than at first launch, and on iOS the system prompt can only be shown once.
How many push notifications are too many?
There is no universal number. Transactional and user-requested alerts can be as frequent as the events behind them. Promotional pushes need a strict weekly cap per user, enforced on the server, plus quiet hours in the user’s local time. Watch opt-out and uninstall rates after each campaign; they tell you when you have crossed the line for your audience.
Do Android apps need permission to send notifications?
Yes, since Android 13 (API 33). Apps must request the POST_NOTIFICATIONS runtime permission, and notifications are off by default for new installs. Media-session notifications and qualifying call notifications are exempt, and apps that already had notification channels are pre-granted when a device upgrades. Older Android versions grant notifications automatically.
What are iOS provisional notifications?
A permission option that lets an app deliver notifications without showing a prompt. They arrive quietly in Notification Center with no sound, banner or lock-screen alert, and include Keep and Turn Off buttons. They suit apps whose first messages are informative rather than urgent, because the user decides after seeing real content instead of a promise.
Can I require users to enable notifications to use my app?
No, not on the App Store. Apple’s guidelines state that apps may not require users to enable push notifications to access functionality. Explain the value, offer the option at a useful moment and let the app work without it. Gating features behind the permission risks rejection and tends to produce users who grant it and then ignore everything you send.
Build notifications users keep switched on
Tell us about your app. We reply within one business day with a notification plan covering permission flows, message types, caps and the APNs and FCM setup, under NDA if you prefer.