The question always comes up, usually in the first week: "Do the notifications reach iPhones?" The honest answer is yes, but not the way they do on Android, and not the way they do on a computer. Web push is real on iPhone and iPad, but it goes through a narrow door that Apple built, and no platform can make that door any wider.
This guide lays out what works, what doesn't, what the reader actually sees, how to explain the one gesture that matters, and when it makes sense to consider something different, such as a native app. It applies to anyone sending web push, whatever tool they use. If you are starting from scratch, it helps to read what web push notifications are first.
Apple's rule, in one sentence
Since iOS and iPadOS 16.4, a website can send push notifications to an iPhone or iPad only if the reader has added it to the Home Screen as a web app, and only if they have allowed notifications after opening it from there.
Everything else follows from that sentence. Let's take it apart piece by piece.
It has to be a web app, not just a page
When someone adds a site to the Home Screen, iOS creates an icon that looks like an app icon. If the site has a web app manifest (a small file describing its name, icon and display mode) set up to open as a standalone app, tapping that icon opens the site full screen, without the Safari address bar. From that point on, iOS treats it as a web app, with its own settings and its own notifications.
Without a suitable manifest, the Home Screen icon behaves like a bookmark and the site reopens inside Safari. In that case, notifications cannot be requested at all. The manifest is part of your site: whoever looks after your theme or development handles it, and many modern themes and content management systems already include one. It is worth checking that yours exists and declares standalone display (technically, display set to standalone).
Permission has to follow a tap
Even inside the web app, iOS does not let a site ask for permission whenever it likes. The request has to come from something the reader does, such as tapping a button labelled "Turn on notifications". Only then does the system dialog appear with "Allow" and "Don't Allow". A request fired on its own when the page loads is simply ignored.
It is a sensible rule, and frankly it is good practice everywhere: ask when the reader has just shown interest, not the moment they land.
Regular Safari shows no prompt
This is where most of the confusion starts. When a reader visits your site in Safari on their iPhone, the way they normally would, there is no permission prompt. It is not being blocked or hidden. In an ordinary browser tab, the system just does not give the site a way to ask for notifications.
So if your stats show very few subscribers from iPhone, that is not an installation problem. It is exactly how it is supposed to behave.
What about Chrome, Firefox and Edge on iPhone?
It pays to be careful here, because Apple has changed this ground more than once. The solid part is this: on iPhone and iPad, third party browsers use Safari's engine (WebKit), as Apple's rules require. They look different and they sync your bookmarks, but underneath, the page is rendered by the same engine.
In practice that means the notification rules are the same. Opening a site in Chrome on iPhone does not unlock a prompt that Safari lacks. The route still goes through the Home Screen. Since iOS 16.4, Apple also lets third party browsers add sites to the Home Screen, but whether and how each browser offers that option depends on its version, and it can change.
In recent years some regions (the European Union, for example) have relaxed the rules on alternative browser engines by law. In practice, though, web notifications on iPhone still work the way described here: a web app added to the Home Screen, with permission requested after a tap. When you explain it to readers, the simplest route is to point them to Safari, where the steps are clearest and best documented.
Safari on Mac: no problem
On the Mac, things are much simpler. Safari has supported standard web push since version 16.1, on macOS Ventura and also on updated Monterey and Big Sur, using the same technology as Chrome, Edge and Firefox. The reader visits the site, sees the permission request (after a click, which is what almost every browser expects nowadays), accepts, and notifications land in the Mac's Notification Center like those from any other app.
No Home Screen, no web app: on a Mac, your site behaves just like it does in Chrome on a Windows PC. If part of your audience reads on a Mac, you reach them the normal way.
What the reader sees on iPhone
Once the reader has gone through every step, the experience is good. Notifications from a web app behave like those from an installed app: they show up on the lock screen and in Notification Center with the site's icon, they respect the Focus modes set on the phone, and the reader finds the web app by name under Notifications in the phone's Settings, where they can silence it or switch it off.
Tapping the notification opens the web app, not Safari, on the page linked in the push.
There are a few differences worth keeping in mind, none of them dramatic:
- The title is still what matters most. As on every phone, the text gets cut off early. The rules for writing push titles people click apply here too, maybe even more.
- A large image may not appear the way it does on Android. Every push should work with just a title and a line of text.
- If the reader removes the icon from the Home Screen, the web app goes away and, as a rule, its notification subscription goes with it. From then on the device gets nothing, and sooner or later that subscriber shows up as no longer valid.
How to explain "Add to Home Screen" to your iPhone readers
If your site has a loyal audience reading on iPhone, it is worth walking them through the steps. Not everyone will bother, but the ones who do tend to be your most committed readers. You can put these instructions on a dedicated page, in a box at the end of your articles, or in a newsletter.
Here is a step by step text you can adapt:
- Open the site in Safari on your iPhone.
- Tap the Share button, the icon with a square and an arrow pointing up. Depending on your iOS version, it sits in the bottom bar or inside the menu with three dots.
- Scroll through the list of actions and tap "Add to Home Screen". If you don't see it right away, scroll down: sometimes it is further along.
- Check the name that will appear under the icon and tap "Add". If there is an option to open the site as a web app, leave it switched on.
- Go back to your Home Screen and open the site from the new icon, not from Safari.
- Tap the button to turn on notifications and, when iOS asks, choose "Allow".
Two tips make this text work better. First, explain the why before the how. "On iPhone, getting our breaking news takes one extra step" lands better than a bare list of instructions. Second, don't push it. Showing these steps on every visit to every iPhone reader turns an invitation into an annoyance. One well made page, linked where it helps, does the job.
Keep in mind that step 6 only works if the web app contains a button that asks for permission when tapped. If your site fires an automatic request on page load, nothing will appear on iPhone: readers need something they can tap.
Why most subscribers will still come from Android and desktop
Even with the best instructions, the share of subscribers on iPhone will stay lower than your iPhone traffic might suggest. That is not a failure, it is the arithmetic of the route: between a reader arriving from a link and a reader receiving notifications there are five or six steps, and every step loses some people.
On Android, the route is a single tap: the reader sees the request in the browser, accepts, and starts getting notifications. The same goes for desktop, with Chrome, Edge, Firefox and Safari on Mac. That is why, for the vast majority of sites, a push audience is made up mostly of Android and desktop readers.
What that means in practice:
- Don't size your potential on total traffic. Say half your visitors arrive on iPhone: that half will add relatively few subscribers, and that is normal.
- Look at your stats by device and browser, not just the total. They tell you where your audience actually comes from.
- Don't compare your opt-in rate with a site whose readers are different. A site read mostly on iPhone will have a lower overall rate than one read mostly on Android, all else being equal.
Web push is still worth switching on even with a heavily iPhone audience: it reaches everyone else, and your most loyal iPhone readers can come in through the Home Screen door.
The alternative: a native app
If most of your audience is on iPhone and notifications are central to what you do, sooner or later someone suggests a native app. It is a real option, with benefits and costs you should weigh calmly.
The benefits. A native iPhone app asks for notification permission directly, with no Home Screen step. It can offer features a website can't, and it gets a listing in the App Store.
The costs. An app has to be designed, built and, above all, maintained, usually on two platforms (iOS and Android). There are developer program memberships, store review for every update, publishing delays, and forced updates whenever the operating systems change. For a small publisher or a blog, that is a project measured in months and a cost that keeps running, not a one time expense.
The underlying problem. A native app has its own extra step: the reader has to download it. People unwilling to add a site to their Home Screen are often just as unwilling to install an app. An app solves the permission problem, not the attention problem.
That is why many sites take a middle path: web push for everyone (reaching Android, desktop and the iPhone users who take the extra step), and an app only when the audience and the business model genuinely justify it. If you are comparing tools, there is a guide on how to choose a web push platform.
What Natom does on iPhone
On iPhone, Natom has the same limits as every other web push platform: these are iOS rules, not choices made by whoever sends the notifications. Anyone promising to reach every iPhone without the Home Screen step is promising something the system does not allow.
Within those limits, Natom sends pushes with high priority, which on Android means they arrive even when the screen is off, and with a delivery window: if a device is off or offline, the notification is delivered when it comes back online, within the time you set. It is the same standard technology browsers use, built on Google's Firebase Cloud Messaging.
Natom's statistics break subscribers down by browser and device, so you know how much of your audience comes from iPhone instead of guessing. Subscriptions are also rechecked and the ones no longer valid are removed: what you pay for is the count of active subscribers.
Everything else (the prompt, the service worker, audiences) is covered in the documentation. The piece that makes notifications possible, on iPhone too, is the service worker, and there is a plain English guide if you want to understand it.
Frequently asked questions
Does web push work on every iPhone? It works on iPhone and iPad running iOS or iPadOS 16.4 or later, and only for sites the reader has added to the Home Screen and allowed notifications from. Devices on older versions are not supported.
Why is there no notification prompt on iPhone? Because in an ordinary Safari tab, or in any other browser on iPhone, the system does not let websites ask for notifications. The request is only possible inside the web app opened from its Home Screen icon, and only after the reader taps something.
Does it make a difference if the reader uses Chrome on iPhone? For notifications, in practice, no. On iPhone, third party browsers use Safari's engine and follow the same rules. When you explain the steps to readers, pointing them to Safari keeps things clearest.
Do Mac users with Safari need to add the site anywhere? No. With Safari 16.1 or later (macOS Big Sur, Monterey, Ventura and newer), web push works like it does in any desktop browser: the reader accepts the request and gets notifications.
Can a web push platform get around the iOS limit? No. It is an operating system rule and it applies to every platform, Natom included. All you can do is explain the Home Screen step clearly to your readers.
Is a native app worth it to reach iPhone users? It depends on your audience and your budget. An app skips the Home Screen step but takes time and money to build and maintain, and readers still have to download it. For many sites, web push for everyone plus a clear invitation to iPhone readers is the most sensible place to start.