What is a progressive web app: a developer’s guide

A progressive web app (PWA) is a website built with standard web technologies that can be installed on a device and behave like a native app. That single sentence covers the core idea. The technical reality behind it rests on three minimum pieces: a web app manifest, a service worker, and delivery over HTTPS. Get those three right and browsers can promote your site for installation.

What installability actually unlocks for users:

• A home-screen or app-launcher icon, just like a native app
• A standalone window with no browser address bar
• Offline or low-connectivity behaviour through cached content
• Push notifications and background sync where the browser supports them

Key takeaways

A progressive web app is a website built with standard web technologies that installs and behaves like a native app, requiring a manifest, a service worker, and HTTPS as the minimum technical foundation.

Table of Contents

• What are the core technologies inside a PWA?
• How do installability and offline behaviour actually work?
• Why do businesses and developers choose PWAs?
• What are the real limitations of PWAs you should know?
• Real-world PWAs you can try right now
• How to build a simple PWA: a developer checklist
• How do you test PWA behaviour across browsers?
• What does a production-ready PWA deployment checklist look like?
• How CantyDigital builds high-performance PWAs for Australian businesses
• Accessibility considerations in PWAs
• When does CantyDigital recommend a PWA over other options?
• CantyDigital can build your PWA from the ground up
• Sources

What are the core technologies inside a PWA?

The web app manifest

The manifest is a JSON file that tells the browser how your app should present itself. MDN’s installability guide explains it as the required signal that triggers installability promotion. At minimum it needs:

The display field matters more than most developers expect. standalone removes all browser chrome, so your UI must provide its own navigation. minimal-ui keeps a small toolbar. fullscreen is typically reserved for games or immersive media. Design your interface to work in whichever mode you declare, because users launching from the home screen will never see a browser address bar.

Pro Tip: Link your manifest in every HTML page with <link rel="manifest" href="/manifest.json">, not just the index. Browsers check the page the user is on, not just the root.

Service workers

A service worker is a JavaScript file that runs in the background, separate from the main browser thread. It acts as a programmable proxy between your app and the network. MDN describes service workers as the component that gives PWAs offline capability, background sync, and push notification handling, with the browser able to start them independently of the page lifecycle.

Three caching strategies cover most use cases:

• Cache-first: Serve from cache, fall back to network. Best for static assets (fonts, icons, CSS) that rarely change.
• Network-first: Try the network, fall back to cache. Best for dynamic content where freshness matters.
• Stale-while-revalidate: Serve the cached version immediately, then fetch a fresh copy in the background for next time. Good for content that updates regularly but where a slightly stale response is acceptable.

Progressive enhancement

Web as progressive enhancement in practice: the site works as a normal webpage everywhere, and app-like features layer on top where the browser supports them. A user on an older browser gets the full web experience. A user on Chrome for Android gets the install prompt, offline support, and push notifications. One codebase, two tiers of experience.

How do installability and offline behaviour actually work?

Browsers do not hand out install prompts automatically. They check a set of criteria before promoting a site for installation. MDN’s installability guide lists the core requirements: a valid manifest with the right fields, delivery over HTTPS, and in most browsers a registered service worker. Chrome and Edge also apply engagement heuristics, meaning a user who has visited the site more than once is more likely to see the prompt.

What “offline” realistically means depends on what you cache. A well-built PWA can serve its app shell (the HTML, CSS and JavaScript skeleton) instantly from cache, display cached content, and queue any writes or form submissions for background sync once connectivity returns. It cannot fetch live data it has never seen. Set user expectations accordingly.

Here is a practical checklist to confirm your site is installable and offers offline support:

1. Confirm the site is served over HTTPS with a valid certificate.
2. Add manifest.json with at minimum name, icons (at least one 192×192 PNG), start_url, and display: standalone.
3. Link the manifest in your HTML <head>.
4. Register a service worker from your main JavaScript file.
5. Implement at least a basic cache-first strategy for the app shell.
6. Open Chrome DevTools, go to the Application tab, and verify the manifest and service worker are detected without errors.
7. Run a Lighthouse audit and check the PWA section for any failing criteria.
8. Test the install flow manually on an Android device and on a desktop Chrome or Edge browser.

Why do businesses and developers choose PWAs?

The business case for PWAs comes down to reach, cost, and engagement, and those three factors often point in the same direction.

Reach is the clearest advantage. A PWA lives at a URL, so it is discoverable through search engines, shareable via a link, and accessible without an app store download. Web.dev notes that PWAs combine web reach with native-like capabilities through a single codebase, which means a developer team maintains one product rather than separate iOS and Android builds.

Cost follows from that single codebase. Maintaining two native apps requires two separate development tracks, two sets of store submissions, and two review cycles for every release. A PWA collapses that overhead significantly, particularly for teams without dedicated mobile specialists.

Engagement improves because the app is on the home screen. Users who install a PWA return more often than users who only bookmark a website. Push notifications, when used judiciously, bring users back without requiring them to open a browser tab first.

Performance is where PWAs intersect directly with SEO. Caching the app shell means near-instant load times on repeat visits, which feeds directly into Core Web Vitals scores. Faster pages rank better, and personalised, faster experiences also lift conversion rates.

PWAs sit at the intersection of platform capabilities and web reach: the web gives distribution and discoverability, while native-like capabilities come from modern web APIs.

What are the real limitations of PWAs you should know?

PWAs are not the right answer for every product. The trade-offs are real and worth naming clearly before a team commits.

• iOS and Safari caveats. Apple has historically limited PWA capabilities on iOS. Push notifications via the Web Push API arrived on iOS 16.4, but only for installed PWAs, and behaviour still differs from Android. Some background sync features remain restricted. If your audience is heavily iOS-based, test thoroughly on Safari before assuming feature parity with Chrome.
• Native API gaps. Low-level Bluetooth, NFC, advanced camera controls, and complex background processing are either unavailable or inconsistently supported through web APIs. A fitness app that needs continuous heart-rate monitoring or a logistics app requiring persistent background location tracking will hit these walls.
• App store discoverability. PWAs do not appear in the App Store or Google Play by default. Microsoft’s Store accepts PWAs, but iOS and Android app stores remain largely closed to them. If your growth strategy depends on app store search, a PWA alone will not cover it.
• Testing overhead. Install prompts, push permission flows, and offline behaviour all vary by browser and OS. Testing a PWA properly means covering Chrome on Android, Safari on iOS, Edge and Chrome on desktop, and Firefox where relevant. That is more surface area than a single native app.
• Maintenance complexity. Service worker update bugs are notoriously hard to debug in production. A bad cache invalidation can leave users stuck on a stale version of your app until they manually clear storage.

Real-world PWAs you can try right now

Several well-known services run as PWAs and are accessible from Australia. Each one illustrates a different aspect of what the technology can do.

Twitter / X demonstrates home-screen installation and push notifications. Install it from a desktop Chrome browser and the experience is nearly indistinguishable from the native app, including offline reading of cached timelines.

Starbucks built a PWA that works offline, letting users browse the menu and customise orders without a connection. The order is submitted once connectivity returns, a practical demonstration of background sync.

Pinterest rebuilt its mobile web experience as a PWA and saw significant engagement improvements, with users spending more time on the installed version than on the previous mobile site.

Google Maps offers a lightweight PWA version aimed at low-bandwidth environments, showing how PWAs can serve users in regions with unreliable connectivity.

Browser behaviour varies. On iOS, install the PWA from Safari using the Share menu and “Add to Home Screen.” On Android, Chrome typically shows an install banner or an icon in the address bar. Desktop Chrome and Edge both support installation from the address bar menu.

How to build a simple PWA: a developer checklist

Building a basic PWA is less complex than most developers expect. The core files are HTML, CSS, JavaScript, a manifest, and a service worker, all of which Microsoft Learn describes as the standard front-end architecture for a PWA, deployable from static hosting.

1. Set up HTTPS. Use a host that provides TLS by default (Netlify, Vercel, GitHub Pages, or any modern Australian hosting provider). No HTTPS means no service worker registration.
2. Create manifest.json in your project root with at minimum:

{
  "name": "My App",
  "short_name": "App",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#000000",
  "icons": [
    { "src": "/icons/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

3. Link the manifest in your HTML <head>: <link rel="manifest" href="/manifest.json">.
4. Register a service worker in your main JavaScript:

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}

5. Implement basic caching inside sw.js using a cache-first strategy for your app shell assets.
6. Set icons and start_url correctly. The start_url should be a real, accessible page. Icons must include at least a 192×192 and a 512×512 PNG.
7. Test installability using the Lighthouse PWA audit in Chrome DevTools, then manually trigger the install flow on a real Android device and on desktop Chrome.

Pro Tip: Run Lighthouse in an Incognito window to avoid cached results from previous test runs skewing your audit scores.

How do you test PWA behaviour across browsers?

Lighthouse is the primary tool. Open Chrome DevTools, go to the Lighthouse tab, select “Progressive Web App” from the categories, and run the audit. The report flags missing manifest fields, service worker registration failures, and HTTPS issues with specific, actionable messages.

The Application tab in Chrome DevTools is equally useful for day-to-day debugging. It shows the parsed manifest, the registered service worker and its status, the cache storage contents, and the background sync queue. Use the “Update on reload” checkbox in the Service Workers panel during development to force the latest worker to activate without manually clearing storage.

For browser support, the picture varies. Chrome and Edge offer the most complete PWA feature set, including install prompts on both desktop and Android, push notifications, and background sync. Firefox on Android supports service workers and offline caching but does not currently show install prompts. Safari on iOS supports installation via the Share menu and, from iOS 16.4 onwards, Web Push for installed PWAs, but several background APIs remain limited. Firefox on desktop has reduced its PWA installation support over time.

Pro Tip: Use remote debugging via Chrome DevTools to inspect a PWA running on a physical Android device. Connect via USB, open chrome://inspect, and you get the full DevTools panel against the real device environment, which catches issues that desktop simulation misses.

Test on real devices, not just browser emulation. Install prompts, push permission dialogues, and offline fallback pages all behave differently on physical hardware.

What does a production-ready PWA deployment checklist look like?

Security and deployment hygiene matter as much as the code itself. A PWA that works locally but ships with misconfigured headers or a poorly scoped service worker will cause real problems in production.

1. Enforce HTTPS everywhere. Configure HSTS (HTTP Strict Transport Security) headers so browsers never attempt an insecure connection. Automate certificate renewal through Let’s Encrypt or your hosting provider.
2. Scope your service worker correctly. A service worker at /sw.js controls the entire origin. A worker at /app/sw.js only controls paths under /app/. Scope mismatches are a common source of unexpected caching behaviour.
3. Version your caches. Name caches with a version string (e.g., cache-v2) and delete old caches in the service worker’s activate event. This prevents stale assets from persisting after a deployment.
4. Set correct caching headers on your assets. Static assets with content-hashed filenames can use long Cache-Control: max-age values. The service worker file itself should be served with Cache-Control: no-cache so browsers always check for updates.
5. Implement a Content Security Policy (CSP). A CSP header limits what scripts and resources your PWA can load, reducing XSS risk. Start with a restrictive policy and loosen it only where necessary.
6. Handle push subscriptions carefully. Store push subscription endpoints server-side with appropriate encryption. Never log subscription data, and provide users with a clear unsubscribe path.
7. Plan your rollback strategy. If a bad service worker ships, users can be stuck. Keep the previous worker version deployable and document the steps to force an update (posting a message to all clients or incrementing the cache version).
8. Monitor in production. Use browser error reporting (such as Sentry) to catch service worker errors that only appear on specific devices or network conditions.

How CantyDigital builds high-performance PWAs for Australian businesses

CantyDigital’s web development work covers the full PWA delivery stack: front-end implementation, service worker strategy, performance optimisation, and SEO alignment from the first commit. The goal on every project is a site that loads fast, installs cleanly, and is structured for both traditional search and AI-driven discovery.

For Australian businesses, that means building PWAs with Core Web Vitals as a baseline requirement, not an afterthought. Service worker caching is designed around the specific content model of each client, whether that is a retail catalogue that needs near-instant product browsing or a service business that needs offline lead capture and background sync. You can see examples of this approach in the CantyDigital web design portfolio.

CantyDigital also aligns PWA architecture with responsive web design principles, so the installed experience and the browser experience are both first-class. Businesses considering a site modernisation can find a practical starting point in the website redesign guide.

Accessibility considerations in PWAs

PWAs inherit the full accessibility model of the web, which is both an advantage and a responsibility. Because a PWA is built on HTML, CSS and JavaScript, every WCAG 2.1 guideline applies, and there is no platform-specific accessibility layer to fall back on.

A few areas need particular attention. When a PWA runs in standalone display mode, the browser’s built-in navigation controls disappear. If your app shell does not provide keyboard-accessible navigation, focus management, and visible focus indicators, keyboard and screen reader users lose orientation immediately. Use ARIA landmarks (<nav>, <main>, <header>) to give assistive technologies a clear document structure.

Offline states need accessible error messaging. A blank screen or a silent failure when the network drops is not acceptable. Display a clear, text-based offline notice that screen readers can announce, and ensure any retry controls are reachable by keyboard.

Push notification permission prompts should be triggered by a deliberate user action, not on page load. Unsolicited permission requests are disruptive for all users and particularly disorienting for screen reader users who may not have context for why the browser is interrupting them.

Finally, test with real assistive technology. VoiceOver on iOS, TalkBack on Android, and NVDA or JAWS on Windows each interact with web content differently. An automated accessibility audit catches structural issues, but it will not catch focus-trap bugs or confusing announcement sequences that only appear during real interaction.

When does CantyDigital recommend a PWA over other options?

PWAs are a strong fit for a specific set of client profiles, and being clear about that saves everyone time.

Consumer-facing services with repeat visitors benefit most: media publishers, retail catalogues, booking platforms, and local service businesses where users return weekly. The home-screen presence and push notifications deliver measurable retention gains for these audiences. For a business considering automated lead capture and funnel optimisation, a PWA with offline form handling and background sync is a natural complement.

Responsive websites without PWA features are the right call when the product is primarily informational, the audience is unlikely to install anything, and the budget is better spent on content and SEO. Not every business needs a home-screen icon.

Native apps remain the better choice when the product depends on low-level device APIs (continuous background location, Bluetooth peripherals, complex camera processing), needs deep app store integration, or requires intensive background computation that web APIs cannot support reliably across iOS and Android.

When advising clients, CantyDigital weighs three factors: the user’s likely behaviour pattern (will they return often enough to justify installation?), the technical requirements (do any features require native APIs?), and the SEO and discoverability goals (a PWA at a URL is indexable; a native app is not). Most Australian SMEs land in PWA territory when those three questions are answered honestly.

CantyDigital can build your PWA from the ground up

Building a production-grade PWA means more than adding a manifest file. It means a tested service worker strategy, correct HTTPS configuration, Lighthouse-verified installability, and a codebase structured for long-term SEO performance.

CantyDigital is a Wollongong-based digital agency with 12 years of experience delivering high-performance web builds for Australian businesses, with no lock-in contracts and a focus on measurable results. Whether you are starting from scratch or modernising an existing site, the team handles the full delivery: front-end build, service worker implementation, performance tuning, and SEO alignment. Visit the website design FAQs to understand what a typical project covers, or go straight to Cantydigital to start a conversation about your project.

Sources

• Web
• Progressive Web Apps – Microsoft Learn

Recommended

• What is responsive web design: a developer’s guide
• What is modular web design: a practical guide
• Accessibility in web design: a practical 2026 guide
• Role of grid systems in web design: 2026 guide