When Not To Choose PWA
Choose native, cross-platform native, or desktop when the product depends on platform guarantees the web cannot provide reliably.
Native Triggers
| Requirement | Why PWA is weak |
|---|---|
| Deep background execution | Browsers throttle, stop, or do not support background APIs uniformly |
| Exact alarms or reminders | Web notifications and background work are permission and platform constrained |
| Restricted OS APIs | SMS, calls, contacts, low-level file access, and device management are native territory |
| Heavy Bluetooth/USB/HID workflows | Browser support and permissions vary sharply |
| High-performance native UI | Browser rendering and input latency may not meet product expectations |
| Store-only monetization | Store policies and in-app purchase rules can dominate architecture |
| Compliance-sensitive local data | Native secure storage, MDM, or platform attestation may be required |
| Offline must never lose work | Native storage, backups, and background sync may be more controllable |
Better Defaults
| Product shape | Consider |
|---|---|
| Android-first with permissions | Android Kotlin Compose |
| Cross-platform mobile with standard APIs | Expo or React Native |
| Branded UI across platforms | Flutter |
| Local-first desktop power tool | Tauri or Electron |
| Content/reporting surface | Static Astro before PWA |
| API integration or shared state product | Backend plus thin UI |
The Hard Line
Do not pick PWA because it sounds cheaper if the app’s main value is a native capability. Pick PWA when the web version is already a valid product and installation/offline capabilities make it better.