The Web App

The Progressive Web App

The platform can be installed on a device like an app — an icon on the home screen, its own window, no browser chrome.

Where to find it

Architect Panel → Configuration:

• Site Settings — the Progressive Web App and Service Workers option groups

Architect Panel → Layout & Pages:

• Dependencies — the files the site loads, and what the offline cache is built from

Architect Panel → Background Messaging:

• Push Notifications — the VAPID keys web push needs

Configuration is in Site Settings rather than on a dedicated console. There are two option groups: Progressive Web App and Service Workers.

What it gives you

• An icon on the home screen, launching straight into the app.
• Its own window without an address bar, which makes it feel like an application rather than a website.
• A defined starting page, so it opens somewhere useful.
• Remembered position, so a user returns where they left off.
• Optional offline caching and push notifications, through the service worker.

What it is not

Not a native app. It does not appear in an app store, cannot use device features a browser cannot reach, and is installed by the user choosing to add it rather than by downloading it.

If you need store distribution, biometrics, camera capture or background location, that is the mobile app builder, not this.

The trade is real though

A progressive web app costs almost nothing — a few settings on a site you already have — and needs no store review, no release process and no build. For a lot of internal tools that is the right answer.

Two settings, then the service worker

The web app itself is two settings: the home page and whether state is remembered. Everything else — offline caching, push — comes from the service worker engine, which is separate and switched on independently.

Installation is the user’s choice

Which is the main practical limitation. Nobody gets the app unless they add it, and most people do not know they can.

If you want adoption, tell people how — a short instruction with screenshots for each platform is worth more than any amount of configuration.

Test on a real device

Installed, not in a browser tab. The installed experience differs — no address bar, different navigation, different back behaviour — and problems only appear there.

Worked example

A field service organisation runs its job app as an installable web app with a defined home page and state remembered, offline caching on for the app scope only. Staff were sent a one-page instruction with screenshots for adding it, and adoption reached almost everybody within a fortnight.

Recommendations

• Set the home page before promoting the app.
• Tell people how to install it — nobody discovers it.
• Test installed, not in a tab.
• Use the mobile builder if you need device features or store distribution.

Getting It Installed

Nothing installs the web app for a user. They choose to add it, and most will not without being told.

Where to find it

Architect Panel → Configuration:

• Site Settings — the Progressive Web App and Service Workers option groups

How it is added

• iPhone and iPad — the share button, then Add to Home Screen. It must be Safari; other browsers on iOS cannot do it.
• Android — the browser menu, then Install or Add to Home Screen, and Chrome often prompts on its own.
• Desktop — an install icon in the address bar in Chrome and Edge.

The iOS restriction matters

A user who has set another browser as their default has to open the site in Safari specifically. That single point defeats more installations than anything else, and your instructions should say it explicitly.

Write instructions with screenshots

Three short pages, one per platform, with the actual buttons circled. This is the highest-return effort in the whole exercise — configuration is quick and adoption is the hard part.

Ask at the right moment

Somebody who has just used the site successfully is receptive; somebody signing in for the first time is not. If you prompt, prompt after a few visits rather than immediately.

What changes once installed

• There is no address bar, so users cannot see or edit the URL.
• Navigation depends entirely on what your interface provides — an app with no visible way back traps people.
• It launches at the configured home page.
• The service worker, if enabled, is active.

Provide navigation, because the browser will not

The most common complaint about an installed web app is being stuck on a page. Make sure every page has a visible route back.

Updates are automatic, mostly

The app loads your site, so changes appear without anybody reinstalling. Cached files are the exception — if the service worker is caching, a user can be running old assets until the cache updates.

Uninstalling is just removing the icon

Which is worth knowing when supporting somebody with a stubborn problem: remove it, reinstall it, and most caching oddities disappear.

Worked example

An organisation published three short instruction pages with screenshots, sent them once, and repeated the message after a fortnight. The iOS page led with "you must open this in Safari", which had been the single largest source of failed attempts.

Recommendations

• Say "use Safari" prominently for iOS.
• Screenshots per platform, one page each.
• Give every page a visible way back.
• Remove and reinstall as the first support step.

The Home Page

A single setting names the page the web app opens at. It is short to configure and disproportionately important.

Where to find it

Architect Panel → Configuration:

• Site Settings — the Progressive Web App and Service Workers option groups

What it does

The configured page is where the app starts, and it is also the anchor for remembered state — the point from which a user’s previous session is replayed.

So it is not merely a landing page; it is the root of the app’s navigation.

Choose the page people actually need

Not a welcome screen, not a menu of everything. The right home page is the one that answers "what do I have to do now" for the largest share of users.

For a field app that is today’s jobs. For a support tool it is the open queue. A page that requires two taps before showing anything useful costs those two taps every single time the app is opened.

It must work for everybody

There is one setting, so every user gets the same starting page. Choose one that degrades gracefully for people with fewer permissions rather than one that shows an error to half your users.

It must be fast

It is the first thing anybody sees and it is loaded on a phone, often on a poor connection. A home page assembling six reports is a home page people wait for, several times a day.

And it must work signed out

Or redirect cleanly to sign-in and return afterwards. An app that opens to an error when the session has expired reads as broken.

Changing it is not disruptive

Unlike most decisions in this category. If the home page turns out to be wrong, change it — installed apps pick it up on their next launch.

Watch what people do next

If most users navigate away from the home page immediately, and always to the same place, that place is your home page. This is the cheapest usability signal available.

Test it cold

From a fresh install, on a phone, on a slow connection, as a user with ordinary permissions. That is the real first experience, and it is rarely what the person configuring it sees.

Worked example

An app originally opened to a dashboard of six panels. Usage showed almost everybody going straight to today’s jobs, so that became the home page; the dashboard moved to a menu item. Time to first useful action fell from several seconds and two taps to none.

Recommendations

• Open at the task, not at a menu.
• Choose a page that works for every permission level.
• Keep it fast — it loads on phones on poor connections.
• Watch where people go next and follow them.

Remembering Where They Were

The web app can return a user to where they were rather than to the home page.

Where to find it

Architect Panel → Configuration:

• Site Settings — the Progressive Web App and Service Workers option groups

What is actually recorded

For each page a user visits: the address, the query parameters, any posted form values, and the scroll position — against that user’s identity.

Because query parameters are included, filters and selections that live in the URL come back with the page. Because scroll position is included, a long list returns where the user was reading.

How it is replayed

On reopening, the platform takes the user’s recorded steps from their most recent visit to the home page onwards, and replays them. So the app rebuilds the path they were on rather than jumping to a single page out of context.

That is why the home page setting matters here — it is the anchor the replay starts from.

What it does not remember

Unsaved form input that was never submitted. A half-completed form is not recovered, and anybody who has been told otherwise will be disappointed at the worst moment.

If losing work is a real risk in your application, that needs solving in the form, not here.

When it is clearly right

• Long forms and processes spanning several pages.
• Field use, where the app is interrupted constantly.
• Long lists, where losing the scroll position means finding your place again.

When to leave it off

• Shared devices. Restoring one person’s position on a shared tablet shows the next person where they were.
• Sensitive content, where reopening onto a record is not appropriate.
• Anything where a fresh start is correct — a till, a kiosk, a check-in screen.

It stores what people did

The recorded state includes addresses and posted values, which is a record of activity. Consider retention, and consider what it holds before enabling it on anything sensitive.

Give people a way home

Restoring to a deep page is helpful and occasionally disorienting. A visible route back to the home page turns a confusing restore into a minor one.

Test the interruption

Use the app, close it mid-task, reopen it. That is the experience the setting exists for, and it is the only way to know whether it feels helpful or strange in your application.

Worked example

A field app keeps state on, because engineers are interrupted constantly and returning to the middle of a job sheet saves real time. The same organisation’s reception check-in screen has it off, because each visitor should start fresh.

Recommendations

• On for personal devices, off for shared ones.
• Do not promise form recovery — it is not stored.
• Consider retention of the recorded activity.
• Test by interrupting a real task.