In App Notifications: A Practical Guide for Modern Products.

• Treat permission as the beginning: A user opting in hasn't formed a notification habit. Relevance, timing and trust determine whether they stay engaged.
• Match format to urgency: Use banners, modals, toasts and inboxes for different jobs. Blocking interfaces should be reserved for decisions users genuinely need to make.
• Minimise permission breadth: Separate service alerts from marketing, redact sensitive lock-screen content and provide useful in-app alternatives.
• Measure fatigue, not just opens: Track sent, displayed, opened, dismissed and deep-link-completed events, then compare notified and non-notified cohorts.
• Build the system in layers: Start with an audit, taxonomy, consent model and fallback surfaces before adding complex personalisation.

A user taps “Allow” during onboarding. The team celebrates the opt-in rate, adds the device token to its messaging platform and schedules a sequence of reminders. A few weeks later, the user has silenced the app, ignored its banners and learned that every alert can wait.

That outcome is common because permission is a technical state, not a relationship. UK mobile news alerts offer a useful historical comparison. Usage among UK adults rose from 3% in 2014 to 18% in 2025, a sixfold increase over 11 years, but most of that growth happened before 2017. Adoption then slowed as users faced more competition for attention on the lock screen. The Press Gazette's coverage of the 2025 Digital News Report also shows how reach concentrates around trusted publishers, with BBC News identified by 46% of UK respondents who receive news alerts.

The lesson for product teams is straightforward. A large addressable channel doesn't guarantee habitual use, and an opt-in doesn't prove that a message deserves attention. The most effective in app notifications begin with a clear job, arrive in a relevant context and give the user control over what happens next.

The Notification Habit Is Not the Same as the Permission

A permission prompt records access, not attention. A banking app that asks before the customer has checked a balance, completed a payment or received useful service is requesting future interruption without showing its value.

In the UK, 79% of surveyed respondents said they received no news alerts during an average week. BBC News reached a concentrated audience of trusted recipients, which shows why permission alone says little about routine use. The UK mobile news alert data gives product teams two separate questions: can the app reach this person, and has it earned a place in the person's routine?

Practical rule: Design the first useful notification before designing the permission request. If the team cannot explain what immediate value follows, the prompt is premature.

Timing also shapes habit. Research involving UK academic institutions found that receiving a notification increased the probability of opening an app during the following hour by 3.5 times, with a reported 95% confidence interval of 2.91 to 4.25. Across 24 hours, the probability increased by 1.3 times, indicating that the strongest measured effect occurred near delivery rather than evenly across the day. The LSHTM study on notification-driven engagement supports a narrower conclusion: a message linked to an immediate task can prompt action, while repeated messages may still fail to improve retention.

Treat each notification as a behavioural intervention. Identify the task, decision or meaningful change before choosing the channel. If none exists, an inbox item or quiet in-app status may serve the user better than an interruption.

Permission sequencing also needs realistic account testing. When staged account journeys require SMS verification, teams sometimes use quackr for instant SMS verification to keep test accounts separate from customer data. That supports test setup, but consent behaviour still requires checks on real devices and operating systems.

What In App Notifications Are

“In app notifications” describes several communication patterns, and their consent implications differ. The surface determines how much attention the product claims, whether the user can continue a task, and whether the message remains available after dismissal. Treating every format as interchangeable turns a design choice into an accidental permission request.

Banners create ambient awareness

A banner sits at the top or bottom of the active interface. It fits service notices, maintenance information, account-status changes and low-pressure prompts. Users can continue browsing while it remains visible, but persistence becomes a problem when the message has no clear expiry.

Use a banner when the user can continue without acting immediately. It should not carry a critical decision that may disappear beneath the interface or compete with concentrated work.

Modals demand a decision

A user opening a payment flow may need to confirm a consequential change before continuing. A modal blocks the underlying interface until the user closes it or chooses an action, so it suits safety warnings, confirmations and workflow changes that require acknowledgement.

That interruption carries a consent cost. A modal asks the user to stop. If the message could wait for an inbox visit, a banner or a contextual panel, the stronger surface claims more attention than the task warrants.

Toasts confirm completed actions

The trade-off with a toast is discoverability. It appears briefly and does not block the interface, but it is a poor place for information the user may need later.

Use it to confirm a completed action, such as a file finishing its upload, a setting saving or an invitation sending. Because no decision is required, the message can disappear without disrupting the workflow. Important confirmations should also appear in a persistent activity record or inbox entry.

Inboxes preserve user choice

An inbox stores unread or recent items for later review. It suits secure messages, account activity, support responses and updates that matter without requiring immediate interruption. The user chooses when to open it, making an inbox a useful fallback when push access is declined.

It also gives teams a consent-aware destination for information that should remain available without claiming lock-screen or foreground attention.

These formats occupy different points on an attention spectrum. Toasts are fleeting, banners are ambient, inboxes are persistent but user-initiated, and modals are interruptive. Choose the surface by urgency, reversibility and context, then confirm that the user has agreed to the level of exposure it creates.

UX Best Practices That Hold Up in Real Products

Good notification UX is less about clever copy than about disciplined decisions. Start with the user's current task, then decide whether the message belongs in the foreground, the background or nowhere at all.

Time the message around the task

A notification about an export belongs near the Reports screen, not immediately after login. A reminder about an unfinished form should wait for a natural pause rather than cover the next field. Use quiet hours, recent notification load and interaction history as inputs to delivery policy.

A useful server-side priority score can combine urgency, user intent, message category and recent exposure. Local operating-system scheduling can then delay or group low-value events while allowing important service events through.

Write for the next action

Keep the message specific. State what changed, why it matters and what the user can do. “Your secure message is ready” is clearer than a generic “You have an update”, especially when the action opens the exact destination.

Deep links should land on the relevant screen, not the app home page. For accessibility, the action must also be available through keyboard navigation, screen readers and a visible in-app route, not only through a timed visual element.

For teams refining the broader experience, mobile app design guidance should sit alongside notification decisions. A notification can't compensate for confusing navigation or a destination that fails to explain what happens next.

Personalise without profiling by default

Personalisation should use the smallest useful set of signals. A service may need account status and recent activity to show an accurate message, but it may not need a detailed behavioural profile for every promotional prompt.

Give users category controls where the product supports several notification jobs. Service alerts, reminders, product education and marketing shouldn't be treated as one undifferentiated stream. Progressive disclosure also helps: show a concise message first, then let the user open detail if they need it.

Use frequency as a product rule

Set exclusion rules for active high-stakes workflows. Add quiet hours, suppress duplicates and stop a campaign when the user completes the intended action. A notification system should know when not to send.

A good notification system isn't the one that can send everything. It's the one that can confidently hold most things back.

Permission as a Product Problem, Not a Prompt

The strongest contrarian move in notification design is to request less, not more. Which? tested 20 popular UK apps and found that 16 requested permission to create windows over other apps. The investigation also found that two-thirds of surveyed UK adults were concerned about precise location collection, while 15 of the 20 apps tested requested precise location data. Which?’s investigation into app permissions places notification design inside a wider privacy relationship.

That matters because 91% of surveyed UK adults ranked privacy above usability, speed and reliability, and visual appeal in the same Which? research. A product that gains a permission but creates suspicion may lose the more valuable asset, user trust.

Explain value before access

Use your own interface to explain what the user will receive before showing the operating-system prompt. Name the category, frequency expectation and privacy treatment. Then let the user choose a narrow option rather than forcing an all-or-nothing decision.

The GOV.UK app privacy notice provides a useful model. Personalised notifications require processing attributes such as first and most recent app use, usage frequency and time spent in the app. The notice identifies consent as the legal basis and allows people to continue using the service without receiving notifications. The GOV.UK app privacy notice supports separating notification permission from analytics and behavioural profiling.

Separate service from promotion

A payment receipt, appointment update or security alert may be part of the service. A product offer or campaign message may be direct marketing. The ICO says organisations must identify whether a message is direct marketing, establish an appropriate lawful basis and comply with PECR where applicable. People also have an absolute right to object to direct marketing, and opt-out requests must be easy to exercise and acted on promptly. The ICO's direct marketing checklist should inform the notification taxonomy before copy is written.

The ICO also requires marketing consent to be clear, freely given and based on affirmative action. Pre-ticked boxes aren't valid, consent can't be made a condition of service unless strictly necessary, and withdrawal must be as easy as giving consent. The ICO's detailed marketing guidance makes a separate promotional preference essential.

Teams reviewing permission architecture can also use a lesson in privacy from Venmo as a prompt to examine defaults, visibility and user expectations. Redact sensitive content on lock screens, keep an audit trail of preference changes and provide equivalent in-app status when push access is refused.

Mobile and Web Delivery Compared Without the Marketing Gloss

Mobile and web delivery solve different reach problems. Native mobile push can reach someone outside the app through operating-system surfaces, while an in-app message depends on an active session. Browser push can reach web users beyond the current page, but its permission path and persistent visibility vary by browser and device.

Native apps typically deliver through APNs on iOS and FCM on Android. The transport layer handles delivery, but it doesn't guarantee that the user sees, opens or acts on the message. Tokens can become stale, operating systems can suppress interruptions and users can change settings outside the product.

Web push uses browser permissions and service-worker infrastructure. It can suit a web-first product that needs re-engagement without requiring a native download, but the installation and permission journey still creates friction. On iOS, browser push depends on adding the web app to the Home Screen, which changes the acquisition path for products that expect a simple browser prompt to create a persistent channel.

Choose the channel by the job

Use in-app surfaces for contextual guidance, feature education, workflow feedback and secure content already available in the product. Use mobile push for time-sensitive events, reminders and re-engagement when the user isn't active. Use web push when browser-based reach is strategically important and the team can explain the installation and permission steps clearly.

The NHS App illustrates why delivery state needs careful modelling. Users manage notification permission through device settings, changes can take up to 24 hours to take effect and people using multiple devices must enable notifications separately on each one. Notifications may also be visible to anyone using a shared device. The NHS guidance on managing app notifications is a reminder that “enabled” isn't always an immediate or universal state.

NHS England makes the distinction even clearer. A secure inbox message can exist without an operating-system alert, and a device notification arrives only when notifications are enabled. Preference changes may again take up to 24 hours. NHS England's notification and messaging guidance supports building inbox availability, permission status and delivery status as separate parts of the user journey.

Measuring Notifications Without Hiding the Fatigue

Open rate is only one signal. It cannot show whether someone read a lock-screen message without opening the app, tapped by mistake, dismissed it immediately, or opened the product for another reason.

Track the complete path:

• Sent: The service accepted the message for delivery.
• Displayed: The device or in-app surface rendered it.
• Opened: The user entered the notification destination.
• Dismissed: The user cleared or rejected it.
• Deep-link completed: The user reached and completed the intended action.

Break these events down by channel, message category, device, permission state and experiment cohort. High opens with low completion can indicate a broken destination or weak message-to-action fit. Rising dismissals often reveal fatigue before users revoke permission.

Measurement discipline: Every notification needs an intended outcome after the tap. Without one, the team is measuring attention rather than user value.

Use controlled comparisons to separate notification impact from existing engagement. As noted earlier, the UK behaviour-change app research found its strongest effect soon after notification exposure. Compare notified and non-notified users, then report both immediate actions and later behaviour rather than treating an open as success.

A useful dashboard combines delivery health, completed actions, category-level dismissals and permission changes. Add a fatigue view for repeated exposure without action. For example, set a review trigger when a category reaches a 50% dismissal rate across a defined cohort, then suppress, retime or redesign that category before increasing its reach. The threshold is a governance rule, not a universal benchmark, so teams should validate it against their baseline and consent expectations.

Optimise for completed user jobs, not message volume.

Implementation Approaches and What to Verify Before Launch

Start with an audit, not a vendor shortlist. Inventory every current send, its trigger, audience, message category, destination, fallback and owner. Remove duplicates, identify messages with no measurable outcome and separate service communications from promotional activity.

Next, define the consent model and content taxonomy. Store explicit preference states, device-level status and revocation events independently of the device token. Keep notification delivery to the minimum stable identifier and segmentation fields required, with retention and deletion rules managed separately.

A managed notification service can accelerate transport, token handling, templates and segmentation. An in-house layer may offer tighter control over policy, data boundaries and experimentation, but it also creates operational responsibility. Teams evaluating domain-specific patterns can review guidance on streamlining youth sports alerts, especially where event timing and audience relevance shape the message.

Before launch, verify:

• Permission framing: The user understands the value and can decline optional messaging.
• Preference separation: Service, reminder, education and marketing categories behave independently.
• Privacy controls: Lock-screen content is redacted where needed, and overlay permissions aren't treated as an automatic substitute for notification consent.
• Fallback surfaces: Important content remains available in an in-app inbox or status area.
• Event quality: Sent, displayed, opened, dismissed and completed actions are tested independently.
• Rollback: The team can pause a campaign or category without waiting for a full release.
• Cross-device behaviour: Settings, tokens and delayed permission changes are handled explicitly.

Use integration testing for notification workflows to verify the complete path, including permission denial, delayed settings, deep links, duplicate suppression and expired content. A staged release with a small audience is safer than launching every category at once. The first goal is not sophistication. It's a trustworthy system that can explain why each alert exists and stop sending when it no longer helps.

Arch helps teams design and build mobile products with notification architecture treated as part of the wider user journey, from discovery and permission flows through delivery, analytics and ongoing support. Visit Arch to scope a product review or development engagement focused on safer, more useful in app notifications.

Frequently Asked Questions

What are in app notifications?

In app notifications are messages shown inside a mobile or web product while someone is using it. Common formats include banners, modals, toasts and persistent inbox items. Unlike device push alerts, they rely on an active session and can use immediate product context. That makes them useful for guidance, confirmations, service status and feature education, but unsuitable for reaching people who aren't currently in the product.

How are in app notifications different from push notifications?

In app notifications appear within the product and usually respond to what the user is doing on screen. Push notifications appear through an operating system or browser surface, including a lock screen or notification tray, and can reach someone outside the app. Push requires permission, while in-app messaging doesn't use the same system-level permission model. The channels work best when coordinated rather than treated as interchangeable.

Should promotional messages use the same permission as service alerts?

They shouldn't be bundled automatically. Promotional messages can constitute direct marketing, so teams need to identify the message type, establish an appropriate lawful basis and make withdrawal straightforward. Service alerts and marketing also have different user expectations. Separating categories lets people retain essential account communication while declining optional promotions, which creates a clearer consent experience and reduces unnecessary permission breadth.

What should teams measure beyond open rate?

Track the complete sequence: sent, displayed, opened, dismissed and deep-link completed. These events reveal different failure modes. A message can be delivered but never displayed, opened without producing the intended action or dismissed repeatedly because it arrives at the wrong time. Compare notified and non-notified cohorts where appropriate, and monitor permission changes and repeated exposure so fatigue doesn't disappear behind a single engagement metric.

How should an app handle users who refuse notifications?

Keep the core service usable and provide equivalent in-app information wherever possible. An inbox, account activity area or status centre can preserve important content without relying on a device alert. Explain what the user may miss, but don't repeatedly pressure them. Store the preference clearly, respect revocation and offer a route back to settings if the user later decides that notifications would be useful.

About the Author

Hamish Kerry is the Marketing Manager at Arch, where he's spent the past six years shaping how digital products are positioned, launched, and understood. With over eight years in the tech industry, Hamish brings a deep understanding of accessible design and user-centred development, always with a focus on delivering real impact to end users. His interests span AI, app and web development, and the emerging potential of new technologies. When he's not strategising the next big campaign, he's keeping a close eye on how tech can drive meaningful change.

Hamish's LinkedIn profile