Cross-platform or native: deciding like an adult

Few technical debates attract more tribal energy than mobile stack choice, and few deserve it less. The right answer is boring, situational, and discoverable with about five questions. Here they are, roughly in the order they should be asked.

First: does the product live or die on platform intimacy? A small set of app categories genuinely does. Heavy real-time graphics, advanced camera pipelines, audio processing with strict latency needs, deep OS integration like widgets, watch apps, or background modes that push platform limits. If the core product experience sits in that territory, build native and stop reading. The abstraction tax of a cross-platform layer lands exactly where you cannot afford it.

Second, and this is where most real products land: is the app essentially interface over data? Screens, lists, forms, media, payments, notifications, offline sync. This describes the overwhelming majority of business and consumer apps, and for it, modern cross-platform frameworks are not a compromise. React Native and Flutter both render experiences users cannot distinguish from native in this category. Claiming otherwise in 2026 is arguing from memories of 2017.

Third: what does your team already know? A team fluent in TypeScript and React acquires enormous leverage from React Native: shared language across web and mobile, shared tooling, often shared business logic. That leverage compounds in hiring too, because one profile covers both surfaces. Choosing a stack your team must learn from zero, in either direction, quietly adds months.

Fourth: how many codebases can you actually afford to keep alive? Not build. Keep alive. Two native apps means every feature, bug fix, and design change lands twice, drifts twice, and gets reviewed twice, forever. For a startup or a product team of modest size, this is the difference between shipping weekly and shipping quarterly. The teams that maintain parallel native apps well tend to have a platform team per OS. If you do not recognize your org in that sentence, take the hint.

Fifth: where will this product be in three years? Cross-platform is not a one-way door, and treating it as one causes bad decisions in both directions. The pragmatic pattern we recommend to most founders: launch cross-platform to learn fast on both stores with one team, keep the architecture modular, and if a specific surface later demands native performance, build that surface natively. Both major frameworks support embedding native modules and screens precisely for this. You are choosing a starting posture, not a religion.

A note on the option that outranks both in the right conditions: no app at all. If the product does not need push notifications, deep offline, or store presence, a well-built responsive web app ships faster, updates instantly, and skips two review processes. The number of companies that built two apps before validating that anyone wanted one app remains the quiet tragedy of this industry.

So: native when the product's soul demands the platform, cross-platform for interface-over-data with a small team, web when the app was never the point. Identity should be reserved for things that deserve it. A rendering framework is not one of them.