Often clients approach us with a request for a mobile presence without publishing to the App Store and Google Play. Or they already have a website on React/Vue/Angular and need to add offline mode, push notifications, and a home screen icon — without rewriting everything from scratch. A real PWA requires a Service Worker with the correct caching strategy, a Web App Manifest with proper parameters for each platform, and HTTPS without exceptions. Skip any of these three components, and you get an app that doesn't install or works incorrectly offline. Request an assessment of your project in 1 day — contact us.
Where does PWA typically break?
Service Worker and caching strategies
The most common mistake is caching everything with CacheFirst without invalidation. The user opens an updated app but sees the old version because sw.js serves resources from an outdated cache. Workbox solves this by using StaleWhileRevalidate for static assets and NetworkFirst for API requests, but you need to clearly separate what to cache aggressively (fonts, icons, JS bundles with hashes) and what to always fetch fresh (user data, inventory, content).
Another issue is background synchronization via the Background Sync API. A user submits a form offline, the Service Worker intercepts the request and stores it in SyncManager. When connectivity is restored, the request is sent. It sounds simple, but registration.sync.register('sync-orders') only works on Chrome/Android. On iOS Safari, Background Sync is still not supported — this must be considered when designing offline scenarios. For example, an alternative could be manual data sending when the connection is restored.
| Caching strategy | Application | Data staleness | Suitable for |
|---|---|---|---|
| CacheFirst | Static resources | No | Fonts, icons, JS bundles with hashes |
| StaleWhileRevalidate | Fast display | Yes | HTML pages, images |
| NetworkFirst | Always fresh | Yes | API requests, user data |
| NetworkOnly | No cache | No | Forms, authentication |
What limitations exist on iOS?
Apple has been systematically limiting PWAs: until version 16.4, push notifications in PWAs did not work at all. They now work, but only if the app is added to the home screen via Safari — not from Chrome, not from Firefox. The default IndexedDB storage quota on iOS is 50 MB, compared to gigabytes on Android. Cacheable resources need to be calculated in advance. If you plan push notifications, be sure to use VAPID keys and note that on iOS, installation via Safari is required.
Why is PWA better than native for some scenarios?
PWA development is 3–5 times faster than a native app and costs 2–3 times less. Updates happen automatically, without store reviews. For informational portals, news sites, and corporate services, PWA often proves more efficient: it takes up less space on the device, does not require installation from a store, and the conversion to installation (via beforeinstallprompt) can reach 60%. However, for apps with deep system integration (camera, Bluetooth, NFC), a native app remains the only option.
How we build PWAs: step-by-step
- Audit — check HTTPS, Core Web Vitals, and the current Service Worker (if any).
- Configuration — we use Workbox 7.x via
vite-plugin-pwa. ThegenerateSWmode automatically creates a precache manifest from the bundle. - Manifest —
name,short_name,start_urlwith the parameter?source=pwa,display: standalone,theme_color,background_color, icons 192×192 and 512×512, plus amaskablevariant for Android. - Service Worker — configure strategies: StaleWhileRevalidate for static assets, NetworkFirst for APIs, CacheFirst for immutable resources.
- Push notifications — register VAPID keys, subscribe via
PushManager.subscribe(). - Testing — debug with Lighthouse, Chrome DevTools (Application → Service Workers → Offline) and on real devices.
How to achieve high installation conversion?
Chrome shows the "Add to Home Screen" banner when criteria are met: HTTPS, a valid manifest, and a registered Service Worker with a fetch handler. Lighthouse checks all conditions. For independent control, we use the beforeinstallprompt event: intercept it via event.preventDefault(), defer it, and show our own UI at the right moment, then call prompt(). This gives us control over when and to whom to offer installation. On iOS, installation is only manual via Share → "Add to Home Screen" — no automatic prompts.
Push notifications via the Web Push Protocol
VAPID keys are generated once, the public key is passed to the client when subscribing via PushManager.subscribe(). On the server, we use the web-push library for Node.js or an equivalent. The subscription object with endpoint, p256dh, and auth is saved in the database — this is what is needed for sending.
// Subscription registration const subscription = await registration.pushManager.subscribe({ userVisibleOnly: true, applicationServerKey: urlBase64ToUint8Array(PUBLIC_VAPID_KEY) }); Comparison of PWA and native apps
| Criterion | PWA | Native app |
|---|---|---|
| Development | 2–4 weeks | 2–6 months |
| Cost | 2–3 times lower | High |
| Updates | Automatic | Via stores |
| Offline | Limited | Full |
| Push notifications | Yes (with iOS limitations) | Yes |
| Installation | Without stores | App Store / Google Play |
What is included in the work
During the audit phase, we check performance (Core Web Vitals), HTTPS configuration, and the current Service Worker if any. Then we develop a Service Worker with caching strategies for specific routes, create a manifest, icons of all sizes, and splash screens for iOS. If push notifications are needed, we set up Web Push and test offline scenarios in Chrome DevTools and on real devices. On average, adding PWA to an existing site takes 3–7 days, and full development from scratch takes 2–4 weeks.
The result is verified using the Lighthouse PWA audit — all items must be green. We have been working on PWAs for over five years, and every project undergoes such testing. Our experience includes integration with Firebase and Supabase for push notifications and background synchronization.
Typical mistakes when implementing PWA:
- Ignoring cache invalidation — users see outdated content.
- Missing
maskableicon — on Android, the icon appears with a white background. - Push notifications without checking iOS support.
- Using only CacheFirst for APIs — loss of data freshness.
Timelines
Adding PWA to an existing web application: 3–7 days. Developing a PWA from scratch with offline logic and push notifications: 2–4 weeks. The cost is calculated after analyzing the current stack and requirements for offline functionality. We will assess your project in 1 day — contact us for a consultation.







