Progressive Web App Development
A progressive web app delivers push notifications, offline access, and an install prompt without going near the App Store — and ships from a single codebase your web team already owns.
We architect, build, and optimise progressive web apps that score 90+ on Lighthouse and behave like native apps across Chrome, Safari, and Edge.
The Gap Between a Website and an Installable App Is Smaller Than You Think
Most people treat “website” and “mobile app” as two separate things that require two separate builds. That distinction has been narrowing since 2018. A progressive web app isn’t a compromise — it’s a technically specific set of capabilities layered onto a web application: a Service Worker that intercepts network requests and serves cached content when the connection drops, a manifest.json that tells the browser how to present the app when installed on the home screen, and HTTPS throughout. When those three components are correctly implemented, Chrome, Edge, and Android offer the user an install prompt without an App Store involved.
The commercial case is straightforward. One codebase, deployed to a URL, delivers an experience that users install, return to without a browser bar, and use offline. For products that don’t justify two separate native app builds, a progressive web app is frequently the right first move. See how we’ve built them for agency and founder clients.
Progressive Web App Development Services
Six engineering services covering every layer of a production-grade PWA.
Service Worker Architecture
We implement Service Workers using caching strategies matched to content type — CacheFirst for static assets, NetworkFirst for API calls where fresh data matters, StaleWhileRevalidate for content that can briefly lag. The Service Worker lifecycle (install, activate, fetch) is managed to prevent stale cache states on updates, and skipWaiting() with clients.claim() is handled so new versions reach users without a manual refresh. We use Workbox for all production implementations rather than hand-rolled fetch handlers.
Web App Manifest and Installability
A correctly configured manifest defines the app name, display mode (standalone removes browser chrome entirely), theme colour, icon set across all required sizes including maskable variants, and app shortcuts. We wire the beforeinstallprompt event to a custom trigger rather than the browser’s default banner — giving you control over when the install prompt surfaces and to which user segments. See MDN’s PWA documentation for the full manifest specification.
Offline-First Data Strategy
Offline capability in a progressive web app is only as good as its data strategy. We design the offline layer based on actual usage patterns: what does a user need when their connection drops, what can safely be stale, and what must fail explicitly with a clear UI state. Static assets are pre-cached at Service Worker install time. API responses are cached with defined TTLs. User-initiated writes that happen offline are queued in IndexedDB and replayed via the Background Sync API when connectivity returns — without requiring the user to be on the page when the sync fires.
Push Notifications
We implement Web Push using the VAPID authentication standard. The server generates public and private key pairs, the client subscribes via PushManager.subscribe(), and the subscription endpoint is stored server-side for message delivery. Notification display runs inside the Service Worker’s push event handler — persistent even when the browser tab is closed. We design the permission request flow for high opt-in rates: triggered after demonstrated value, not on first visit, and never as an immediate popup on the landing page. White-label delivery available for agency partners.
Core Web Vitals Optimisation
A progressive web app lives and dies by its Lighthouse scores. We audit against all five categories — Performance, Accessibility, Best Practices, SEO, and PWA — and target 90+ across them. LCP improvements typically involve image format (WebP/AVIF), preload hints, and server response time. CLS issues usually trace to undimensioned images or late-injected DOM nodes. INP (Interaction to Next Paint, which replaced FID in 2024) requires profiling main thread blocking during interaction handlers.
PWA Audit and Remediation
If you have an existing web application that should qualify as a progressive web app but doesn’t, we audit it against the full PWA checklist — HTTPS, valid manifest, Service Worker registered, offline fallback page, installable, passing all Lighthouse PWA thresholds — and deliver a prioritised remediation list with effort estimates per item. This is often faster than a greenfield build. For well-structured applications, full PWA compliance is typically achievable in two to three weeks. See audit examples in our case studies.
When a Progressive Web App Is the Right Choice — and When It Isn't
PWAs work extremely well for content-heavy products, SaaS dashboards, e-commerce, booking flows, internal tooling, and any product where the primary interface is web-based but you want app-like retention mechanics: install prompt, push notifications, and offline access. They’re not the right choice when the product needs deep native hardware access — Bluetooth peripherals, ARKit or ARCore experiences, NFC, background HealthKit data reads, or advanced camera APIs. The decision isn’t about budget. It’s about the feature list. If the product’s core journeys work well on the web and don’t need those native APIs, a progressive web app gets you to market faster, at lower ongoing maintenance cost, and without the App Store review queue standing between you and a critical fix. We’ll tell you which one fits before you commit.
Four Core Capabilities in Every PWA Engagement
What we deliver beyond the Service Worker and manifest.
Lighthouse Audit and Scoring
Before writing a line of new code, we run a full Lighthouse audit and establish a documented baseline across all five categories. That baseline shapes the architecture decisions that follow. A site scoring 45 on Performance and missing a Service Worker needs a different migration path than one scoring 80 with an incomplete manifest. The audit report is yours regardless of whether you continue into development with us. Request a baseline audit.
Cross-Browser Compatibility Matrix
Chrome and Edge give the fullest PWA experience — install prompt, push notifications, background sync. Safari on iOS 16.4+ supports push for installed PWAs only, not browser tabs. Samsung Internet adds Play Store TWA packaging support. We test across this browser matrix and document exactly what features are available on each, designing graceful degradation rather than making the entire progressive web app contingent on the Chrome experience.
Caching Strategy and Background Sync
We implement Workbox-based caching with explicit strategies per route type: CacheFirst for versioned static assets, StaleWhileRevalidate for non-critical API responses, NetworkFirst for data that must be current. Background Sync queues failed mutations — form submissions, cart updates, data writes — and replays them on reconnect without the user needing to be in the browser tab when the sync executes.
Progressive Enhancement Architecture
The app shell renders from cache. Core navigation works without JavaScript. Service Worker enhancements layer on top of a functional baseline rather than replacing it. This means the progressive web app degrades gracefully on browsers with partial support, and it scores significantly better on Lighthouse accessibility and best-practices categories because the base HTML carries semantic structure and ARIA attributes — not a hydrated JS tree that adds them post-load.
White-Label Progressive Web App Development for Agency Partners
Your clients are asking whether their web product can behave like an app — install prompt, offline access, push notifications — without the cost and timeline of a native build. That’s a progressive web app engagement. We run these as white-label projects under your brand, integrated directly with the client’s web codebase and deployment pipeline. NDA-standard. No direct contact with your client unless you decide otherwise.
Agency partners get a dedicated engineering lead, a fixed-scope statement of work, and Lighthouse score documentation that you can present to your client as a measurable delivery outcome. We’ve built progressive web apps on React, Next.js, Vue, Nuxt, and vanilla JS stacks. Explore the agency partner programme or review the white-label development model to understand how we operate as your engineering back-end.
What Building Two Native Apps Actually Costs
Separate iOS and Android codebases mean two teams or one team stretched across two platforms, two App Store accounts, two submission queues, two sets of OS-version-specific regressions, and two review timelines every time you need to push a critical fix. For products where the core journeys are UI-heavy but hardware-light — SaaS dashboards, booking flows, e-commerce, content platforms, internal tooling — that overhead is often unjustified in year one.
A progressive web app ships from one codebase, updates the moment you deploy without waiting for App Store review, and is indexable in search engines. The trade-off is real: if the product needs Bluetooth, NFC, HealthKit, or ARCore, native is the right answer and we’ll tell you that. We’d rather give you the honest assessment than sell you a PWA that should have been a native app.
Progressive Web App Engagement Models
Choose the starting point that matches where your project is.
Greenfield PWA Build
Architecture planning, Service Worker implementation, manifest configuration, offline data strategy, push notification setup, and Lighthouse score validation — all from scratch. We deliver a PWA that installs on Android and iOS, works offline for core user journeys, and scores 90+ on Lighthouse PWA, Performance, and Accessibility categories. Suitable for new products and web applications being launched without an existing codebase.
Website-to-PWA Conversion
Your existing web application gets a Service Worker, a manifest, and an offline strategy. We assess the current codebase, identify the migration path, and add PWA capabilities without restructuring the app. Most conversions reach a Lighthouse PWA score of 90+ within two to three weeks. The result is a site that can be installed on the home screen, works offline for critical paths, and qualifies for Play Store submission via Trusted Web Activity.
PWA Performance Audit
A comprehensive Lighthouse audit, main-thread profiling, network waterfall analysis, and a prioritised optimisation report with effort estimates per item. You get a full assessment of Core Web Vitals (LCP, INP, CLS), PWA compliance gaps, accessibility issues, and SEO technical factors. Fixed-scope. You execute the recommendations yourself or continue with us. Talk to us about a performance audit.
Ongoing PWA Maintenance
Browser PWA APIs, Lighthouse scoring criteria, and Core Web Vitals thresholds change with browser releases. A progressive web app scoring 95 last year might score 81 today because Google updated the INP metric or Safari changed how it handles beforeinstallprompt. We provide ongoing Lighthouse re-audits, Service Worker update management, and maintenance sprints to keep the PWA’s scores, install behaviour, and offline functionality current as the browser landscape evolves.
How We Build a Progressive Web App Engagement
01. Discovery and Lighthouse Baseline
02. App Shell and Manifest Architecture
We audit the existing web application (or spec, for greenfield builds) against the full PWA checklist and run Lighthouse across all five categories. The baseline report defines the starting point — Performance score, existing Service Worker state, manifest completeness, HTTPS status, offline behaviour — and drives the architecture decisions in the next phase. Typically two to three days.
03. Service Worker Implementation
We design the app shell — the minimal HTML, CSS, and JS skeleton that renders immediately from cache — and configure the Web App Manifest. Manifest decisions include display mode, theme and background colours, the full icon set (including maskable icons for Android adaptive icon support), app shortcuts, and the start_url. The manifest is tested for installability in Chrome DevTools and against the Lighthouse installability audit before we move to Service Worker implementation.
04. Offline Strategy and Data Layer
We implement the Service Worker using Workbox, defining caching strategies per route type and ensuring the install, activate, and fetch lifecycle is handled correctly. Precaching covers the app shell and critical static assets. Runtime caching handles API routes with explicit strategies. The Service Worker update flow is tested to confirm new versions reach users without stale-cache issues arising. Push notification integration is wired in this phase if it’s in scope.
05. Core Web Vitals Optimisation
We design and implement the offline data strategy based on the product’s actual user flows: which journeys need to work offline, what data can tolerate being stale, and what should fail explicitly with a clear UI state rather than silently. Cache storage is structured using Cache API for network responses and IndexedDB for structured data. Background Sync is wired for write operations that need to queue offline and replay on reconnect without user intervention.
06. Audit, Deployment, and Handover
With the Service Worker in place, we profile against Core Web Vitals benchmarks in both lab (Lighthouse) and field (Chrome UX Report). Optimisations vary by app but typically include image format conversion to WebP or AVIF, critical CSS inlining, font loading strategy adjustments, lazy loading for below-fold assets, and yield patterns for heavy JS that’s blocking interaction response. We target 90+ on Lighthouse Performance before sign-off. Every change is benchmarked before and after.
From web application to installable PWA.
We run a final Lighthouse audit across all five categories, verify the install prompt triggers correctly on Android and iOS, test the offline experience on a throttled connection, confirm push notifications deliver end-to-end, and document the Service Worker update strategy. Handover includes the full Lighthouse report, Service Worker architecture notes, and a caching strategy reference. We remain available through the first two weeks post-launch to handle anything that surfaces in production.
Progressive Web App Development: Common Questions
Direct answers from the engineers who build them.
Which browsers and devices actually support progressive web apps?
Chrome on Android and desktop, Edge, Samsung Internet, and most Chromium-based browsers support the full progressive web app feature set — install prompt, Service Worker, push notifications, and offline access. Safari on iOS supports PWAs through “Add to Home Screen,” but push notifications require iOS 16.4+ and only work when the PWA is installed to the home screen, not running as a browser tab. Firefox removed PWA install support from desktop in 2021 and hasn’t restored it. Chrome on Android covers the broadest user base with full feature support; Safari on iOS 16.4+ handles push for installed PWAs.
Can a progressive web app be listed in the Google Play Store or App Store?
Yes, through Trusted Web Activity (TWA). Google introduced TWA as a mechanism for packaging a progressive web app into an Android APK that can be submitted to the Play Store. The app opens the PWA URL in a Chrome Custom Tab without browser UI, provided the site is linked via Digital Asset Links. The PWA must pass a full Lighthouse PWA audit and meet Play Store quality policies. We handle the TWA configuration and Play Store submission as part of the deployment phase.
What's the difference between a PWA and a React Native app?
React Native compiles to genuinely native UI components — iOS UIKit on Apple hardware, Android View system on Android — and runs JavaScript via the Hermes engine with access to native device APIs: Bluetooth, NFC, HealthKit, ARCore, advanced camera, and background processing. A progressive web app runs in a browser engine and is limited to what Web APIs expose. What a PWA can do is ship from a URL, update without App Store review, and index in search. If the product doesn’t need those native hardware APIs, a PWA usually gets to market faster and at lower ongoing maintenance cost.
How does offline mode actually work in a progressive web app?
A Service Worker is a JavaScript file that runs in the background, separate from the page, intercepting network requests. On first load, it pre-caches the app shell — HTML, CSS, JS, and static assets needed to render the UI. When the user goes offline, cached requests are served from the cache rather than the network. For dynamic data, you choose a strategy: CacheFirst serves from cache and updates in the background, NetworkFirst tries the network first and falls back to cache, and offline-first stores writes locally in IndexedDB and replays them via Background Sync on reconnect.
How do push notifications work in a PWA on iOS?
Push notifications for iOS progressive web apps were added in iOS 16.4 and require the PWA to be installed to the home screen — they don’t function in the browser tab. Once installed, the PWA requests permission via the Web Push API, receives a VAPID-authenticated push subscription, and the Service Worker’s push event handler displays the notification. On Android, Chrome supports push including when the browser is closed, and installation isn’t required. This shapes the onboarding flow: prompt the user to install before requesting push permission, and never show the request on the first visit.
How long does it take to convert an existing website into a progressive web app?
For a well-structured web application, adding a basic Service Worker with app-shell caching and a Web App Manifest typically takes two to five days. Reaching a full offline-first experience with Background Sync, push notifications, and a Lighthouse PWA score of 90+ is usually a two to three week engagement. The biggest variable is the data layer: single-page apps with a clean API boundary are much easier to make offline-capable than multi-page server-rendered apps with complex session state or server-side rendering that can’t be cached at the edge. We always start with a Lighthouse audit and a codebase assessment before quoting a timeline. Anyone giving you a fixed number before reviewing the codebase is guessing.