Native vs Cross-Platform App Development: An Honest Take

It’s one of the first questions that comes up in almost every app project conversation: should we build native, or use something like React Native?

The honest answer is: for most product apps, a well-built React Native app is the right call. But it depends on what you’re building, and it’s worth knowing where the exceptions are.

What “native” actually means

A native app is built using the platform’s own language and tools: Swift or Objective-C for iOS, Kotlin or Java for Android. It talks directly to the operating system with no translation layer in between.

React Native sits on top of that. It renders real native components, but your logic and UI are written once in JavaScript or TypeScript and shared across both platforms. Done well, the result looks and feels genuinely native, because it’s using the platform’s own components under the hood, not redrawing its own approximation of them.

Where React Native is the right choice

For the large majority of product apps, a shared codebase is the pragmatic, well-engineered choice, not a corner cut.

It tends to work well when:

• The app is built around accounts, forms, lists, and data (the shape of most products people actually use day to day)
• You want consistent quality on both iOS and Android from day one, without doubling the size of the engineering team
• The app shares logic or design with a companion website, so keeping everything in one codebase avoids maintaining the same business logic twice
• You want to iterate quickly, ship updates on both platforms at once, and keep the codebase manageable as the product grows

With modern tooling (TypeScript, Expo, and a component library built with accessibility in mind from the start), a React Native app doesn’t have to feel like a compromise on either platform.

Where native still makes sense

There are still cases where I’d recommend native over a shared codebase.

That’s true when:

• The app depends heavily on cutting-edge platform features the day they ship (brand-new OS APIs, deep widget or shortcut integration)
• It needs sustained, uncompromising performance: real-time processing, games, or heavy graphics work where any bridge overhead matters
• It sits in a regulated sector (healthcare, finance) with certification requirements that are specifically scoped to a native stack

For everything else, the case for native mostly comes down to habit rather than necessity.

The “one codebase” argument

The concern people raise about cross-platform is that one codebase can’t respect two different platforms. That’s true if “write once” is treated as license to ignore platform conventions. It’s not true if you build with the platform in mind.

That means using React Native’s platform-specific APIs and styling where iOS and Android genuinely diverge, testing on real devices rather than just simulators, and never treating accessibility as an afterthought. Done this way, a shared codebase doesn’t mean a compromised app: it means one team, one test suite, and one release process to maintain across both platforms, and often the companion website too.

What I do

I build with React Native: TypeScript, on Expo, with accessibility (WCAG-aligned components, tested with VoiceOver and TalkBack) and automated testing (Jest, React Native Testing Library) built in from the start, not bolted on afterwards.

For most of the app projects I take on, that shared codebase means faster delivery, easier long-term maintenance, and a consistent experience across iOS, Android, and any companion website, without cutting corners on quality. For the handful of projects where native genuinely is the better fit, I’ll say so upfront.

If you’re genuinely unsure which approach fits your project, that’s exactly the kind of question I’m happy to work through in a consultancy conversation.