Progressive Web App

For a long time the web and apps had exactly opposite strengths. A website opens for anyone with a URL and updates the moment you change it, but it had no icon on the home screen, did nothing once the network dropped, and couldn't send notifications. Apps had all three and had to be built separately per operating system, with a review before every change.

Pagedeck had to choose between them. Enterprise meetings kept producing the question of whether there was an app, and the answer kept being no. Theo estimated that building for both operating systems would take six months even after hiring. What customers actually wanted wasn't the full product — it was opening a document and leaving a comment while out of the office. Six months of work for two of those was a poor trade.

A progressive web app (PWA) is the result of choosing to adapt the existing web build instead. Rather than building something new, you add a few pieces to the site so it installs to a home screen, opens offline, and can send notifications. Mia and Theo spent three weeks doing exactly that.

It fills four gaps the web had, each by a different mechanism.

1. Home screen installation — you put a description file on the site listing the icon, the name, and the start screen. It's called a web app manifest, and with it the browser treats the site as installable. Once installed it opens full-screen with no address bar, which makes it visually indistinguishable from an app. Most users who install one never learn it's a website.
2. Offline and unstable networks — a small program sits between the browser and the network and intercepts requests. It's called a service worker. It stores screens and data it has fetched once, and answers from that store when the network is gone. Caching — keeping a result to reuse it — is what you're handling directly here. A document opening on the subway is this piece doing its job, and nothing else in the stack can do it.
3. Notifications — push notifications, delivered by the device itself, become available from the web too, limited to users who installed it and granted permission. That limit makes the reachable audience smaller than a native app's.
4. Updates and release — no store review. Change the web build and it applies the next time someone opens it, so an urgent fix ships in minutes rather than after a review queue. Install size stays small as well: what gets installed is a shell, and the content arrives over the network as it always did.

Two preconditions. The site has to be served over an encrypted connection, and both the description file and the request-intercepting program have to be present. Missing any one of the three and the browser won't treat it as installable, and no error message explains why.

Three other routes solve the same problem.

1. Native apps — a mobile app built the way each operating system prescribes. It's the application installed on a phone, and it's the right call for products that reach deep into device hardware like cameras or Bluetooth, and for products where users arrive through store search. The cost is building twice and passing review each time, and carrying two codebases afterward.
2. One codebase producing both apps — build once and ship to both stores. You get close to native results at lower cost, but every use of device hardware goes through an intermediate layer, so new platform features mean waiting for support.
3. Leaving the web build as it is — adjusting only the layout to the screen size. When installation, offline, and notifications aren't needed this is the cheapest option, and plenty of products genuinely don't need all three, however often the app question comes up.

Three questions decide it: how deeply device hardware has to be used, whether users arriving from store search matter, and whether offline actually affects real usage. None of them applying points at option three, which is a common and correct answer.

Differences between operating systems get checked too. On one family the install flow is buried in a browser menu and notification support arrived late. That can mean building a separate screen explaining how to install, which is work the store would otherwise have done for you.

"Let's turn the current web build into a PWA rather than building an app. Three weeks."

Adapting what exists to gain installation and offline.

"Documents don't open on the subway. We need to revisit the cache strategy."

The piece responsible for offline behavior isn't wired properly.

"This feature can't be done as a PWA. It needs device access."

Checking the limits of web technology and looking elsewhere.

Pagedeck spent three weeks adding the description file and the request-intercepting program. It stored the document list and the ten most recently opened documents so they could be read with no network, and comments left in that state got sent once the connection returned, which took a queue nobody had needed before.

A month later, three enterprise customers put installation instructions into their internal onboarding. The question about an app dropped off without disappearing entirely. Customers who expected to find it by searching a store still had to be sent an install link.

The most common belief is that a PWA replaces a native app. It installs, it notifies, it opens offline, so it looks complete. But anything reaching into the device still meets a wall, and what works varies by browser and operating system version. You also don't inherit traffic from store search. Start from the assumption of replacement and a list of things that don't work piles up after launch, at which point you build both. "Overlaps enough to be sufficient for many products" is the accurate phrasing.

The other common belief is that adding the request-intercepting program is what makes something work offline. Dropping the piece in isn't hard, so it feels that way. But deciding what to store, for how long, and when to refetch is the actual work. Store everything and you eat device storage while serving stale content; store nothing and offline shows a blank screen. Neither failure is visible in testing on a good network. Without a rule for discarding what you stored, users mistake a document from three days ago for the current one.