Progressive web apps and offline access — do you need one

A progressive web app adds installability and a degree of offline functionality to a website through the browser itself, and for the overwhelming majority of small Australian businesses, neither of those two things solves a problem the business actually has.

What a progressive web app — a PWA — technically is

A progressive web app is a website built to also behave, in supporting browsers, more like an installed app. It can be added to a phone’s home screen. It can run in a full-screen window without browser chrome. And, through a service worker, it can cache some content for use without an active internet connection. It remains fundamentally a website, served over the web, rather than a separate application distributed through the App Store or Google Play.

What PWAs and other installed web apps cannot access via the browser API

A PWA does not have the same depth of access to device hardware and platform-specific features that a genuine native app has. Some platform-specific capabilities and integrations available to a native app are not available in a PWA, or are more limited. It also is not discovered through app store search the way a native app is. A visitor generally needs to already be on the website to be offered the option to install it.

Where offline access via a service worker genuinely matters for a small business

Offline functionality solves a real problem only where a business’s site is genuinely used in situations with unreliable or absent connectivity. Examples include a field-service tool a tradesperson’s own staff use on job sites with poor reception. Or a reference tool for on-site information that needs to remain accessible without signal. Or a specific inventory or checklist a business uses internally away from Wi-Fi. This is a narrow, specific use case. It is meaningfully different from a general customer-facing marketing and enquiry website. Visitors reach that kind of site by browsing the internet in the first place, so they are already online.

Where it usually is not worth the added complexity

For a typical trade, professional services, or local retail website — informational content, a services catalogue, an enquiry form, contact details — there is very little for offline access to actually do. A visitor without a connection cannot reach the site to load it in the first place for their first visit. Repeat visits from a genuinely offline state are a rare edge case for this kind of business, rather than a common pattern worth engineering around. Building and maintaining service-worker caching logic adds real development complexity. It also adds an ongoing maintenance surface, for a capability that will very rarely be used.

What a PWA’s app manifest requires for install, including the Microsoft Store via Microsoft Edge

Beyond a service worker, becoming installable in the way a PWA is generally understood requires a web app manifest. This is a small configuration file declaring the site’s name, icon set, start page and display mode — whether it opens in a browser window or a standalone full-screen view. A site missing a correctly configured manifest will not offer the “add to home screen” prompt supporting browsers can show, regardless of what other PWA-adjacent features it has. That is a specific, checkable requirement, rather than something that happens automatically once a site is otherwise well built. On Windows, a correctly configured manifest can also make a PWA eligible for listing in the Microsoft Store through Microsoft Edge’s PWA submission tooling. That is a genuine but narrow distribution channel that most small-business sites have no practical use for.

Push notifications are a separate capability, and one worth real restraint about

A PWA can request permission to send push notifications, similar to a native app. But this is a distinct capability from offline access and installability. It carries its own cost. A visitor asked for notification permission before they have any reason to trust the site is likely to decline. A business sending low-value or overly frequent notifications trains visitors to decline, or later revoke permission entirely. For the overwhelming majority of small-business marketing and enquiry sites, there is no genuine ongoing content stream that justifies push notifications at all. Requesting the permission anyway, because the platform offers it, adds friction without a clear underlying need.

A cached site can show visitors outdated content if this is not managed carefully

A service worker’s whole purpose is serving content without a live network request. That means a visitor can be shown a cached, outdated version of a page, after the live site has actually been updated, until the cache is correctly invalidated. Managing this is an ongoing technical responsibility. It means deciding how long content is cached before being refreshed, and correctly triggering a cache update when the site changes. It does not exist at all for a site with no service worker. It is a specific, real cost of offline capability beyond the initial build effort. It is worth weighing against how rarely the underlying offline scenario actually occurs for most small-business sites.

A short decision guide

Situation	PWA / offline access likely worth it	Not likely worth it
Internal tool used by field staff with known patchy connectivity	Yes	—
General marketing and enquiry website for a local trade or service business	—	Yes — added complexity with little real use case
A reference tool genuinely needed without signal (safety checklist, site plan)	Yes	—
A business wanting an “app” primarily for the appearance of one	—	Yes — a native app or a PWA both add cost for a perception benefit, not a functional one

What to do next

Be specific about which real, current problem offline access or installability would solve before commissioning either — “it would be nice to have an app” is not the same as a genuine offline-use case. Where a genuine business need for something closer to an app exists, website or app for a small business covers the broader decision between a responsive website and a native app. For the cost implications of adding this kind of functionality, web development services covers where it typically sits in a project scope.