A Progressive Web App (PWA) is a web app you access through a URL and, on supported devices, can install as an app. Offline tasks and push notifications are possible features that need to be implemented separately. The PWA label doesn’t tell you what your users can do. This guide explains the agreements and trials you need. The custom website guide provides the wider context; app development compares the development options.
What makes a web app a Progressive Web App?
A PWA remains a web application even when you open it through its own icon. Installing it doesn’t turn it into a native app. As MDN’s installation guide explains, a web app manifest defines aspects of its presentation. A service worker isn’t required for every installation.
That distinction matters in practice. A customer may have an icon on their phone while the application still needs a connection to retrieve an order. Assess the task itself. Opening without internet is different from viewing information, changing it and sending those changes correctly later.
How does it differ from a website or native app?
A responsive website adjusts its layout to the screen. That says nothing about installation, storage or notifications. Web applications can gain those capabilities; the boundary between a website and PWA isn’t a rigid list of allowed and prohibited functions.
| Topic | Web app or PWA | App for iOS or Android |
|---|---|---|
| Access | Through a URL; installation depends on browser and setup | Through a chosen distribution route, such as an app store |
| Without a connection | Only tasks with implemented storage and recovery | Offline behaviour must be implemented here too |
| Device functions | Depend on web APIs, browser and permission | Depend on platform APIs, permissions and implementation |
| New version | Web deployment, with attention to caches and open sessions | New release and its associated update process |
| Verification | The browsers and devices in use | The supported platforms and devices |
Don’t choose solely on the basis of one codebase. Cross-platform apps can share code too. The platform needs to fit distribution, use and maintenance. The distinction between web apps, SaaS and custom platforms helps if those terms get mixed up in proposals.
How do installation and push notifications work on iPhone?
Since iOS and iPadOS 16.4, supported third-party browsers can also offer Add to Home Screen. The old claim that this is exclusive to Safari is incorrect. WebKit also describes web push for home-screen apps, with permission requested after a user’s own action in the app. See WebKit’s explanation.
Don’t make notifications an unspoken requirement for an important task. If someone refuses them, it should still be clear where they can find a request or message. Have installation tested on devices your audience uses. A demonstration in the developer’s browser isn’t enough.
Installation differs between browsers and operating systems. Google documents those differences in its PWA guidance. Give users instructions for their own devices rather than promising an identical installation button everywhere.
What does working offline mean in practice?
Offline isn’t a single feature. It might mean viewing previously loaded information, saving a draft or queuing a change to send later. These are different requirements with different ways to fail.
A service worker can handle network requests and use previously saved files. But a cache contains only what has been stored in it, and the chosen caching strategy determines when older or newer data is shown. Opening a form doesn’t mean a server has received its contents.
Consider a hypothetical employee filling in a job sheet on-site, temporarily without reception. The app could keep the sheet as a draft and offer it for submission later. The person commissioning it would need answers to questions such as:
- Which job sheets and attachments are available beforehand?
- How does the user distinguish locally saved information from received information?
- What happens if the office changes the same sheet?
- How is a repeat submission prevented from creating a duplicate job?
- Which data is removed when someone signs out on a shared device?
Ask the developer to demonstrate these situations. You’ll be testing business rules and recovery, rather than just whether an offline icon appears.
Can a PWA always synchronise in the background?
No. The browser manages background tasks, which may be subject to conditions and time limits. MDN’s offline and background guide explains how a sync attempt can be restarted and why long-running tasks don’t simply keep running.
Design a visible recovery route. If automatic submission fails, for example, the app could show pending changes when it next opens. That’s a design choice to agree, not a standard PWA guarantee.
A process that must measure continuously or respond at an exact moment needs a feasibility trial before you choose the web route. Look at the particular device and function. Saying PWAs can’t use hardware is no more useful than saying native apps can do everything.
Does everyone immediately get the latest version?
Deploying a new web version doesn’t mean every open app switches immediately. A new service worker can wait until the old one no longer serves any windows. The service worker documentation explains this update behaviour.
Discuss what users experience during an update. Can they finish a form in progress? How does a new version read old local data? Who helps if a device keeps displaying an older interface?
Speed needs its own assessment. The PWA label doesn’t make a heavy page light or predict conversion. Measure the journey people actually take; our guide to Core Web Vitals and website speed gives you a starting point.
How do you test whether a PWA is suitable?
Start with the riskiest task on a representative device. You don’t need a complete product, but you do need a trial that shows the real behaviour. For a portal, retrieving and updating records may matter more than an attractive installation animation.
| Trial | What you want to assess |
|---|---|
| First visit without installation | Can someone find and start the main task? |
| Use after installation | Do sign-in, links and returning to the app work? |
| Connection drops | Do entered data and submission status remain understandable? |
| Connection returns | Are changes processed without confusing duplicates? |
| Permission refused | Is there a usable route without notifications or camera access? |
| New version during use | Is unfinished work preserved? |
Record the devices and browser versions on which this was demonstrated. Include keyboard operation, readability and error messages in the assessment. A successful technical connection doesn’t yet make an app usable.
What determines the cost of a PWA?
The price mainly follows the application: accounts, roles, data processing, integrations and the tasks you want to support. Adding installability is different from making an existing product handle offline changes and conflicting edits.
Ask for separate estimates for the base app, offline behaviour, notifications, compatibility testing and maintenance. Don’t assume a PWA layer always takes only a few days. Have the supplier assess the existing application and requested scenarios first.
Installation may add little value to a simple information site. For recurring work in a portal, it may be useful. The choice should solve a user’s problem, rather than merely tick a technical box.
How do you actually get started?
Write down who uses the app, on which devices and what must remain available without a connection. Distinguish viewing, editing and submitting. Then choose the scenario whose failure would cause the most disruption and have that tested first.
Read about our approach to custom websites or book a call. We’ll help identify useful web features and when you should investigate another development route.
