Push Notifications for Apps: Opt-in, Copy and Timing That Work

Push notification best practices come down to three things: ask for permission at a moment when the value is obvious, send fewer and more useful messages, and use in-app messages for anything the user should see while they're already in the app.

Most apps lose opt-ins by asking on first launch and lose users by sending too much.

The tests below show that timing and context matter more than wording.

A quick caveat before the details. Our database has few clean A/B tests of push copy itself.

What it does have is a set of app tests on timing, offers and in-app messages, and those point the same way.

We link them throughout, and you can browse every related result on the push notifications element page.

Opt-in: when and how to ask for push permission

On both platforms, push is opt-in. On iOS, the system prompt shows up the first time your app requests authorization.

According to Apple's documentation, later requests won't prompt the user again.

If someone taps "Don't Allow," they'd have to dig into Settings to change it.

Android moved to the same model in Android 13 (API level 33), which added the POST_NOTIFICATIONS runtime permission.

Google's guidance says apps targeting Android 13 or higher decide when the dialog appears.

Apps targeting 12L or lower get the prompt automatically, usually at startup, and after one denial the user isn't asked again unless they reinstall or the app updates its target.

Both vendors give the same advice: ask in context.

Apple's example is a task app that asks after the person schedules their first task, because "people can see the purpose your app's notifications serve."

Google suggests asking when the user taps a bell icon, follows an account or places an order, or after a few app launches.

What this means in practice:

  • Don't ask on first launch. The user hasn't seen any value yet, so you're burning a prompt you can only show once.
  • Tie the ask to an action. Ask after the user sets a goal, saves an item, books something or starts a trial.
  • Say what they'll get. "Get a reminder before your lesson streak breaks" works better than "Turn on notifications."
  • Consider provisional authorization on iOS. With the provisional option, Apple lets you send quiet notifications that show up only in Notification Center history, with no sound, banner or lock-screen alert. Each one has Keep and Turn Off buttons, so people can judge your notifications before they commit.

For context on what "good" looks like, Airship's 2026 benchmark report (2025 data from thousands of apps) puts the median opt-in rate at 53.3% on Android and 48.85% on iOS.

That's a gap of under five points, now that Android also requires explicit permission.

We track more figures by vertical on our push opt-in rate benchmarks page.

Pre-permission screens (soft asks)

A pre-permission screen, also called a primer or soft ask, is your own screen shown before the system dialog.

It explains what notifications you'll send and offers two buttons, such as "Turn on reminders" and "Not now."

Only a yes triggers the real system prompt.

The logic is simple. A "Not now" on your screen costs nothing, and you can show it again later at a better moment.

A "Don't Allow" on the iOS system dialog is close to permanent. The primer protects your one real chance.

A good primer has:

  • One concrete benefit tied to what the user just did ("We'll tell you when your scan is ready")
  • An honest picture of how often you'll send ("About two reminders a week")
  • A visible "Not now" that doesn't punish the user
  • A screenshot or mockup of a real notification, so the user knows what they're agreeing to

Don't stack the primer with other asks. One RevenueCat article on trial conversion warns that onboarding flows pile on permission requests, which drains the user's patience.

If your onboarding already asks for tracking, location and a paywall decision, move the push ask later.

See our permission primer tests and the onboarding guide for how the order of asks plays out.

Copy and timing

Once you have permission, each push has to earn its interruption.

The copy rules are the same as for any short message: lead with the specific thing that happened, keep it personal, and make the tap worth it.

  • Be specific. "Your 7-day streak ends tonight" beats "Come back and practice!"
  • Deep link to the right screen. A push about a saved workout should open that workout, not the home screen.
  • Trigger on behavior, not the calendar. Messages sent because of something the user did (or stopped doing) are more relevant than a batch blast at 10 a.m.
  • Respect local time. Schedule by the user's time zone, and keep quiet hours.

Timing matters as much as copy, and our paywall tests show it clearly.

Wizz showed fewer offers, but at better moments, and saw +81% on the primary offer flow and LTV up about 20%, as reported on RevenueCat's blog.

That was a paywall test, not a push test, but the lesson carries over: one well-timed message beats several random ones.

Subscription apps have a high-stakes moment for messages: the end of a free trial.

Blinkist's trial timeline paywall, which told users up front what would happen and when, brought a significant rise in trial opt-in and 4% fewer trial cancellations (test credited to Marcus Burke).

Stardust's trial timeline design lifted conversion 13.6%, with trial-to-paid unchanged.

If your paywall promises a reminder before the trial ends, send it on time.

It's one of the few pushes users actually expect.

Frequency and fatigue

Every push draws on a limited stock of goodwill.

Too many and users mute the channel, turn notifications off in Settings, or uninstall.

Android also shows users how many notifications each app sends per day, and they can revoke permission at any time, according to Android's developer docs.

Engagement is also slipping. Airship's report found the median iOS direct open rate fell 13.71% year over year, and Android saw single-digit declines.

A crowded lock screen is a reason to send less, not more.

Ways to keep frequency in check:

  • Set a cap. Pick a maximum number of marketing pushes per user per week, and enforce it across every team that sends.
  • Let users choose. Offer categories (reminders, offers, updates) in settings, so people can turn off one type without losing all of them.
  • Watch opt-out and uninstall rates as the guardrail metrics in every push test, not just opens.
  • Follow Apple's rules on marketing. App Review Guideline 4.5.4 says push must not be required for the app to work, and that promotions or direct marketing need explicit opt-in through consent language in your app's UI, plus a way to opt out.

Push vs in-app messages

The push notification vs in-app notification question has a clear answer: they do different jobs.

Push reaches people who aren't in your app.

In-app messages reach people who are, and who are already in the right frame of mind to act.

Push notificationIn-app message
Where it showsLock screen, banner, Notification CenterInside the app (modal, banner, card)
Needs OS permissionYes, on iOS and Android 13+No
Best forBringing lapsed users back, time-sensitive reminders, trial-end noticesOffers, feature tips, upgrade prompts, surveys
Main riskOpt-outs and uninstalls if overusedInterrupting a task the user came to do
ReachOnly users who opted inEvery active user

Lose It! has the strongest data point on this.

When they kept an offer's content the same but changed its format to an in-app message, they made about 10x more money.

The team told RevenueCat that in-app messaging was more powerful and cheaper than push or email, because users saw the offer while they were already in the app and open to upgrading.

The practical split: use push to bring people back into the app, then use in-app messages and paywalls to make the offer.

If you send an offer by push, have it open straight to a matching paywall, not to the home screen.

What the tests show

Here's what the app tests in our database suggest for a push strategy:

  1. Context beats channel. Lose It!'s 10x result came from showing the same offer in a better place. The Wizz test reached the same conclusion with fewer, better-timed offers.
  2. Win-back offers work when they're targeted. Unscripted aimed a personal reactivation trial offer at a lapsed cohort and saw trial starts rise by over 240%, according to a Superwall case study (vendor-reported). The case study doesn't say which channel brought users back to the offer. Push is the usual way to reach lapsed users, so that's a good test to run yourself.
  3. Trial reminders build trust. Timeline paywalls that spell out what happens and when lifted conversion at Stardust and cut cancellations at Blinkist.
  4. Trial-stage offers can pay. Across tests posted by Vahe Baghdasaryan, an "end your trial now" discount offer averaged +15–17% ARPU. A push during the trial is a natural way to deliver an offer like this to users who have gone quiet.

When you test push yourself, measure what happens downstream: return sessions, trial conversion, retention and opt-outs, not just open rate.

Our retention guide and win-back tests cover the metrics, and app A/B testing explains how to split users fairly.

Push notification tools

Most teams start with a free sender and move to a full engagement platform once they need segmentation, journeys and testing.

A few common options, with prices as of November 2026:

ToolPricingGood forNot for
Firebase Cloud MessagingNo cost on both Firebase plans, as is Firebase In-App MessagingTeams with developers who want a free, reliable delivery layerMarketers who want a visual journey builder and built-in A/B testing without engineering help
OneSignalFree plan with unlimited mobile push up to 1,000 MAU; Growth from $19/month plus $0.012 per mobile push MAU; Professional and Enterprise custom, on annual contractsSmall and mid-size apps that want push, in-app and email in one placeLarge apps that need deep data warehousing; the free plan limits journeys and segments
BrazeNo public prices; based on MAUs, user profiles and message credits, across four editionsLarger teams running cross-channel lifecycle programsIndie and early-stage apps that need clear, predictable costs

We haven't used these tools ourselves. This summary comes from each vendor's public pricing pages.

For a wider comparison, see our push notification tools roundup.

If your offers live on paywalls, our paywall tools guide covers the other half of the push-to-paywall flow.

Questions

What are push notification best practices for apps?

Ask for permission in context instead of on first launch, show a pre-permission screen first, send specific, behavior-triggered messages that deep link to the right screen, cap how often you send, and use in-app messages for offers shown to active users.

What is the difference between a push notification and an in-app notification?

A push notification shows outside the app, on the lock screen or as a banner, and needs OS permission.

An in-app message shows only while the user is in the app and needs no permission.

Push brings users back; in-app messages work best for offers and tips.

How do I increase push notification opt-in?

Wait until the user has seen value, ask right after a related action, explain the specific benefit and how often you'll send, and use a soft-ask screen so a 'Not now' doesn't burn the one-time system prompt.

On iOS, provisional authorization lets users try quiet notifications first.

What is a good push notification opt-in rate?

Airship's 2026 benchmark report, based on 2025 data, puts the median at 53.3% on Android and 48.85% on iOS, with wide differences between app categories.

Does Android require permission for push notifications?

Yes. Since Android 13 (API level 33), apps need the POST_NOTIFICATIONS runtime permission to send most notifications, much like iOS.