A progressive web app works by combining three browser technologies, a service worker, a web app manifest, and HTTPS, to make a website behave like a native app. The service worker handles background tasks and offline caching. The manifest tells the device how to display the app on the home screen. HTTPS keeps every interaction secure. No app store required.
Why 'It's Just a Website' Is the Wrong Way to Think About PWAs
A progressive web app is built with the same technologies as any website, HTML, CSS, and JavaScript. But that description is a bit like saying a Tesla is 'just a car.' Technically accurate. Completely misses the point.
What makes a PWA different is not the materials it is built with. It is what those materials are assembled to do: install on a device without an app store, work offline, send push notifications, and load in under a second even on a spotty 3G connection. The gap between a standard website and a PWA is the gap between a brochure and a product.
The three technologies that make this possible, service workers, the web app manifest, and HTTPS, are not complicated once you strip away the technical jargon. If you understand what each one does in plain English, you understand how a PWA works. That is the goal of this article.
If you are still deciding whether a PWA is the right build for your product, the full breakdown lives in our guide to what a progressive web app is. Come back here when you are ready to understand the mechanics.
2.47B Global PWA market value in 2025, projected to reach $34.58B by 2035 Source: Allied Market Research. 30.2% CAGR. 2026 figure estimated at ~$3.14B. |
The Service Worker: Your App's Always-On Personal Assistant
The service worker is the engine behind everything that makes a PWA feel like a native app. It is a background process, a small piece of logic that runs separately from the main app, invisible to the user, doing work on your behalf even when the app is not open. Think of it as a personal assistant who never goes home.
Here is the analogy that makes it click: imagine you have an assistant who memorises your daily coffee order on the first day. Every morning after that, even when the café's ordering system is offline, your assistant can still place your usual order from memory. That is exactly what the service worker does for your app.
What the Service Worker Actually Manages
On a user's first visit, the service worker studies the app, noting which pages, images, and data are used most often, and quietly stores copies of them on the device. From that point forward, those resources load from the device itself rather than travelling across the network.
The practical effect: the app opens instantly on repeat visits, even on a weak connection. If the connection drops entirely, the app still works for everything that was previously cached. A user filling out a form on a shaky train connection can complete it and the service worker will queue the submission and send it the moment connectivity returns, all without the user knowing anything happened.
Push notifications work through the service worker too. Because it runs in the background independently of the app, it can receive a message from the server and surface a notification to the user even when the app is closed. This is the same mechanism that native apps use, PWAs simply access it through the browser rather than through the App Store.
⚡ Service Worker in Practice When Alibaba rebuilt their mobile experience as a PWA, the service worker's caching reduced load time by 36% for returning users. Conversions from iOS increased 76%. The service worker was not a feature, it was the foundation that made every other improvement possible. |
Want to understand what that means for business outcomes? The full case study data is in our article on progressive web app benefits.
The Web App Manifest: Your App's Digital Passport
Every country has a passport format. It tells border control the traveller's name, photo, nationality, and date of birth, enough information to know who they are and how to process them. The web app manifest does the same thing for your PWA, except the border control is the device's operating system and the question being answered is: how should this app appear on this device?
The manifest is a small configuration file that contains the app's name, short name, icons (in multiple sizes for different device screens), the colour the browser toolbar should show, whether the app should open in full screen or with a browser bar visible, and the URL it should open to. None of this is visible to the user in the traditional sense, but they experience every bit of it.
What the Manifest Controls on the Home Screen
When a user taps 'Add to Home Screen' on iOS or sees Chrome's install prompt on Android, the device reads the manifest to build the home screen icon, the splash screen that appears during loading, and the app's entry point. Without a valid manifest, the device cannot complete the installation, it is like trying to check a passenger in without a passport.
The manifest also controls whether the app launches with a browser address bar visible. Set to 'standalone' mode and the app fills the screen like a native app, with no URL bar, no browser chrome, no visual clue that it is technically a website. This is how apps like Twitter Lite and Starbucks's PWA achieve that full-screen, native-app feel.
Once you understand the install experience, you will want to see exactly what it looks like from the user's perspective. The step-by-step walkthrough across iOS, Android, and desktop lives in our guide to how to install a progressive web app at adeocode.com/blog/how-to-install-progressive-web-app.
📋 What Goes into a Manifest Name and short name (what appears under the icon), icons in at least 192px and 512px sizes, background colour and theme colour, display mode (standalone removes the browser bar), and a start URL. That is the minimum. Optional additions include orientation lock, categories for app store listings, and screenshot references for richer install prompts on Android. |
HTTPS: The Secure Envelope That Makes Everything Else Possible
Imagine sending a letter. You could drop it in a standard envelope, unsealed, and hope nobody reads it on the way. Or you could seal it in a tamper-evident security envelope, the kind used for legal documents and bank cards, where any attempt to open it before delivery leaves visible evidence of tampering. HTTPS is the secure envelope. Standard HTTP is the unsealed one.
Progressive web apps require HTTPS. This is not a best practice or a recommendation. It is a hard requirement, browsers will not activate the service worker on an insecure connection, which means no caching, no offline support, no push notifications, and no install prompt. The entire PWA experience depends on HTTPS being in place.
Why Security Unlocks the Rest of the Feature Set
The reasoning is straightforward: a service worker is a powerful intermediary. It sits between the user's browser and the network and can intercept, modify, or redirect requests. That power is only safe to grant when the connection between the server and the browser has been verified as secure. HTTPS provides that verification.
The practical overhead of HTTPS is minimal in 2026. Services like Let's Encrypt provide SSL certificates at no cost, and every major hosting provider automates the setup. If you are building a PWA, HTTPS is a prerequisite that should be configured before anything else, not an afterthought.
For a detailed look at what goes into building a PWA from a cost and effort perspective, our article on progressive web app cost, breaks down the full investment, including infrastructure, build time, and ongoing maintenance.
How the Three Technologies Work Together (The Full Picture)
Individually, a service worker is a caching mechanism, a manifest is a configuration file, and HTTPS is a security protocol. Together, they create an experience that is indistinguishable from a native app for most users, and in some ways better.
The First Visit
A user lands on your PWA for the first time via a Google search, something a native app sitting in the App Store cannot achieve, since app store listings are not indexed for specific content queries. The browser loads the app over HTTPS, confirms the connection is secure, and activates the service worker. The service worker begins caching key assets in the background. The manifest is read, and if Chrome on Android detects that the user has visited twice within a short window, it surfaces an install prompt.
The Return Visit
The user returns. The service worker intercepts the request and serves the cached assets from the device before checking the network for updates. The app appears to open instantly, not because the server responded quickly, but because the server was not consulted at all for the initial load. Any content that has changed since the last visit is fetched and updated quietly in the background.
The Offline Visit
The connection drops. The service worker continues to serve cached pages and content without interruption. The user navigates through sections of the app, reads content, and fills in a form. When connectivity returns, the service worker syncs any queued actions with the server. From the user's perspective, the app just worked.
🔄 The Loop That Builds Loyalty Fast first load from HTTPS-secured delivery. Instant repeat loads from service worker cache. Native-feel home screen presence from the manifest. Push notifications that re-engage users without requiring an app store install. Each layer reinforces the others. This is why PWA adoption correlates so strongly with engagement metrics, the technology itself creates conditions for habitual use. |
If you are comparing this to building separate iOS and Android apps, the economics shift significantly when you factor in one codebase versus two. The full comparison is in our PWA vs native app breakdown.
Is Progressive Web App the Future? What the Market Data Says
The global PWA market was valued at $2.47 billion in 2025. Allied Market Research projects it will reach $34.58 billion by 2035, a compound annual growth rate of 30.2%. At that pace, the 2026 figure is estimated around $3.14 billion. These are not speculative projections from enthusiast publications. They come from the same research infrastructure that enterprise technology buyers use to validate capital allocation decisions.
The adoption curve is already visible in the decisions of large companies. Starbucks launched a PWA in 2017 that now handles 2 million users per week and has driven double-digit increases in daily active users. Twitter Lite runs as a PWA and increased pages per session by 65% while reducing data consumption by 70%. Uber built a PWA that loads in under 3 seconds on 2G networks. These are not experiments, they are production systems running at scale.
What Is Driving Growth in 2026
Three forces are accelerating PWA adoption right now. The first is iOS parity, Apple added meaningful PWA support in Safari across a series of updates, and iOS 17 opened the door for Chrome and Edge to support PWA installs on iPhone for the first time. The second is AI search: Google's Search Generative Experience and ChatGPT's browsing tool both index and surface web content, which gives PWAs a discoverability advantage over native apps that cannot be crawled. The third is cost discipline, companies building for emerging markets where device storage is limited and data costs are high find that PWAs are the only viable format for reaching those users at scale.
What PWAs Still Cannot Do
Honest assessment requires listing the gaps. In 2026, PWAs still cannot access Bluetooth in Safari on iOS, cannot interact with NFC readers on iOS, and cannot integrate with some platform-specific health and fitness APIs that native apps access through HealthKit and Google Fit. If your product requires deep hardware integration, a medical device app, for instance, or a product that relies on reading Bluetooth peripherals, a native app is still the right choice.
For most B2C and B2B SaaS products, however, these gaps do not apply. The question is not 'is PWA better than native' in the abstract, it is whether the capabilities a PWA cannot yet provide are capabilities your users actually need. Our full analysis of where each format wins lives in the PWA vs native app comparison.
30.2% CAGR of the global PWA market through 2035 Market was $2.47B in 2025. Allied Market Research, 2025. |
Is a progressive web app just a website?
What is required for a progressive web app?
Do progressive web apps work without the internet?
Can a PWA send push notifications on iPhone?
Is progressive web app the future of mobile development?
How long does it take to build a progressive web app?
Ninety percent of startups fail. The single most common cause is building a product that nobody needs. The MVP, or Minimum Viable Product, was invented specifically to prevent that outcome by making founders test their assumptions with real users before investing a full development budget in the wrong direction.
But the term has been so stretched by overuse that it now confuses more founders than it helps. Some use "MVP" to describe a clickable Figma prototype. Others use it for a fully polished beta with 50 features. Neither is correct, and the confusion is expensive.
This guide defines exactly what an MVP is, where it came from, what it means across different contexts (business, software development, agile, and project management), what the different types of MVP look like in practice, and how to build one correctly. If you have ever wondered what MVP stands for, when to use it, or what separates a good MVP from a bad one, this is the definitive answer.
You built the MVP. You shipped it. Real users are in the product. Now what? If you're still defining what an MVP actually is or how it should be built, read our MVP vs Prototype vs PoC guide.
This is where most founders freeze. The build phase had a clear goal and a clear end state. The post-MVP phase has neither. There is no delivery date to hit, no backlog to finish, and no obvious next feature to ship. There is only data, users, and a decision you have to make with incomplete information: do you build more, pivot the direction, or shut it down?
The answer is in the metrics, but only if you know which metrics matter. This guide walks through the full post-MVP playbook: how to read your early data, how to make the build-pivot-kill decision, what the post-MVP product stages actually mean (MMP, MLP, MDP, MAP), when scaling is safe and when it destroys you, and how to prioritize what to build next without wasting runway on the wrong things.
Every first-time founder eventually lands on the same trifecta of confusing jargon: proof of concept, prototype, and MVP. Investors ask for one. Developers quote you for another. Blog posts use all three interchangeably, and that creates expensive mistakes.
Skip the PoC when you have genuine technical risk and you end up rebuilding from scratch. Spend $40,000 on a polished prototype when what you needed was a five-line proof of concept and you have burned runway on slides, not signal. Build an MVP before you understand what users actually want and you join the 42% of startups that fail because they built something nobody needed.
This guide draws a sharp, clear line between all three. You will know exactly which stage applies to your situation, what each one costs, how long it takes, and what evidence it produces, so you make one informed decision instead of three expensive ones.
The best SaaS app ideas in 2026 are not new categories, they are underserved niches within existing categories. An AI meeting notes tool for construction site foremen is more buildable, more defensible, and more profitable than another generic AI writing assistant. Every idea in this article passes four tests: there is a specific person who has this problem, they are already paying for a worse solution, the core product can be built in 8 weeks, and the niche is narrow enough to own.