The requirement was an icon
A team asked for a native app, then described login, a dashboard, document upload and notifications. None of those requirements answered why the product needed native software. What they wanted was a service that felt permanent, opened quickly and could be reached from a phone's home screen.
Native brings platform code, store review, coordinated releases and a larger test surface. That cost is justified only when the product needs capabilities the web cannot provide reliably, not when native is a synonym for serious.
The first decision is therefore not web or native. It is whether the product needs a URL, an installed presence or privileged access to the operating system.
What a web app already does honestly
A web app is usually the strongest start for account portals, booking, marketplaces, dashboards, internal tools and workflows shared between desktop and mobile. One codebase reaches the browser immediately, links open the right state and updates skip store review.
Installation is not exclusive to native software. The Web Application Manifest specification defines the name, icons, launch URL, display mode and scope of an installed web experience. Service workers can support cached interfaces and offline work, so intermittent connectivity is not a native requirement by itself.
Push is not automatically native either. Apple documents standards-based web push for Home Screen web apps. Camera, microphone, location, upload and sharing also work on the web when browser support fits the audience.
The honest limitation is consistency. A web capability that exists in one browser may be restricted or absent in another. The target device matrix matters more than a generic list of web APIs.
What genuinely requires native
Native becomes the honest answer when the core value depends on privileged, durable or platform-specific behaviour:
- Sustained background work. If the product must continue processing, tracking or transferring data after the interface closes, native platforms expose dedicated scheduling and execution frameworks. Apple's Background Tasks framework is an example.
- Operating-system extensions. Home and lock screen widgets, Live Activities, controls, watch complications, share extensions and similar surfaces live outside the main app. Apple exposes these through frameworks such as WidgetKit.
- Deep hardware and health integration. Continuous accessory communication, specialist sensors, HealthKit, Health Connect or platform credential stores often require native entitlements and SDKs. Apple describes HealthKit as an app capability, while Web Bluetooth remains a limited-availability browser API.
- Device-pipeline performance. Real-time audio, demanding camera capture or long on-device computation may need native media and GPU frameworks.
Native is not required merely because the product has authentication, subscriptions, animations, maps, push, a camera button or an offline screen. Those are questions to test, not conclusions.
Hybrid is a product decision, not a compromise
Some products need broad web delivery and a narrow native capability. The web app can remain the product while a native shell adds store distribution, secure credentials, background tasks or a hardware bridge. Native modules then handle only the platform boundary.
This works when most flows are forms, content and account data, but one mobile moment needs deeper access. It does not work when the interaction depends on native navigation, continuous sensors or platform-specific surfaces. A shell cannot hide a native product.
Hybrid also creates its own maintenance contract. The bridge, store releases and platform modules still need testing. It should be chosen because the boundary is clear, not because the team wants to postpone the decision.
Decide from the hardest capability this week
Write the core user journey without naming a technology. Mark every moment that must work offline, in the background, with hardware or outside the main interface. For each marked moment, test the exact browsers and devices used by the audience.
If the difficult capability works reliably on the web, build the web app first and measure real demand for installation. If only a narrow capability fails, evaluate a native shell with a small bridge. If the product depends on background execution, system extensions or privileged device data throughout, choose native and budget for platform ownership.
The honest answer is the least expensive architecture that guarantees the product's hardest requirement. Everything else brands the container before defining its contents.