PWA or Native App? Choose Around the Features You Need
TL;DR
Compare PWA and native app options around offline work, push notifications, hardware and distribution. Includes a practical acceptance-test checklist.
Choose a progressive web app when reaching users through a link and supporting web-based journeys matter most, provided the required features work on their devices. Choose a mobile app with native platform access when a mandatory workflow depends on capabilities the web cannot reliably deliver for those users. Prove the difficult feature before committing to either approach.
“It needs to work offline” is not enough to decide. Reading a saved manual, recording a day’s work without a connection and uploading files while the phone is locked are three different requirements. The same is true of “uses the camera” or “sends notifications”. The detail changes the choice.
This guide gives product owners a comparison and a short acceptance-test plan. Platform documentation was checked on 1 October 2026; the worked scenario is illustrative, and no device testing is claimed.
First, separate the decisions
A PWA is a web application enhanced with capabilities such as installation and planned offline behaviour. Users can reach it through a URL. What it can do depends on the browser, operating system, permissions and implementation.
A platform-specific native app is built for a particular operating system, commonly using Swift for iOS or Kotlin for Android. It can use the platform’s application APIs, subject to permissions and operating-system restrictions.
There is also a relevant middle option: a cross-platform mobile app, for example one built with Flutter or React Native. This can share substantial application code while integrating with native platform capabilities. It is not simply another name for a website wrapped in a WebView. Both React Native’s native platform documentation and Flutter’s architectural overview describe platform integration mechanisms.
Decide the distribution and device requirements first. The framework choice comes afterwards. Needing a mobile app does not automatically mean commissioning two entirely separate implementations.
Compare the journey, not a generic feature score
The table below is a starting point for requirements. “Possible” is not the same as “reliable enough for this job on every supported device”.
| Requirement | PWA considerations | Mobile app with native platform access |
|---|---|---|
| Open from an email or QR code | Users can begin through a web link; installation need not be the first step | Plan the path from link to installation or an existing installed app |
| Repeated access from the home screen | Installation flow and presentation vary by platform | Familiar installed-app route; distribution and release management still need work |
| Read previously saved information offline | Design what is cached, how old it may be and what happens when it is missing | Also needs explicit storage, freshness and expiry rules |
| Capture work offline and sync later | Design local records, retry, duplicate prevention and conflict handling | More platform options; the same data-consistency problems remain |
| Send push notifications | Check installation and permission requirements on target devices | Check permissions and delivery behaviour; push is not a guaranteed acknowledgement |
| Work while the screen is locked | A potential blocker; verify the exact background operation | Platform APIs provide options, but execution is still constrained |
| Connect specialist hardware | Verify the particular API, peripheral and browser combination | Check the vendor SDK and support for the chosen mobile framework |
| Reach desktop and mobile users | A responsive web interface can cover both | A separate web experience may still be needed |
Write mandatory outcomes beside these rows. “Record a photo and save the inspection while offline” is testable. “Native-like experience” is too vague to settle a supplier disagreement.
Offline support needs a definition of “finished”
A PWA can use a service worker and local caching to make selected resources available without a network. The MDN guide to offline and background operation explains that mechanism and the trade-off between returning cached content quickly and keeping it fresh.
For a product brief, define four separate states:
- Available: the user can open the information needed for the task.
- Saved locally: the device has retained the user’s changes.
- Submitted: the server has accepted the record.
- Confirmed: the application has shown the user what was accepted or needs attention.
A green “saved” message should not imply that the office has received a record still held on the phone. Decide what the person sees when storage is unavailable, a login expires, or the app is closed before submission finishes.
Background Sync can help defer a request until connectivity returns, but MDN marks its browser availability as limited. Do not make successful delivery depend on an unsupported API. A foreground retry or visible pending queue may be an acceptable alternative; for some jobs, it will not be.
Native development does not remove these decisions. Android’s background task guidance distinguishes tasks by their constraints and recommended execution mechanisms. “It is native” is not an acceptance test for uninterrupted background work.
Notifications and hardware can change the answer
The statement “PWAs cannot send push notifications on iPhones” is outdated. WebKit introduced Web Push for Home Screen web apps in iOS and iPadOS 16.4. The user must grant permission, and the request must follow direct user interaction. See WebKit’s explanation of iOS Web Push.
The product question is whether your users will complete the required setup. A notification feature may be technically available yet fail its purpose if people never install the web app or decline permission. Provide an in-app status view or another agreed fallback where missing a notification would leave work unnoticed.
Be equally precise about hardware. Taking a photograph through a supported browser is different from continuously scanning specialist equipment or using a manufacturer’s SDK. Web Bluetooth has limited browser availability; a sales promise that “Bluetooth is supported” needs the device, browser and peripheral named beside it.
For any essential hardware integration, request a small working demonstration on the actual equipment before approving the full build. A desktop demonstration is not evidence for an iPhone workflow. Record the operating-system version, permission state and reconnection behaviour with the result.
A worked choice: a field-service inspection tool
Imagine a fictional maintenance business planning a tool for engineers. They need to view assigned jobs, take photographs, record notes and submit completed inspections. Office staff use a desktop dashboard. The business has not yet decided whether technicians must upload while the phone is locked.
There are two materially different briefs:
| Version of the requirement | Initial direction | Evidence needed |
|---|---|---|
| Engineers open a link, download the day’s jobs, capture work offline and reopen the app to submit | Consider a PWA | Successful local save, reopening, explicit synchronisation and recovery on every supported device |
| Engineers use specialist Bluetooth equipment and must complete a defined upload workflow after leaving the app | Investigate a mobile implementation with the required native APIs | Peripheral compatibility and a background-work design demonstrated under platform constraints |
These are proposed directions, not measured results. The second brief could change again if the hardware supplier has no usable SDK or the operating system restricts the requested behaviour. That uncertainty belongs in discovery, before either option receives a fixed build commitment.
For the first brief, give both shortlisted suppliers the same acceptance exercise:
- Sign in and load the assigned job while connected.
- Disconnect the device, create a note and attach a photograph.
- Close and reopen the app; confirm the work remains available.
- Restore connectivity and submit; confirm one server record is created.
- Interrupt the upload and retry; confirm it does not duplicate the inspection.
- Change the same job from the office and synchronise; show how conflicting edits are resolved.
- Repeat with an expired session and a denied permission; show the recovery route.
If locked-screen submission is mandatory, add a separate test with an agreed completion condition. Include representative older devices, not only the developer’s newest phone. Run the exercise with realistic attachment sizes and network interruptions.
Download the PWA versus native acceptance worksheet. It includes the scenario, expected outcomes and blank result fields. No row is pre-labelled as passed.
Distribution and updates are part of the product
A web link can reduce the steps before someone tries a service. Installation may still matter for frequent users, notifications or an expected home-screen presence. MDN’s installation guidance documents differences between platforms and routes for packaging PWAs for app stores. Store presence is therefore not an absolute dividing line, but packaging and approval remain separate tasks.
Ask how users will discover the app, sign in for the first time and find it again a week later. For an internal workforce, test those steps with a few representative employees. For occasional customers, forcing installation before a simple booking may introduce unnecessary work.
Plan updates too. A deployed web release does not guarantee every open session instantly uses the new code or cached assets. Define the update experience and compatibility between older clients and the server. Mobile releases also need a policy for supported versions, rollout and users who postpone updating.
The practical requirement is a recoverable release process. Ask what happens when the next version changes a locally stored record or an API response while someone is completing a task.
Compare total delivery and maintenance effort
A shared web implementation can avoid some separate platform work. That does not prove a PWA is cheaper for your particular requirements. Workarounds for a blocking device feature, a complex offline queue or a later mobile rebuild may outweigh the initial saving.
Conversely, a cross-platform mobile app can share code but still needs platform testing, integration maintenance and release management. Avoid both “native costs twice as much” and “one codebase means one test”. Neither is a dependable estimate.
Ask for comparable proposals covering the same journeys, devices, backend, offline behaviour, acceptance tests and support period. Identify what can be reused if the distribution choice changes: a documented API and well-defined business rules can remain useful, while the interface and device-specific behaviour may need substantial work.
Our guides to UK app development costs and app maintenance costs help organise those separate allowances.
Make the decision around the blocking requirement
Start with the smallest set of capabilities that must work for the product to be useful. If a PWA can meet them on the actual device mix, it deserves serious consideration. If a required platform capability cannot be delivered acceptably on the web, investigate the appropriate mobile implementation and prove that capability first.
Then compare onboarding, accessibility, usability and ongoing ownership. Passing an API compatibility check does not prove the finished application will be easy to use.
Bring your target devices, distribution plan and hardest user journey to Pixelfield. We can help assess a progressive web application or scope a mobile app project around the requirements that decide the outcome.
