Are progressive web apps dead? The honest 2026 answer

No. And the reason is the opposite of what most articles tell you.

In September 2025 Apple deleted every requirement for installing a website to the iPhone home screen. No manifest file, no service worker, no special settings. WebKit's own words: "there are now zero requirements for 'installability' in Safari." Any website can be opened as an app on an iPhone today.

So progressive web apps are not dead. What died is the marketing cycle around them, and most of the numbers people still quote.

Here is the decision underneath the question, because if you searched this you are probably choosing between a PWA and a native app, not writing a history essay.

The short version

Build a PWA if your product is content, shopping, booking, or a customer account area, and if the phone's own hardware is not part of the job.

Build native if you need Bluetooth, NFC, background location, biometric login inside the app, heavy 3D graphics, or reliable syncing while the app is closed. On iPhone, none of those work in a PWA and Apple has published its reasons for keeping it that way.

Everything else below is the detail behind that call.

What a PWA actually is

A progressive web app is a website that behaves like an app once you add it to your home screen.

It gets its own icon. It opens full screen with no browser bar. It can work with no internet, using a copy of itself saved on the phone. It can send push notifications. And it is still a normal web address, so Google can index it and you can send someone a link to any screen inside it.

That is the whole idea. No download from a store, no review process, no 200 MB install.

What was actually dropped, by whom, and when

A lot of people search a half-remembered sentence about PWA support being dropped. Here is where that comes from, with dates, because three separate things get mashed together.

Firefox removed desktop PWA installs in early 2021. Mozilla deleted its Site Specific Browser feature in the Firefox 86 code cycle and said plainly on the bug ticket: "there is currently no plan for PWA support in Firefox." Most reporting at the time said Firefox 85, because that was the shipping version when the story broke. Mozilla's own ticket says 86.

Then Firefox brought it back. Firefox 143, released 16 September 2025, added web apps again. It is Windows only for now, and Mozilla says macOS and Linux are under consideration. Firefox on Android never lost the feature.

Apple threatened to kill home screen web apps in the EU, then reversed in nine days. In February 2024 Apple said iOS 17.4 would remove home screen web apps for EU users as part of its Digital Markets Act compliance. On 1 March 2024, after pressure from developers and the European Commission, Apple wrote: "We have received requests to continue to offer support for Home Screen web apps in iOS and iPadOS, therefore we will continue to offer the existing Home Screen web apps capability in the EU." That text is still on Apple's developer site.

Microsoft deprecated the old kind of PWA in September 2025. This one gets misread constantly. Microsoft deprecated legacy PWAs built on the retired EdgeHTML engine, alongside Windows 8 era HTML apps. Chromium based PWAs in Edge are the recommended replacement, and Microsoft Store PWA publishing is still live and documented.

Nothing else has been dropped. Chrome has removed no PWA capability, and the direction of travel over the last year has been the opposite: Apple loosened its rules, Firefox reinstated a feature it had killed.

What a PWA can and cannot do, next to a native app

This is the table that should decide it. Everything here reflects iOS 26.6, the version shipping as of late July 2026.

Two rows deserve more than a cell.

Push on iPhone works, with a condition. Apple added web push in iOS 16.4, back in March 2023. The site has to be on the home screen first. Push from a normal Safari tab still does not exist. Since iOS 18.4 in March 2025 there is also declarative push, which delivers a notification without needing a service worker to wake up, so notifications survive Safari cleaning up in the background.

Background sync does not work on iPhone and probably will not soon. Apple's position on the Background Sync API has been open since June 2022 with power and privacy concerns attached, and Periodic Background Sync is a similar story. If your app has to reliably upload things while nobody is looking at it, that is your answer.

Two myths worth killing

"iOS caps a PWA at 50 MB." No. Since Safari 17 the limit is a share of the device's disk, up to 60% for a single site inside the browser, and Apple's documentation says a home screen web app gets exactly the same allowance as the same site in a browser tab. On a modern iPhone that is gigabytes, not megabytes.

"iOS deletes your PWA's data after 7 days." Not for an installed one. Safari's tracking prevention does clear script-writable storage after seven days without interaction, but Apple explicitly exempts the first-party domain of a home screen web app from that rule and has called it a serious bug if it happens. Data can still be cleared under storage pressure, so ask for persistent storage and never treat the phone as the only copy of anything.

Can you put a PWA in the app stores?

Google Play: yes, properly. Trusted Web Activity is Google's sanctioned route. Your PWA runs full screen inside the user's Chrome, verified as yours, wrapped in an Android package. Tooling exists and works.

Apple App Store: possible, not guaranteed. There is no Apple-blessed wrapper. You are shipping a WebView app and arguing your case with a reviewer against guideline 4.2, which says an app "should include features, content, and UI that elevate it beyond a repackaged website." Guideline 4.2.2 rules out anything that is mostly web clippings or a collection of links. PWABuilder, Microsoft's free packaging tool, ships an iOS packager and labels it experimental in its own documentation.

One trap for agencies and their clients: guideline 4.2.6 says apps built from a template or generation service get rejected unless the owner of the content submits them. Whoever owns the brand has to own the developer account.

The cost question, without the invented numbers

Search this topic and you will find "native costs USD 150,000 to 500,000, a PWA costs USD 30,000 to 100,000, you save 70 to 80 percent." We went looking for the source of those figures. There isn't one. The nearest thing is a survey of app development companies pricing their own services, and a widely quoted median that dates back to 2015 and gets a fresh date stamped on it every year.

Ignore the percentages. Here is what actually differs, and every item is real:

• One codebase instead of an iOS app, an Android app, and a website
• No USD 99 a year Apple developer fee
• No waiting on app review to ship a fix
• No store commission on what you sell
• No user stuck on an old version because they never tapped update

That last one is worth more than founders expect. A bug in a native app takes a build, a review, and then weeks of waiting for people to update. A bug in a PWA takes a deploy.

If you want real figures for your own project, our breakdown of what website development actually costs is scoped to Kuwait and the GCC rather than pulled from an American blog post.

What the store commission argument looks like in 2026

The "30% app store tax" line is out of date, and in an interesting direction.

On Apple's US storefront, purchases made through an external link currently carry no Apple commission at all. That came out of the Epic litigation: Apple was found in civil contempt in April 2025 over its 27% external link fee, and while the appeal courts have since allowed Apple to charge something again, the rate is still being fought over. Apple's Small Business Program remains 15% for developers under USD 1 million in proceeds. In the EU, Apple replaced its per-install Core Technology Fee with a 5% Core Technology Commission on 1 January 2026.

Google Play changed more recently and almost nothing online reflects it yet. From 30 June 2026 in the US, UK and EEA, Google split its fee in two. A service fee applies whether or not you use Google's billing, starting at 10% on your first USD 1 million a year and 10% on all recurring subscriptions. A separate 5% billing fee applies only if you use Play's billing system, so linking out avoids it entirely.

So the honest version of the argument is no longer "the stores take 30%." It is that store economics keep changing under you, and the web charges nothing and never changes its mind.

About those famous case studies

Every PWA article quotes the same five brands. They are real measurements, and they are also nine and ten years old.

Pinterest measured a 60% lift in core engagement in 2017. Twitter measured 65% more pages per session in May 2017. Alibaba measured 76% more conversions in November 2016, and Google's own page defines a conversion there as a buyer contacting a supplier, not a sale. Flipkart measured triple the time on site in March 2016.

A few of the numbers that circulate are worse than stale. The Washington Post "88% faster" figure is from Google's AMP case study and has nothing to do with PWAs. The Flipkart "70% more conversions" describes only people who had added the site to their home screen, which is a self-selected group of returning customers. And Starbucks folded its separate PWA into its main site in late 2025, so the offline menu everyone still writes about is no longer there to look at.

Also worth retiring: Gartner's 2017 prediction that PWAs would replace half of consumer-facing apps by 2020. That did not happen. Sensor Tower counted 149 billion app downloads in 2025, up slightly on the year, with USD 167 billion spent inside apps. Downloads have flattened while spending keeps climbing. That is a real argument for the web, and it is the opposite of the one the listicles make.

So, PWA or native?

Ask one question: does your product need the phone, or does it need a screen and a login?

If a customer's job is to browse, book, order, pay, check a balance, or read something, the phone is a screen and a PWA does the job with less to build and nothing to update. If your product needs the hardware, or if being findable in the App Store is genuinely part of your acquisition plan, build native and accept the cost.

There is also a third answer people forget. Ship the PWA first, learn what people actually use, then build native for the parts that earn it. The web version keeps working for everyone who never installs anything, which on most sites is the majority.

If you are still weighing the three options rather than two, we wrote the full comparison of a website, a web app and a mobile app. And if you have already decided you need native, choosing between React Native, Flutter and fully native is the next decision in front of you.

Working out which one you need

If you are sitting on a quote for a native app and wondering whether you need one, the cheapest next step is to write down the five things a customer must be able to do, and mark which of them touch the phone itself rather than the screen. If none of them do, you are looking at a web project with an app icon.

We build both at dsrpt, for clients in Kuwait, the GCC and Australia, and we will tell you when a PWA is enough. Mobile app development is where the native side lives if that is where you land. Either way, start the conversation with the feature list, not the technology.