Push Notifications That Users Keep Switched On: A Strategy Guide for App Owners

A push notification is the only way your app can speak to a customer who is not currently using it. That makes it valuable, and it also makes it easy to abuse. Every message that feels like noise gives the user a reason to open their phone settings and switch you off, and once that happens you rarely get a second chance.

If you are planning Android app development or an iPhone app, notification strategy deserves a decision of its own rather than a line in the feature list. This guide covers the business side: when to ask for permission, what to send, what the app stores say about promotional messages, and how to tell whether your approach is working. It does not explain how notifications are delivered technically.

Why permission is the scarce resource

On both major platforms, the user decides whether your app may notify them, and they can change that decision at any time without telling you. Sending a notification costs you almost nothing. The limited thing is the user's willingness to keep receiving them.

It helps to treat notification permission as a budget. Each irrelevant message spends some of it. A user who turns notifications off also stops receiving the messages they wanted, such as a delivery update or a security alert, so careless promotional pushes damage the parts of your app that work well.

How permission works on iOS and Android today

On iOS, an app must request authorization before it can show notifications. Apple's documentation states that the system prompts the person the first time the app makes the request and records the response, and that subsequent requests do not prompt again. In practice you get one system dialog. After a refusal, the only route back is for the user to change the setting themselves.

Android used to allow notifications by default. That changed with Android 13: according to the Android developer documentation, on a device running Android 13 or higher a newly installed app's notifications are off by default until the app requests permission and the user grants it. If the user taps "Don't allow", the app's notification channels are blocked, apart from a few exemptions such as media playback. If the user swipes the dialog away without choosing, the permission state does not change.

This behavior belongs to the operating system, so it is the same whether your app is native, Flutter or React Native.

When and how to ask

Do not ask on first launch. Apple recommends making the request in a context that helps people understand why the app needs it, such as a task app asking after the person schedules their first task. Android's guidance suggests triggering the prompt from a user action, such as tapping an alert bell or submitting a food delivery order.

A common technique is a short screen of your own before the system dialog, explaining what you will send and offering "Not now". If the user declines your screen, you have not used up the system prompt and can ask again at a better moment.

Provisional authorization on iOS

iOS also offers provisional authorization, which Apple describes as sending notifications on a trial basis. They are delivered quietly, without a sound or banner and not on the lock screen, and appear only in the notification center's history with buttons to keep them or turn them off. It suits apps whose value is easier to show than to explain.

The four kinds of notification and what the stores say

Most notifications fall into one of four groups, and users tolerate them very differently:

• Transactional: a direct result of something the user did, such as an order confirmation, payment receipt or delivery status.
• Reminders: something the user asked to be told about, such as an appointment or a saved search.
• Updates: new activity relevant to them, such as a reply or a price change on a watched item.
• Promotional: offers, sales and campaigns that the business wants to send.

The first two are the reason people accept notifications at all. Promotional messages are where permission is most easily lost, and where the platform rules are most explicit.

Apple's rule

Apple's App Store Review Guidelines, section 4.5.4, state that push notifications should not be used for promotions or direct marketing purposes unless customers have explicitly opted in via consent language displayed in the app's UI, and the app provides a method to opt out. The same section says notifications must not be required for the app to function and should not carry sensitive personal or confidential information. A separate guideline, 5.1.2(i), says an app may not require users to enable push notifications in order to access functionality or receive rewards.

Google Play's rules

In the Google Play policy pages we reviewed, we did not find a clause worded like Apple's opt-in rule for promotional pushes. What the Play Ads policy does say is that ads may only be displayed inside the app serving them, and it lists ads that mimic a system notification as a violation. Our recommendation is to apply Apple's standard on both platforms: separate consent for marketing, and an easy way out. Check the current policy wording before launch. Marketing messages can also fall under US and UK privacy and marketing law, which is outside this guide; nothing here is legal advice.

Preferences and frequency

A single on/off switch forces users to choose between everything and nothing. Offer a preferences screen inside the app, organized by the categories above, so that someone who is tired of offers can keep their order updates.

On Android this maps onto a platform feature. Since Android 8.0, every notification must be assigned to a notification channel, which the system settings show to users as a category they can silence individually. Once a channel is created, the app can no longer change its behavior; only the user can. Decide your categories before the first release.

For frequency, set a ceiling per user, not per campaign. Three teams each sending "only one message this week" still add up to three interruptions. Exempt transactional messages from the cap, but not promotional ones.

Timing, time zones and deep links

Schedule by the recipient's local time, not your office's. A push sent at 10 am in New York arrives at 3 pm in London and at 7 am in Los Angeles. If you serve both the US and UK, store each user's time zone and define quiet hours within it.

On iOS, users can also route notifications into a scheduled summary or filter them with a Focus. Apple's Human Interface Guidelines say to never use the Time Sensitive interruption level for a marketing notification. Reserve that level for things like security issues and deliveries.

Every notification should also open the exact screen it refers to, which is called a deep link. A message about a shipped order that opens the home screen makes the user hunt for the detail, and teaches them that tapping is not worth the effort.

Measuring opt-outs and opens

Track three things. First, the opt-in rate: of the people shown the permission prompt, how many accepted, per platform. Second, the open rate per notification type, so you can see which categories earn their place. Third, opt-outs over time. Apple notes that people can change authorization settings at any time, so the app should check its status regularly and record the change.

The most useful analysis links an opt-out or uninstall to the notifications that preceded it. If opt-outs rise in the days after a campaign, that campaign cost more than its click figures suggest.

Common mistakes

• Asking for permission on the first screen, before the user knows what the app does.
• Offering no in-app preferences, so the only option is to switch everything off.
• Scheduling by server time and waking people in other time zones.
• Making a feature or reward depend on notifications being enabled, which Apple's guidelines prohibit.
• Judging success by opens alone and never looking at opt-outs.

What to do next

List every notification your app sends or plans to send and assign each to one of the four categories. For each one, write down the user action that triggers it, the screen it opens and who in your business is allowed to send it. Anything you cannot justify from the user's point of view is a candidate for removal.

Then decide where in the user journey the permission request belongs, and brief your developers on the preferences screen, the frequency cap and the events you want measured. These are easier to build in from the start than to retrofit.

Conclusion

Users keep notifications switched on when the messages are expected, relevant and easy to control. Ask at a moment when the benefit is clear, keep transactional and promotional messages separate, respect local time, and watch opt-outs as closely as opens.

Entrant Technologies builds mobile apps and the software behind them. If you want notifications designed in from the beginning, you can request a quote and describe what your app needs to tell its users.