Every mobile project starts with the same question: native or cross-platform? The answer gets debated like a tribal identity, which is strange because the actual trade-offs aren’t that mysterious. There are a handful of factors that matter, and most apps land clearly on one side or the other once you walk through them. This post is the framework we use at Mainix when a client asks us to help them decide.
The short version
Use React Native when your app is primarily UI-driven, needs to ship on both platforms at once, and leans mostly on REST or GraphQL APIs. Most B2B apps, most SaaS mobile companions, and most content-heavy consumer apps fit here. You cut engineering time roughly in half and maintain one codebase.
Use native (Swift + Kotlin) when your app pushes hardware, needs complex platform-specific animations, or integrates deeply with system features like HealthKit, CarPlay, WatchKit, ARKit, or heavy real-time audio and video. You pay roughly 2x the engineering cost but get full platform fidelity and access to anything the OS exposes on day one.
That’s the 80% answer. Below are the factors that drive it.
What actually matters in the decision
1. How much of your app is native UI chrome?
React Native’s UI primitives are a lowest-common-denominator of iOS and Android components. They look great, but they don’t always feelnative. Scroll physics, swipe gestures, haptic response, and context-menu interactions are subtly off if you benchmark them against Apple Mail or Google Photos. For most apps this doesn’t matter. For apps where the brand is the interaction (think iA Writer, Things, Procreate), it matters a lot.
2. How much of your app is business logic over an API?
If your app is mostly screens that fetch JSON, render lists, and submit forms, the UI layer barely matters. Both React Native and native perform identically for this work. In that case, picking React Native gets you one codebase, shared TypeScript models, and the ability for your web developers to move fluidly between web and mobile, a huge team-level multiplier.
3. How much do you need hardware and platform APIs?
React Native has bridges for most common APIs: camera, location, push notifications, Bluetooth Low Energy, biometrics. They work. But the moment you need something new or platform-specific, say, Apple’s new LiveActivities, CarPlay integration, or Vision Framework for on-device ML, you’re either writing a native module yourself or waiting for the community. In native, these are day-one APIs. For apps that lean hard on OS features, native saves months.
4. How fast do you need to ship?
React Native with Expo can take you from idea to App Store in weeks with a small team. Pure native with separate iOS and Android codebases doubles the engineering work and usually adds an entire team member. If you’re an early-stage company validating a product, that difference isn’t close. If you’re an established company with a long-term app, the up-front cost of native matters less.
5. What happens when you need to hire?
The pool of web developers who can pick up React Native in a week is vast. The pool of senior iOS engineers is smaller and considerably more expensive. Same for Android. If you plan to grow a team around this codebase, React Native is easier to staff. If you’re a one-app-for-life company and can afford to hire specialists, native is fine.
The common mistakes
Picking React Native because “we have React developers”
React Native shares JSX and some hooks with React, but it’s not the web. Navigation, styling, animations, and state management all have mobile-specific patterns. A strong React developer will be productive in React Native within a month, but there’s a learning curve. Treat it as a related skill, not the same one.
Picking native because “it’ll be faster”
For almost every app that’s not a game or an intensive media tool, React Native performance is indistinguishable from native. Users cannot feel 60fps vs 60fps. Where React Native loses is complex gesture-driven interactions and heavy animations on low-end Android devices, and even those are usually solvable with Reanimated and careful architecture. If you pick native purely for performance without actually measuring, you’re paying a real cost for a theoretical win.
Picking either one and fighting it for two years
The worst outcome is committing to a stack and refusing to revisit the decision. We’ve seen React Native apps that should have been native, and native apps that should have been React Native. Building one screen in the other stack isn’t the disaster people treat it as. React Native supports native modules, and native apps can embed React Native views. Use the right tool per screen when it matters.
What we usually recommend
For most clients, we start with React Native and Expo. Most B2B and SaaS apps stay there permanently. For consumer apps with heavy interaction design, we build the scaffolding in React Native but plan from day one to rewrite specific screens in native if the UX requires it. For apps that are fundamentally hardware- or media-heavy (AR, camera-first products, real-time audio tools), we go native from the start.
The pattern we avoid: picking a stack based on what the last project used, or what the team is most comfortable with. Those are real considerations, but they’re usually downstream of the decision, not the driver.
A quick decision checklist
- Does the app need hardware APIs that don’t have stable React Native support? → Native
- Is the app mostly screens backed by REST/GraphQL? → React Native
- Do you need to ship in under 3 months with a small team? → React Native
- Is brand-defining interaction fidelity a key differentiator? → Native
- Do you expect to grow a team from your web engineers? → React Native
- Will the app rely on platform-exclusive features that get updated with each OS release? → Native
If your answers split down the middle, React Native is usually the safer default. You can always rewrite a screen. It’s much harder to rewrite an entire app.