Progressive web apps
Progressive web app development that installs, works offline and ranks
We handle progressive web app development for product teams in the USA, UK, UAE, Europe and Australia who want one codebase that runs in the browser, installs to the home screen and keeps working on a bad connection. A PWA is often the fastest route to a usable product. It is also sometimes the wrong one, and we will tell you which before you spend a sprint on it.
- Installable on Android, desktop and iOS Home Screen
- Offline-first caching designed per screen
- Server-rendered pages search engines can index
- NDA before discovery, code in your repository
What progressive web app development involves
A progressive web app is a website built to behave like an app. Three pieces make that happen: a web app manifest that tells the operating system the app’s name, icons and launch behaviour; a service worker that sits between the app and the network to cache files and handle push messages; and HTTPS, without which none of it runs.
Installability is simpler than most teams assume. According to MDN’s installability guide, Chromium browsers need a linked manifest with a name or short_name, 192px and 512px icons, a start_url and a display mode, served over HTTPS. A service worker is not required to install. It is what makes the app useful offline, which is where most of the engineering effort goes.
So the hard work is not the manifest. It is deciding what each screen should do with no signal, how stale data is allowed to be, how updates roll out without breaking open tabs, and how the app behaves in Safari, which follows its own rules. It sits within our wider app development services.
PWA vs native vs cross-platform: which should you build?
This is the decision we help with most often. The answer depends on the device features you need and how users will find you, not on which option is cheapest on paper.
| Factor | Progressive web app | Cross-platform (Flutter / React Native) | Native (Swift / Kotlin) |
|---|---|---|---|
| Codebases | One web codebase for browser, Android, iOS and desktop | One shared codebase for iOS and Android | Separate iOS and Android apps |
| How users get it | A link, a search result or a QR code; install is optional | App Store and Google Play | App Store and Google Play |
| Updates | Live on next load; no store review | Store review for each binary release | Store review for each binary release |
| Push on iOS | Only after the user adds it to the Home Screen (iOS 16.4+) | Full support via APNs/FCM | Full support via APNs |
| Device access | Camera, location, notifications; limited background work, Bluetooth and health data on iOS | Most native APIs through plugins or native modules | Everything the OS offers, first |
| Search visibility | Every screen can be an indexable URL | Store listing only, plus a separate website | Store listing only, plus a separate website |
| Best fit | Content, commerce, booking, internal tools, markets where users avoid installs | Consumer apps needing store presence on both platforms | Apps close to the OS: widgets, wearables, heavy media, HealthKit |
Store-based options are compared in depth in our native vs cross-platform guide.
Choosing between a PWA and a store app
Choose a PWA if most of your users arrive from search, ads or shared links, if you release changes weekly and cannot wait on review, or if your audience is on low-storage Android phones and resists installing anything.
Choose a store app if you need reliable background location, Bluetooth peripherals, health data, home-screen widgets or in-app purchases, or if your buyers expect to find you in the App Store. Our cross-platform app development team covers that route, and the trade-offs are set out in our guide to native vs cross-platform app development.
Many products end up with both: a PWA for acquisition and occasional users, and a store app for the loyal core. If that is where you are heading, we design the backend and API once so both clients share it, which is the main job of our mobile app backend development service.
iOS web push and the EU situation
For years the biggest objection to PWAs was that iPhones could not receive web push. That changed with iOS and iPadOS 16.4, which, as WebKit announced, added Web Push for Home Screen web apps using the standard Push API, Notifications API and service workers, plus the Badging API for icon badges.
The conditions matter. The user must first add the app to the Home Screen, and the permission request must follow a user gesture such as a tap. We design the flow around that: explain the value, show install instructions, then ask for permission inside the installed app.
In the EU, Apple planned to remove Home Screen web apps in iOS 17.4 under the Digital Markets Act, then reversed the decision on 1 March 2024, as reported by 9to5Mac. EU users keep the capability, and those apps still run on WebKit. Platform policy can shift again, so we keep push as an enhancement, never the only way a user hears about an order.
iOS push checklist
- iOS/iPadOS 16.4 or later
- App added to Home Screen first
- Permission asked after a tap, not on load
- Service worker handles push events
- Email or SMS fallback for critical messages
PWAs we build
A PWA earns its place when reach and update speed matter more than deep device access.
Commerce and catalogue PWAs
Fast product listing and checkout pages that are indexable, cache the catalogue for repeat visits and survive a dropped connection at the payment step without double-charging.
Booking and appointment apps
Clinics, salons, tours and services. Users book from a search result, add the app to their home screen and get reminders through web push where the platform allows it.
Field and internal tools
Inspection forms, delivery proof and stock counts that queue entries offline in IndexedDB and sync when the device reconnects, with conflict rules agreed up front.
Website-to-app upgrades
Turning an existing site into an installable app is often the cheapest first step before a website to mobile app conversion into a store app.
Offline support: designing each screen for no signal
Offline support is not a switch. Each type of content needs a caching strategy, and choosing the wrong one creates bugs that only appear on trains and in basements.
- Cache first for the app shell, fonts and icons. These change only on release, so serve them from cache and update in the background.
- Network first, cache fallback for prices, stock and account data, where stale numbers cause problems. Show the cached version with a clear “last updated” label when offline.
- Stale while revalidate for articles, menus and listings, where a slightly old copy is fine and speed matters more.
- Queue and retry for writes such as forms and orders, stored locally and sent when the connection returns, with an idempotency key so a retry cannot create a duplicate.
We usually build the service worker with Workbox and version every cache. A common PWA failure is a service worker that cached an old build forever, leaving some users on a broken version with no way to update. We ship every release with a tested update path and a service-worker kill switch.
Not sure a PWA is enough?
Send us your feature list. Within one business day you get our view on PWA vs store app, which features iOS will limit, and the next step toward a fixed quote.
Install prompts that people accept
On Chromium browsers you can catch the beforeinstallprompt event and show your own install button at a sensible moment, such as after a second visit or a completed order. Prompting on the first page view gets dismissed and teaches users to ignore you.
Safari on iOS has no install event. Users install through the Share menu and “Add to Home Screen”, so we build a short, illustrated instruction sheet that appears only on iOS Safari, only once the user has shown intent, and never again after a dismissal.
Making the installed app feel native
Standalone display mode, a proper splash colour, safe-area handling for notched phones, and navigation that does not depend on the browser’s back button. Our mobile app UI/UX design team designs these states explicitly, since an installed app with no back control strands users.
SEO benefits of a progressive web app
This is where a PWA beats any store app: each product, article or location can be its own URL that search engines crawl and rank. A store listing gives you one page; a PWA can give you thousands.
That only works if the content is in the HTML search engines receive. A single-page app that renders everything in the browser after a large JavaScript download often indexes poorly and loads slowly on mid-range phones. We render pages on the server (Next.js, Nuxt or SvelteKit depending on your team), hydrate only what needs interaction, and keep each route with its own title, meta description, canonical tag and structured data.
Service-worker caching speeds up repeat visits, but search users judge the first one, so we budget JavaScript per route and test on throttled mid-range Android phones.
Limits of PWAs we will tell you about up front
If any of these are core to your product, a store app is likely the better choice, and we will say so in discovery.
- Background work on iOS is restricted: no reliable background location tracking or long-running sync.
- No access to HealthKit, home-screen widgets, Live Activities or Apple Watch from a PWA.
- Bluetooth and NFC web APIs are not available in Safari, so hardware pairing usually needs native code.
- iOS push only works after the user adds the app to the Home Screen.
- Wrapping a PWA in a thin store shell risks rejection under Apple’s Guideline 4.2, which expects more than a repackaged website.
- Browser storage can be cleared by the user or the OS, so offline data must be re-syncable from the server.
How we deliver a PWA
The same backbone as our delivery process, with the browser-specific steps made explicit.
Discovery (one to two weeks)
Workshops to map users, traffic sources and must-have device features. We confirm PWA is the right fit, list what iOS will limit and agree an offline behaviour for every screen. A fixed price follows discovery.
Design and app shell
Clickable prototype, design system, installed-app states and the install and push permission flows for each browser.
Two-week sprints
Each sprint ends with a working build on a staging URL you can install on your own phone, plus a demo call.
Cross-browser and device QA
Chrome on Android, Safari on iPhone and iPad, Samsung Internet and desktop browsers, including offline and slow-network runs. Our mobile app testing practice owns the device matrix.
Launch and monitoring
Production release, analytics on install and push events, error tracking with Sentry and a documented service-worker update path.
Progressive web app development FAQs
Is a PWA cheaper than a native app?
Usually, because one web codebase covers browsers, Android and iOS, and there is no store review cycle slowing releases. The saving shrinks if you need features that browsers restrict, since workarounds cost time. The fairest comparison is your actual feature list priced both ways, which is what our discovery phase produces before any fixed price is agreed.
Do PWAs support push notifications on iPhone?
Yes, since iOS and iPadOS 16.4, but only for web apps the user has added to the Home Screen, and permission must be requested after a user action such as a tap. Push from a normal Safari tab is not supported on iPhone. We design an install-then-subscribe flow and keep email or SMS as a fallback for messages that must arrive.
Can a PWA be published on Google Play or the App Store?
Google Play accepts PWAs packaged as Trusted Web Activities, which works well for Android. Apple is stricter: an app that is little more than a repackaged website risks rejection under Guideline 4.2. If App Store presence matters, we usually recommend a native or cross-platform app that adds genuine device features, sharing the PWA’s backend.
Does a PWA help SEO?
It can, more than any store app, because every screen can be a crawlable URL with its own title and structured data. The catch is rendering: content must be in the HTML search engines receive, so we server-render pages and keep JavaScript lean. A client-only single-page app with the same design can index poorly.
What happens to a PWA when the user is offline?
Whatever you designed for that screen. We decide per screen: the app shell loads from cache, read-only content shows the last saved copy with a timestamp, and forms or orders are queued locally and sent when the connection returns. Screens that genuinely need live data, such as payment confirmation, show a clear offline message instead of failing silently.
Can you convert our existing website into a PWA?
Often, yes. Adding a manifest and a service worker to an existing site is quick; making it work well offline and feel like an app takes more design and testing. We start with an audit of your current site’s performance, rendering and structure, then recommend whether to upgrade it in place or rebuild the front end.
Plan your PWA with a clear answer on fit
Book a 30-minute scoping call. We will go through your users, traffic sources and device needs, and tell you plainly whether a PWA, a store app or both makes sense.