React Native or native Swift and Kotlin: how we decide

Clients ask us this question in almost every mobile engagement, often after reading strong opinions in both directions. The honest answer is that both approaches produce good apps in the right circumstances, and the choice depends on a handful of factors you can evaluate before writing any code. This is the checklist we use.

What each option actually means

React Native lets a team write most of an app in TypeScript and React while rendering real platform interface components on iOS and Android. One codebase covers both platforms, with platform-specific code where it is needed. Tooling such as Expo handles much of the build, update and device-testing workflow.

Native development means two separate apps: Swift, usually with SwiftUI, for iOS, and Kotlin, usually with Jetpack Compose, for Android. Each app uses its platform's own tools and libraries directly, with no cross-platform layer in between.

Both are distributed through the App Store and Google Play, and in ordinary use a customer can't tell which approach was used. The real differences are in cost, team structure, access to platform features and long-term maintenance.

When we recommend React Native

For most business apps, React Native is our default. A typical business app is a set of forms, lists, detail screens, account settings and notifications backed by an API. Those are exactly the things React Native does well, and building them once instead of twice matters.

• You need both iOS and Android, and your budget doesn't comfortably cover two parallel builds.
• You already have a web product in React and TypeScript, so types, validation rules and API clients can be shared between web and mobile.
• Your app is mainly content, forms, scheduling, commerce or account management rather than heavy graphics or hardware work.
• Your team will maintain the app later and has web developers rather than dedicated iOS and Android engineers.
• You want to ship JavaScript-only fixes quickly through over-the-air updates, within the limits app store policies allow.

When we recommend native Swift and Kotlin

Native is the better choice when the app's value depends on the platform itself. That usually means deep, sustained use of hardware or operating-system features, where a cross-platform layer adds friction instead of saving time.

• Sustained real-time work with the camera, audio or sensors, such as scanning, signal processing or augmented reality.
• Heavy use of platform extensions: widgets, watch apps, CarPlay or Android Auto, shortcuts and background processing with strict system limits.
• Bluetooth hardware integration, where most of the work happens inside the platform's own APIs and debugging tools.
• Graphics-intensive interfaces or complex animation where every frame counts.
• An organization that already employs iOS and Android engineers and wants the app to fit their existing skills and tooling.

The questions that actually decide it

When the answer isn't obvious, we work through a short set of questions with the client. None of them is about which technology is more fashionable.

• Where will most of the engineering hours go? If the answer is screens and business logic, shared code pays off. If it is platform APIs, native pays off.
• How different should the two platforms feel? If each app must follow its platform's conventions closely, the shared portion of a React Native app shrinks.
• Who maintains the app in two years? The best technology is one your future team can staff, and hiring TypeScript developers is a different search from hiring Swift and Kotlin specialists.
• What does the rest of your stack look like? Shared types and API clients between web and mobile remove a whole category of bugs.
• What are the hard platform requirements? Check every must-have feature against React Native's ecosystem before committing, and prototype anything uncertain.

Performance, honestly

Performance is the most common objection to React Native and the most frequently overstated. For typical business apps, a well-built React Native app is smooth on current devices. Most slow React Native apps we have reviewed were slow for reasons that would have hurt a native app too: long lists rendered without virtualization, heavy work on the main thread, or large images loaded at full size.

That said, native code gives you the most direct control, and for the demanding cases above that control matters. We would rather tell a client to go native at the start than spend months working around a framework's limits later.

Cost over the life of the app

The initial build is only part of the cost. Mobile apps need ongoing work: each major iOS and Android release brings new requirements, app store policies change, and dependencies need updating. With React Native you maintain one codebase plus the framework itself, which needs a deliberate upgrade a few times a year. With native you maintain two codebases, each moving with its own platform.

Neither option is free to maintain. Budget for maintenance from the start, whichever you choose, and ask any vendor how they handle major OS releases and framework upgrades.

How we make the call with clients

We make the recommendation in writing during scoping, after reviewing the must-have features against both options. If a single feature is uncertain, such as a Bluetooth integration with a specific device, we build a small prototype of that feature before committing the whole project. The recommendation names the trade-offs, so you can see what you would give up either way.

If you are weighing this decision now, start by listing the three features your app cannot launch without. That list usually answers the question faster than any general argument.