One decision, long consequences
Before a mobile app gets a design or a feature list, it needs one technical decision: how it will be built. The main options are native, cross-platform, and the web-based progressive app. The choice rarely excites anyone outside the development team, but it shapes the app's cost, the speed of building it, how it feels to use, and how much it costs to maintain for as long as it exists.
Getting this decision right means matching the approach to what the app actually is. There is no universally best option. There is an option that fits a particular product, budget, and timeline, and three options that each suit a different kind of app. Understanding the trade each one makes is what allows a sound choice.
Native apps, and what they buy you
A native app is built specifically for one platform using that platform's own tools: one codebase for iOS, a separate one for Android. Because the code speaks directly to the platform, native apps generally deliver the best performance, the smoothest feel, and the fullest access to device features such as the camera, sensors, and notifications.
The cost of that quality is duplication. Supporting both major platforms means building and maintaining two separate apps, which roughly doubles the development effort. Native is the right choice when the app is performance-sensitive, graphics-heavy, or deeply dependent on device hardware, and when the budget supports doing the work twice. For those apps, the quality difference is real and worth paying for.
Cross-platform, and the trade it makes
Cross-platform frameworks, such as React Native and Flutter, let a team write one codebase that runs on both iOS and Android. The appeal is obvious: one team, one codebase, and a substantial saving compared with building two native apps. For a large share of business apps, the result is genuinely good and indistinguishable to most users from native.
The trade is at the edges. Cross-platform apps can lag slightly behind native ones on the most demanding performance, and access to brand-new or unusual device features sometimes requires extra native work anyway. For most apps, those limits never bite. Cross-platform is the sensible default for the typical business app, and only specific, demanding requirements justify moving away from it.
Progressive web apps, the lighter path
A progressive web app is not an app in the traditional sense. It is a website built so that it behaves much like an app: it can be added to the home screen, it works offline to a degree, and it can send notifications on supported platforms. Crucially, it needs no app store and runs from a single web codebase.
That makes a progressive web app the lightest and cheapest path to something app-like, and it sidesteps app store approval entirely. The limits are real: it has less access to device features than an installed app, and its capabilities vary between platforms. For content, tools, and services that do not need deep hardware access, though, it can deliver most of the value at a fraction of the cost.
Matching the choice to the product
The right approach falls out of the product itself. An app whose value depends on performance or hardware, a game, a camera-centric tool, an app using sensors continuously, points toward native. A standard business app, a marketplace, a service app, an internal tool, is usually best served by cross-platform, which delivers most of the quality for much less cost.
An experience that is essentially a website with some app-like convenience often does not need a true app at all, and a progressive web app will serve it well. The questions that decide it are practical: how much does performance matter, how much device hardware does the app rely on, what is the budget, and how fast does it need to ship.
A simple way to decide
A useful default is to start at cross-platform and require a reason to move away from it. Cross-platform fits the majority of business apps and offers the best balance of cost, speed, and quality. Move to native only when a concrete requirement, demanding performance or deep hardware use, genuinely justifies building twice.
Move to a progressive web app when the product does not really need to be installed and an app-like website would satisfy users. Framed this way, the decision is not about which technology is best in the abstract. It is about what the specific app needs, and being honest about whether expensive capability would actually be used.