Progressive Web Apps vs Native: A Cost Conversation, Not a Religious One
The install barrier is real and often decisive
Every step between discovering your service and using it costs a share of your audience, and app installation is a large step — especially for infrequent use cases and for users on devices with limited storage. For services people use a few times a year, a booking, a form, an order lookup, the install requirement can cost more customers than any feature gains back. A web app that works immediately from a link is a legitimate strategic choice, not a compromise.
What web apps can now do
Offline operation with cached data, home screen installation, camera and file access, geolocation, background sync and payment request are broadly available. Push notifications work across major platforms, including iOS for installed web apps, though behaviour and permission flows differ enough that you should test rather than assume. The gap that remains is real but narrower than most decision-makers believe, and it has narrowed further each year.
Where native still wins clearly
Background processing that must continue reliably when the app is closed, precise or continuous location tracking, Bluetooth peripherals, advanced camera control, biometric-secured local storage, widgets, deep OS integration, and anything requiring the platform's payment or subscription mechanics. Also apps where discovery genuinely happens through store search rather than through your own marketing. If two or more of those are core to your product, build native.
The cost difference is larger than the feature difference
One codebase, one release process, no store review, instant updates for every user, and no version fragmentation to support. Against that, a native app on two platforms plus a website means three surfaces to build, test and maintain indefinitely. For a mid-sized business, that difference is frequently the deciding factor once it is stated as an annual cost rather than a one-off build comparison.
Data cost and device reality in emerging markets
In markets where mid-range Android devices and metered data dominate, a lightweight web app that loads in a couple of seconds on a slow connection can outperform a native app that requires a 60MB download. Test on a real budget device on a throttled connection, not on the newest phone in the office. The performance decisions that follow from that test — image strategy, bundle size, offline caching — matter more than the platform choice itself.
The pragmatic sequence
Build the web app first, instrument it, and see how users behave. If retention and usage frequency justify it, and the feature gaps are costing you, build native for the segment that warrants it. This order gives you real data instead of a hypothesis, and the web app remains valuable afterwards as your acquisition surface. Starting with native because it feels more serious is how small teams end up maintaining three products with the budget for one.
Have a project that needs this kind of thinking?
Let's talk through what you're building — free consultation, no commitment.
Get in Touch