How to Implement In-App Messaging
Discover formats, rules, and best practices for in-app messaging. See how to use pop-ups, bottom sheets, and fullscreens to boost engagement.
September 01, 2025•10min
Share the article
Push Notification Alternative
Karina
Author @ InAppStory
August 09, 2026•20 min
By 2026, push delivery is increasingly shaped by the operating system rather than the sender. On modern Android, notification permission is already a standard runtime gate for non-exempt alerts. Android 15 added notification cooldown, which reduces the visual prominence, sound volume, and vibration of repetitive notifications arriving in quick succession. Android 16 went further and can automatically group notifications on an app’s behalf.
Apple is moving in the same direction. In iOS 26, Apple Intelligence can summarize long or stacked notifications, place priority notifications at the top, and use Reduce Interruptions to silence alerts it considers less important.
The lock screen is rented media. The brand can send a push message, but whether it gets the attention depends on the operating system and the user.
For product and CRM teams, this changes the role of push notification alternatives. Push should be reserved for messages where delay has a real cost.
Why the Lock Screen Is Rented Media for Push Notifications
Sending a push notification does not guarantee visibility. Three parties now shape what happens between send and view.
| Who controls it | What they control | |
|---|---|---|
 | Brand | Message, audience, trigger, send time |
| User | Permission, notification settings, Focus modes |
| Operating system | Grouping, prioritization, summaries, interruption level |
The balance has shifted toward the last two. Android can reduce the prominence of repeated notifications or group them automatically. Apple Intelligence can summarize notifications and prioritize selected alerts.
A push journey now looks closer to this:
Brand sends → User allows → OS filters → User notices
The first step belongs to the brand. The last three do not.
This is why push notification alternatives matter even when push performs well. They give product and CRM teams communication surfaces that do not depend entirely on lock-screen visibility.
Which Messages Still Deserve a Push Notification?
A push notification earns its place when delay changes the value of the message.
| Message | Cost of delay | Push? | |
|---|---|---|---|
| Suspicious login | High | Yes |
| Payment failure blocking an order | High | Yes |
| Delivery arriving soon | High | Yes |
| Time-sensitive service disruption | High | Yes |
| Feature announcement | Low | Usually no |
| Product education | Low | Usually no |
| Recommendation | Low | Usually no |
| General promotion | Low | Usually no |
The distinction matters because every interruption spends some of the user’s tolerance for future notifications.
Reuters Institute found this effect clearly in news apps. Among respondents who did not receive news alerts, 43% said they had actively disabled them because there were too many or they were not useful enough. The figure is specific to news and should not be treated as a general mobile-app benchmark. It does show how notification fatigue develops.
A practical rule follows:
High cost of delay → interrupt externally.
Low cost of delay → wait for a better communication moment.
Security, transactional, and genuinely urgent messages usually stay with push. Everything else should compete for the channel on value, not habit.
Choose a Push Notification Alternative by the Job of the Message
There is no universal best alternative to push notifications - the right format depends on what the message needs the user to do.
| Job of the message | Better surface | Example | Why it fits | |
|---|---|---|---|---|
| Explain something | In-app stories, cards, onboarding flows | New feature, changed subscription terms, new loyalty mechanics | The message has space for context, visuals, and several steps. |
| Influence a decision in progress | Contextual in-app message | Upgrade prompt, abandoned action, relevant recommendation | It appears while the user is already in the relevant flow. |
| Keep information available | App inbox, notification center, content hub | Rewards, offers, account updates, saved recommendations | The user can return to it instead of acting immediately. |
| Deliver detailed information | Email or an in-app content page | Monthly statement, policy update, detailed product education | Longer content remains readable and searchable. |
The key difference is where the message gets its relevance from.
The push notification has a lot to do with timing. Contextual in-app messages get their relevance from the user’s activity at the time. The app inbox gets its relevance from persistence. Email gets its relevance from available space for details.
And it's also why a replacement of push notifications with any other broadcasting medium doesn't actually solve the problem. Changing the delivery channel of the feature announcement from push to email will change the delivery method. Changing its location to the app itself when the feature gets relevant will change the message itself.
The helpful question to ask here is: What should this message do, and what's the best surface to achieve that?
How Push Notifications and In-App Messaging Can Share One Journey
Push and in-app messaging solve different parts of the same journey. Push can bring the user back. Once the app opens, the communication job changes.
Push → App open → Context → Action
| Journey step | Best role | |
|---|---|---|
| Push notification | Signal that something requires attention |
| App screen | Restore the context of the event |
| In-app message or story | Explain what happened and what to do next |
| CTA | Take the user directly to the relevant action |
Let us take the case of a payment failure. A push notification may briefly communicate the failure status. After the tap, a message in the app can communicate the reason for the failure, the order number and the next course of action. The push notification has garnered attention. The in-app layer translates that attention into a smart action.
The above process could also be achieved directly through InAppStory. Push notifications can include story IDs and open that particular story on the tap of the push. Product and CRM teams may also trigger in-app messages on events and target them through segments or tags.
This helps in achieving a division of labor between product and CRM teams:
➡️ Use push notifications to make the entry point.
➡️ Use in-app messaging to carry the story forward.
InAppStory can support stories as well as contextual elements such as bottom sheets, fullscreens and popups depending on the extent of communication and action involved in the latter part of the story journey.
What If the User Never Enables Push Notifications?
Push opt-out should be treated as a normal state of the customer journey.
If push is unavailable, communication starts when the user returns to the app. The task is to identify what still matters at that moment and choose a surface that matches it.
A push-independent journey can look like this:
App open → Check relevance → Show message → Offer action → Keep important information accessible
| Need | Surface | Example | |
|---|---|---|---|
| Explain something at the next visit | Story, card, fullscreen | New feature, changed process, loyalty update |
| React to user behavior | Contextual in-app message | Upgrade prompt after reaching a limit |
| Preserve information for later | App inbox, content feed | Offers, rewards, account updates |
| Reach the user outside the app when appropriate | Email or SMS | Account information, detailed transactional communication |
The secret lies in the consistency throughout sessions. An important message on Monday may still require display when the user opens the application on Wednesday, but an offer that expired needs to be removed.
It is here that event-based targeting and segmentation can come into play. For instance, InAppStory can initiate in-app communication in response to certain user segments and product events, thus making sure that the journey will be consistent without requiring any push permissions.
The outcome is a communication system where push expands reach, but the customer journey does not rely on push.
FAQ
The main push notification alternatives are in-app messages, stories, app inboxes, email, SMS, web push, and persistent content feeds. The best option depends on the message. In-app formats work well when context and timing inside the product matter, while email is better for detailed information that users may need to revisit.
Use in-app messaging when the message becomes more useful after the user enters the product. Common examples include onboarding, feature education, recommendations, upgrade prompts, and explanations that require more context than a lock-screen notification can provide.
Usually, no. Push and in-app messaging perform different jobs. Push can bring a user back to the app, while an in-app message can explain the situation and lead to the next action once the user is already there. In many journeys, the two formats work better together.
There is no single replacement. For users who disable push notifications, teams can combine contextual in-app messages, stories, app inboxes, email, or SMS depending on the message. The important part is to make the journey continue when the user returns to the product instead of relying on a lock-screen alert.
Start by reducing low-value interruptions. Reserve push for messages with a meaningful cost of delay, move contextual communication into the product, and keep non-urgent information available in persistent surfaces. The goal is to avoid making every message compete for the lock screen.
Read also
