# In-app messaging vs push notifications: when to use which

Page: https://alidemirbas.com.tr/en/blog/in-app-messaging-vs-push-notifications

2026-11-02 · CRM & Lifecycle · Ali Demirbaş

In-app messaging vs push notifications: who each reaches, Android 13 and iOS permission rules, in-app message types, collision rules and a starting set.

In-app messaging means showing a message on the app's own screen while the user has the app open. A push notification lands on the lock screen and in the notification center even when the app is closed. That is the core of in-app messaging vs push notifications.

Push reaches people outside the app but needs the operating system's permission. An in-app message needs no permission but only reaches people who open the app.

This guide covers who each channel can and can't reach and the current notification permission rules on Android 13 and iOS. It also covers the types of in-app messages and how to decide which one to use. It is about the messages product and marketing teams send to users, not in-app chat between users.

## The difference that decides most cases: inside the app or outside it

What separates the two channels isn't content or design but where the user is at that moment. Android's [developer documentation](https://developer.android.com/develop/ui/compose/notifications) defines a notification as a message Android displays outside your app's UI. Apple describes notifications as getting a person's attention when the app isn't running or is in the background.

An in-app message works the other way around, while the user is inside the app. Google's [Firebase In-App Messaging](https://firebase.google.com/docs/in-app-messaging) docs describe it as sending messages while users are actually in your app.

### What push can do that in-app can't

Push is the only app channel that reaches someone who isn't using the app right now. A user can learn that an order shipped, an appointment is coming up or a payment failed without opening the app. It comes with two limits: the user has to grant permission, and they can turn it off in settings at any time. A notification that was sent waits in the notification center even if the user never opens the app.

### What in-app can do that push can't

An in-app message can speak to the screen the user is looking at. It can show how a feature works on that feature's screen. A user who is stuck at a checkout step can get help at that very step.

In-app messages don't depend on the operating system's notification permission. Braze writes that [in-app messages](https://www.braze.com/docs/user_guide/channels/in_app_messages/faq/) don't require push notifications to function and appear during an active app session. Airship and Klaviyo also note that these messages reach users who have turned push off.

How in-app messages are delivered matters too. Most tools download messages to the device when the app opens or a session starts, then show them when a trigger fires. Braze notes that users who become eligible during a session receive the message at their next session start. OneSignal adds that if segment criteria change mid-session, the user has to reopen the app to see the message.

*Based on Apple, Android and the platforms' own documentation.*

| Feature | Push notification | In-app message |
| --- | --- | --- |
| Where it appears | Lock screen, banner, notification center | On the app's own screen |
| OS permission | Required, and the user can revoke it any time | Not required |
| Who it reaches | Only users who granted permission | Only users who open the app |
| When it shows | When sent, even if the app is closed | While the app is open, when a trigger fires |
| How long it lasts | Waits in the notification center | Short-lived, with an in-app inbox for persistence |
| Typical job | Bringing the user back to the app | Getting a step inside the app done |

### Who each channel can't reach

Each channel has an audience it can't see, and it is worth knowing that before you build a customer relationship management (CRM) flow.

A user who doesn't open the app never sees an in-app message. According to Braze, if the user never restarts the app or never starts a session, the app can't find out whether the user is eligible. So the in-app message won't be sent.

Bringing back someone who hasn't opened the app in a long time is therefore not a job for in-app. That is when push comes in if the user granted permission, and channels outside the app such as email or SMS if not.

The [App channel recovery](https://alidemirbas.com.tr/en/lab/journeys/app-channel-recovery) journey shows how to reach a user who hasn't opened the app in 30 days through the first permitted, deliverable channel. [Usage habit recovery](https://alidemirbas.com.tr/en/lab/journeys/usage-habit-recovery) is an example for users whose usage has dropped.

A user who denied notification permission can't get push, but still sees in-app messages as long as they open the app. You can also give them a persistent surface. Airship's [Message Center](https://www.airship.com/docs/guides/features/messaging/message-center/) doesn't require push opt-in, and messages stay in the inbox until they expire or are deleted. Braze's Content Cards don't require permission either, and Braze describes them as the permanent counterpart to short-lived in-app messages.

A hypothetical example shows both gaps together. Picture a brand whose app is installed on 100,000 devices. Say 40,000 of those users opened the app in the last 30 days and 60,000 didn't. Of the active users, 22,000 granted notification permission, and so did 15,000 of the inactive users:

*Hypothetical example: which channel reaches which group.*

| Group | Users | In-app message | Push notification |
| --- | --- | --- | --- |
| Active, permission granted | 22,000 | Reaches | Reaches |
| Active, no permission | 18,000 | Reaches | Doesn't reach |
| Inactive, permission granted | 15,000 | Doesn't reach | Reaches |
| Inactive, no permission | 45,000 | Doesn't reach | Doesn't reach |

In this example in-app messages reach 40% of the audience and push reaches 37%. Together the two channels reach 55,000 people and miss 45,000, or 45% of the audience. Those users can only be reached through channels outside the app, such as email or SMS, and only if they have consented there.

## Notification permission: Android 13, iOS and asking at the right moment

Push permission now depends on the user's explicit consent on both platforms. That means your push audience is not your whole app audience.

### Android 13's runtime permission

According to Android's [notification permission documentation](https://developer.android.com/develop/ui/views/notifications/notification-permission), Android 13 (API level 33) and higher requires a runtime permission called POST_NOTIFICATIONS to send notifications. When a user installs your app on a device running Android 13 or higher, notifications are off by default. The app has to wait until it requests the permission and the user grants it.

Android's permissions documentation also covers repeated denials. If the user denies a permission more than once during the app's lifetime on a device, the system permission dialog no longer appears. Since Android 8.0, every notification has also belonged to a channel whose behavior the user controls separately.

### iOS: one prompt, and quiet provisional notifications

According to Apple's [documentation on asking permission](https://developer.apple.com/documentation/usernotifications/asking-permission-to-use-notifications), the first time an app requests authorization, the system prompts the person and records the response. Later requests don't prompt again. Apple also offers an alternative: provisional authorization.

Notifications sent this way arrive quietly, without a sound or banner and without appearing on the lock screen. They show up only in the notification center's history, and no permission prompt is shown. The person decides whether to keep or turn off these notifications when they actually receive one.

For marketing, Apple's rule is clear. Under guideline 4.5.4 of the [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/), push notifications should not be used for promotions or direct marketing. The exception is when customers have explicitly opted in through consent language shown in the app's UI.

The app must also provide a way to opt out. Apple's Human Interface Guidelines add that the Time Sensitive interruption level should never be used for a marketing notification.

### Explain in-app first, then ask

Because the system prompt doesn't come back once it's spent, timing matters. Apple says requesting authorization in context is a better experience than requesting it on first launch, because people can see the purpose your notifications serve. Android recommends letting users get familiar with the app before asking for any permission.

This is where an in-app message earns its place. When the user completes an action where notifications would help, explain what they'll get with an in-app message first. Open the system prompt only if they continue.

OneSignal notes that dismissing this kind of soft prompt doesn't use up a system prompt attempt. The [Notification permission education](https://alidemirbas.com.tr/en/lab/journeys/notification-permission-education) journey lays out the flow step by step.

## When should you use an in-app message instead of a push?

Start with one question: does the message need the user to be inside the app right now, or should it reach them wherever they are?

In-app messages fit jobs tied to what is on screen. Examples are the next onboarding step, a benefit the user owns but has never used, or an upgrade left half done. The [App install to first value](https://alidemirbas.com.tr/en/lab/journeys/app-install-to-first-value), [Benefit discovery](https://alidemirbas.com.tr/en/lab/journeys/unused-benefit-discovery) and [Upgrade completion reminder](https://alidemirbas.com.tr/en/lab/journeys/upgrade-blocker-prompt) journeys show where an in-app message fits in each of these.

Push is for time-bound moments that need to reach the user outside the app. Think of a delivery, a failed payment, or an action the user started and is waiting on.

Google's [notification design guide](https://developer.android.com/design/ui/mobile/guides/home-screen/notifications) also lists what notifications shouldn't be used for. The list covers messages to users who have never opened the app and encouraging users to return without providing direct value. It also covers requests to rate the app, holiday or birthday messages, and cross-promotion of another product.

The third question is about shelf life: will the message still be true the next time the user opens the app? An in-app message only appears when the user opens the app, so it is a poor fit for information that goes stale within hours. Braze also recommends avoiding in-app messages and similar channels for critical, time-sensitive updates. If you do send something in-app, setting an expiry keeps an outdated message from showing up at the wrong moment.

App review requests are a good example of the split. Apple requires its own system prompt for ratings and disallows custom review prompts. The system shows that prompt at most three times in a 365-day period.

Google Play applies a time-bound quota to its review dialog without publishing the value. So a rating request is neither a push job nor a free-form in-app message job.

## Types of in-app messages, by how much they interrupt

Tools give the same formats different names. Braze uses slide-up, modal and fullscreen, Firebase uses card, banner, modal and image only, and Airship uses banner, modal, fullscreen and custom HTML. Choosing by how much a format interrupts the user is more useful than going by the name:

- **Blocking (modal, fullscreen):** Covers the screen until the user acts or closes it. Fits decisions that really need to happen now, such as an account warning or a required update.
- **Passing (banner, slide-up):** Appears at the edge of the screen and goes away on its own. Airship says banner messages disappear automatically after 15 seconds. Fits information that shouldn't stop the user.
- **In place (tooltip, inline card):** Looks like part of the screen and doesn't break the user's flow. Braze's Banners, Airship's Embedded Content and CleverTap's Native Display work this way.
- **Persistent (in-app inbox):** Messages wait until the user opens them or they expire. In Airship's Message Center, messages expire after one year by default, and in Dengage's inbox after seven days at most.

### Rules that keep in-app messages from colliding

When several in-app campaigns run in one app, the most common problem is messages stacking up in the same session. The tools' defaults help.

In Braze, only one message can display per session for session-start triggers. Insider One also shows one in-app message per session except for event-triggered cases. Airship waits 30 seconds after one message closes before showing the next.

In Firebase, a campaign is not shown again by default once the user has seen it. CleverTap lets you give in-app campaigns a priority from 1 to 10.

Defaults don't replace a priority policy, though. Braze notes that in-app messages don't count toward the caps you set on campaigns, so a frequency rule built for push may not cover in-app.

Write your own rules. Allow at most one blocking message per session, and put transactional messages before lifecycle messages and lifecycle messages before campaigns. Show no messages on checkout or form screens, and stop the message once the action it was aiming for happens.

## Push and in-app messages in the same journey

The two channels aren't rivals but two steps in the same flow. Push brings the user back to the app, and the in-app message carries the conversation on the screen they land on. The key is that the in-app message shouldn't repeat the push.

Suppose the user tapped a push and arrived on the right screen through a deep link. In that case, show the next step on that screen instead of repeating the same sentence in a modal. Klaviyo sums up the relationship this way: push notifications drive app opens, while in-app forms provide visual content integrated into the app experience.

One detail is easy to miss. Dengage notes that if a push arrives and the user doesn't tap it and enter the app, no in-app message appears.

CleverTap notes that when push and an inbox message go out together, the push is delivered instantly. The inbox message only appears on the next app launch. Decide what a user who ignored the push should see the next time they open the app, and add it to the flow.

The triggers for these steps come from the app's event data. To see which flows your current events can support, the [Journey Builder](https://alidemirbas.com.tr/en/lab/claude-lifecycle) maps them. The [Onboarding help](https://alidemirbas.com.tr/en/lab/journeys/struggling-user-assistance) journey is an example of both channels working in one flow.

## Reading the impact of an in-app message

In-app click-through rates usually look high, because everyone who sees the message is already in the app. That rate doesn't tell you whether the message changed behavior.

Holding out a control group that doesn't see the message gives a truer answer. Compare how often the target action happens in each group (a feature's first use, a step completed). Alongside it, watch dismissals, push permission opt-outs and changes in session length to see whether the message is annoying users.

## A starting set for a mobile app

For a team starting from scratch, these are messages you can ship first, each with its channel and format:

1. **Before the notification prompt:** An in-app message, then the system permission dialog. Shown when the user completes an action where notifications would help.
2. **Reaching first value:** In-screen tips and cards for onboarding steps, plus a push reminder if a step is left half done and permission was granted.
3. **An unused benefit:** An in-app message on the relevant screen, then an email a few days later if it still isn't used.
4. **An unfinished upgrade:** A banner or inline card at the step where the user got stuck.
5. **Transactional updates:** Push for time-bound information such as orders, payments and account security.
6. **An inbox for users without push:** A persistent copy of campaigns and announcements in the in-app inbox.

In this set each message picks its channel from where the user is. It uses push or email when they are outside the app and in-app when they are inside it. It uses the inbox when the message needs to last. To see which CRM and marketing automation platforms support these channels, the [CRM and marketing automation tools](https://alidemirbas.com.tr/en/blog/crm-marketing-automation-tools) post compares them side by side.