A progressive web app (PWA) is a web application that uses modern browser capabilities, chiefly service workers and a web app manifest, to behave like an installed native app. You tap a link, and the thing that opens looks like an app, works offline, and sits on your home screen afterwards, yet you never visited a store or accepted an install. Think of a native app as a shop that asks you to fill in a membership form at the door. A PWA is the same shop with the door already open.
But it is not always the right call. Apple's support for installed web apps lags Google's, hardware access is narrower than native, and neither app store lists a PWA by default. So the question is not whether PWAs work, but when one is right for your business, which is what the rest of this covers: what a PWA does, what it costs, where it stops, and how to decide.
The web platform view of what a PWA is, and the standards behind it, are documented by MDN Web Docs and Google's web.dev PWA learning path.
Mobile apps matter because they let you build something more convenient and more personal than a web page usually manages. There are three broad ways to build one.
Native apps are built for a specific platform. They run in that platform's own language, iOS in Swift and Android in Kotlin, and they reach every feature of that platform. Two platforms mean two codebases.
Hybrid apps combine native code with web code, so one codebase ships to several platforms inside a native shell. Depending on the framework and the plugins available, hybrid apps may not reach every platform-specific feature, so check push notifications and hardware access such as GPS or camera against your requirements before you commit.
Progressive web apps are websites built with modern web technologies that users can install to the home screen and use offline. They are not as powerful as native apps. They do deliver many of the same benefits from one codebase and one deployment pipeline.
Read more about Native app vs Hybrid app vs PWA: the pros and cons. If you want the wider picture first, our ultimate guide to web app development covers the ground this article builds on.
A web application, or web app, is software you reach through a browser such as Chrome, Safari or Firefox. Web applications keep taking ground from traditional desktop software for three unglamorous reasons: they install nothing, they update centrally, and they run anywhere a browser does.
A progressive web app takes that one step further. It uses browser APIs to hold a usable experience together when the connection is slow or gone entirely, and it adapts to the device it lands on rather than assuming a fast phone on a fast network. One build serves every platform, so your features do not fork per operating system.
PWAs also borrow behaviours from mobile applications: push notifications where the platform allows them, offline functionality, installation to the home screen. And because the app is served rather than shipped, users get the current version the moment they open it. No store update to accept, no long tail of people running last quarter's build.
Underneath, a PWA is HTML, CSS and JavaScript, which means it inherits the whole web ecosystem: libraries, tooling, hiring pool, and a deployment process your team already runs. That is the practical reason a PWA gets live faster than a native pair. Not magic. Plumbing you already own.
The bar it has to clear, though, is set by native apps. So what does a good PWA actually need?
Six things separate a PWA from a mobile-friendly website, and every one of them is a decision rather than a setting.
The minimum bar for installability, an HTTPS origin and a valid manifest, is set out in MDN's Making PWAs installable guide. Cross-browser support for service workers is tracked on caniuse.
Less than you would expect. Three of the requirements are technical, two are judgement.
HTTPS, because service workers demand it. Your site has to be served over HTTPS. It protects user data in transit, and browsers will not register a service worker on an insecure origin, so without it there is no PWA. That one is not negotiable.
A service worker, for offline and caching. A service worker is a background script the browser runs separately from your page. It supports offline usage, caches assets and data, and handles background operations, and it can finish work when your PWA is not even open, which is what makes push notifications and background sync possible.
A web app manifest. This JSON file tells the browser how your PWA should look and behave once installed: name, short name, description, icons, theme and background colours, display mode and start URL. It is the thing that turns a tab into an app. MDN keeps a full reference of manifest members, and web.dev has a practical web app manifest walkthrough.
Frameworks and tooling. Any modern JavaScript framework will do, and most now have a documented PWA path: React, Angular, Vue, Svelte, and meta-frameworks such as Next.js, Nuxt and SvelteKit. For the service worker itself, most teams reach for Workbox rather than hand-writing caching strategies. Older guidance naming AngularJS or Polymer is out of date and both are retired, so treat any tutorial that still recommends them as a warning about the rest of its advice.
A first load worth having. That first screen is what users judge you on, so measure it rather than guess. Lighthouse, Google's open-source auditing tool, reports on performance, accessibility, SEO and installability, and it runs in Chrome DevTools against any URL.
One caveat before the numbers, because it changes how much weight they carry. Each result below comes from the company's own engineering write-up, collected in the web.dev case study library, and most were published around 2016 and 2017.
That was a period when PWAs were new and the mobile sites they replaced were frequently bad. So read them as evidence that the pattern can pay off, not as a forecast for your own build. Google's summary of what users want from a mobile experience comes from the same body of work: the FIRE acronym, fast, installable, reliable and engaging.
Business success looks different depending on what you sell, so pick the measure that matches your model. Time on site, bounce rate, conversion rate, returning visitors. And because a PWA ships incrementally, you can launch the features that earn their keep first and add the rest when they do.
Pinterest rebuilt its mobile web experience as a PWA to support international growth. Only 1% of mobile users were converting into sign-ups, logins or app installs, and poor mobile performance was the culprit, so the team started from scratch.
The rebuild produced three results, per Pinterest's own engineering write-up: time spent on mobile web up 40% against the previous version, core interactions up 60%, and a 44% rise in revenue from ads shown against user-generated content, which is how Pinterest monetises the feed.
With more than 80% of its users on mobile, Twitter wanted a mobile web experience that was faster, more reliable and cheaper on data. Twitter Lite became the default mobile web experience for every user globally, built around instant loading, engagement and data reduction.
Twitter's engineering team reported 65% more pages per session, 75% more Tweets sent, and 20% fewer bounces. Twitter Lite loaded within three seconds even on slow connections.
Uber rebuilt its web app as a PWA to offer a booking experience comparable to the native app as the company pushed into new territories. The PWA makes booking work on 2G networks and runs in any modern browser, which reaches riders on lower-end devices that cannot run the native Uber app at all.
Per Uber's engineering write-up, the result was a lightweight web app that loads in three seconds on 2G, regardless of location, network speed or device.
Starbucks built a PWA of its ordering system to match the experience of its native app. Customers browse the menu, customise orders and add items to a cart without a steady connection, then see location-specific pricing and place the order once they are back online.
Because so much of it works offline, it suits customers who move in and out of connectivity through the day. The app is under 0.15 MB, and Starbucks reported that since launch it has doubled daily active users, with desktop orders arriving at close to the rate of mobile browsers.
Trivago, one of the largest hotel search engines, invested in a PWA for a steadier mobile experience. The team prioritised offline access, push notifications and add-to-home-screen, judging those the most valuable to their users.
Trivago's reported figures: add-to-home-screen actions up 150%, and a 97% increase in click-outs, the clicks that send a user through to a hotel's own offer and earn Trivago its revenue. Users who lose connection can carry on browsing, and 67% do exactly that once they are back online.
The original figures for these five come from each company's engineering write-ups, gathered in Google's web.dev case study library. Treat them as period evidence rather than current benchmarks.
Strip out the marketing and three benefits do all the work.
One codebase, several platforms. A PWA runs on any web-enabled device and browser, so you build and maintain one thing instead of a web app plus an iOS app plus an Android app. That is where the saving comes from, and it compounds: every feature, every fix, every security patch ships once.
App behaviours without the door. Offline access, push notifications where the platform supports them, low data usage and home-screen installation are all available to a web app now. Twitter Lite's 20% drop in bounces and Trivago's 150% rise in installs are the same benefit measured two ways. People who would never have filled in the membership form still end up pinning the shop to their home screen.
Faster to ship, cheaper to keep. Web APIs and existing tooling let a team put a customer-facing service live without building separate mobile and desktop applications, and there is one deployment path instead of two store review queues. Maintenance is lighter for the same structural reason: fewer codebases, fewer pipelines, no version fragmentation across users who never updated.
One caveat belongs with all three. A PWA fits when your requirements sit inside what the browser can do, and when they do not, none of the above rescues it.
The engagement percentages above are the easy part of the business case. The next four questions are the rest of it, and they are the ones worth taking into a decision.
Build cost. The honest answer is a range, not a figure, and it turns on scope rather than on technology. The structural point is simple: a PWA is one codebase where native is two, so you are comparing one build against two, plus the design and back-end work you pay for either way. Get a scoped estimate before you plan against a number.
Time to first release. A PWA goes live when you deploy it. No store submission, no review queue, which removes both the wait before launch and the drag on every update after it. For a team shipping weekly, that alone often settles the argument.
Maintenance. One codebase, one pipeline, one version in the field. Native means two codebases tracking two operating systems on their own release schedules, plus a long tail of users on old builds you still have to support. A PWA is not free of upkeep, mind: browser support shifts, and caching logic needs revisiting as the app changes.
Risk, first on the platform. Apple's support for installed web apps has historically trailed Google's, and it once wobbled hard: in early 2024 Apple briefly removed Home Screen web apps for EU users to comply with the Digital Markets Act, then reversed within weeks after the backlash. That episode is settled now, and the direction since has been steadily forward. Push notifications have worked on installed PWAs since iOS 16.4, and as of iOS 26 any site added to the Home Screen opens as a web app by default, which removes a step users used to have to know about. What has not moved is the harder stuff. Hardware and OS access is still narrower than native, so Bluetooth, background sync, deep OS integration and some sensors may simply be out of reach, and iOS can evict a PWA's cached data after long disuse. If a large share of your users are on iOS, test your critical features on current Safari before you commit.
Risk, then on distribution and exit. Neither app store lists a PWA by default, so if store presence is part of your acquisition plan you need a separate route to it. And if you later discover you need native after all, you are funding a second build rather than extending the first.
Apple documents the current position on Home Screen web apps in the EU in its DMA and apps in the EU developer Q&A, and the arrival of iOS web push is described on the WebKit blog.
We ask the same four questions on every project where a PWA is on the table. They resolve most of these decisions in a single conversation.
Where do your users come from? If it is search, ads or a shared link, a PWA keeps the whole journey on the web with nothing to install. If they arrive through the app stores, that argument evaporates.
What does the app need from the device? List the hardware and OS features you cannot ship without, then check each one against browser support on the platforms your users actually hold. One unavoidable gap decides this on its own.
What does offline have to do? "Works offline" covers everything from showing cached content to queueing transactions for later. The harder your answer, the more of the build goes into the service worker.
What happens in 18 months? If the roadmap heads towards features only native can deliver, building the PWA first may still be right, as long as you are choosing to pay for both rather than discovering it later. Sometimes native is simply the honest answer from day one. When we built Jinga Life, a digital family health platform, the requirements pointed at iOS from the start, so that is what we built, rather than forcing a web app to do a job it was not suited to. The point of the four questions is not to talk you into a PWA. It is to tell you which of the two you actually need.
Answer those four and the choice usually makes itself. Where it genuinely does not, the split path is legitimate: ship the PWA, learn from real usage, go native later for the parts that need it.
Three things separate a PWA that holds up from one that only works on your desk.
Yes, and better than the reputation suggests. Safari supports service workers, offline caching and add-to-home-screen, so the core of a PWA works on iPhone and iPad. Push notifications have been available to installed PWAs since iOS 16.4, and from iOS 26 a site saved to the Home Screen opens as its own app by default rather than as a browser shortcut.
The caveats are about depth, not whether it runs at all. There is still no automatic install prompt on iOS the way there is on Android, so the user has to tap Share and then Add to Home Screen, and it is worth designing that nudge rather than assuming people will find it. Push only fires once the app is installed and permission is granted, so it cannot re-engage someone who never installed. And background sync, most Bluetooth and sensor work, and persistent large-scale storage are either absent or unreliable. If a meaningful share of your users are on iOS, test your specific must-have features on current Safari before you plan around them. Apple's developer Q&A on EU apps is the place to confirm the latest position.
The difference comes from the number of codebases, not from the technology. A PWA is one build serving every platform, where matching it natively means an iOS app and an Android app, each with its own release cycle and its own maintenance. Design and back-end work cost roughly the same either way. Ask for a scoped estimate against your own feature list rather than working from a published average.
Not by default. A PWA is distributed through the web, so users find it by search, link or ad rather than by browsing a store. If store presence matters to you, you can wrap the app for listing: on Android through a Trusted Web Activity, Google's mechanism for shipping a PWA inside a thin native package, and on iOS through a native wrapper, a minimal native app whose only job is to display your web app. Either route adds a build and a review process you did not otherwise have.
Yes. The technologies underneath them, service workers, the web app manifest and the install prompt, are standard parts of the platform now rather than an experiment, and the frameworks most teams already use support them directly. What has changed is the framing. A PWA is no longer a separate category of product, it is a set of capabilities you switch on for a web app when they earn their place.
Anything that needs deep access to the device or the operating system. Background location, most Bluetooth and sensor work, tight integration with system features, and anything requiring an always-running background process are either unavailable or unevenly supported. Availability differs by browser and platform, so decide against your own list of requirements, checking each against MDN's PWA reference, rather than a general answer.
It depends on scope, but two things reliably shorten it against native: one codebase to build, and no store review before release. If you already have a well-built web app, adding a service worker, a manifest and an offline strategy is a focused piece of work rather than a rebuild. If the existing app is the problem, as it was for Pinterest, then you are looking at a rebuild and the timeline is the rebuild's.
Here is the whole thing in one line. A progressive web app is right when your requirements fit what the browser can do, your users arrive from the web, and you would rather maintain one codebase than two. It is wrong when a feature you cannot ship without lives in the operating system, or when the app stores are your distribution. Leave the door open when you can. Fit the membership form when you have to.
We have built both, from web apps that install to the home screen to native products like Jinga Life, so the recommendation you get is the one your project needs. Have a look at how we approach web development and mobile development, or get in touch and we will walk your requirements through the four questions above.
Alexandra Mendes is a Senior Growth Specialist at Imaginary Cloud with 3+ years of experience writing about software development, AI, and digital transformation. After completing a frontend development course, Alexandra picked up some hands-on coding skills and now works closely with technical teams. Passionate about how new technologies shape business and society, Alexandra enjoys turning complex topics into clear, helpful content for decision-makers.
Inês Silva is a Project Manager with over four years of experience writing about software delivery, agile methodologies, and tech leadership. Because she started her career as a developer, Inês brings a real, deeply technical understanding to the management side of things. She loves bridging the gap between big-picture business strategy and day-to-day engineering execution, and she's passionate about sharing practical tips that help teams collaborate better and ship great products.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
