Push notifications are the one channel that reaches users when your app is closed. Used well, they deliver genuinely useful information at the right moment: your order has shipped, your appointment is in an hour, a colleague approved your request. Used badly, they train people to ignore your app, switch notifications off or uninstall it altogether. This guide covers the practices that keep notifications on the useful side of that line.
How push notifications work, briefly
Your app registers with the operating system and receives a unique device token, which it sends to your backend. When your backend wants to notify that user, it sends the message to Apple Push Notification service (APNs) for iOS devices or Firebase Cloud Messaging (FCM) for Android, and they deliver it to the device. Delivery is generally fast, but neither service guarantees delivery or exact timing, so never rely on a push notification as the only way critical information reaches someone.
On iOS, apps must ask the user's permission before showing notifications. Recent Android versions also require runtime permission. A "no" is hard to reverse, because users must then go into system settings to change it. That makes the permission request the most important moment in your notification strategy.
Asking for permission at the right moment
- Do not ask on first launch before users understand what the app does. They have no reason to say yes.
- Ask in context. The best moment is when notifications are obviously useful: just after a user books an appointment ("Want a reminder before your appointment?") or places an order ("Get updates when it ships?").
- Explain first. Show your own screen describing what you will send and why, with clear "Allow" and "Not now" options, before triggering the system prompt. If they choose "Not now", you have not used up your one system prompt.
- Consider quieter options. iOS supports provisional authorisation, which delivers notifications quietly to the notification centre so users can judge their value before deciding.
What to send: push notification best practices for content
Every notification should pass a simple test: would this user be glad, or at least not annoyed, to receive it right now?
Transactional notifications
Messages triggered by the user's own activity, such as order updates, payment confirmations, booking reminders, replies to their messages and security alerts, are the most valued. Make these excellent before adding anything else.
Marketing and engagement notifications
Promotions, recommendations and "we miss you" messages carry the most risk. Send them sparingly, make them relevant to each user's behaviour, and give users a separate setting to turn them off without losing transactional updates. Check the consent and marketing rules that apply in your markets, as well as each store's policies on promotional notifications.
Writing the message
- Lead with the useful information: "Your order #4821 is out for delivery" beats "Great news!"
- Keep it short. Lock screens truncate long text.
- Personalise with care: the user's name rarely adds value; their order, appointment or document does.
- Avoid clickbait and false urgency. Users notice, and stores can take action against misleading notifications.
Timing and frequency
- Respect time zones. Schedule non-urgent messages for the user's local daytime, not your server's.
- Cap frequency. Set limits on marketing messages per user per week, and stop sending if users stop opening them.
- Batch where sensible. Ten separate "new comment" alerts in an hour are worse than one summary.
- Use urgency levels honestly. iOS lets apps mark notifications as passive, active or time-sensitive. Reserve time-sensitive for things that genuinely cannot wait.
Give users control
On Android, group notifications into notification channels by type, such as "Order updates", "Messages" and "Offers". Users can then mute promotional channels while keeping important ones. Mirror this with in-app notification preferences on both platforms. People who can fine-tune notifications are less likely to disable them all.
Deep linking
Tapping a notification should open the exact screen it refers to: the specific order, message or invoice, not the app's home screen. Test deep links for users who are logged out, users on old app versions, and items that no longer exist, and show something sensible in each case.
Privacy and security
- Notifications often appear on lock screens. Avoid putting sensitive details, such as account balances, health information or one-time passwords for high-value actions, in the visible text. A generic "You have a new secure message" protects users.
- Keep the notification credentials for APNs and FCM on your backend, never in the app.
- Remove device tokens when users log out, so the next person using that phone does not receive the previous user's notifications.
- Update stored tokens when the operating system issues new ones, and clean up tokens that APNs or FCM report as invalid.
Measuring what works
| Metric | What it tells you |
|---|---|
| Permission opt-in rate | Whether your request timing and explanation work |
| Open rate by notification type | Which messages users value |
| Conversion after open | Whether the notification led to the intended action |
| Opt-outs and channel muting | Which messages annoy users |
| Uninstalls after campaigns | Whether a campaign did more harm than good |
Run controlled tests, holding back a group that does not receive a campaign, to see whether notifications actually change behaviour or simply coincide with it.
Technical checklist
- Backend stores tokens per user and per device, with platform and app version.
- Sending happens from a background queue, with retries for temporary failures.
- Preferences are respected server-side before every send.
- Quiet hours and frequency caps are enforced centrally.
- Delivery and open events are logged for analysis.
A reliable notification system depends as much on the backend as on the app; both are part of our mobile app development work, typically running on the kind of infrastructure described on our cloud solutions page.
Key takeaways
- Ask for permission in context, after explaining the benefit.
- Prioritise transactional messages; send marketing sparingly and let users opt out separately.
- Respect time zones, cap frequency and deep link to the right screen.
- Keep sensitive data off the lock screen and measure opt-outs as carefully as opens.