Native app, web app or PWA: an architectural choice, not a fashion one

The question "do we need an app?" almost always comes with an answer already in mind: the icon in the store. But choosing between native, cross-platform, web app and PWA is not about the icon. It is about hardware access, distribution, maintenance costs over time and how many codebases have to be kept alive. It is an architectural choice, and it is worth making on technical grounds.

The four options, briefly

• Native app: Swift for iOS, Kotlin for Android. Two codebases, full access to system APIs, maximum performance.
• Cross-platform: React Native or Flutter. Much of the code is shared, with platform-specific integrations. React Native uses native components; Flutter mainly draws the interface through its own engine.
• Web app: an application in the browser, one codebase for every device and instant updates.
• PWA: a web app that offers an installable experience through a manifest and compatible browsers. Offline use and notifications need dedicated implementations, often based on service workers: they are not automatic consequences of installing the app.

Halfway sits Capacitor: a web app wrapped in a native shell, publishable in the stores and with access to device plugins.

The real limits of PWAs

PWAs were long promoted as the universal answer. Today they are much more mature, but on iOS there are differences to know:

• push notifications work from iOS 16.4 only for PWAs added to the Home Screen, and the user has to do that step manually;
• background sync and some APIs (Bluetooth, NFC, extended file system access) are unavailable or only partly available;
• storage can be cleared by the system if the app is not used for a while;
• web distribution does not require the stores; getting into them may need packaging wrappers and platform-specific checks.

On Android and desktop the limits are much smaller. If the audience is mostly internal (staff, members, existing customers) on mixed devices, a PWA can cover the requirements, to be verified on the devices and system versions actually in use.

When native is really needed

Native or cross-platform become necessary when:

• the app uses hardware heavily: Bluetooth Low Energy, sensors, camera with real-time processing, background location;
• high graphics performance or complex 60 fps animations are needed on low-end devices;
• the store is the channel through which people find the service;
• the app must work offline for long periods with reliable sync.

Between pure native and cross-platform, for most projects I see cross-platform is the best compromise: one codebase, two stores, native modules only where needed.

The cost you do not see in the quote

A store app is not delivered once. Every year Apple and Google release new OS versions, change publishing requirements, deprecate APIs and raise minimum SDK levels. The project's native libraries have to be updated accordingly. With two native apps, the work doubles.

A web app or PWA updates with a deploy, without store review and with centralised distribution of updates. Caches, service workers and sessions already open still need a strategy for the version change. It is a difference in operating cost that weighs more than the upfront cost.

The backend is what lasts

Whatever the client, the part that lasts longest is the backend: APIs, authentication, data, integrations. Designing it well, with documented APIs independent of the client, lets you start with a web app and add a native client later, reusing the backend and integrations, though the new client must still be developed and verified. The most expensive mistake I see is an app built with its logic inside the client, which becomes impossible to bring to another platform.

How I decide

The questions I ask at the start:

1. Who uses the app and how do they find it: in the stores, or through the service provider?
2. Which device features are really needed, not "might be needed"?
3. How much must it work offline, and with what kind of sync?
4. Who will maintain it in three years, and with what yearly budget?
5. Is there already a web app or management system to start from?

If the answers do not point to specific hardware or the store as a channel, I suggest starting from the web.

Offline and sync, the most underrated part

"It works offline too" is a phrase that hides a lot of work. In a PWA the service worker decides what to serve from cache and what to fetch from the network: static assets from the cache, data from the network with a cache fallback, pages refreshed in the background. Data the user creates without a connection must be stored locally, in IndexedDB, and sent to the server when the network returns.

The real problem is conflict: two devices edit the same record offline, or the record changed on the server in the meantime. You need an explicit rule, agreed with whoever knows the process: last write wins, the server wins, or the user is asked. Without that rule, sync loses data silently.

On iOS, background sync for PWAs is limited, so sending happens when the app is reopened. For many use cases (checklists, notes, forms filled in the field) that is fine; for an app that must sync continuously even when closed, it is an argument for native or cross-platform.

Checking offline use and concurrency

A local queue is not enough to guarantee synchronisation. Every operation needs a stable identifier to avoid duplicates when it is retried, and every editable record must carry the version the client read. The server accepts the change only if the version matches, otherwise it returns a conflict to be resolved.

The minimum test covers: creating something offline, reopening the app after closing it, sending a duplicate, an expired session and a simultaneous edit from two devices. Data must stay distinguishable between saved locally, sent and confirmed by the server. On iPhone I check separately the experience in the browser and the one added to the Home Screen: notifications require installation, permission and an explicit user interaction.

Reference: Web Push for web apps on iOS and iPadOS, WebKit.

My take

My preference is clear: web app or PWA as the first choice, native when the requirements demand it. Not out of laziness, but because a single codebase, updated with a deploy, lowers the cost of the whole lifecycle. The Altura Vela management app and the Fix and Sail platform are Nuxt.js web applications used daily on phones, and neither needed a store to work.

When something closer to the device is needed, it is done carefully: with VeWorld, for example, I worked on the React front end of a Chrome extension, where the execution context imposed precise constraints. The choice of tool always comes after the requirements, never before.

Why work with me

I started programming in 1999 and have delivered more than 300 projects, many of them apps and sites for agencies, from Rome and remotely. I build web apps, PWAs and cross-platform apps, and design the backend so the client can change without rebuilding everything.

If you are considering an app, get in touch: in a call of about 20 minutes we work out which architecture your case really needs. The service is in Mobile apps.