Use push notifications for short, time-sensitive messages that need to reach someone who is not in your app, in-app messages for anything tied to what the user is doing right now, and email for detail, records and people who have stopped opening the app. The three channels do not compete: push brings people back, in-app guides them once they are there, and email carries whatever needs to be kept or read properly.
Push vs email vs in-app: how do the three channels compare?
Each channel is defined by where the message appears and who is able to receive it. Everything else follows from those two facts.
| Push notification | In-app message | ||
|---|---|---|---|
| Where it appears | Lock screen, banner and notification centre, outside the app | Inside the app, during a session | The user's inbox, outside the app |
| Who can receive it | Users who have the app installed and have allowed notifications | Users who open the app | Anyone whose email address you hold and who has not unsubscribed |
| Does the app need to be open? | No | Yes | No |
| Needs the user to allow it first? | Yes, through a system prompt | No | They must give you an address, and can unsubscribe |
| How much it can say | A title and a line or two | A sentence to a full screen, with buttons and images | As much as you need |
| How long it lasts | Until dismissed or pushed down by newer notifications | Until the user closes it, unless you build an inbox | Until the user deletes or archives it |
| How interruptive it is | High | Medium, the user is already engaged | Low, read when the user chooses |
| Best job | Bring the user back for something happening now | Guide, announce or prompt in context | Explain, confirm, summarise, win back |
| Main risk | Users switch notifications off | Never seen by users who do not return | Goes unread or lands in the wrong folder |
What is the difference between push notifications and in-app notifications?
A push notification is delivered by the phone's operating system and shows up outside your app. An in-app notification is drawn by your own app and shows up only while someone is using it. That single difference decides who sees the message, when, and whether they needed to agree to it first.
Where each one appears
Push notifications are sent through Apple's and Google's delivery services to the device, where the system shows them on the lock screen, as a banner or in the notification centre. Your app does not need to be running.
In-app notifications are part of your interface. Firebase In-App Messaging, Google's tool for this, describes the job as sending targeted, contextual messages to your app's active users, and offers them as cards, banners, modals or images. Tooltips, full-screen takeovers and a notification inbox inside the app are common variations of the same idea.
Who can receive each one
Push only reaches people who have said yes. On iOS, Apple's developer documentation says you must obtain permission to use notifications, and that the system prompts the person the first time your app asks and does not prompt again on later requests. On Android, Google's documentation says that on Android 13 or higher an app's notifications are off by default until the user grants the permission.
In-app messages need no system permission, because they are simply part of the app. The limit is different: a user who never opens the app never sees them.
So the two audiences overlap but are not the same. Push reaches installed users who allowed notifications, whether or not they are active. In-app reaches active users, whether or not they allowed notifications.
What happens after the message is seen
A push notification is easy to lose. One swipe clears it, and a busy notification centre buries it. An in-app message can be just as brief (a banner that disappears) or it can be stored, if you build an inbox or notification feed where past messages stay available. If the user may need the information next week, neither a push nor a passing banner is enough on its own.
Push vs in-app notifications: when should you use each?
Use push when the user is away and the message cannot wait. Use in-app when the message only makes sense in the context of what the user is doing, or when it can wait until their next visit.
When push is the right choice
- Something is happening now or very soon: a live session starting, a delivery arriving, a bid being beaten.
- Another person did something the user cares about: a reply, a mention, a friend joining.
- A reminder the user asked for: a workout, a lesson, a medication time.
- A short account alert, such as a renewal failing, with the detail sent by email as well.
Push is the wrong choice for anything long, anything that is not timely, and general promotion. Apple's guidance on managing notifications says not to use notifications for marketing or promotional content unless people have explicitly agreed to receive it, and to keep its Time Sensitive level for events happening now or within the hour.
When in-app is the right choice
- Onboarding steps and tips that relate to the screen the user is on.
- Announcing a feature at the point where it is useful.
- Upgrade prompts and paywalls, shown when the user reaches a limit.
- Surveys and feedback requests, straight after the experience you are asking about.
- Referral invitations, at a moment when the user is pleased with the app.
In-app is the wrong choice for reaching people who have drifted away, and for anything the user must act on outside the app.
Push notification vs email: which should you send?
Send a push when the value of the message is in its timing. Send an email when the value is in its content. If a message would be useless tomorrow, it is a push. If the user may want to find it again in a month, it is an email.
What email does that push cannot
- It lasts. Receipts, renewal notices, password resets and changes to your terms belong in a place the user can search later.
- It carries detail. A changelog, a weekly progress summary or a step-by-step guide will not fit in a notification.
- It reaches people without the app. Someone who uninstalled, switched phones or never allowed notifications can still be reached by email.
- It works on any device. The user can read it at a desk and act there.
What push does that email cannot
- It arrives on the lock screen within moments, without the user opening anything.
- It opens the app at the right screen in one tap.
- It suits a single short prompt, where an email would feel heavy.
What email needs from you
Email has its own entry requirements. Mailbox providers expect senders to authenticate their sending domain: Google's email sender guidelines ask all senders to set up SPF or DKIM, and ask marketing messages to support one-click unsubscribe. An email that is not set up correctly may not reach the inbox at all, which is the email equivalent of a user switching notifications off.
Messages that deserve both
A few messages are both urgent and detailed. A failed payment is the usual example: send a short push so the user knows today, and an email with the amount, the date and the link to fix it. The push does the alerting, the email does the explaining. Avoid sending identical wording on both, because the user will read it twice and learn to skip one of them.
How do you choose a channel for a specific message?
Ask three questions in order, and stop at the first one that gives an answer.
- Does it only make sense inside the app, at a particular moment? Use in-app.
- Does it lose its value within hours? Use push, with in-app as the fallback for users who have notifications off.
- Does it need detail, or will the user want to keep it? Use email.
If a message passes none of the three, it may not need sending.
Here is how that plays out for the messages most apps send:
| Message | First choice | Add a second channel when |
|---|---|---|
| Someone replied to you | Push | Show it in-app if the user is in a session |
| Trial ends tomorrow | Push | Email the same day with what happens next |
| Purchase receipt | Confirm on screen straight after the purchase | |
| Password reset | Never, keep it in one place | |
| New feature | In-app | Email users who have not opened the app recently |
| Upgrade prompt | In-app | Rarely, an email offer for lapsed trial users |
| Weekly or monthly summary | A push only if the user asked for it | |
| Feedback survey | In-app | Email for longer research surveys |
| Win back a lapsed user | Push if they still have notifications on | |
| Invite to refer a friend | In-app | Email as a follow-up with their link |
How do you use email, push and in-app together without annoying users?
Decide the order of channels for each message, send through the least interruptive one first, and only escalate for people who have not seen it. Sending everything everywhere at once is the fastest way to lose the push permission.
Cascade instead of broadcasting
Take a feature launch as a worked example. You might:
- Show an in-app announcement to everyone who opens the app in the first week.
- Email users who did not open the app in that week, with the full explanation.
- Send a push only to users who saw neither, and only if the feature is something they would thank you for.
Each step skips the people the previous step already reached. The same pattern works in the other direction for urgent messages: push first, then in-app on the next session, then email if the matter is still open.
Ask for the push permission at a sensible moment
Because iOS shows its permission prompt once, the timing of that first request matters more than any later optimisation. Apple suggests making the request in context, for example after someone schedules their first task in a task app, so that people can see what the notifications are for. Google gives similar advice for Android, suggesting the prompt follows a user action such as tapping a bell icon or placing an order.
Let users choose by topic, not all or nothing
If the only switch a user has is "all notifications off", that is the one they will use. Give them categories. On Android this is built in: notification channels let users change the settings for each type of notification your app sends, and once a channel is created its behaviour is under the user's control. On iOS, Apple asks apps that send informational or marketing notifications to provide a settings screen inside the app where people can change their choice. Do the same for email, with separate options for product news, summaries and offers.
Which channel works best for referral invites and affiliate updates?
Referral invitations work best in-app, and updates to affiliates or partners work best by email, because the two audiences are in different places.
A user is most likely to share your app straight after it has done something for them: a streak completed, a goal reached, a project finished. That moment only exists inside the app, so the invitation belongs there, with a share button that opens the phone's share sheet. We have a separate post on turning users into affiliates with in-app referrals. If you would sooner not build the screen yourself, Insert Affiliate's in-app referrals include a drop-in Refer a friend screen that gives each user their own code and link with Copy and Share buttons. There is an overview on the mobile app referral programme page.
Affiliates and creators are different. They do not live in your app, and what they need (a new offer, a commission change, their results for the month) is detail they will want to refer back to. That is email's job, ideally backed by an inbox they can log in to. This is how affiliate messaging works in Insert Affiliate: a direct message or a broadcast to all affiliates is sent as an email notification and also appears in the affiliate's Messages section in their dashboard. Affiliates can opt out of broadcast emails while still receiving direct messages, which is the same "choose by topic" principle described above. Related reading: keeping affiliate communication in one place.
Frequently asked questions
Are in-app notifications the same as push notifications?
No. A push notification is delivered by the operating system and appears outside the app, on the lock screen or in the notification centre. An in-app notification is shown by the app itself and can only be seen while the app is open. They are often triggered by the same event, with the app choosing one or the other depending on whether the user is currently in a session.
Do in-app notifications need the user's permission?
No system permission is needed, because in-app messages are part of your own interface. Push is different: iOS requires the user to allow notifications, and on Android 13 or higher notifications are off by default until the user grants the permission.
Is push better than email?
Neither is better overall. Push is better for short messages whose value depends on timing, and it can open the app in one tap. Email is better for detail, for anything the user needs to keep, and for people who no longer have the app or have notifications switched off.
Which channel should I use to re-engage inactive users?
Start with email, because it does not depend on the app being installed or on notifications being allowed. Push can work for users who still have notifications on, as long as the message offers a real reason to return. In-app messages cannot help here, since inactive users will not see them.
What should I do for users who turned push notifications off?
Treat in-app and email as your fallbacks. Show the message in-app on their next session, and send an email when it cannot wait that long. If push would clearly help them, explain the benefit inside the app at a relevant moment and point them to their device settings, since iOS will not show the system prompt a second time.
Your next step
List every message your app sends today, and put each one through the three questions above. Move any pushes that should be in-app messages first, then add category-level preferences so users can turn down the volume without switching you off completely.