PWAs: what they are, why we built ours that way, and when it is worth it

Let me declare it up front so you know what you are reading: I am not neutral on this. Every application in our ecosystem is built this way. LogicInvoice, MS-Finance, Ekkremés, and the ones still in the works. It was not a marketing decision, it was a maintenance one: one codebase, one update, everybody covered. I use them every day from my phone as though they were ordinary apps, so I know both what you gain and where you bang your head.

The problem is not my bias, though. It is that almost every PWA guide you will find is two or three years out of date, telling you to do things that are no longer required while omitting the one thing that will cut your plan in half. Let us sort it out.

What it is, without the grand words

A PWA means a site can be installed on a device like an app. It gets an icon on the Home Screen, opens without an address bar, can send notifications, and usually copes better when the network misbehaves.

It is not a new technology and it is not a separate product. It is your own site plus two or three extra files. That is the appeal: you are not maintaining two things, you are not waiting for approval from any app store, and when you fix something it is fixed for everyone at once.

What Chrome requires today, and what it stopped requiring

Here is the first place the old guides send you down the wrong road.

The current installability criteria are mundane: HTTPS, a manifest with name or short_name, icons at 192 and 512 pixels, a start_url, and display set to one of fullscreen, standalone, minimal-ui or window-controls-overlay. Plus two practical ones: that it is not already installed, and that the user has interacted with the page.

And now the bit you will find wrong everywhere. For years the requirement was a service worker with a fetch handler. Chrome removed it: “we have removed the requirement to have a service worker that implements the fetch() method for installation from the menu, since version 108 on mobile and 112 on Desktop”.

But mind the detail, because this is where even careful people slip. The same page continues: “for now the algorithm that displays the install prompt still requires the presence of a fetch() handler”.

In practical language: without a service worker, your site can be installed if the user asks for it from the browser menu. But the browser will not offer it on its own. Technically you are fine, commercially you are not, because nobody goes hunting through menus. So the service worker is no longer mandatory, but it is what separates “installable” from “actually installed”.

The number that looks like an explosion, and is not

Let us see how many actually do this. The 2025 Web Almanac records service workers on 20.5% of desktop pages and 20.0% of mobile, up from about 1.4% in 2022. A tenfold rise in three years. You would think the web had filled up with apps.

It has not. And the Web Almanac says so itself: the rise is attributed mainly to Google Tag Manager, which registers a service worker on many sites for its own reasons. So the number is not counting PWAs, it is counting service workers.

Here is the number that does count: manifests are on about 9%, and both together on just 3.3% to 3.5%. Three in a hundred. That is where the truth sits, and where the opportunity sits too.

I find it a useful illustration of something broader: a percentage that rises tenfold in three years is always suspect. Somebody usually raised it by accident.

The iPhone, where half the plans collapse

And now the part you need to know before you promise a client notifications.

First, a correction I find in every other article: adding to the Home Screen is not new on iPhone, it has been there since its earliest releases. What arrived with iOS and iPadOS 16.4 was push notifications, not installation.

And they arrived with a condition that changes everything. WebKit puts it plainly: “a web app that has been added to the Home Screen can request permission to receive push notifications”. Which means nothing is received in an ordinary Safari tab. The user must first, of their own accord, add it.

Think about what that means commercially. If half your audience is on iPhone, your notifications reach only those who have already made the effort to install. It is not a channel for acquiring an audience, it is a channel for talking to people who already want you. And that changes entirely who should be using it.

Two more things from the same source, both positive. Permission is requested only after direct user action, so there is no obnoxious pop-up appearing before you have finished reading. And no Apple Developer Program membership is needed: Web Push goes through the same Apple service that powers native notifications.

Where I find it genuinely useful

Let me tell you where it worked for us, and where I would not recommend it.

It works when the same person opens the same tool several times a week. I open Ekkremés ten times a day, so the icon on the Home Screen is not decoration, it is seconds saved every single time. Same with finances: when you want to enter a receipt at a shop counter, you do not open a browser and type an address. And the same goes for invoicing, where the need usually arrives standing up, at the client’s premises, with a phone in one hand.

It is not worth it, and I say this as someone who sells websites, for a page a visitor will see once. Nobody puts on their Home Screen a hotel they booked for one weekend or a shop they bought one cable from. Installing is a commitment, and commitment needs a reason.

There is a middle case people underrate: your client’s own staff. The crew at a workshop, the people on reception, technicians out on the road. There a PWA is almost always the right answer, because the audience is small, known and repeating, and does not justify the cost of two native apps.

What I will not promise you

I will not tell you a PWA replaces a native app. For heavy hardware use, for background work that must run continuously, for deep integration with the operating system, native remains stronger, particularly on iPhone.

And I will not give you a sales uplift percentage, because the ones in circulation are self-reported by the companies that published them, with their own methodology, on their own pages. They may be true and still have nothing to do with you.

What I can say is measurable and humble: the same site, with the same content, becomes an icon in the pocket of the person who needs it, with no second codebase and no app store in the middle.

And a suggestion for how to approach it

If you are considering it, do not start from the technology. Start from one question: who will open this tomorrow, and the day after? If the answer is “the same person”, then it is worth discussing. If the answer is “somebody new each time”, your money goes further on speed and content.

Which brings us back to where we started, to my not being neutral. We built ours this way because we use them ourselves every day, not because it sounds modern. If you want to work out whether your case is one of the ones that justify it, get in touch.