ActiveManage Docs ← Back to activemanage.co.uk

Progressive Web App

Progressive Web App Overview

A Progressive Web App (PWA) is a web app that behaves like a native mobile app — installable to the home screen, runs full-screen without browser chrome, works offline, supports push notifications. ActiveManage produces a PWA-capable shell out of the box; the controls in this section let you tune it.

Phone home screen with the platform's icon installed alongside native apps; opening it launches the platform full-screen with no browser chrome, splash screen visible during load

What Makes a PWA

  • Manifest: A JSON file declaring the app's name, icons, theme colour and start URL.
  • Service worker: Background JavaScript that caches assets, handles push, and works offline.
  • HTTPS: Required — browsers won't install PWAs from insecure origins.
  • Responsive design: The app must work well at phone and tablet sizes.
  • Discoverable installation prompt: Browsers show an “Install” option in the menu or address bar.

Why Bother

  • No app store gatekeeping: Users install with one tap; no Apple/Google review needed.
  • One codebase: Same site works in browser and as an installed PWA.
  • Offline support: Useful for field workers, intermittent connections.
  • Push notifications: Even when not in the foreground.
  • Home screen presence: Brand visibility next to native apps.

Where PWAs Shine — and Don't

  • Great for: Internal tools, B2B SaaS, marketplace apps, content sites, field service.
  • Less ideal for: Apps requiring Bluetooth, NFC pairing, deep OS integration (calendar add-ons, photo library access — all improving but still limited).
  • iOS gotchas: Push notification support landed only in iOS 16.4 and requires the user to add the PWA to their home screen first.

Worked Examples

  • Field service technicians: Install the PWA on their phones; works offline at remote sites; pushes job assignments to the device.
  • Healthcare staff portal: Installed PWA replaces the browser shortcut; sign-in persists; biometric unlock works on supported devices.
  • Marketplace seller app: Mobile-optimised PWA for managing listings and chatting with buyers; install banner appears after second visit.
  • Internal status board: PWA mode used in kiosk style on dedicated tablets in the operations centre.

PWA Home Page Setting

The PWA home page is the URL the app opens when launched from the user's home-screen icon. Choose well — it's the first thing the user sees on every cold start.

Configuration showing 'PWA start URL' input field with current value '/dashboard', a 'Test as installed PWA' button, and helper note explaining how this differs from the browser start URL

Why It's Different from Your Web Home Page

The browser home page (the URL someone hits when they type in your domain) is typically a marketing landing page — “Sign up”, “Pricing”, “Features”. The PWA home page assumes the user is signed in and ready to work; routing them through marketing is a friction step that doesn't make sense for the installed-app experience.

Recommended Patterns

  • SaaS apps: /dashboard or /home — the user's primary workspace.
  • Field-service apps: /jobs/today — the technician's task list.
  • Marketplace seller app: /seller/inbox — buyer messages first.
  • Member portal: /account — their profile and recent activity.

If Not Signed In

If the PWA opens and the user isn't authenticated (session expired, fresh install), the start URL redirects to the login page, which after sign-in bounces the user back to the start URL. The result: a seamless return to where they expected to be.

Worked Examples

  • CRM SaaS: Start URL /leads/my — the “my pipeline” page.
  • Healthcare: Start URL /today — today's patients and appointments.
  • Internal ops: Start URL /queue — the current operational queue.
  • Education: Start URL /courses — student's enrolled courses.
Tip: Test from a freshly-installed PWA on a real device. Some routing edge cases (deep links, role-based redirects) only show up in PWA mode where the browser back button can behave differently.

Remember State Across Sessions

One of the biggest UX wins of an installed PWA is that the app feels stateful — you reopen it and you're back where you left off. This article covers what's remembered, how the state survives device reboots, and how to tune retention.

Diagram showing PWA closed mid-task → user reopens later → same page restored with filter state, scroll position, draft form contents, open record IDs all preserved

What Can Be Remembered

  • Last visited URL: User reopens to where they were.
  • Active filters: Saved per-page so list views remember their state.
  • Draft form contents: Unsaved input persisted; restored on reopen.
  • Scroll position: Long pages restore to the previous scroll.
  • Open tabs / panels: Multi-pane UIs remember which panes were open.
  • Selection: Active rows in browse views.
  • Search query: The query that produced the current results.

Where State Lives

  • LocalStorage: Per-domain key-value store, persistent across sessions.
  • IndexedDB: Structured storage for larger state (drafts, cached records).
  • Service Worker cache: Page shells and assets for fast reopen.
  • Session cookie: Authentication, refreshed via long-lived refresh tokens.

Privacy and Cleanup

Users can clear stored data by uninstalling the PWA. From inside the app, a “Clear local data” action wipes all state without signing out from the server. Useful when a device is shared or before lending it out.

Worked Examples

  • Field engineer logs a job: Power dies mid-form. Reopens app, draft preserved, finishes and submits.
  • Support agent on long ticket: Closes laptop overnight. Reopens, scroll position restored, comments draft preserved.
  • Multi-step booking: User abandons booking flow mid-way, returns next day, finds step 3 of 5 still in progress.
  • Filter state: User filters tickets to assignee=me and priority=high; closes app; reopens; filters still applied.