Why notifications deserve care
A notification is an interruption. It reaches someone on their lock screen, possibly in a meeting, at dinner or in the middle of the night, and it asks for a moment of attention. When the message is genuinely useful, such as a delivery update or a reminder the person set up, that interruption is welcome. When it is not, people mute the app, turn notifications off or uninstall it.
For a builder, the useful test is simple: would the person be glad they received this? If the honest answer is “only if they were already thinking about the app,” the message is probably for your benefit rather than theirs.
How push notifications work, briefly
Push notifications are messages your server sends to a phone through the platform’s own delivery service, even when your app is not open. In general terms, the app registers with the platform, receives an identifier for that device, and passes it to your server. Your server then asks the platform to deliver a message to that identifier. The details differ between platforms and change over time, so check the current official documentation rather than relying on memory.
There are also local notifications, which the app schedules on the device itself without a server. Reminders, timers and alarms are good examples. Local notifications are simpler, need no account system, and reveal less about the user to anyone, which makes them a good starting point for a small first app.
Ask for permission at a sensible moment
Phones generally require the user to agree before an app can send alerts, and how that request appears varies by platform and version. Asking the instant the app opens, before the person knows what it does, is a common mistake. They have no reason to say yes, and a refusal can be awkward to undo because it moves into system settings.
A better pattern:
- Wait until the person has done something that makes alerts relevant, such as creating a reminder.
- Explain in a sentence what they will receive and why.
- Make it fine to say no, and keep the app working without alerts.
This follows the broader principle behind how app permissions work: ask for access when the reason is obvious, and ask for only what you need.
Decide what deserves a message
Before writing any code, list every notification you think the app might send and sort them into three groups.
Time-sensitive and expected. Things the person asked for or would clearly want, such as a reminder they scheduled or a confirmation of something they just did.
Helpful but optional. Summaries, tips, or updates about activity they follow. These should be opt-in and easy to switch off separately.
Promotional or re-engagement. Messages whose main purpose is to bring someone back. Treat these with the most caution. If you send them at all, keep them rare, honest and clearly separate from the first two groups.
If you are unsure about a message, leave it out. You can always add one later, but you cannot take back the annoyance of a bad one.
Avoid pressure tactics
Some notification patterns are designed to create anxiety or guilt: countdown warnings, messages implying the user is missing out, or alerts that exploit a streak so the person feels they must return. These are examples of manipulative design, and they can contribute to unhealthy habits such as the pull described in discussions of daily streaks. A responsible app does not need them. If your app is only useful when people feel pressured to open it, the underlying product may need rethinking.
Give people control
Good notification settings are part of the feature, not an afterthought. Consider including:
- Separate switches for each category of message, not one all-or-nothing toggle.
- A quiet period option, or respect for the phone’s own do-not-disturb modes.
- A clear way to reach those controls from inside the app.
- A frequency limit on your side, so that a bug or a busy day cannot send twenty messages in a row.
Users also manage alerts from the phone itself, using the notification settings built into the operating system. Your app should behave well when those are changed, including when the person turns everything off.
Write short, honest messages
A good notification is specific and calm. It says what happened and what, if anything, the person can do. Avoid vague teasers, all-capital words, and urgency that is not real. Do not put sensitive information in a message, since it may appear on a locked screen where others can see it. Details such as account balances, health information or private messages are usually better revealed only after the person opens the app.
Clear wording matters here as much as anywhere else in the interface, so the same habits behind good interface microcopy apply: short sentences, plain words, and no surprises.
Test and review what you send
Try your notifications on real devices, with the screen locked, with the app closed, and with settings changed. Check what happens when the person is offline or in another time zone. If you collect any information about whether messages are opened, keep it modest and explain it in your privacy policy; the thinking behind usage analytics without overreaching applies here too.
Finally, review your notification list now and then. If a message is rarely opened or often silenced, that is feedback. Removing it is usually better than tweaking it. An app that sends fewer, better-chosen messages tends to earn more trust, and trust is what keeps notifications turned on.