In-app messaging,
without the guesswork.
In-app messaging shows up in nearly every product roadmap discussion, usually right after someone says “let’s just send a push notification” and someone else says that’s not the same thing. They’re both onto something — in-app messaging, push notifications, and in-app chat are three different tools that get lumped together constantly, and building the wrong one wastes a sprint. This guide defines in-app messaging precisely, shows exactly where it stops and push or chat begin, and covers the tools people send it with and the practices that keep it from feeling like spam. It’s also one of the more effective levers in most app monetization strategies, since a well-timed upgrade prompt reaches someone already inside your product rather than someone you’re trying to pull back in.
In the app
In-app messages only appear during an active session — never on a lock screen
0 opt-in
In-app messages don’t need OS notification permission, unlike push
+224%
Higher engagement when push and in-app messaging are paired, per Braze
$19/mo
Starting price for OneSignal’s paid tier, after its free plan
The short version
A message the app shows itself, while it’s open.
In-app messaging is a banner, modal, tooltip, or full-screen card that your app renders on its own, to a user who already has it open, based on something they did or a group they belong to. It doesn’t touch the device’s notification system — it’s just UI the app decides to show, the same way it decides to show any other screen. That’s what separates it from a push notification, which travels through the operating system and can reach someone whether or not the app is even running.
Scope check
What counts as in-app messaging (and what doesn’t).
Before the deeper comparison below, the short version. If a message fails any line on the left, it isn’t in-app messaging — it’s one of its two neighbors instead.
Not in-app messaging
- A notification that can reach a closed app — that’s push
- A two-way conversation with a reply box — that’s chat
- A blanket announcement blasted to every single user
- A replacement for onboarding your product actually needs
Is in-app messaging
- A message the app renders itself, only during an active session
- Triggered by something the user did, or the segment they belong to
- Free to show — no OS notification permission required
- Fully within your control: timing, design, and who sees it
The three that get conflated
How it differs from push notifications and in-app chat.
These three names get used interchangeably in planning meetings, and they shouldn’t be. OneSignal’s own documentation draws the first line clearly: “in-app messages display inside your app while the User is actively using it. Push notifications appear on the device’s notification tray and can reach Users even when the app is closed.” That’s the whole difference between the first two — location and reachability, not importance.
In-app chat is a separate thing again. Where in-app messaging is one-way — the app decides to show something — chat is a two-way, usually user-initiated conversation with a person on the other end, whether that’s support or another user. Sendbird frames the split as chat being “a two-way street, facilitating a dialogue between user and provider,” against messaging that exists “to enhance engagement, educate, or promote content.” If what you actually need is real back-and-forth conversation rather than a one-way nudge, that’s a different build than anything on this page — we cover it separately in adding chat to your app.
| Channel | Where it appears | Who starts it | Permission | Best for |
|---|---|---|---|---|
| In-app messaging | Inside the app, only while it’s already open | The app, based on a trigger or segment | Not required | Feature nudges, onboarding, upsells, announcements |
| Push notification | Lock screen or notification tray, even when the app is closed | The app, but reaches users outside it | Required — OS-level opt-in | Re-engagement, time-sensitive alerts |
| In-app chat | A dedicated conversation view inside the app | The user, expecting a reply | Not required (but the feature itself has to be built) | Support, or real conversation between users |
Pick a channel
Which channel actually fits your message?
The table above is the theory. In practice, the fastest way to tell in-app messaging, push, and chat apart is to look at the specific message you’re trying to send.
Try it
Which channel actually fits what you’re sending?
Pick the closest match to the message you’re trying to send.
What it looks like
In-app messaging comes in four shapes.
Once you know it’s an in-app message and not a push or a chat, the next choice is what it looks like. Firebase’s campaign builder names four layouts, and every other in-app messaging tool ships some variation of the same set.
Try it
The four formats Firebase ships with
Every in-app messaging tool offers some version of these four. Tap one to see how it sits on screen.
Best for
A feature announcement with enough detail to explain itself
Firebase’s richest layout: a title, body copy, an image, and both a primary and a secondary action button. Built for messages that need real explanation, not just a nudge.
| Format | Action buttons | Best for |
|---|---|---|
| Card | Primary and secondary | A feature announcement with enough detail to explain itself |
| Modal | Primary and secondary | A decision point — confirm, upgrade, or dismiss |
| Banner | Single tap action | A low-priority nudge that shouldn’t interrupt anything |
| Image only | None | A visual promo or seasonal graphic that speaks for itself |
Doing it well
In-app messaging best practices that keep it from feeling like spam.
In-app messaging works because it reaches people already engaged with your product — Braze puts a number on that advantage, finding that when push is paired with in-app messaging, users engaged at a rate 224% higher than users targeted with push alone. That advantage disappears fast if every message feels like an ad. The pattern that causes the most damage is showing something the instant the app opens, before the user has done anything — it reads as an interruption rather than something earned by context.
The fix is mostly discipline, not tooling: trigger off behavior, limit frequency, give one clear action, and target a segment instead of everyone who opens the app. Use the checklist below against the next message you’re planning.
Try it
Does your in-app message check these boxes?
Check off what the message you’re planning already does.
0 of 8 · Start here — most in-app messages skip most of these.
Tools and platforms
The in-app messaging tools people actually use.
Most teams don’t build in-app messaging from scratch — they add an in-app messaging platform that already handles targeting, scheduling, and rendering. Firebase In-App Messaging is a free product on every Firebase plan and ties directly into Firebase Analytics for targeting. OneSignal offers unlimited mobile push on its free plan plus a base allotment of in-app messages, then moves to paid tiers starting around $19 a month as usage grows. Braze serves larger, cross-channel programs and publishes no self-serve pricing — you get a quote across its Go, Select, Pro, and Enterprise editions instead. All three expose an in-app messaging API for triggering or personalizing messages from your own backend, not just through a dashboard.
| Tool | Free tier | API access | Notes |
|---|---|---|---|
| Firebase In-App Messaging | Free — listed as a no-cost Firebase product on every plan | Console-based targeting, tied to Firebase Analytics | Simplest default if your app already uses Firebase Analytics |
| OneSignal | Free tier includes unlimited mobile push and a base in-app allotment | REST API, plus a dashboard message editor | Paid tier starts around $19/month, then usage-based |
| Braze | No public self-serve pricing — sales-only quote | REST API, built for large cross-channel programs | Editions named Go, Select, Pro, and Enterprise |
Which messages are worth building depends heavily on how your app makes money. If part of the plan is prompting people toward a paid tier at the right moment, that’s really a question of revenuecat pricing and paywall timing as much as it is about messaging tools. And if the goal is growth rather than revenue, a well-placed in-app message pointing people at an app referral program tends to convert better than the same offer sent as a push, because the person reading it is already inside the product.
In the wild
What this looks like in apps you already use.
Sendbird’s own breakdown of messaging versus chat across popular apps makes the line concrete — some of these could be push just as easily as in-app messaging, but none of them are chat, and none of the chat examples could be swapped for a one-way message.
| App | What they send | Channel |
|---|---|---|
| Uber Eats | Notifies customers when their order is en route | In-app messaging / push |
| PicPay & PayPay | Alerts users about account transactions | In-app messaging / push |
| Poshmark | Sends sale coupons to shoppers | In-app messaging |
| DoorDash | Connects drivers and customers, or links users to support | In-app chat |
| Hinge | Real-time or asynchronous conversation between users | In-app chat |
Building your own
When the off-the-shelf tools don’t quite fit.
Firebase, OneSignal, and Braze cover the common cases well, but plenty of apps have messaging logic that doesn’t map cleanly onto a generic dashboard — triggers based on a proprietary scoring model, messages that pull live data from your own backend, or targeting rules specific to how your app segments users. Teams in that position usually end up building the trigger and targeting logic themselves, on top of their own database, and rendering it with a simple in-app component rather than adopting a full third-party SDK for a handful of message types.
That’s the kind of custom logic Newly is built for — describe the trigger and the message you want, and it gets wired into the app you’re already building, backed by its own database, without adding a separate vendor for something that’s really just a few conditional screens.
FAQ
In-app messaging, answered.
In-app messaging is a message the app itself displays to a user while they have the app open, such as a banner, modal, or tooltip triggered by something they did or a segment they belong to. Firebase describes its version as sending messages “while users are actually in your app,” which is the core idea across every platform that offers it: the message is contextual to an active session, not something that arrives on a lock screen or notification tray.
Sources
Where these facts come from.
“Firebase In-App Messaging sends messages when they’re most needed: while users are actually in your app.”
“In-app messages display inside your app while the User is actively using it. Push notifications appear on the device’s notification tray and can reach Users even when the app is closed.”
Know what to send. Now build it.
Newly turns a description of a trigger and a message into a real native app feature — no separate messaging vendor to configure, starting at $25 a month.