THE CENTRAL IDEA
Choose the channel that makes the user’s task easier. Having an app-store listing is not, on its own, a reason to build an app.
Start with the nature of the visit
Someone discovering your services needs a quick route from a link or search engine, a clear message and a contact step. An employee managing transactions needs states, filtering and permissions. Both can look like browser pages, but their data models and testing needs differ. The decision is not simply about appearance on a phone.
What does a PWA add?
A PWA is an approach to a web experience that can use capabilities such as installation and some offline behavior, depending on implementation, browser and platform. It is not a language and does not automatically provide every native capability. Test required features on the actual devices, especially notifications, storage, synchronization and background behavior, rather than assuming identical support.
Offline use is a data decision
Showing a cached page is simpler than editing a record and synchronizing it safely. What can be read or changed offline? What happens when two people edit the same record? When does local data expire, and how is it protected on a shared device? These questions precede Flutter or PWA selection; an “offline supported” label does not answer them.
Example: booking a service versus field work
A booking reached from a link may start as a responsive web experience. A worker scanning barcodes, taking photos and completing forms in poor coverage needs a practical test of device access and synchronization. Office administration can remain in the browser while a field channel is added. A new channel need not imply rewriting the whole system when data and authorization boundaries are clear.
A channel costs more than its initial build
Maintenance includes browser or operating-system updates, permissions, sign-in and store releases where relevant. Define the audience and update owner for every channel. Do not choose native merely because it sounds more professional, or reject it simply because code sharing appears cheaper. Judge the actual tasks, constraints and user experience.
EDUCATIONAL EXAMPLE / REVIEWABLE STEPS
Acceptance matrix: task, channel & device
An educational example for choosing channels for service booking and field work. Each row links a task to a candidate and an acceptance criterion; a capability remains unverified until tested on target devices and browsers.
- Read a service from a link — candidate: a responsive website. Accept when information and contact are reachable without sign-in and remain clear on mobile and keyboard navigation.
- Book and track an appointment — candidate: a web application. Accept when booking and permitted edits work and another user cannot retrieve its details, including through a direct server request.
- Open an installed experience — candidate: a PWA where suitable. Accept after testing installation, launch and links on each target environment, with a usable browser path when installation is unavailable.
- Capture a visit photo — candidate: web or mobile, based on testing. Accept when permission is requested contextually, denial or cancellation preserves the draft, and retry does not lose data.
- Record a visit offline — candidate: an experience with local storage and synchronization. Accept when closing and reopening preserves the draft and reconnection synchronizes one record without duplication.
- Notify a user — candidate: a verified notification channel. Accept after testing permission grants, denial and background behavior on real devices, with status available inside the product if a notification is missed.
Compare fit, not popularity.
Website
Fits: Service discovery, reading and contact.
Consider: Does not automatically include accounts or custom workflows.
Web app / PWA
Fits: Tasks reached by a link, with additional web capabilities where verified.
Consider: Platform and offline limits must be tested against the actual task.
Mobile app
Fits: Device-focused, recurring or distribution-specific use.
Consider: Distribution, maintenance and testing for each target platform.
This is decision support, not a service offer or a performance guarantee. Your final choice depends on your requirements and the versions selected at implementation.
Official sources for further reading
web.dev — Learn PWAopens in a new windowApple — Swiftopens in a new windowAndroid — Kotlinopens in a new windowweb.dev — PWA capability detection and platform differencesopens in a new windowSources describe technology characteristics. The scenarios and trade-offs are contextual guidance, not benchmark results.