Choosing a PWA: A Practical Guide Without Misconceptions
A PWA (progressive web app) is an application built with web technologies (HTML, CSS, JavaScript) that offers advanced features such as installation on the home screen, partial offline access, or push notifications. But it does not systematically replace a native app: its capabilities vary by browser, operating system, and installation state. This guide helps you objectively assess whether a PWA suits your project.
What a PWA Really Is
To prepare a PWA, you use a web manifest that describes the name, icons, and display mode. You can also plan a service worker to manage certain requests and cached resources. The service worker is not required for installation. Do not confuse "installable" and "usable offline": your team must define and test these two behaviors separately. See MDN's PWA overview for this distinction.
Contrary to common belief, a PWA is not necessarily a single-page app (SPA). It can be built with any web architecture. The key is to adopt progressive enhancement: detect supported features and provide fallbacks. For example, if the Background Sync API is unavailable, the app should inform the user that sending a message failed and allow manual retry.
Known PWA Limitations, Especially on iOS
PWAs do not have access to all native app capabilities. Here are the main points to watch.
Installation and Updates
Check the installation journey on every device, browser, and version combination you support. Commands and installation options differ; do not write universal help based on one phone.
Your team must also manage code and service worker updates if you use one. A new version may wait before taking control. Test what happens with multiple windows open and with an unsent form. Provide clear instructions when asking users to reload, without deleting pending data.
Hardware Feature Access
List precisely what the user must do: take a photo, attach a file, get their location, or communicate with a specific device. For each essential need, your team must check the browser's official documentation and try the journey on target devices. Do not replace this verification with a general claim about "hardware access."
Also plan for permission denial. If the user denies camera access, can they attach an existing file? If no fallback meets the need, you must reconsider the scope or the technical solution.
Push Notifications
Push notifications for web apps are available on iOS/iPadOS 16.4 and later, but only when the app is added to the home screen WebKit. The user must grant permission after a direct interaction. So, on a recent iPhone, an installed PWA can receive push notifications, but the exact behavior depends on the OS version, browser, and installation state. Test on your target devices.
Offline Data and Write Conflicts
Local storage (IndexedDB, Cache API) allows keeping data offline, but you must handle write conflicts when the user modifies data on multiple devices or when connectivity is restored. Without robust synchronization, data can be lost. For example, an offline form saved locally might be overwritten by a newer server version if you naively apply "last write wins." Define a resolution rule suited to the business. For a form where both versions contain important information, plan a comparison and explicit choice rather than silent overwrite.
Decision Matrix: Evaluate Needs, Not Architectures
Choose between PWA and native app based on essential operations, target devices, and prototype results. Each project has specific needs. Use this matrix to clarify what is essential and what is optional, then prove the chosen solution works on real devices.
| Criterion | Question to ask | PWA candidate? |
|---|---|---|
| Installation | Must the user be able to install the app on their home screen? | Yes, via the manifest, but check the process on each target browser. |
| Offline | Must the app work without a network connection? | Potentially. Implement and test offline loading, local storage and conflict handling. |
| Push notifications | Are notifications critical for engagement? | Possible on Android and on iOS 16.4+ if the app is installed. Test on your targets. |
| Hardware access | Which device and operation are essential? | Test the required API on each target browser and document the fallback. |
| Distribution | Should users access the product via link, store, or both? | Link access is possible. Store distribution is separate work, with platform conditions to verify. |
| Sensitive data | Does the app handle critical data offline? | Possible, but requires careful design (encryption, synchronization). |
| Updates | Must users always have the latest version? | PWA updates can be delayed; plan a strategy. |
How to use:
- For each criterion, mark the capability as Essential, Optional, or Not needed.
- If an essential capability is not reliably supported by a PWA on one of your target devices, consider another solution (native, hybrid) or revise the scope.
- Do not conclude from a simple count of columns: a single blocking criterion can disqualify the PWA, even if all others are favorable.
Concrete Example: Field Data Entry Form
Fictional context: a maintenance company sends technicians to clients' sites to fill out service forms (serial number, photos, signature). Technicians sometimes work in areas with no network. The team is considering a PWA.
Step 1: Needs analysis with the matrix
| Capability | Essential? | Likely PWA support? | Proof needed |
|---|---|---|---|
| Home screen installation | Yes | To verify for browsers and versions chosen | Test on technicians' phone models |
| Offline data entry | Yes | Yes with service worker and IndexedDB | Test in airplane mode |
| Form synchronization | Yes | Possible but requires specific design | Test reconnection and conflicts |
| Camera | Yes | Capture or file attachment to prototype | Test on iOS and Android |
| Push notifications | No | - | - |
| Store distribution | No (internal web link) | - | - |
Step 2: Decision The PWA seems feasible, but the critical point is offline synchronization. The team decides to build a prototype and test synchronization before committing to a PWA.
Step 3: Designing synchronization Each local form receives a unique stable identifier (e.g., a client-generated UUID). The form's state is tracked explicitly:
saved_locally: saved on the device, not yet sent to the server.sending: currently being sent.server_acknowledged: the server has confirmed receipt. When sending, the client sends the identifier and data. The server must be idempotent: if the same identifier is received twice (e.g., due to a retry after connection loss), it does not create a duplicate but responds with an acknowledgment. If a conflict occurs (e.g., the same form was modified on two different devices), the app does not automatically overwrite the newer version. It presents both versions to the user and asks them to choose or merge. Keep both versions until resolution and test for possible errors during this choice. Simply showing a conflict does not guarantee data preservation.
Test scenario: A technician fills out a form in airplane mode. The app saves it locally with state saved_locally. Back at the office, they reconnect. The app attempts to send. If the server responds, the state changes to server_acknowledged. If the connection fails, the state remains saved_locally and the app retries later. If a code update occurs while a form is pending, the app must preserve local data and resend after the update.
This example defines what the prototype must demonstrate. It does not yet prove feasibility on this company's devices; the team must obtain these results before choosing the PWA.
Validation Checklist Before Committing
Before deciding, test these points on real user devices (not just a simulator).
- Installation: On each target browser, verify the manifest is correct and installation works. Note differences (Android banner, iOS Share menu).
- HTTPS: The site must be served over HTTPS. For production, verify the secure context required by the features you use; do not confuse a local development test with public deployment.
- Hardware features: Test each required API (camera, GPS, etc.) on all devices. If an API is unsupported, show a clear message and offer an alternative.
- Offline:
- Load the app, then turn off the network: does the app load?
- Fill out a form offline, close the app, reopen it: is the data still there?
- Reconnect: is the data sent? Are there duplicates?
- Conflicts: Simulate two devices modifying the same record offline, then sync. Does the app present the conflict to the user instead of silently overwriting?
- Update with pending data: Have an unsent form, deploy a new code version, open the app. Is data preserved and resent?
- Permissions: Deny permissions (notifications, camera) and check behavior. Does the app remain usable?
- Storage: Test behavior if local storage is nearly full or purged by the browser. Plan warnings and backups.
- Shared device: If multiple users share a device, test logging out and logging in as another account. Are local data isolated?
Decide Based on the Tested Journey
A PWA can be an excellent solution for many projects, provided you know its limits and test them precisely. Do not rely on general promises: verify each capability on your users' devices. If an essential need is not reliably met, explore other options.
If you need help assessing your case or developing a PWA tailored to your constraints, Doved Studio can help you clarify your user flow and define a realistic architecture. Bring a concrete user flow example and your list of target devices to start a practical discussion.