Push Notifications Done Right: A Guide for App Owners

Push notifications work when each message is timely, relevant and wanted, and they backfire when they are frequent, generic or sent without a reason the user can see. To do them right, ask permission at a meaningful moment, send messages triggered by real events, give people control over what they receive, and test delivery carefully on both iOS and Android. This guide covers the product decisions and the technical setup so you can plan notifications that help rather than irritate.

What push notifications are good for

Notifications bring people back to an app that is not currently open, so they should deliver something the user would otherwise miss. Strong use cases are:

• Transactional updates: order confirmed, delivery arriving, payment received.
• Time-sensitive alerts: appointment reminders, security warnings, price or stock changes the user asked about.
• Social or collaborative events: a message from a person, a comment on something the user wrote.
• Personal progress: a streak, a goal, a task due soon, if the user opted into it.

Weak use cases are generic broadcasts to everyone, "we miss you" messages sent daily and promotions unrelated to anything the user did.

Permission: the moment decides the outcome

On iOS the system asks the user once, and a denial is hard to reverse because it requires a trip into the device settings. Android now also asks for notification permission at runtime on recent versions. Because of this, a prompt shown on first launch, before the user understands the value, wastes a one-off chance.

A reliable permission pattern

1. Wait until the user has done something that notifications would improve.
2. Show your own screen first: one sentence on what they will receive and why it helps, with "Allow" and "Not now" buttons.
3. Only if they choose "Allow", trigger the real system prompt.
4. If they choose "Not now", ask again later at another relevant moment, and never repeatedly in a row.
5. If they have denied it at system level, show a gentle explanation with a shortcut to settings when they try a feature that needs it.

This follows the same principle as other UX guidance in mobile app UX patterns that reduce drop-off: ask for things in context.

Design the message

A good notification is a very small piece of writing. It should be understandable at a glance on a lock screen.

• Put the useful information first, for example "Your table is booked for 7pm tomorrow."
• Keep it short and specific. Avoid vague teasers.
• Make it actionable, with a deep link that opens the exact screen the message refers to, not the home screen.
• Use a consistent tone that matches the product.
• Avoid sending sensitive content that would be visible to anyone who glances at the screen.

Relevance, timing and frequency

Segment and trigger messages by behaviour rather than blasting everyone. Respect time zones and quiet hours, so people are not woken by a promotion. Group related notifications instead of sending five in a row. A sensible approach is to define notification categories, such as order updates, messages and offers, and let users switch each category on or off inside the app. Fewer, well-targeted messages usually do better than volume, and you can verify that with your own opt-out and engagement data rather than industry averages.

How push notifications work technically

Understanding the plumbing helps you plan and debug.

1. The app asks the operating system for permission and, once granted, receives a device token.
2. The app sends that token to your backend, which stores it against the user.
3. When an event occurs, your backend sends a message to the platform's push service: Apple Push Notification service for iOS, or Firebase Cloud Messaging for Android.
4. The push service delivers the message to the device, where the OS displays it or hands data to the app.

Tokens change, expire or become invalid when an app is uninstalled, so your backend must refresh and clean them regularly. Your choice of backend, covered in Firebase versus a custom API, affects how much of this you build yourself. Many teams use Firebase Cloud Messaging, or a dedicated engagement platform, rather than managing every detail directly.

Notification types to know

Type	What it does	Typical use
Display notification	Shows visible text on the device	Order and message alerts
Silent or data message	Delivers data to the app without showing a banner	Refreshing content in the background, subject to OS limits
Local notification	Scheduled on the device with no server	Reminders and timers
Rich notification	Includes an image or actions	Reply or confirm from the banner

Operating systems limit background delivery to protect battery, so never rely on silent messages for anything critical.

Testing notifications properly

Notifications fail in subtle ways, so build them into your test plan. Check delivery on real devices for both platforms, with the app in the foreground, in the background and fully closed. Test with permission denied, with battery-saving modes on and after reinstalling. Verify deep links, language and time zone handling, and the behaviour when a user is logged out or switches accounts. See our mobile app testing strategy for how to organise this.

Measure what notifications do

Track opt-in rate, delivery, opens, the action taken afterwards and opt-outs or uninstalls following a change in frequency. Compare notified and un-notified groups where you can. The point is not to maximise opens but to improve outcomes the user cares about. Our article on mobile app analytics explains how to organise those events.

Give users control inside the app

A notification settings screen is not optional polish; it is what keeps people from turning notifications off entirely. Offer a switch per category, a way to choose how often to hear from you and, where relevant, quiet hours. Explain each category in a few words, such as "Order updates: when your order is confirmed, shipped or delivered." Make the settings easy to find from the profile or settings area, and reflect the system-level permission state honestly, so the screen does not claim notifications are on when the device blocks them.

Also think about account changes. When a user logs out, the device should stop receiving that user's notifications. When two people share a device, notifications for one account should not appear for the other. These details are easy to miss and embarrassing to ship.

Common mistakes

• Asking for permission at install. The user has no reason to say yes yet.
• Sending the same message to everyone. Generic broadcasts feel like spam.
• Linking to the home screen. Every notification should land on the relevant content.
• Offering no controls. Without category settings, the only option left to users is to switch everything off.
• Ignoring token hygiene. Stale tokens waste sends and distort delivery data.
• Using notifications to fix a retention problem. If the app lacks value, messages only delay the uninstall.
• Forgetting privacy rules. Marketing messages and personal data are subject to EU consent and data protection requirements. Seek proper advice; this is general information, not legal advice.

Plan notifications as part of the product

Treat notifications as a feature with its own design, content, engineering and measurement, not as a switch to flip before launch. If you are planning an app and want help designing and building a notification system that respects users, see our mobile app development service and get in touch.