The short version
These two channels look similar because both render small messages in your product, but they sit on opposite sides of two lines: reach and consent. Web push leaves your site and lands on the device after the user grants a browser permission. In-app messaging stays inside an active session and needs no separate permission. Treat them as two tools, not one.
How web push works
Web push relies on three browser pieces working together: a service worker (a background script the browser keeps running), the Push API (which subscribes the browser to a push service and receives messages), and the Notifications API (which renders the system notification). The user must explicitly click Allow on the browser permission prompt; until they do, you cannot send anything. After opt-in you get a subscription endpoint and encryption keys, and your server sends through the browser's push service even when the tab is closed. Because the message arrives off-site, web push is the re-engagement channel of the group — closer in job to SMS or email than to anything that lives inside your app. The catch: it is bounded by browser and OS support, and the user can revoke the permission at any time.
The iOS caveat
On iPhone and iPad, web push does not work for a plain Safari tab. Apple added web push only for web apps the user has added to the Home Screen, starting in Safari 16.4 (March 2023). The permission request must come in response to a direct tap — for example, a Subscribe button — not on page load. So on iOS your reachable audience is the subset of users who installed your site as a web app and then granted permission. Plan for that gap rather than assuming parity with desktop.
How in-app messaging works
In-app messages render inside an active session — a banner, modal, slideout, or tooltip drawn by your product while the user is using it. There is no separate opt-in because the user is already in your product; the message is part of the experience. The trade-off is reach: in-app only touches people who are present right now. It cannot pull a lapsed user back, and a churned user will never see it.
When to use which
| Job | Reach for |
|---|---|
| Bring a lapsed user back | Web push (or email / SMS) |
| Announce a feature to active users | In-app banner or modal |
| Guide a first-time user through setup | In-app tooltip or slideout |
| Alert on a time-sensitive event off-site | Web push |
| Prompt an upgrade mid-task | In-app modal |
The honest division: in-app handles the people already in the room, web push goes to find the ones who left. Most products use both, coordinated inside a customer journey so the same person does not get an in-app nudge and a push for the same thing within minutes of each other. Deciding which channel carries which message, in what order, without overlap is the move from running many channels to running them as one — the subject of multi-channel versus omnichannel. Standalone tools such as OneSignal or Novu specialize in push and notification delivery; an engagement platform folds push and in-app into the same journey logic as the rest of your channels.