Mobile — Cross Platform Development
React Native vs Native iOS/Android Development: When Each Wins
Direct answer
Go native (Swift/Kotlin) when the app's core value depends on deep platform integration — widgets, watch companions, camera pipelines, platform AI APIs — or when you're a platform-flagship product with separate iOS and Android teams. Go React Native when you're shipping a product app (most apps: feeds, forms, commerce, chat, dashboards) and want one team delivering both platforms with shared logic and faster iteration. The hybrid path is underrated: a native shell with React Native for product screens, or vice versa, is a first-class architecture, not a compromise.
The 'native vs cross-platform' debate is usually argued with decade-old talking points. Having shipped React Native into production apps used by millions — and integrated it alongside native code — here's the current, honest version of when each approach wins.
Key facts, with sources
- In the Stack Overflow 2024 Developer Survey, Flutter was used by 9.4% of developers versus React Native's 8.4%, and among professional developers the gap nearly vanishes at 9.21% versus 9.14%. (Nomtek (citing Stack Overflow Developer Survey))
- Among developers who build cross-platform, Statista-based figures put Flutter at about 46% adoption versus 35% for React Native, with the two frameworks together dominating the cross-platform market. (Tech-Insider)
- Instagram shares 85 to 99% of its code between iOS and Android using React Native, and Shopify reports 86% unified code across its app portfolio. (CatDoes)
- According to Flutter.dev data, nearly 30% of new free iOS apps submitted to the App Store in 2025 were built with Flutter, up from roughly 10% in 2021. (Droids on Roids (citing Flutter.dev))
- The official React Native showcase lists production apps from Meta, Microsoft, Shopify, and Amazon, including desktop targets like Messenger Desktop and Microsoft apps on Windows and macOS. (React Native Showcase)
What 'native' buys you, concretely
Native development gives you day-zero access to every platform capability: the newest iOS APIs the week they ship, watchOS and widget extensions, advanced camera and media pipelines, platform AI frameworks, and the last few percent of scrolling and animation polish that platform teams obsess over. It also gives you two codebases, two release trains, and — realistically — two teams, or one team that context-switches between Swift and Kotlin.
That cost is worth paying for platform-flagship products: apps where the platform integration is the product, or companies at a scale where dedicated iOS and Android teams each earn their headcount. It's rarely worth paying for a product app whose screens are lists, forms, media, and payments — which is most apps.
What React Native buys you, concretely
One codebase and one team shipping both platforms simultaneously — for a startup, that's often the difference between shipping iOS-first and 'Android eventually' versus launching both. Shared TypeScript business logic with your web app. Over-the-air updates for JavaScript-level fixes through Expo's update service, which shortens the worst feedback loop in mobile: the store-review wait. And real native views under the hood, so the result reads as a native app to users — this isn't a webview approach.
The boundary is native modules: when you need a platform capability the ecosystem doesn't already wrap, you write Swift/Kotlin and expose it to JavaScript. On product apps this is a small percentage of the work — and it means the correct comparison isn't 'React Native or native' but 'how much of this app needs to be native, and should the rest be shared?'
The performance question, answered honestly
For product apps — feeds, commerce, chat, dashboards, media browsing — a well-built React Native app is indistinguishable from native to users, especially since the new architecture removed the old bridge bottleneck and Hermes tightened startup. The domains where native still measurably wins: sustained heavy computation on the UI path, complex custom rendering (think design tools or games — where you'd actually reach for game engines anyway), very large real-time canvases, and battery-critical background processing.
The uncomfortable truth from audits I run: most 'React Native is slow' apps I'm hired to rescue are slow because of unvirtualized lists, render storms from careless state management, and 10MB images — problems those teams would have reproduced in Swift. Framework choice caps your ceiling far less than engineering discipline sets your floor.
The hybrid architecture nobody markets
The choice isn't binary. React Native embeds into existing native apps (brownfield), so companies with mature native codebases add cross-platform screens incrementally — new feature areas ship once instead of twice, while the native core stays untouched. The reverse composition also works: a React Native app with native modules and native screens where the platform demands it (a camera flow, a widget, a watch companion).
This is how I ship platform-heavy requirements inside React Native apps: the 90% that's product UI is shared, the 10% that's platform-specific is Swift/Kotlin behind a typed interface. Teams that frame the decision as 'what percentage of this app benefits from sharing' consistently make better calls than teams that frame it as an identity choice.
Decision checklist
Choose native when: platform integration is the product (widgets, watch, camera-first, platform AI); you have or can fund separate iOS and Android teams; you're at flagship scale where per-platform polish is a competitive weapon. Choose React Native when: one team must ship both platforms; you have React/web engineers or share logic with a web product; iteration speed and OTA fixes matter; your app is product screens rather than platform tricks. Choose the hybrid when: you have an existing native app and want shared velocity for new features, or a shared app with a few genuinely native surfaces.
And whichever you pick: budget for the unglamorous parts — testing, performance monitoring, release automation — because those, not the framework, decide whether the app feels professional in month twelve.
When to hire senior help
The framework decision is a one-way door worth a short senior consultation, because switching stacks after a year of development is effectively a rewrite. A senior cross-platform engineer can also audit whether your planned feature set has hidden native-heavy corners, like payments hardware or background location, that change the cost math before you commit. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.
Bottom line
Dhairya Senjaliya ships Mobile — Cross Platform Development projects worldwide — book a scoping call to discuss your specific situation.
Common pitfalls to avoid
- ✕Picking the framework by hype rather than team composition, such as a React web team adopting Flutter and forfeiting years of transferable JavaScript expertise
- ✕Budgeting for 100% code reuse and zero platform-specific time, then discovering payments, background tasks, and widgets all require per-platform native work
- ✕Recreating navigation and interaction patterns generically so iOS swipe-back gestures and Android back-button behavior both feel wrong to native users
- ✕Ignoring the maintenance tail: never budgeting for framework major-version upgrades, so the app rots on an unsupported runtime within two years
Frequently asked questions
Is React Native actually native?
React Native renders real platform-native views — a button is backed by an actual UIKit/Android view, not a webview — while your app logic runs in JavaScript. That's why well-built React Native apps feel native to users. It differs from Flutter (which draws its own pixels) and from webview wrappers like Cordova, which render HTML.
When should a startup choose native development over React Native?
When the product's core value is deep platform integration — widgets, watch apps, advanced camera/media pipelines, platform-specific AI features — or when the startup is unusually well-funded for separate iOS and Android teams from day one. For product apps (marketplaces, social, fintech UIs, SaaS companions), one React Native team shipping both platforms is usually the stronger use of an early budget.
Can React Native and native code coexist in one app?
Yes — this is a first-class, documented pattern in both directions. Existing native apps embed React Native screens for shared feature development (brownfield integration), and React Native apps drop into Swift/Kotlin via native modules and native screens wherever the platform demands it. Many production apps used by millions run exactly this hybrid architecture.
Should we choose Flutter or React Native?
Adoption among professional developers is nearly tied (9.21% versus 9.14% in the Stack Overflow 2024 survey), so the deciding factor is your team: React or JavaScript experience strongly favors React Native, while a greenfield team with no web-code-sharing needs can prefer Flutter. Both run massive production apps, so neither choice is inherently risky.
How much money does cross-platform actually save versus two native apps?
Industry cost guides put savings around 30 to 40% versus parallel native builds, driven by one codebase and one team, with production apps sharing 85 to 95% of code. Real savings depend on how much platform-specific work your feature set demands, such as payments, widgets, and background processing.
When is fully native the better choice?
Heavy 3D or AR workloads, advanced camera or audio processing, platform-first experiences like watchOS apps, or a company that already employs strong separate iOS and Android teams. For typical business, marketplace, and content apps, cross-platform is now the default choice at both startups and large companies like Shopify and Microsoft.
Bottom line: Dhairya Senjaliya ships Mobile — Cross Platform Development projects worldwide. Book a scoping call at https://dhairyasenjaliya.com/#book-call.