·2 min read·9Tech Team
Web App vs Mobile App: A Decision Framework That Actually Decides
Most teams get this choice wrong because they frame it backwards. Here is the framework we use with clients before we write a single line of code.
"Should we build this as a web app or a mobile app?"
It is the wrong question. The right question is: where does the user already open apps, and what does the product need to do that the browser cannot?
The browser can do more than you think
In 2026, a modern progressive web app on a current iOS or Android device can:
- Install to home screen and launch fullscreen
- Receive push notifications
- Work offline with a service worker
- Access camera, geolocation, Bluetooth, USB, file system
- Use biometric auth via WebAuthn
- Handle payments via the Payment Request API
If your only argument for native is "we want it on the home screen," a PWA will do that.
Where native wins, hard
There are specific capabilities the browser still cannot match, and they are usually clear from the first conversation:
- Continuous background work. Location tracking while the phone is locked. Health sensor polling. Long-running uploads. Native wins.
- Deep OS integration. Share sheet extensions, Siri shortcuts, home screen widgets, Live Activities, Android complications. Native only.
- High-fidelity graphics. Heavy 3D, AR/VR, Metal/Vulkan compute. Native.
- App store discovery. If your acquisition depends on being findable in the App Store or Play Store (games, consumer utilities), you ship native.
- Stable platform APIs that browser vendors have not shipped yet. Rare, but real for some sensor and hardware categories.
If none of those apply, a PWA is almost always the right first step.
The framework
We ask three questions in order. The first "yes" ends the conversation.
- Does the user need the app to run work when it is not in the foreground? → Native.
- Is app store discoverability the primary acquisition channel? → Native.
- Does the product need an OS surface (widget, share extension, shortcut) to work? → Native.
Otherwise: web-first, PWA-capable. Ship faster, one codebase, one deployment, no review queues.
What changes our mind
Two things, often:
- Enterprise MDM requirements. If clients distribute through corporate app stores, we ship native.
- Specific regulated integrations. Certain banking and healthcare SDKs are native-only and the web shims are years away.
Both are rare. Most of the time the PWA wins, and the client spent three meetings debating the wrong question.
What we build
In practice, our portfolio is roughly 70% PWA, 30% native. For native work we use Flutter or React Native depending on the platform API surface. We do not ship separate iOS and Android codebases unless the client has a specific reason to.
Trying to make this call on a current project? Send us the scope and we will walk through the framework with your specifics.