When a business decides to build a mobile app, one of the first technical questions is whether to build natively — Swift or SwiftUI for iOS and Kotlin or Jetpack Compose for Android — or cross-platform with a framework such as React Native.
The debate online is often tribal. For a business, the right answer depends on cost, timeline, the kind of app you are building and who will maintain it. Here is how I help clients think it through.
What each approach means in practice
Native development means two separate applications, written in the platform's own language, using the platform's own UI toolkit. Usually that means two codebases and often two teams.
React Native lets you write one application in JavaScript or TypeScript that renders real native UI components on both platforms. It is not a website in a wrapper. Screens are drawn with native views, and you can drop down to native Swift or Kotlin code when you need to. Expo sits on top of React Native and removes much of the setup, build and release friction.
Cost
This is where cross-platform usually wins clearly.
With native development, most features are built twice: two UIs, two implementations of the same business logic, two sets of tests and two sets of bugs. With React Native, most of that code is shared. Platform-specific work still exists, but it is the exception rather than the rule.
The saving also continues after launch. Every future feature, bug fix and design change is one piece of work instead of two. For many businesses, the long-term maintenance saving matters more than the initial build.
If you already have a React web application, the saving grows: your team's skills transfer, and validation logic, API clients and TypeScript types can often be shared.
Development speed
A single team shipping to both platforms simultaneously removes coordination overhead: no waiting for the Android version to catch up, no feature parity spreadsheets. Fast refresh during development and, with Expo, over-the-air updates for JavaScript changes also shorten feedback loops.
Native can be faster in one specific situation: when the app depends heavily on brand-new platform APIs on the day they are released. Cross-platform support for new OS features sometimes lags.
Performance
For the large majority of business apps — e-commerce, booking, field-service tools, dashboards, content, social features, internal tools — well-built React Native apps perform well, and users cannot tell them apart from native apps. React Native's newer architecture has reduced much of the overhead that caused older performance complaints.
Native development has a real edge when the app is dominated by:
- Heavy, continuous graphics or animation (games, advanced camera or video processing, AR).
- Intensive on-device computation.
- Deep, constant integration with low-level hardware or OS features.
In practice, React Native performance problems usually come from the same issues as in React on the web: unnecessary re-renders, unvirtualised long lists, large images and too much work on the JavaScript thread. Those are engineering problems with known solutions, not limits of the framework.
User experience
A common worry is that cross-platform apps feel "off". This usually happens when a team designs one UI and forces it onto both platforms without respecting platform conventions: back navigation, gestures, date pickers, typography, haptics.
React Native uses native components and supports platform-specific code where it matters, so a thoughtfully designed app can feel at home on both iOS and Android. The quality of the UX depends far more on design and implementation care than on the framework.
Maintenance and long-term risk
Consider who will maintain the app in three years:
- Hiring. JavaScript/TypeScript and React developers are widely available. Experienced Swift and Kotlin developers are in demand and often more expensive — and native means hiring for two skill sets.
- Dependencies. React Native apps rely on community libraries for some native features. Choose well-maintained ones, keep them updated and budget time for framework upgrades. Expo helps considerably here by providing a curated, versioned set of native modules.
- Platform changes. Both approaches must respond to annual iOS and Android releases. Native teams do it twice; cross-platform teams usually do most of it once.
A decision guide
React Native is usually the better choice when
- You need both iOS and Android and budget or time is limited.
- The app is primarily forms, lists, content, commerce, bookings or dashboards.
- You already have a React web app or a JavaScript/TypeScript team.
- You want one team to own the product across platforms.
- You are validating a product and need to reach users quickly, with the option to optimise later.
Native is usually the better choice when
- The app's core value is graphics-, media- or hardware-intensive.
- You need day-one access to new platform capabilities.
- You only target one platform and already have native expertise.
- You already have mature native teams and codebases that work well.
A hybrid path is often sensible
Many successful apps are React Native with a small number of native modules for the performance-critical or platform-specific pieces. You do not have to choose purely one way.
Questions to answer before deciding
- Do you need both platforms at launch, or can you start with one?
- What does the app do most of the time — display and edit data, or process media and hardware input?
- What skills does your current team have, and what can you hire locally?
- How often will the app change after launch?
- Is there an existing web product whose code or team you can leverage?
Summary
For most business applications, React Native — especially with Expo — offers the best balance of cost, speed and quality, and lets one team serve both platforms. Native development remains the right choice for apps where performance-critical graphics, media or hardware access are the product itself.
The framework is only part of the outcome. Architecture, navigation design, API handling, offline behaviour and release processes decide whether users experience the app as polished or fragile. If you are planning a mobile app and want an honest assessment of which approach fits your situation, I am glad to help you think it through.