Delivery Paths
Notifications reach people two ways, and an installation may use both.
Where to find it
Architect Panel → Background Messaging:
- Push Notifications — web push subscriptions
Architect Panel → Mobile Apps:
- Mobile Canvas — the app, and its push delivery settings
Web push
Through the browser, using a service worker and a subscription tied to that browser on that device. It works without an app, on desktop and mobile, and it requires no app store.
The subscription belongs to the browser, so somebody using two browsers has two — and clearing site data removes it.
Mobile app push
Through the platform's mobile app, delivered by the operating system's own service — Apple's for iOS and Google's for Android, each configurable.
More reliable than web push on mobile, and it requires the app to be installed.
One person, several subscriptions
Somebody with a work laptop, a phone browser and the app may hold three. That is correct — each is a device they might be looking at — and it means "notify this person" is not one delivery.
It also means a stale subscription among them causes a failure that is not a failure to reach the person.
Choosing
- Web push where users work at a desk, or where you cannot expect an app to be installed.
- App push where the audience is mobile and the app is already part of how they work.
- Both, where the population is mixed.
Reliability differs
App push is generally more dependable on a phone: mobile browsers are aggressive about background activity, and web push on iOS in particular has had a chequered history and requires the site to be added to the home screen in some versions.
If mobile reach genuinely matters, the app path is the stronger one.
Neither is guaranteed
Both depend on the device being reachable, the user's own notification settings, and a service you do not control. Treat delivery as likely rather than certain, and never as evidence somebody was told.
Test on real devices
Notification behaviour varies by operating system version, browser and the user's settings, in ways an emulator will not reveal. Test on actual phones — at minimum one recent iOS and one Android.
Worked example
An organisation uses web push for office staff and app push for field engineers, who already carry the app. Engineers hold both subscriptions and receive one notification per event because delivery is per person rather than per subscription. Critical alerts also go by SMS, since neither push path is guaranteed.
Recommendations
- Match the path to how people work.
- Prefer app push where mobile reach matters.
- Test on real devices, both platforms.
- Never treat delivery as proof somebody was told.