How long does it take to turn my site into a PWA?

Most projects run for a few weeks of part-time work. A content site with offline reading and an install prompt is usually the short end, while a product with queued writes, conflict handling, and push notifications takes longer. We quote the whole thing after an audit of your current routes and data flows.

Will a PWA replace our iPhone app?

For some products it can, and for others it cannot. iOS supports home screen installation and web push, but it blocks background sync and continuous background location, and there is no App Store listing. If you rely on sensors, watch or widget integration, or store discovery, we build a native or cross-platform app instead, which sits under [mobile apps development](/services/mobile-apps-development).

What happens when I publish a new version?

A service worker caches aggressively, so an old worker can keep serving an old build after you deploy. We control this with versioned caches, a deliberate activation step, and a prompt that tells the user a new version is ready to load. Nobody is updated mid-session, and nobody is left on a mix of old HTML and new JavaScript.

Do push notifications work on iPhone?

They work only for sites the user has added to the home screen, and permission has to follow a user gesture. Chrome on Android is more permissive, and desktop browsers vary. We place the permission prompt behind a real action in your product and keep email or in-app messaging as the fallback, so a declined prompt does not end the conversation.

Does my current application work offline as it is?

Partly. Read-only screens are the easy part, because a cached response can stand in for the network. Anything that writes needs a queue in IndexedDB and a rule for two devices editing the same record, and we map that during the audit.

Progressive Web App Development

We turn existing web apps into installable, offline-capable PWAs with service workers, caching strategy, install prompts, and a safe update path.

See our work:

Eggifest: Dreams Without Borders→Voteme App→Walking Cure→

Most people read your product on a phone, in a lift, or at the edge of a mobile signal that keeps dropping. A blank screen with a browser error ends the visit, and the user sends no feedback about it. They tap something else on the home screen.

A progressive web app reduces that failure. The site you already run gets a manifest, a service worker, and a caching strategy, so it can be installed to a home screen, opened with no network connection, and updated without a download. We add that layer to your existing codebase in most cases.

What a progressive web app really is

Three technical pieces do the work. The manifest is a JSON file describing the application name, icons, colours, and start URL, which is what makes the browser treat the site as installable. The service worker runs outside the page, sees every network request your app makes, and decides which are answered from the cache. HTTPS makes both possible.

A PWA is still your website running in a browser engine, with browser controlled access to the device. Adding a manifest does not turn it into native code, so when your product needs hardware or background behaviour that browsers do not expose, we say so early.

Who this work suits

Home screen installation and cached loading pay off in predictable places:

Content and reference products, where offline reading of already visited pages has real value
Booking, order, and registration flows used where connectivity is weak, such as events and field work
Marketplaces and catalogues that users browse repeatedly and resent reloading
Products that want a mobile presence without store fees and a second release pipeline

A PWA is the wrong answer for some products, and pretending otherwise costs clients money. Browsers will not give you continuous background location, Bluetooth pairing with peripherals, NFC, or always-on background work comparable to native. If your product depends on those, or on App Store and Play Store discovery as a growth channel, the honest route is a native or cross-platform build, which we cover in mobile apps development.

What we deliver

Install experience

A manifest with icons sized for Android, iOS, and desktop, a theme colour that matches your brand, and a start URL that opens where the user expects. On Android and desktop Chrome we wire an install prompt that appears after the user has shown interest, not on the first page load. On iOS we add a short instruction path for the Share menu.

Caching strategy, route by route

Caching decisions get made per route type. App shell assets are precached with the install. Marketing and article pages use stale-while-revalidate, so a returning visitor sees content immediately. Account data and anything money related stays network first, because a stale balance is worse than a spinner. Cache names carry versions so a deploy can retire old entries cleanly.

Offline behaviour

An offline fallback page for routes with nothing cached. Queued writes in IndexedDB for form submissions, with optimistic UI so a user can keep working and a flush happens when connectivity returns. Conflict handling for two devices touching the same record, and clear messaging when a write genuinely failed.

The update path

A deployed update does not reach an installed user until the service worker changes, and a half updated cache can serve new HTML with old JavaScript. We version caches, activate the new worker deliberately, and show an in-product notice when a new version is ready. Users choose when to reload.

Push notifications where supported

Push is unevenly supported, so we treat it as an extra rather than a core promise. Permission is requested after a user action that explains the benefit, subscriptions live on your backend, and messaging falls back to email or in-app notices for users who decline.

Platform limits that matter in practice

iOS installation has no prompt. A user must open the Share menu and choose Add to Home Screen, and the installed app keeps its own storage and login state, separate from Safari. Onboarding for these users is part of the work, because install rates depend on guiding them.

Background sync is not available on iOS. Chromium browsers have a Background Sync API, Safari does not, so queued writes flush when the user next opens the app or the page regains focus. That suits forms and comments, and rules out anything that must transmit within seconds.

Web push on iOS reaches installed sites only. A user who visits in Safari and never installs receives nothing. Android notifications through Chrome are more dependable, and desktop browsers differ.

Storage can be evicted. Browsers clear cached data under storage pressure, and iOS applies its own eviction rules to sites left unused. We request persistent storage where the browser offers it and treat the cache as a performance layer.

Hardware access stays narrow. No Bluetooth pairing, no NFC, no continuous background location. Camera and file access work through web APIs, with behaviour differing between browsers.

How the engagement runs

We start with an audit of your current application: the route inventory, the authentication flow, which data is read and which is written, and how the front end builds. That takes a few days and ends with a short written plan naming which screens can work offline.

The build phase covers the manifest, the service worker, the offline shell, the write queue, and the update flow. It runs one to three weeks depending on route count and whether offline writes are in scope. We work inside your framework, Next.js, React, WordPress, or a plain server-rendered application, and we flag it if the current pipeline cannot produce a stable app shell without a refactor first.

Device testing comes next: real phones on iOS and Android, flight mode toggled at awkward moments, a deploy pushed while a session is open, and caches inspected to confirm what is stored. Push notifications and measurement follow, since they only matter once installation works.

What it costs

Work is billed at our flat rate of $39 per hour, or as a fixed price once the audit gives us a real scope. The scope drivers are the number of route types needing a cache policy, whether writes must queue offline, whether push notifications are included, and how much of the front end needs reshaping so the app shell caches well. Those drivers move a project between a couple of weeks and a couple of months, which is why we quote after the audit.

Our pricing page sets out hourly billing, fixed-price projects, and monthly capacity plans from $2,699 for teams that need continuous delivery.

Proof

Voteme is a cross-platform Xamarin app for iOS and Android with photo voting, credits, real-time chat, push-style notifications, and blocking and reporting controls for community safety. It covers the engagement and notification behaviour a PWA has to reproduce.

Walking Cure is a WordPress site for a California clinic, with sections explaining a walking-based health method, a blog, a contact form, and responsive, search aware implementation. Already visited articles are exactly what an offline reading cache handles best.

Eggifest, the Dreams Without Borders charity platform, reached 27 countries with more than 10,000 Dream Capsules distributed through donation flows, contest registration, event management, and multilingual content. Registration forms used across countries with uneven connectivity are where queued offline submissions and clear failure messaging matter most.

Related services

Web development for the front-end and back-end work behind the product itself
Mobile apps development when native device APIs or store distribution turn out to be required
Custom web application development to build the application before it becomes installable
Website speed and performance optimization for loading problems that caching alone will not solve
Offline-first mobile development for local storage, sync, and conflict handling beyond a browser cache

Next step

Send us the URL of the application and a sentence about where your users lose connection. We will tell you which parts can work offline, which cannot, and what the first phase would contain.

Contact us to start that conversation, or run your requirements through the Vasilkoff.info estimator to get an early scope and cost range before you talk to anyone.