Send Mobile Push Notifications People Open Instead of Mute

On iOS, you get exactly one shot at asking a user for permission to send push notifications. One. If you fire the system prompt the moment the app launches, before the user has any idea what your app does or why notifications from it would be worth getting, most of them tap "Don't Allow," and that no is permanent. You do not get to ask again. You have spent your one chance and lost the channel forever, on a user who had not even seen the product yet.

That single constraint reshapes everything about push notifications. The difference between an app that reaches its users and one that talks to nobody comes down to when you ask, what you ask for, and whether what you send afterward respects the person on the other end. Get the timing right and your opt-in rate roughly doubles. Get it wrong and you are sending notifications to a fraction of your users, while the rest have a channel they can never reopen.

The numbers that explain the stakes

Push opt-in rates split sharply by platform, and the split is the whole reason iOS timing matters so much. On Android, the average opt-in rate is around 91 percent, because Android historically granted notification permission by default or with low friction. On iOS, the average is just under 44 percent, because iOS requires explicit permission and gives you only that one prompt.

But the iOS average hides a huge spread, and the spread is entirely about timing. Apps that fire the system prompt immediately on first launch see opt-in rates of 30 to 40 percent. Apps that wait and ask at the moment of first value see 55 to 70 percent. Same prompt, same operating system, but nearly double the opt-in rate, purely from asking at the right moment. That gap is the single highest-leverage decision in your entire push strategy.

The soft ask: earn the prompt before you spend it

The technique that produces the higher numbers is the soft ask, also called the pre-permission prompt, and it works because it lets you ask twice without spending your one system prompt.

Here is the pattern. Before you ever trigger the iOS system permission dialog, you show your own in-app modal, fully under your control, that explains the specific value the user will get. Not "Allow notifications," but "Get notified when your order ships," or "See when friends reply to your posts," or "Never miss a price drop on items you saved." Concrete, specific, framed entirely around what the user receives.

If the user taps yes on your soft ask, you then trigger the real iOS system prompt, and because they have already said they want this, they almost always allow it. If the user taps no on your soft ask, you have lost nothing, because you never triggered the system prompt. You can ask again later, at a better moment, since your own modal is not subject to the one-shot rule. The system prompt, your single irreplaceable asset, is only spent on users who have already told you they want notifications.

The reason this matters psychologically: most users deny push permission because they fear it means spam. The soft ask is your chance to reduce that perceived risk and highlight the specific reward, in your own words, before the blunt system dialog forces a permanent decision. You are converting "this app wants to bother me" into "this app will tell me when my order ships," and those produce very different answers.

Time the ask to the first meaningful action

The optimal moment to show the soft ask is not first launch and not a random later session. It is immediately after the user completes their first meaningful action in the app: they place their first order, finish their first workout, send their first message, save their first item. That first meaningful action is exactly the first win onboarding flows are built to reach, and the same moment an empty state is designed to drive the user toward. At that moment the user has just experienced the app's value, and the notification you are offering is an obvious extension of something they just did and clearly care about.

Asking at first launch fails because the user has no context. Asking right after the first valuable action succeeds because the notification now has an obvious purpose tied to something the user just chose to do. The request stops being an interruption and becomes a helpful offer. This single change, moving the ask from launch to first-value, is what drives the opt-in rate from the 30s into the 60s.

Segment what you send, or the opt-in was wasted

Winning the opt-in is only half the job. If you then bombard the user with promotional blasts, they will mute you or uninstall, and a muted user is barely better than one who never opted in. The structural fix for notification fatigue is to segment everything you send into three tiers and treat each differently:

• Transactional notifications: always send. Order shipped, payment received, fraud alert, password changed, the ride is here. These are the notifications the user actually wants and the reason they opted in. They are time-sensitive and individually relevant, and they are never the problem. They are the push equivalent of the transactional email that should send in the background so it never blocks the request that triggered it.
• Behavioral triggers: send based on what the user does or does not do. A reminder that an item is still in their cart, a nudge that they have not finished setup, an alert that something they follow changed. When the user taps one, it has to land them on the exact screen it referenced, which is why deep links and attribution have to survive the app store round trip. These are valuable when they are timely and relevant, and annoying when they are generic. Tie them to actual user behavior, not to a broadcast schedule.
• Promotional notifications: explicit opt-in only. Sales, announcements, "we miss you" campaigns. These are the notifications users hate most, so they should require a separate, explicit opt-in, and they should be rare. A user who allowed notifications to track their order did not necessarily sign up for your marketing blasts.

Sorting your notifications into these tiers is the fastest way to cut the fatigue and the uninstalls that come from treating every notification as equally fair to send.

Respect quiet hours, always

One rule overrides volume and segmentation both: do not wake people up. Never send promotional or behavioral notifications between roughly 10pm and 8am in the user's local time. A buzz at 2am is how you turn an opted-in user into someone who mutes you in the dark and never turns it back on.

The exception is genuine transactional urgency, a fraud alert, a time-critical order update, the things a user would actually want to know at 2am. But everything discretionary waits for waking hours. And local time is the operative phrase. Sending on your timezone instead of the user's is how a "good morning" notification lands at 3am for half your audience. Respecting quiet hours is not a nicety; it is the difference between a channel users tolerate and one they kill.

The whole strategy, in order

Put together, a push approach that people open instead of mute looks like this:

1. Never fire the system prompt on first launch. Protect your one iOS shot.
2. Show a soft ask first, framed around specific value, after the user's first meaningful action.
3. Only spend the system prompt on users who said yes to the soft ask.
4. Segment everything you send into transactional, behavioral, and promotional, and treat each tier by its rules.
5. Respect quiet hours in the user's local time, with only genuine urgency as the exception.

This is the discipline we build into the mobile apps we ship, because a push channel is an asset that is trivial to squander and hard to rebuild, especially on iOS where the permission is one-and-done. The soft-ask modal itself deserves the micro-interactions that make a product feel alive, not a flat dialog, and on the web the same outcome comes from a PWA that feels native on iOS. The apps that earn the opt-in and then send notifications worth getting keep a live line to their users for years. The apps that ask too early and send too much spend their one prompt badly and then talk to a muted room.

The mechanics are not complicated. Ask at the right moment, in the user's interest, then send only what they actually want. Do that and push becomes a channel people open. Skip it and push becomes the feature they turn off and forget you have.