PWA vs native app: which to choose for field teams

The supervisor is on the quay with a tablet, the gatehouse shares one phone between shifts and the technician on board goes hours without signal. When a system has to reach these people, the first question is always the same: do we need an app in the store? Most of the time, no.

This article shows what a PWA can already do on a phone, when a native app is still required and how each one behaves offline. In the middle you will find an 18-item checklist to define your field team's app before asking for a quote. If your question comes earlier, between buying a product and building one, start with custom software vs. off-the-shelf.

What is a PWA?

A PWA, or progressive web app, is a website built to behave like an app. The user opens an address, installs it on the home screen and uses it full screen, with its own icon. Underneath, it is still web technology.

MDN defines a PWA as "an app that's built using web platform technologies, but that provides a user experience like that of a platform-specific app". In practice, that means one codebase for Android, iPhone and desktop, and an address your team receives by link or QR code.

What can a PWA do today?

A modern PWA does almost everything a field team uses day to day:

• Uses the camera for photos and to read QR codes.
• Reads GPS location while it is open.
• Receives push notifications, including on iPhone.
• Keeps the interface and part of the data on the device so it opens offline.
• Updates for every user the moment a new version is published.

Notifications on iPhone are recent. The WebKit blog, from the team behind Safari's engine, announced in February 2023 that iOS and iPadOS 16.4 support push notifications for web apps added to the home screen. The permission request has to come from a user tap, such as an "enable alerts" button. Before that, notifications were the main reason to go to the store.

When is a native app required?

A native app is required in four situations: selling to the public through app stores, charging inside the app, tracking with the phone locked and using specific device features.

Payment rules weigh more than they seem to. Apple's App Review Guidelines, in section 3.1.1, say that features sold inside the app, such as subscriptions or premium content, must use the store's in-app purchase system.

In the health app we built, store subscriptions and Sign in with Apple decided for native. We used React Native with Expo, which builds the iOS and Android versions from the same codebase, and the same Ruby on Rails back end serves the app.

How does each one behave offline?

Both can work without signal, but the development effort differs. In a native app, storing data on the device is the natural path. In a PWA, you need to plan what is stored, for how long and how data syncs when the connection returns.

One iPhone detail shapes the design. According to web.dev, Safari may clear data a site has stored on the device after seven days without use, but that cap does not apply to PWAs added to the home screen. For a team that works without signal, installing the app is no longer optional and becomes part of the rollout procedure.

The tricky part is conflicts. If two people edit the same record offline, the system needs a rule to decide which change wins. That is a business rule and must be defined before development, whichever technology you choose.

On vessels and in remote areas, this is usually the requirement that weighs most. In the vessel inspection case study, a finding recorded on board shows up ashore as soon as the device is back online.

Checklist: what should you define before choosing?

The checklist below gathers the decisions that change the choice between PWA and native, and those that change the cost of the project. Answer it with people who know the field routine, not only with whoever approves the purchase.

If no "native" item was ticked, a PWA will do. If one or more were, the next question is whether the native app has to exist from day one or can come later, using the same API. Bring the completed checklist to the conversation with whoever will build the app: it covers much of what a first meeting would.

Which one costs less to maintain?

A PWA costs less to maintain. There is one codebase and no old versions in circulation, because everyone gets the new one at the same time. There is also no store review and no developer account to manage.

A native app means publishing to two stores, keeping up with each store's rule changes and living with users who are slow to update. Tools like Expo cut much of that work, but it does not go away. It belongs in the support budget for the app. If the question is what drives the price of building the app, not only of maintaining it, how much does an app cost lists what belongs in the quote.

How secure is a PWA?

A PWA is as secure as a well-built web system. It only runs over an encrypted connection, access requires a login and permissions are checked on the server for every action. Camera, location and notifications need explicit user permission, requested by the operating system itself.

The difference from native is distribution. Anyone who finds a store app can install it. An internal PWA is an address only your team receives, and it does not show up in store searches. For operations systems, that is usually an advantage.

What needs attention is the shared device. At gatehouses and on vessels, several people often use the same phone or tablet. The system should log out after inactivity and record who did each action. Our port operations case study shows this kind of use at the gatehouse, and the article on the digital permit to work shows what regulations require when signatures happen on a phone.

Can you publish a PWA in an app store?

Yes, with limits. On Google Play, a PWA can be published inside an Android app through Trusted Web Activity, documented by Google. The App Store is stricter: section 4.2 of Apple's guidelines asks apps to offer features, content and interface that go beyond a repackaged website.

For internal teams, publishing in a store rarely pays off. For a product sold to the public, it is usually better to build the native app from the start, reusing the web system's API.

When does neither a PWA nor a native app solve it alone?

Neither one solves the problem when the issue is the process or the system behind the app. A field app is the front end of a system: if records, rules and reports still live in spreadsheets that do not match, the app only moves the mess onto the phone.

In that case, the first step is the custom web system that holds the data and the rules, with the app as one of its screens. That is how we structure our mobile app projects: one API, consumed by the PWA, the native app or both. If you would like to talk about your team's app, the first conversation has no cost.