How to use push notifications properly (2026 guide)

Used well, a push notification tells a specific person something they already wanted to know, at a moment when they can act on it. That is the whole discipline. Everything else is plumbing and judgement: asking for permission at the right time, segmenting on behaviour rather than sending to everyone, deep linking into the screen the message refers to, and measuring uninstalls alongside opens. If you cannot say who a message is for and what they will do next, do not send it.

We build mobile and web applications for UK businesses, and notifications are one of the few features where a poor implementation actively loses you users. A bad email gets deleted. A bad push wakes someone up.

How push notifications actually work

A push notification is not sent by your app. Your server sends a payload to a platform push service, and that service delivers it to the device. On iOS that is the Apple Push Notification service (APNs). On Android it is Firebase Cloud Messaging (FCM). In a browser it is the Web Push protocol, using the push service belonging to whichever browser the user has, authenticated with VAPID keys.

Each device registers with the relevant service and receives a token. Your backend stores that token against the user account, and messages are addressed to tokens rather than to people. Tokens rotate and become invalid when somebody reinstalls, so you need a job that prunes dead ones, otherwise your delivery figures quietly drift away from reality.

Two consequences follow:

• Delivery is best effort, not guaranteed. Devices that are offline, in battery-saver mode or heavily throttled may receive a message late or not at all, so never make a push the only route to something important.
• The payload is small and passes through a third party. Send identifiers and a short message, then let the app fetch the detail over your own API. Nothing confidential belongs in the body, because it displays on a locked screen.

Push, in-app messages and local notifications are different things

A local notification is scheduled on the device itself and needs no server, which makes it ideal for reminders and timers. An in-app message only appears when someone already has your app open, so it costs no permission and no goodwill. Push is the only one that reaches somebody who is not thinking about you, which is why it should be rationed.

Getting permission without burning it

On both iOS and Android, you get roughly one chance. If someone declines, re-prompting is either blocked or requires sending them into system settings, and almost nobody goes.

The mistake we see most often is asking on first launch, before the person knows what your app does. A better sequence is a soft ask: explain in your own interface what you would send and why, and only trigger the system dialogue once they have said yes to that. If they decline your own screen, you have lost nothing and can ask again later.

Better still, tie the ask to a moment where the value is obvious: after somebody places an order, saves a search or joins a conversation. This is a UI and UX design decision as much as a technical one, and it deserves designing properly rather than accepting your framework’s default.

A few platform details worth knowing:

Platform	What you need to know
iOS	Permission is explicit and effectively one-shot. Provisional authorisation lets you deliver quietly to the Notification Centre without a prompt, which is a reasonable way to earn the full permission later.
Android	Notification permission is requested at runtime on Android 13 and above. Notification channels are mandatory, and users can mute one channel without muting the rest.
Web	Requires HTTPS, a service worker and a user gesture. Browsers penalise sites that prompt immediately, so a soft ask matters even more here.

Android’s channels are underused. Splitting messages into channels (order updates, account security, offers, product news) lets people keep the useful ones and mute the marketing, which is far better for you than a blanket opt-out.

UK consent rules in plain terms

If you are sending anything promotional to people in the UK, push notifications sit in the same territory as email marketing. UK GDPR governs the personal data used to target the message and PECR governs direct marketing sent electronically, so consent must be freely given, specific and as easy to withdraw as it was to give.

Service messages are different. Telling someone their order has shipped, their password has changed or their appointment is tomorrow is not marketing. Bundling an offer into that message is, and mixing the two is where organisations get into trouble.

Two things we would insist on in any build: keep marketing consent separate from the notification permission, and log what somebody consented to and when. The ICO publishes guidance on direct marketing that is worth reading before you design the flow, and our consulting team can review your approach if you want a second opinion.

Making individual notifications worth receiving

Segment on behaviour, not on everyone

Sending to your whole user base is the reason most notification programmes decay. Start from a question: what has this person done, or not done, that makes this message relevant now? Abandoned a basket, followed a topic, not opened the app in a fortnight, hit a usage limit. Each of those is a segment, and each deserves different copy.

You will need event data to do this, which means instrumenting the app properly during the mobile app development lifecycle rather than afterwards. Retrofitting analytics onto a live product always costs more.

Say one thing, and deep link to it

Keep the body short enough to survive truncation on a lock screen, lead with the specific detail rather than your brand name, and make the tap land on the exact screen the message refers to. Dropping somebody on your home screen and expecting them to find the thing you just told them about is the most common way to waste a notification.

Use rich notifications where they add information

Images, action buttons and expandable content help when the media is the message: a delivery photo, a chart, a preview of the item on sale. They do not help when they are decoration. Action buttons that let someone confirm, snooze or dismiss without opening the app respect their time, and people notice.

Timing and frequency depend on the app

There is no universal correct frequency, and any number quoted as one should be treated with suspicion. A messaging app can send dozens of pushes a day because each is prompted by another human. A retail app sending the same volume would be uninstalled within a week. Send in the recipient’s local time zone rather than yours, cap promotional messages per user per week, and enforce that cap centrally rather than per campaign.

Measuring the right things

Open rate flatters push: a notification on a lock screen has already delivered its message whether or not anyone taps. Judge notifications on the behaviour that follows.

• Delivery rate against tokens sent, to catch token rot and platform throttling.
• Direct and assisted conversions, meaning the action you actually wanted, counted within an attribution window rather than only on immediate taps.
• Opt-out and channel-mute rate per campaign type, which shows which messages cost you permission.
• Uninstalls in the days after a send, compared against a holdout group that received nothing.

Keep a genuine holdout, even a small one. Without it you cannot tell whether your notifications caused activity or merely took credit for activity that would have happened anyway.

Frequently asked questions

How do push notifications work?

Your server sends a message to a platform push service rather than to the device directly. Apple’s APNs handles iOS, Firebase Cloud Messaging handles Android, and the Web Push protocol handles browsers. Each installation registers and receives a unique token, which your backend stores against the user. Messages are addressed to those tokens. Delivery is best effort, so a device that is offline or in battery-saver mode may receive a message late or not at all.

When should an app ask for notification permission?

Not on first launch. Ask at a moment where the benefit is obvious, such as immediately after someone places an order, saves a search or joins a conversation. Use a soft ask first: explain in your own interface what you would send and why, and only trigger the system dialogue if they agree. If they decline your screen you have lost nothing, whereas declining the system prompt is close to permanent on iOS.

How many push notifications should you send?

It depends entirely on what the app does. A messaging app can send many a day because each message is initiated by another person and is expected. A retail or content app sending the same volume will be uninstalled. Set a central cap on promotional messages per user per week, enforce it across all campaigns rather than per campaign, and judge the level by watching opt-outs and uninstalls rather than opens.

Do push notifications need consent under UK law?

Marketing notifications do. UK GDPR governs the personal data used to target the message and PECR governs direct marketing sent electronically, so consent must be freely given, specific and easy to withdraw. Service messages such as delivery updates, security alerts and appointment reminders are not marketing and sit outside that requirement. Keep the two separate, and never attach a promotional offer to a transactional message.

What is the difference between push notifications and in-app messages?

A push notification reaches someone whose app is closed, delivered through a platform push service and requiring the user’s permission. An in-app message appears only while somebody is already using your app, so it needs no permission and interrupts nobody. A local notification is scheduled on the device itself and needs no server at all. Choose the least intrusive of the three that will do the job.

Why do users turn push notifications off?

Usually because the messages are irrelevant, too frequent, badly timed for their time zone, or land them on a home screen instead of the thing being described. On Android, people often mute a single notification channel rather than all of them, which is why splitting order updates, security alerts and marketing into separate channels protects the messages that matter most.

Where to go next

Notifications are worth designing before you build rather than bolting on afterwards, because the event data and the permission moments both need to exist in the product from the start. If you are planning a new app, our mobile application development team can help you work through what to send and when, and the cost estimator will give you a realistic budget range for the wider build. If you would rather talk it through, please get in touch.