Progressive Web Apps for Business: Offline Capability and Business Case

A progressive web app (PWA) pays off for businesses above all when teams or customers use the same application regularly, the connection is not always stable and the app is to be distributed by link instead of through the App Store. It is a web application that can be installed like an app, works offline and covers all devices with one codebase. There are limits with deep hardware integration and with individual iOS features.

In this article we show when a PWA pays off, how offline capability works technically, what to consider with push notifications and when a native app is the better investment after all.

What makes a progressive web app

At its core, a PWA is a web application that runs in the browser but behaves like an app. It can be installed on a smartphone or desktop, starts in full screen and can provide content offline. Three technical building blocks form the foundation:

• Web app manifest: describes the app’s name, icons, colors and start behavior.
• Service worker: a script that sits between the app and the network, intercepts requests and caches content.
• HTTPS: Without an encrypted connection, browsers refuse the service worker and with it the most important PWA features.

Installation works differently depending on the system: Android and desktop browsers such as Chrome or Edge offer it directly, while on the iPhone users add the PWA to the home screen via Safari’s share menu. Explain this during rollout.

When a PWA is the right choice

PWAs are particularly strong where people work with the same application regularly and the connection is not always stable. Typical areas of use:

• Field service: Service technicians access jobs, instructions and checklists even in basements or workshops without reception.
• Checklists and inspection reports: Forms are filled out offline and synchronized as soon as a network is available again.
• Product catalogs: Field sales staff present the range and data sheets at the customer’s site – independent of the local Wi-Fi.
• Portals for returning users: Customer or partner portals benefit from fast redisplay from the cache.

Another advantage: the app store is not always necessary. Distribution is by link, for example via email, QR code or intranet. Updates are available to everyone immediately, without users having to update anything or waiting for a store review. For internal tools in particular, this saves coordination effort with IT.

Criterion	PWA	Cross-platform app	Native app
Distribution	link, QR code, intranet	store or internal distribution	store or internal distribution
Updates	immediately for everyone	via the store	via the store
Device features	camera, location, files good; Bluetooth, NFC, background processes limited	largely, partly via additional modules	full access
Codebase and maintenance	one for all platforms	one, plus platform-specific adjustments	separate per platform
Discoverability	web search and direct link	store search	store search

When native apps have the edge

As convincing as PWAs are, they are no cure-all. A native app or a cross-platform solution is usually the better choice when:

• deep hardware integration is required, for example with Bluetooth devices, NFC or background processes – such browser interfaces are hardly available on the iPhone,
• presence in the App Store is an important sales channel,
• very compute-intensive functions or elaborate graphics are central,
• iPhone users are a central target group and features are needed that Safari supports only to a limited extent – push notifications, for example, only work there once the PWA is installed on the home screen.

The decision is rarely black and white. A project often starts as a PWA and later grows – with the same backend interface – to include a native app. If a PWA should still appear in the store, this is possible via a wrapper; Apple, however, often objects to apps that merely embed a website. You can find more about the options on our Mobile Apps page.

Offline capability and cache strategies

Whether a PWA feels good in everyday use is decided by the cache strategy. The service worker determines for each type of content whether it comes from the network or from the cache. Libraries such as Workbox take over part of the manual work.

Strategy	How it works	Suited for
Cache first	content comes from the cache first, the network only when needed	logos, fonts, stylesheets and the interface shell – the app starts almost instantly, even without a connection
Network first	network first, the last saved version if there is no connection	job lists, stock levels, appointments – ideally with a notice such as “Offline – as of 9:15 a.m.”
Stale while revalidate	the saved version immediately, update in the background	product data, instructions, catalogs – speed matters more than up-to-the-second accuracy

Offline forms and synchro­niza­tion

Entries such as inspection reports or working hours are stored locally in the browser – usually in IndexedDB – and transferred as soon as the connection is back. One project type we have already implemented is a mobile app for service technicians with offline synchronization. What matters:

• Conflict rule: What applies if two people have edited the same job – last change wins, merge or a query?
• Visible status: Users see what has not yet been transferred.
• Trigger for the transfer: Not every browser supports background sync – Safari, for example, does not. So plan for a transfer at app start and when the connection returns.
• Do not overestimate storage: Browsers can remove local data when storage runs low. Important entries belong on the server quickly.

Cache invalidation: so nobody sees outdated data

The biggest pitfall with PWAs is not a missing cache but too much of it. If a service worker delivers old prices or outdated instructions, users quickly lose trust. That is why we document in every project which content is cached for how long and how it is renewed.

Versioned caches that are cleared in a targeted way with every release have proven their worth, as has a discreet notice “New version available – update now.” A new service worker is first installed in the background and often takes over only after the app has been closed and reopened – the notice with a button solves exactly this problem. That way, the app stays fast and still reliably up to date.

Push notifica­tions: only with consent and real added value

Push messages can bring users back – or drive them away. Technically, they require explicit permission in the browser. Do not ask for it on the first page view, but at a moment when the benefit is clear, for example after an order: “Would you like to be notified as soon as your delivery is on its way?” On the iPhone, push also only works if the PWA is installed on the home screen.

Equally important are clear content, a moderate frequency and an easy way to turn notifications off again. Which consents and notices are required under data protection law is best agreed with your data protection officer.

The business case: PWA or native app?

Five questions help with the decision:

1. Target group: Internal teams, partners or end customers – and on which devices?
2. Distribution: Is a link enough, or must the app be discoverable in the store?
3. Features: Which device features are mandatory, which optional?
4. Maintenance: How much effort is planned for upkeep and updates? A PWA means one codebase for all platforms.
5. Time to launch: How quickly must a first version be productive?

If several answers point toward a link, returning users and a quick rollout, a PWA is usually a good starting point. How budgets for app projects are made up is explained in the article How much does an app cost?

Practical example: inspection reports in a building services company

Suppose a building services company wants its technicians to fill out maintenance reports digitally at the customer’s site. The devices are company smartphones running iOS and Android, basements and boiler rooms often have no reception, and the app is used internally only. The five questions yield: internal target group, a link is enough for distribution, camera and forms are needed, one codebase saves maintenance, and the launch should happen quickly. The result is a PWA with offline forms and synchronization. If a Bluetooth measuring device is added later, that part can be supplemented as a native app – the backend stays the same.

Checklist for your PWA project

• Use cases with fluctuating connectivity identified
• Manifest with name, icons and start behavior defined
• Cache strategy per content type defined and documented
• Offline notices and synchronization logic including a conflict rule planned for forms
• Versioning and cache invalidation per release defined
• Push only with consent, clear benefit and an opt-out option
• Tests on real iPhones, Android devices and desktop including offline scenarios

How Nano Concepts supports you

On our service page for progressive web apps you can see how we proceed: from the question of whether a PWA fits your project, through cache strategy and offline concept, to testing on iOS, Android and desktop. Lean PWAs without a complex backend belong to our Starter package from €2,500, solutions with a backend, user management and interfaces to the Professional package from €8,000. In the free initial consultation, we work out together which path is right for you. The process of app development is described in the article App development: The process from idea to store.

This article does not replace legal advice.