Progressive Web Apps: When a PWA Beats a Native App

Progressive web app development is the option most UK buyers dismiss in the first ten minutes of a project and rediscover eighteen months later, once the second native codebase has quietly eaten the budget. It gets dismissed because almost everything written about it falls into one of two camps: advocacy that skips the parts iOS refuses to do, or scepticism inherited from 2019, when the platform genuinely could not do them.

Both are wrong now, and wrong in ways that change the arithmetic. Safari has supported push notifications in Home Screen web apps since iOS 16.4. Chrome dropped the service worker requirement for installation. The UK regulator designated Apple and Google as having strategic market status over their mobile browsers and browser engines in October 2025. At the same time iOS still refuses background execution, evicts stored data under rules you do not control, and will never list a web app in the App Store.

What follows is the version I would give a client choosing between one codebase and three. Every capability claim below was checked against the vendor’s own documentation in September 2026, because this is a subject where the received wisdom is reliably two years out of date.

When does a PWA beat a native app? When your users are on Android and desktop as much as on iPhone, when the app is a front end to a server rather than to the device, and when people find you through search rather than through a store. A PWA loses when you need background location, home screen widgets, Bluetooth on iPhone, or store billing. The saving is one codebase instead of three, which in UK terms is roughly £40,000 to £120,000 of build and a materially smaller bill every year afterwards.

What a Progressive Web App Actually Is

The term gets used loosely enough that two people in the same meeting can mean different things. The technical definition is narrow and worth holding to.

MDN describes a progressive web app as an app built with web platform technologies that gives a user experience like a platform specific app. It runs on multiple platforms from one codebase, and it can be installed, run offline, and integrate with the operating system.

In practice that means three artefacts, and a site that lacks any one of them is a website with ambitions rather than a PWA.

The web app manifest

The manifest is a JSON file that tells the operating system what the app is called, which icons to use, which URL to open on launch, and whether to run in a browser frame or standalone. Without it the browser has nothing to install. It is small, it is static, and it is the cheapest part of the whole exercise.

The service worker

A service worker is a script that runs separately from the page, sits between the app and the network, and can answer requests from a cache. It is what makes offline behaviour possible and what receives push messages. It is also the part that goes wrong, because a badly scoped cache serves stale code to users for weeks.

HTTPS

Service workers, push, geolocation and camera access are all restricted to secure contexts. On modern hosting this is free and automatic, so it is a constraint rather than a cost.

What “Installed” Means, Platform by Platform

Buyers assume installation is one behaviour. It is three, and the differences are commercially relevant.

Android

Chrome on Android gives the closest thing to parity. The app gets a home screen icon, its own entry in the app switcher, its own storage, and it can be listed in the Play Store through a wrapper. Install prompts can be triggered from your own UI once the browser has fired the relevant event, so you control the moment you ask.

iOS and iPadOS

Safari installs through the Share sheet and the “Add to Home Screen” item. There is no in page install prompt you can trigger, no banner Apple will show on your behalf, and no way to detect reliably that a user has done it. That single interaction gap is the largest practical difference between platforms, and it is a design problem rather than an engineering one: you have to teach the user a gesture.

Desktop

Chrome, Edge and Safari on macOS all install web apps into the dock or taskbar with their own window. Desktop is where PWAs are least controversial and most underused, particularly for internal tools where the alternative is an Electron build nobody wants to maintain.

Chrome Changed the Installability Rules and Most Guides Did Not Notice

For years every article repeated the same checklist: manifest, icons, HTTPS, and a service worker with a fetch handler. That last item is no longer true for the menu install path.

Google removed the requirement for a service worker implementing fetch for installation from the menu, in version 108 on mobile and 112 on desktop, and now supplies a default offline page for sites that do not provide their own. The install prompt algorithm still wants a fetch handler, but installability itself no longer depends on one.

The knock on effect reached tooling. Lighthouse removed its PWA category entirely in version 12.0.0, released in April 2024, because those audits existed to test criteria that no longer applied. If your build pipeline still fails on a missing PWA score, it is testing something Google retired.

The practical reading is that installation and offline capability have been decoupled. You can ship an installable app with no offline story at all, which is often the right first release, and add caching once you know which screens people actually use without signal.

Offline Is a Design Decision With a Cost

The word “offline” hides an enormous range of scope. A cached shell that shows the last known data is a week of work. A genuinely offline first app that queues writes, resolves conflicts and reconciles on reconnect is a different product.

Caching strategies

Service worker caching comes down to four patterns and a decision per resource type. Cache first serves the stored copy and never checks, which is right for fonts and hashed build assets. Network first tries the server and falls back, which suits data that must be current. Stale while revalidate serves the cache instantly and refreshes in the background, which is the usual choice for content. Network only is what you use for anything that must not be answered from a stale copy, such as payments.

Getting this wrong is the most common PWA failure I see. A cache first policy applied to your application shell will serve last month’s JavaScript to returning users until something forces an update, and the bug reports will describe symptoms that do not exist in your current code.

Background sync

Queuing writes while offline and flushing them when connectivity returns is what the Background Synchronization API is for. MDN lists it as limited availability and explicitly not Baseline, meaning it does not work in some of the most widely used browsers.

So on iOS you write the fallback yourself: persist the queue in IndexedDB, and flush it the next time the app is opened. That works, users accept it, and it is perhaps three to five days of engineering rather than the afternoon the API would have cost.

Push Notifications Decide More Projects Than Anything Else

If a single capability sinks a PWA proposal, it is this one, usually on facts that were true in 2022.

Android and desktop

Web push on Android Chrome, desktop Chrome, Edge and Firefox has worked for years through the Push API, the Notifications API and a service worker acting together. Delivery is handled by the browser vendor’s push service, permission is a standard prompt, and there is no meaningful gap against a native app for the common case of a server sending a message to a subscribed user.

iOS and iPadOS

Apple added Web Push in iOS and iPadOS 16.4. The condition attached to it is the part that gets missed: WebKit states that the web app must be added to the Home Screen, and permission must be requested in response to direct user interaction such as a tap on a subscribe button. Web push does not work for a site sitting in a Safari tab.

The manifest must set display to standalone or fullscreen, and notifications then behave like any other app’s: lock screen, Notification Centre, paired Apple Watch, and per app control in Settings. Badging works too.

Apple later added a simpler path. Declarative Web Push arrived in Safari 18.4, available on iOS and iPadOS 18.4 for web apps added to the Home Screen, and it displays a notification from a standardised JSON payload without needing a service worker to be running. It removes work. It does not remove the Home Screen requirement.

The iOS Gap, Stated Precisely

The gap is real and it is smaller than its reputation. Stating it accurately is more useful than either complaining about it or pretending it closed.

Storage eviction

WebKit evicts website data on a least recently used basis, where last use is measured from the last user interaction or storage operation. Its storage policy documentation sets an origin quota of up to 60% of disk for browser apps and up to 15% for other apps, with overall quotas of 80% and 20% respectively, and confirms that a standalone Home Screen web app gets the same quotas as the browser.

Two things follow. Storage is not the constraint people imagine, and eviction is a scheduling risk rather than a capacity one. Treat the device as a cache and the server as the record, and eviction stops being a product defect.

Background execution

There is no equivalent of a native background task on iOS. No periodic fetch, no background location, no silent processing while the app is closed. Anything that must happen on a schedule happens on your server, and reaches the device through a push message that the user sees.

No presence in the App Store

A PWA cannot be listed in the App Store. If a meaningful share of your customers expect to search the store for your brand and find you there, that is not an engineering problem you can solve on the web at all.

Browser Engines, the DMA and the CMA

This is the part where reporting outruns the primary sources, so it is worth being narrow about what is actually documented.

Apple now permits alternative browser engines, and it is explicit that this applies in the European Union only, on iOS 17.4 or later and iPadOS 18 or later, through two entitlements granted to developers who meet published security, privacy and test suite criteria. Apple requires 90% of Web Platform Tests and 80% of Test262 to pass, operation without JIT, and most vulnerabilities resolved within 30 days.

For a UK business, nothing in that changes anything today. The entitlements are jurisdictional, and a British user on a British carrier is running WebKit whichever browser icon they tapped.

The UK position is moving separately. On 22 October 2025 the CMA designated Apple and Google as having strategic market status in their mobile platforms, covering operating systems, app distribution, browsers and browser engines, for a period of five years. Designation is the power to impose conduct requirements, not the requirements themselves. Plan for the platform as it behaves today and treat any loosening as upside.

Hardware and Device APIs, Verified Rather Than Assumed

“The web cannot access hardware” is the objection I hear most and the one that is most often wrong in a specific case.

What works essentially everywhere

Camera and microphone access through getUserMedia is Baseline on MDN and has worked across browsers since 2017. Geolocation, device orientation, file uploads including camera capture on mobile, clipboard access, the Web Share API on mobile, and passkeys through WebAuthn with Face ID or a fingerprint as the authenticator all work across current mobile browsers. Barcode and QR scanning through the camera stream is routine.

For the large majority of business apps, that list is the whole hardware requirement.

What is Chromium only, and effectively Android only on mobile

Web Bluetooth is documented by Google as available on ChromeOS, Chrome for Android 6.0, macOS from Chrome 56 and Windows 10 from Chrome 70, with no iOS support listed, and MDN marks it as limited availability rather than Baseline. Web NFC is narrower still: Google documents it as available on Android in Chrome 89.

The File System Access API for reading and writing user chosen files is likewise Chromium territory, though the origin private file system covers most app internal storage needs across browsers.

App Store Distribution Is a Commercial Question, Not a Technical One

Teams argue about store distribution as if it were about capability. It is about four commercial variables, and only one of them favours the store unambiguously.

Discovery is the honest advantage. Consumers do search the App Store and Play by brand and by category, and a business with no store presence forfeits that channel. It matters enormously for a consumer product with a recognisable name and very little for a tool used by 200 employees of one company.

Trust is real and asymmetric by audience. Older and less technical users read a store listing as a safety signal. Younger users increasingly do not, and the same user will happily use a bank’s website on the same phone.

Against that, a store adds a review queue between you and your users, a rejection risk on rules that change, and a commission on anything you sell inside the app. A PWA has none of those. You deploy when you decide to deploy, and a critical fix reaches every user on their next load rather than after a review.

What the Stores Actually Charge

The commission numbers move often enough that recalling them is unwise. These are the vendors’ own published terms, checked in September 2026.

Apple charges 30% as the standard commission on digital goods and services. The App Store Small Business Program reduces that to 15% for developers with up to $1,000,000 USD in proceeds in the prior calendar year, with new developers eligible, and the standard rate resuming on future sales once you pass the threshold in a year.

Google publishes a tiered service fee for Google Play: 15% on the first $1M USD of developer revenue each year, 30% above it, and 15% on auto renewing subscriptions regardless of revenue. The same page sets out a different structure taking effect on 30 June 2026 for the EEA, the UK and the US, based on 10% or 20% plus a 5% billing fee depending on whether the install is new or existing.

Both vendors publish in USD. Selling a £9.99 monthly subscription through a store at 15% costs about £18 a year per subscriber, and at 30% about £36. Multiply by your subscriber count before deciding the store is free.

You Can Still Ship a PWA Through Google Play

Android gives you both options at once, which is a genuine asymmetry in the platform comparison and it is rarely mentioned.

A Trusted Web Activity is an Android app that opens your own PWA full screen with no browser chrome, verified as yours through Digital Asset Links. It requires Chrome on Android 72 or above, and the host app has no access to the web content’s cookies or storage. In practice it is a thin wrapper generated from your manifest and submitted to Play like any other app.

So on Android the choice is not store or web. You publish the PWA, wrap it, and get the store listing as well, from the same codebase, for a few days of packaging work and the annual developer account fee.

There is no equivalent on iOS. Apple’s review guidelines have long treated a wrapper around a website as insufficient on its own, so the iOS store route means building something genuinely native. That asymmetry, more than any API gap, is what shapes the cost table below.

Progressive Web App Development Cost Against Two Native Codebases

The comparison people run is build cost, which is the smaller half. The comparison that decides the outcome is total cost over three years, because native’s expense is recurring.

Read those as UK agency bands for a mid complexity business app, not a quote. A PWA of this shape is typically one team of two or three engineers for three to five months. Two native codebases plus a web presence is three teams, three release processes and three sets of platform upgrades every year.

The gap between the first and third rows, roughly £75,000 to £175,000 in build and £27,000 to £60,000 a year afterwards, is what you are buying when you buy native. Sometimes that is money well spent. It should be a decision, not a default. Our website development and software development pages set out how we scope both routes.

Where the Maintenance Money Actually Goes

Build cost gets negotiated. Maintenance cost gets discovered, and it is where multi codebase projects fail quietly rather than loudly.

Native platforms force work on you every year. New OS majors deprecate APIs, signing and provisioning changes, minimum SDK levels rise, and store policies add requirements such as privacy manifests and data safety declarations. None of that ships a feature. On two platforms you pay it twice, on a schedule set by somebody else.

Then there is drift. Two codebases implementing the same feature diverge, and the divergence surfaces as support tickets that reproduce on one platform only. Every product decision has to be made twice and reconciled, and the coordination cost is not visible on any invoice.

A PWA replaces all of that with browser evolution, which is continuous, backwards compatible and almost never breaks working code. The recurring work is your own dependency updates, security patching and hosting, which is the same maintenance any custom web application already needs.

The comparison that matters is not two figures on a proposal. It is one team against three, every year, for as long as the product lives.

Performance and Core Web Vitals for a PWA

An installed app is judged against native, so the performance bar is higher than for a website, not lower. The good news is that the metrics are public and the thresholds are fixed.

Core Web Vitals currently consists of three metrics, each assessed at the 75th percentile of page loads and segmented across mobile and desktop. Largest Contentful Paint is good at 2.5 seconds or less and poor above 4.0. Interaction to Next Paint, which replaced First Input Delay when it became stable in 2024, is good at 200 milliseconds or less and poor above 500. Cumulative Layout Shift is good at 0.1 or less and poor above 0.25.

A PWA has one structural advantage here. A service worker serving the shell from cache makes repeat visits close to instant, which is precisely the pattern an installed app produces, so real user data on an installed PWA usually looks better than the same code visited cold in a browser.

It also has one structural risk. Single page frameworks push work to the client, and INP is the metric that punishes it. If you are already fighting these numbers, our guide to passing Core Web Vitals covers the diagnosis in more depth than this post can.

SEO Is the Advantage Nobody Prices In

This is the argument I would put first in most commercial cases, and it is almost always left out of the comparison entirely.

A PWA is a website. Every screen has a URL, every URL can be crawled, indexed, linked to and shared, and every one can rank. A native app has none of that. App store listings are indexed shallowly and rank inside a walled garden on entirely different signals, and the content inside the app is invisible to search.

The consequence compounds. Marketing spend on a native app buys installs and stops the day the spend stops. The same spend on content and technical quality for a PWA buys a page that keeps ranking. Over three years that difference frequently exceeds the entire build cost of either route.

It only pays if the implementation is crawlable, which is where client side rendered apps go wrong: rendering everything in JavaScript with one URL and no server rendered HTML forfeits the advantage completely. Server rendering or prerendering the indexable routes is the fix, and a technical SEO audit before launch is far cheaper than discovering after six months that nothing indexed.

The Disqualifying Requirements

The decision is easier as a list of vetoes than as a list of benefits, because the vetoes are objective.

You need native if any of the following is a real requirement rather than a wish. Background location tracking while the app is closed. Home screen widgets, watch apps, or CarPlay and Android Auto integration. Bluetooth or NFC on iPhone. HealthKit, Apple Pay in app, or any deep OS integration Apple has not exposed to the web. Store billing for digital goods, where store policy requires it. Sustained heavy computation, such as real time video processing or 3D rendering at native frame rates. Presence in the App Store as a marketing requirement your business genuinely depends on.

If none of those applies, a PWA is very likely the correct answer, and the burden of proof sits with whoever wants three codebases.

Two more considerations tilt it further. If your users are predominantly on desktop or Android, the iOS gaps affect a minority of your audience. And if the app is a front end to your own server rather than to the device, which describes most business software, the device capabilities barely matter.

Scenario One: Field Service for a Facilities Contractor

Two hundred engineers, job sheets, photographs of completed work, signature capture, patchy signal in plant rooms and basements. This is the case people assume needs native, and it is the one where a PWA wins most clearly.

Every requirement is covered. The camera works through getUserMedia. Signatures are a canvas element. Job data caches in IndexedDB and the write queue flushes on reconnect, hand rolled because Background Sync is not dependable across browsers. Dispatch alerts go out as web push, which works on Android and on iOS for engineers who have added the app to their Home Screen, and installation is a five minute item in induction training rather than a user acquisition problem.

There is no store discovery requirement, because the users are employees. There is no billing, so commission is irrelevant. Devices are mixed Android and iOS, which is exactly the case that punishes two native codebases hardest.

Build one PWA for perhaps £45,000 to £70,000 instead of two native apps at £120,000 to £200,000, deploy fixes the same afternoon rather than through review, and spend the difference on the dispatch backend that actually determines whether the thing works.

Scenario Two: A Salon Chain That Wants Bookings and Reminders

Fourteen branches, consumer facing, appointment booking, reminders, a loyalty scheme, payments taken at the till rather than in the app. The instinct is a native app because competitors have one.

The requirements list is unremarkable: booking forms, a calendar, reminders, an account area. Reminders are the only interesting one, and they are better served by SMS and email than by push in this market, because a customer who books twice a year will not have installed anything.

Discovery is the deciding factor, and it favours the web decisively. People find salons through search and maps, not by browsing an app store, so the pages that describe services and take bookings need to rank. A native app is invisible to that entirely. The cost of the website itself is the real budget line, with the app layer added as installability on top.

Build the booking site properly, make it installable so regulars can keep it on their home screen, and add web push for the minority who opt in. A native build here spends £80,000 or more to reach fewer customers than the website already reaches.

Scenario Three: A Subscription Fitness Product

Guided workouts, video content, a wearable integration, £12.99 a month, direct to consumer, growth funded by paid acquisition. This scenario goes the other way, and it is worth showing why.

Store discovery matters here, because fitness is a browse category and a listing is a genuine acquisition channel. The wearable integration means HealthKit, which the web cannot reach. Background audio and screen wake behaviour during a workout are better on native. Video download for offline use at scale is workable on the web but not comfortable.

Billing is the interesting part. Store commission on £12.99 a month is roughly £23 a year per subscriber at 15% and £47 at 30%, which at 20,000 subscribers is £460,000 to £940,000 a year. That is a strong argument for taking payment on the web and treating the app as a client, which several large subscription products now do.

The answer is native apps for the product and a PWA or standard web app for signup, billing and content marketing. Both exist, and the split is deliberate rather than accidental.

How to Decide in an Afternoon

The decision does not need a discovery phase. It needs four answers, written down.

First, list the device capabilities you genuinely need, then check each one against the vendor’s own documentation rather than against a summary. Most lists shorten dramatically at this step. Second, establish where your users come from: if the answer is search, the web already has the advantage, and if it is store browsing, it does not.

Third, price all three routes over three years rather than one, including the maintenance figures above, and include the store commission on whatever you plan to sell. Fourth, be honest about your team. One codebase maintained by three engineers ships more than three codebases maintained by three engineers, every time.

If the answer is still ambiguous after that, build the PWA first. It is the cheaper option to reverse. Going from a PWA to native later means writing the native clients against an API that already exists and is proven, and going the other way means starting again. That asymmetry is worth more than most of the feature comparisons above.

Where This Leaves You

Progressive web app development is not a compromise for people who cannot afford native, and it is not a universal answer either. It is the right architecture for a defined and large category of products: business software, internal tools, booking and account systems, content products, and anything whose customers arrive through search.

The iOS gaps are real, specific and mostly worked around rather than fatal. Push works if the user installs. Storage is generous but evictable. Background execution does not exist and belongs on your server anyway. Bluetooth and NFC do not work on iPhone, and no amount of engineering changes that.

Mecanik builds both routes and will tell you when the answer is native. If you want the comparison run against your actual requirements rather than a generic list, the website development and software development pages describe how we scope it, and our guide to building a web app in 2026 covers the stack decisions that follow.

Frequently Asked Questions

What is a progressive web app? A progressive web app is an app built with web technologies that behaves like a platform specific app. Technically it is a web application served over HTTPS with a web app manifest describing its name, icons and launch behaviour, plus a service worker that can serve requests from a cache and receive push messages. MDN defines it as software that runs on multiple platforms from one codebase while remaining installable and capable of running offline.

Can a PWA send push notifications on iPhone? Yes, with one condition. Apple added Web Push in iOS and iPadOS 16.4, but WebKit requires that the web app has been added to the Home Screen first, and that permission is requested in response to a direct user interaction such as tapping a subscribe button. Push does not work for a site running in a Safari tab. Declarative Web Push, added in iOS and iPadOS 18.4, simplifies the implementation but keeps the same Home Screen requirement.

How much does progressive web app development cost in the UK? For a mid complexity business app, expect £35,000 to £75,000 to build a single PWA codebase and £8,000 to £20,000 a year to maintain it. The comparable native route of separate iOS and Android apps plus a marketing site runs £110,000 to £250,000 to build and £35,000 to £80,000 a year afterwards. These are UK agency bands rather than quotes, and the recurring difference usually matters more than the build difference.

Can you put a PWA in the App Store or Google Play? Google Play yes, the App Store no. On Android a Trusted Web Activity wraps your PWA in a thin native shell verified through Digital Asset Links, so the same codebase gets a Play listing for a few days of packaging work. Apple has no equivalent and its review guidelines treat a wrapper around a website as insufficient, so an App Store presence means building something genuinely native.

When should you choose a native app over a PWA? Choose native when you need background location while the app is closed, home screen widgets, watch or car integrations, Bluetooth or NFC on iPhone, HealthKit or in app Apple Pay, sustained heavy computation such as real time video processing, or App Store presence as a genuine acquisition channel. If none of those applies, a PWA is very likely correct and the burden of proof sits with whoever wants to maintain three codebases.