PWA or Native App: Which Requirements Actually Decide It

The question is usually asked in the wrong form: "should we build a mobile app?" A mobile app is not a requirement, it is a delivery mechanism. The decision becomes straightforward once you write down what the software has to do on the device — and in most business cases the list is short: open a work order, fill a form, take a photograph, capture a signature, work where there is no signal, sync when there is. That list does not require a native app. Some other lists do, and it is worth being precise about which.

The three options, briefly

• Progressive web app. A web application built to standard web technologies that can be installed to the home screen, launches full-screen and works offline. One codebase, shared with your desktop system.
• Cross-platform native. One codebase compiled to native applications for iOS and Android. Full device access, at the cost of a separate build, store releases and a set of platform-specific issues.
• Fully native. Separate applications per platform. Maximum capability and maximum ongoing cost, since every change is made and released twice.

The four requirements that actually decide it

Almost every real decision turns on these, and they can be answered before any technical discussion:

1. 1. Does it need to run while nobody is looking at it?

   Continuous location while the phone is in a pocket, or a process that must run on a schedule with the app closed. This is the clearest native requirement, because the operating systems deliberately restrict what a web app may do in the background.

2. 2. Does it talk to hardware beyond the camera?

   A Bluetooth measuring device, an NFC tag, a specialised scanner. Web Bluetooth and Web NFC are not implemented in Safari at the time of writing, so any iOS requirement here points to native.

3. 3. Do people need to find it in a store?

   If the users are your own staff or your dealers, they can be sent a link. If the users are members of the public who will look for you by name in an app store, no amount of web capability substitutes for being listed there.

4. 4. Are notifications the product or a convenience?

   Push works on Android from the browser and on iOS only once the web app has been added to the home screen. If the whole value depends on a notification arriving reliably to people who may not complete an installation step, weigh that carefully.

If all four answers are no, a PWA is very likely sufficient, and the remaining differences are matters of degree rather than capability.

The comparison, in both directions

Where PWAs genuinely fall short

These are the points a fair comparison has to include, and they are the ones most often left out:

• Installation is a step people skip. On iOS there is no install prompt; the user opens the share menu and chooses to add to the home screen. Until they do, push notifications are unavailable. Plan the rollout around that, with a short instruction sheet rather than an assumption.
• Local storage is not guaranteed forever. A phone under storage pressure can clear a web app's cached data. For a day's queued work this is rarely a problem; for records held offline over weeks it is a design risk, and the answer is to prompt for upload rather than trust the device.
• Background work is limited by design. Anything that must happen while the app is closed is where the model stops. Scheduled background sync is not available across all browsers, so a queued upload generally flushes when the user next opens the app.
• No store listing. If procurement at your customer requires software to come from a managed store, or your users expect to search for you by name, that is a requirement a PWA does not meet.
• Device polish. Native transitions, gesture behaviour and integration with system-level features remain more refined. For a consumer-facing product this matters more than for a technician completing a checklist.

Where native is overkill

The opposite error is common too, and more expensive. Building two native applications for eleven internal users who need a form and a camera means two release cycles, two sets of store credentials, and an update process where a one-line fix reaches the field days later. The cost is not mainly the first build; it is that every subsequent change carries the same overhead. If your users are staff, dealers or partners you can email a link to, the store adds process without adding reach.

A field scenario, worked through

A technician services equipment in a basement plant room with no signal. Before leaving the office the device holds the day's work orders, the equipment history and the checklist templates. Underground, the technician completes the checklist, records the parts used, photographs the installation and takes the customer's signature on the screen. All of it is stored on the device. Back at street level, the queued records upload, the service report is generated and the parts are deducted from stock.

A PWA handles this whole sequence. The one change worth making to the naive design is the upload step: rather than assuming background sync will flush the queue, show the technician a clear count of unsent records and confirm when it reaches zero. That single screen removes the failure mode that gives offline web apps their bad reputation. The same pattern runs in Elevatora SAHA for lift maintenance, where technicians complete jobs in buildings with no reliable connection.

Now change one requirement: the company also wants to see where each van is during the day. That is continuous background location, and it is a native requirement. The right answer is not to rebuild everything natively — it is a small native tracking application alongside the PWA, both writing to the same backend, which is the boundary discussed in where the line goes between a customer app and an internal system.

Cost shape

• PWA on top of an existing web system: a focused module at $3,000–6,000 over 2–4 weeks, sharing the backend and data model rather than duplicating them.
• System with mobile, desktop and integrations: $8,000–15,000 over 4–8 weeks.
• Platform scope: $20,000+ over 3–6 months.
• Native is quoted separately, because it adds a codebase, a release process and store accounts that continue for the life of the product.
• Annual maintenance: optional, 12–25% of build cost. Licence: perpetual, unlimited users, source code delivered.

The honest summary is that a PWA is cheaper mainly because it shares one codebase with the system you already need, not because web technology is inherently less work. Where a native requirement is real, pay for it deliberately and keep it as small as the requirement.

Write down what the software must do on the device, and the choice usually makes itself in ten minutes. Bring that list. Request a quote, read about field service software, or compare bands on the pricing page.

Frequently asked questions

What is a PWA and how do users install it?

A progressive web app is a web application that can be added to a phone's home screen, launches without browser chrome and keeps working offline. Users open a link and choose to install. On Android the browser can offer an install prompt; on iOS the user adds it from the share menu, which is a step worth showing people during rollout.

Can a PWA use the camera and read barcodes?

Yes. A PWA can open the camera through standard web APIs, take photographs and scan barcodes or QR codes in the browser. What it does not get is the low-level camera control a native app has — manual focus, exposure locking, high frame-rate capture — which matters for specialised scanning hardware and rarely for photographing a completed job.

Can a PWA work offline?

Yes, for the pattern most field work needs: cache the screens and reference data in advance, let the user complete forms and capture photos and signatures with no connection, store them locally, and upload when the device is back online. The limit is that a phone can evict local storage under pressure, so uploads should be prompted rather than left indefinitely.

Do PWAs support push notifications?

On Android, yes, from the browser. On iOS, push works only after the user has added the web app to the home screen, and the permission prompt has to come from inside the installed app. If notifications are the primary mechanism of the product rather than a convenience, that extra installation step is a real consideration.

When is a native app genuinely necessary?

Four cases. Continuous background location while the app is closed, such as vehicle tracking. Bluetooth or NFC communication with specialised hardware, which Safari does not support. Being findable and installable from an app store. And sustained high-performance graphics or media processing on the device.

What does a mobile application cost at KodDelta?

A PWA that shares the data model and backend of an existing web system is a focused module at $3,000–6,000 over 2–4 weeks. A system with mobile, desktop and integrations is $8,000–15,000 over 4–8 weeks. Native adds a second codebase and store release process, and is quoted separately against the requirement that makes it necessary.