Push notifications in 2026 are no longer just a simple marketing channel: Chrome now limits overly insistent sites, Android has required explicit permission since Android 13, and iOS strictly governs web apps. For your project, this changes three things: consent must be introduced more effectively, volumes must be managed, and the budget must account for a real product logic, not just an “send” button.
Push notifications 2026: what is really changing
The intent behind a search about push notifications 2026 is often very concrete: to find out whether this channel remains reliable for re-engaging customers, alerting users, or driving activity in an application. The short answer: yes, but only if you accept that browsers and operating systems are doing more to protect users’ attention.
On January 6, 2026, Chrome began rolling out rate limits for the Push API, the interface that allows a website to send notifications through the browser. Sites with high volume and low engagement may receive an HTTP 429 error, which means too many requests are being sent above a limit set at at least 1,000 messages per minute.
This is not just a technical constraint. It is a governance signal. If your site sends a lot of messages to people who do not return, do not click, or spend little time with you, the channel may become less available precisely when you are counting on it.
On mobile, Android 13, also called API level 33, has required a POST_NOTIFICATIONS runtime permission since 2022 before displaying most non-exempt notifications. Apple, for its part, also requires authorization for alerts, sounds, and badges, with variants such as provisional authorization, which allows non-intrusive notifications before an explicit choice.
Why your push notifications may be blocked or ignored
The first risk is not technical blocking. It is indifference. A notification that arrives too early, too often, or without a clear benefit teaches the user to dismiss, block, and then forget your brand.
Chrome calculates daily criteria such as the number of push messages per time spent on the site, the number of permission requests per time spent, as well as engagement and foreground minutes. In other words, a site visited three minutes per month does not have the same leeway as a business tool opened every day.
The common trap for an SMB is to think only in terms of the installed base: “we have 20,000 push subscribers, let’s send to everyone.” Bad reflex. If actual engagement is low, the right strategy is often to reduce volume, segment more precisely, and then reserve notifications for high-value moments.
Chrome also indicates that limitation periods become more severe: 1 day after a first day deemed disruptive, 7 days after the second, then 14 days after the third and subsequent ones. Resetting to zero requires 42 consecutive non-disruptive days. For a commercial campaign, two weeks of limitation may be enough to break the schedule.
On the projects we lead, we often see the same gap: the specifications call for “push notifications,” but not the frequency rules, unsubscribe scenarios, or backup messages by email or SMS. Yet these are precisely the details that prevent dependence on a single fragile channel.
Web, mobile app, or PWA: the right choice depends on the use case
A web push notification works from a compatible browser. It may be suitable for a media outlet, an e-commerce site, a booking platforme, or a customer area. Its advantage: no installed app needed. Its limitation: the experience depends heavily on the browser, the device, and permissions.
Since iOS and iPadOS 16.4, Apple supports Web Push for web apps added to the home screen. Be careful with the nuance: it is not enough to visit a site in Safari. The user must install the web app on their home screen, then the permission request must follow a direct action, for example tapping a subscribe button.
A native mobile app remains more robust for recurring uses: order tracking, appointments, messaging, business alerts, association with active members. If your project fits this logic, it is useful to define the iOS/Android architecture and notification scenarios very early, as for a high-performance mobile development.
A PWA, or progressive web app (installable web application), can be a good compromise when the budget does not allow for two native applications. Honestly, it is only justified if installation on the home screen brings clear value: frequent access, partial offline features, dashbord, lightweight messaging. For a simple showcase site, it is often too much.
| Option | Suitable use case | Indicative cost in France | Realistic timeline | 2026 watchpoint |
|---|---|---|---|---|
| Web push on website | News, cart recovery, simple alerts | €2,000 to €8,000 depending on integration | 1 to 3 weeks | Chrome limitations if volume is high and engagement is low |
| Installable PWA | Customer area, recurring portail, light field service | €8,000 to €30,000 depending on features | 4 to 10 weeks | On iOS, Web Push is reserved for apps added to the home screen |
| Native iOS/Android application | Frequent use, user account, business workflow | €25,000 to €100,000 and more | 3 to 6 months | Android 13+ permissions and Apple rules to address in the UX |
These ordres price ranges vary fortly depending on the back office, segmentation, authentication, and volume. To compare with a more overall budget, a benchmark on the price of a mobile application in 2026 helps avoid underestimating the server side, often invisible in the initial discussions.
Consent: timing matters as much as the message
Requesting autorization as soon as someone lands on a site is rarely a good idea. The user does not yet know what they stand to gain. On Chrome, this approach can even contribute to poor acceptance rates or more discreet prompts for sites poorly received by users, according to the mechanisms announced by Google since Chrome 80.
The right moment comes after a meaningful action: tracking a file, confirmed booking, adding a product to favori, creating an account, signing up for an availability alert. At that moment, the notification is not an interruption. It is the logical continuation of the service.
A pre-permission message, displayed in your interface before the system prompt, can explain in one sentence what the user will receive. Simple example: “Receive an alert only when your appointment is confirmed or changed.” Nothing vague. Nothing anxiety-inducing.
On iOS, this logic is even clearer for web apps: WebKit specifies that the request must follow a direct user interaction, such as tapping a subscribe button. For native Apple applications, the UserNotifications documentation reminds that autorization is required to display alerts, play sounds, or badge the icon.
The Badging API, which displays a counter on the icon of an iOS web app, is available only for apps added to the home screen and only after notification permission. If your management expects a banking-app-style badge on a simple mobile site, you need to corrig the expectation from the planning stage.
Technical architecture: avoiding hidden debt
Behind a push notification, there is always a server that decides what to send, to whom, when, and with what level of priority. This server must manage tokens, that is, the technical identifiers of devices or browsers, user preferences, errors, and unsubscribes.
Firebase Cloud Messaging, often abbreviated as FCM, remains a common building block for Android and some web sends. Since July 22, 2024, Google has begun shutting down the old legacy HTTP/XMPP APIs, with FCM HTTP v1 as the migration target. A provider that still offers a new integration using the old method creates immediate debt.
For a secure client portal, notifications must also comply with the GDPR, the European regulation on personal data in force since 2018. An alert can reveal sensitive information on a locked screen: unpaid bill, medical result, HR incident, new confidential message. In this case, it is better to send a neutral notification such as “A new document is available” and require authenticated access to the portal.
This thinking also ties into designing a secure client portal from the start : permissions, logging, roles, retention period, and communication preferences should not be added afterward. At this budget, it is better to fund fewer scenarios but make them reliable, rather than piling up poorly controlled campaigns.
For critical notifications, Apple has a specific entitlement that allows certain approved apps to request alerts capable of playing a sound even in silent mode or Focus mode. This is not a marketing lever. It applies to strict cases, such as health or safety, and requires approval.
Action plan to avoid losing your users
An effective 2026 push notification strategy begins before development. It connects the business objective, user tolerance, and platform constraints. Without this discipline, the channel quickly becomes an unsubscribe machine.
- Classify notifications by value: expected service, security, transactional, marketing, low-priority re-engagement.
- Define a maximum frequency per segment, with a different rule for active and dormant users.
- Prepare the pre-permission copy and preference screens before technical integration.
- Measure opt-ins, blocks, opens, unsubscribes, and sending errors by browser or OS.
- Plan a fallback channel, often email, for important non-urgent messages.
Tracking must be readable for an executive. A monthly dashboard with opt-in rate, open rate, average frequency, volume sent, and unsubscribes is often enough. Later, cohorts or A/B tests can be added, but the foundation must remain understandable.
For a booking app, for example, the useful notification is not “Take advantage of our offer.” It is “Your 2:30 PM slot is confirmed” or “An earlier slot has just opened up.” The features that save time in an online booking app are often the ones that reduce uncertainty, not the ones that add noise.
From the agency side, the instinct is to separate transactional notifications, which are essential to the service, from engagement campaigns. They do not have the same frequency, the same tone, or the same metrics. Mixing them in the same tool without safeguards almost always ends up degrading trust.
Defining this type of project upstream avoids most unpleasant surprises: denied permissions, Chrome constraints ignorored, aging FCM architecture, overly intrusive messages. An outside perspective is especially helpful for balancing functional ambition, available budget, and the risk of irritating users.
FAQ about push notifications 2026
Do push notifications 2026 work encore on iPhone?
Yes, but depending on the context. Native iOS apps use them with permission, while Web Push has been available since iOS/iPadOS 16.4 for web apps added to the home screen.
Why can Chrome limit my web notifications?
Chrome may limit sites that send a lot of push notifications with little user engagement. The criteria include, in particular, messages per time spent on the site, permission requests, and minutes in the foreground.
How much does it cost to add push notifications to a website or an app?
For a website, expect to pay between 2,000 and 8,000 € depending on the complexity. For a PWA or an application with segmentation, preferences, and back office, the cost can rise from 8,000 to 30,000 € or more.
Should permission be requested on the very first visit?
In most cases, no. It is better to wait for an action that gives meaning to the subscription: booking, order tracking, account creation, or alert request.
Is FCM HTTP v1 mandatory for new projects?
This is the target to prioritize. Google began shutting down the old legacy FCM HTTP/XMPP APIs in 2024, so building a new service on top of them would be a poor technical choice.