Web Push Notifications: How They Work and Limits on iPhone

The Web Push Notifications they allow a web application to alert the user even when the page is closed. For an internal tool — a shared box, a management software, an operational dashboard — they are the difference between something that needs to be checked and something that calls you.

They work well, but they have two constraints that almost everyone discovers the wrong way: the permission must be asked during a user action, otherwise the browser silently ignores it; and on iPhone only work if the application has been added to the home screen.

This article explains how they work and what we learned by implementing them in the shared box of the WhatsApp Agent Case Study by Rial Estate.

How they work, in three pieces

1. The listening component. The browser records a script that continues to live even when the page is closed. It is he who receives the notification and shows it.
2. The inscription. When the user grants permission, the browser generates a unique reference for that device. Your server keeps it: it is the address to which it will send notifications.
3. The sending. Your system sends the message to the browser delivery service, which delivers it to the device. You never speak directly to the phone.

The least intuitive point is the third: you don't ship to the device, you ship to an intermediate service managed by the browser manufacturer. This means that the delivery is not guaranteed and is not instantaneous: if the device is turned off, the notification arrives when it comes back online, and with expiration rules that you do not control.

The Permission Error Cold Asked

It is the mistake we have made and that is worth telling, because it does not give any signal.

The temptation is to ask permission as soon as the application opens: it is the first useful moment and seems the simplest. Browsers, however, block permission requests that do not arise from an interaction: the part call, no pop-up appears, no error appears. The result is an application that seems to work and in which no one ever has active notifications.

The right time also counts for another reason: a permit denied You can't request it again with a pop-up. If the person says no because they haven't figured out what it's for, that door closes and reopens requires you to go through your browser settings. Better to ask late and get a yes than to ask right away and collect no.

Limits on iPhone

On iOS web push notifications exist, but with a condition that must be known before promising them.

The practical consequence is that the onboarding of iPhone users must include an extra pass: explain how to add the application to the home screen. It is not complicated, but it is not obvious, and if no one explains it half the team will be without notifications convinced that they are broken.

In the shared project box we added an alert that only appears on iOS when the application is not installed, with the instructions. It's the kind of detail you add after seeing people use the tool, not while you're designing it.

When they are actually needed

Push notifications are useful in a specific situation: a person who already uses the tool must know immediately that something has happened. Outside of there, there are almost always better channels.

The last line is the most important. The risk is not that notifications will not arrive: it is that they will arrive too much, and that someone will turn them off. Once turned off, they will not turn on themselves.

Push, email or message: how to choose the channel

Push notifications are one of the possible channels, not the channel. Choosing it well avoids building something that nobody then uses.

The most useful line is the last. Many things that would instinctively become notifications are better in a list inside the application: the user finds them when he opens, is not interrupted, and above all does not lose them. An ignored notification is lost forever; a line in a list remains.

The combination that almost always works is: list in the application for everything, push notification only for the subset that requires action within a short time. For outward communications the speech is different and passes from other channels, as described in WhatsApp Cloud API.

What happens when the user changes device

It is a case that in tests never appears and in production always comes.

Subscription to notifications is linked to the device and browser, not to the person. Those who use the tool from the phone and computer have two distinct inscriptions; those who change phones have a new one and a dead one.

The practical consequences are two. The first: if the system sends all registered registrations for a user, that person receives the notification twice when they have two devices. The second: No longer valid inscriptions accumulate errors at each sending.

• Register subscriptions by user, not just by device, so you know who they belong to.
• When a submission fails because the subscription is no longer valid, remove it immediately instead of trying again.
• You consciously decide whether to notify all devices of the same person or only the last used.
• Predict a way for the user to turn off notifications from within the application, without going through the browser settings.

The last point is the one that protects the channel over time: if the only way to reduce notifications is to disable them from the browser, those who get tired turn them off and no longer come back. A control inside the application allows you to reduce instead of zeroing.

Practical examples

A shared box. A guest writes; those on duty receive the notification and respond. Without notification, the box should be checked at intervals, and at work moments no one controls it. It is the case that justified the implementation in the project of short rents.

Automation that fails. A stream fails to complete an operation. Instead of waiting for someone to notice by reading the records, the notification brings the problem before a person. It is the natural complement of the rule described in Six errors paid in the field: to make failures noisy.

An internal management software. A practice goes into a state that requires action. The notification comes to those who have to act, not everyone. The segmentation of recipients is the difference between a useful tool and one that will be silenced. It is the same principle that holds the customer follow-up automation: warn the right person, not all.

An automation that demands a decision. Some streams come to a point where human judgment is needed —approve, choose, correct. Notification is the natural way to bring that point in front of a person without having to check at intervals. The concept is described in AI workflow.

Mistakes to Avoid

Asking for permission to open. It does not produce errors, it produces zero inscriptions. It is the most expensive error because invisible.

Not explaining the step on iPhone. Half the team will think the tool is faulty.

Notifying everything. The consequence is that the user deactivates, and since then he no longer receives even the important things.

Counting on notifications as the only channel. Who denied permission, who did not install the application, who has the phone turned off: you always need an alternative way of seeing what happened, typically a list inside the application itself.

Not handling expired subscriptions. Device references become invalid over time. If the system does not remove them, it will continue to send notifications to dead destinations accumulating unnecessary errors.

How to apply it in the company

1. Decide what a notification deserves. The rule: only what requires an action within a short time. Everything else goes into a list within the application.
2. Put an Explicit Button to activate them, at a point where the value is already clear to the user.
3. Manage the iPhone Case with a warning and instructions, shown only to those who serve.
4. Predict the reserve channel for those who do not receive them.
5. Clear invalid inscriptions periodically.

If you are considering an internal installable tool, the reasoning on building or buying is in Custom PWA or software ready and the overview of the services in PWA and web app.

Conclusion

The Web Push Notifications They work and change the way a team uses an internal tool: you go from controlling to being alerted. The two constraints to know before starting are simple but not negotiable: permission is asked during a user action, and on the iPhone serves the app added to the home screen.

The rule that's worth the most: notify little. A tool that notifies only when needed stays on; one that always notifies is silenced, and at that point it no longer serves anything.

Do you want to understand what processes in your company can be automated with AI? Giallo Studio can help you turn the problem into a real workflow.