Progressive Web Apps: Transforming the Future of Web Development

Progressive web apps get described as a replacement for native apps. They aren’t, and treating them that way is how businesses end up spending a development budget on something their customers never install.

They are a genuinely useful tool for a narrow set of cases. Here’s what they actually do in 2026, what still doesn’t work, and how to tell whether yours is one of those cases.

What a PWA actually is

A website that uses three browser technologies to behave more like an installed application: a service worker for offline caching and background behaviour, a web app manifest describing how it should appear when installed, and HTTPS.

The practical result is a site that can be added to a phone’s home screen, opens without browser chrome, works offline or on poor connections, and can send push notifications.

It’s still a website. Same URL, same codebase, no app store. That’s the appeal and also the limitation.

What changed between 2023 and now

The case against PWAs used to be simple: iOS didn’t support them properly. That’s substantially less true.

iOS 16.4, in March 2023, brought Web Push support for installed PWAs, along with the Badge API for notification counts on the home screen icon. Safari 18.4 later added Declarative Web Push, a simpler mechanism that doesn’t require a service worker. As of iOS 26, any site added to the Home Screen defaults to opening as a web app even without a manifest file.

So the headline capability gap has narrowed. A well-built PWA on a current iPhone installs, runs standalone, and can notify.

What still doesn’t work on iOS

The gap narrowed. It didn’t close.

Push only works when installed. A PWA open in a Safari tab cannot receive push notifications regardless of permission granted. Apple’s WebKit team has documented this as intentional. Push requires the user to have completed the Add to Home Screen flow.

All iOS browsers use WebKit. Chrome and Firefox on iOS are Safari with different interfaces, so PWA capability on iPhone is entirely at Apple’s discretion regardless of which browser your customer uses.

Storage is capped and evictable. Safari imposes a hard limit on Cache API storage, and cached data can be deleted if device storage runs low or the PWA goes unused for a period. Anything depending on reliable offline data needs to account for that.

Several device APIs are absent. Web Bluetooth and Web NFC aren’t implemented. Biometric authentication isn’t available to PWAs. AR requires native.

No App Store presence. For some businesses that’s a feature. For others it removes a discovery channel and a credibility signal.

There’s also an unresolved situation in the EU, where Apple’s handling of standalone PWA support under the Digital Markets Act has shifted more than once. Reporting on the current state is inconsistent, so if you serve EU users, verify rather than assume.

The problem nobody mentions: installation

This is the one that actually kills PWA projects, and it has nothing to do with capability.

There is no install prompt on iOS Safari. A user has to open the site, tap Share, scroll, and tap Add to Home Screen. Most people never do this, because most people don’t know it exists.

One published estimate puts the reachable push audience for a PWA at roughly ten to fifteen times smaller than an equivalent native app, once the multi-step install process is accounted for. Whatever the precise figure, the direction is clear: install rate is the binding constraint, not technical capability.

If your PWA’s value depends on being installed, you’re building on an assumption that most of your audience won’t fulfil.

Where the UAE differs

One factor genuinely favours PWAs here.

Android holds roughly 81% of the UAE device market against iOS at 18.8%. Since almost every iOS limitation above is an iOS limitation, a Dubai business faces a materially better PWA environment than one in the US or UK, where iOS share is far higher.

Chrome on Android offers install prompts, fuller API support, and no WebKit constraint. Four in five of your users are on the platform where PWAs work properly.

That doesn’t make a PWA correct by default. It does mean the standard objection carries less weight here than the international commentary suggests.

When a PWA is the right call

Four situations where it genuinely earns the build.

Repeat-use tools. Booking systems, account portals, internal dashboards, order tracking. Anything a user returns to weekly has a plausible install case, because the install pays them back.

Field and warehouse use. Offline capability is the strongest PWA argument that has nothing to do with app-store economics. Staff in basements, warehouses, or sites with patchy coverage benefit immediately.

You already need a web application. If you’re building one anyway, PWA capabilities are an incremental addition rather than a separate project. This is the most common sensible case.

Cross-platform on a constrained budget. One codebase across Android, iOS and desktop, with published estimates putting development cost meaningfully below equivalent native builds. Real saving, provided the install constraint doesn’t undermine the whole thing.

When it isn’t

Marketing and brochure sites. A PWA adds service worker complexity to a site nobody will install. What these sites need is speed, and speed comes from build discipline rather than PWA features. Around 49% of the mobile web fails Core Web Vitals, which is the problem worth solving first.

Ecommerce, usually. Tempting because of push notifications, but abandoned-cart push requires installation, and shoppers rarely install a store. Effort is better spent on checkout friction, where average cart abandonment sits at 70.2%.

Anything needing hardware access. Bluetooth, NFC, biometrics, AR. If any of these are core, iOS rules out a PWA.

When the goal is app store presence. A PWA doesn’t give you one. If discovery or credibility depends on being in the store, this is the wrong tool.

Choosing between the three options

	Fast website	PWA	Native app
Best for	Marketing, content, lead generation	Repeat-use tools, offline work	Hardware access, store presence
Install required	No	Yes, for full benefit	Yes
iOS constraints	None	Several	None
App store	No	No	Yes
Relative cost	Lowest	Middle	Highest
Ongoing maintenance	Lowest	Middle	Highest

Most businesses asking us about PWAs turn out to need the first column. Their site is slow, and PWA sounded like a solution to slowness. It isn’t — the fix is a properly built site with a performance budget set during design, which we’ve covered in web design vs development.

How to decide

Four questions.

1. How often does a typical user come back? Under weekly, installation won’t happen.
2. Does anything break without a connection? If not, offline capability is decoration.
3. Do you need hardware features iOS blocks? If yes, PWA is out.
4. Is the real problem that the site is slow? If yes, fix that first and reassess.

If the honest answers point away from a PWA, that’s a useful result. Building one for a use case that doesn’t support it produces a normal website with extra maintenance attached.

For the wider context on how PWAs have actually performed against the predictions made for them, see the future of web design in the UAE.

Frequently asked questions

Trying to work out whether you need a PWA, a web application, or just a faster site? Talk to us. The answer is often the third one.