The React Native vs native debate is one of the longest-running arguments in mobile engineering, and most of the public discourse on it is unhelpful — it's either Meta employees telling you RN ships everywhere, or Apple-shop developers telling you Swift is the only serious option. Neither is wrong. Both are missing the question your team is actually trying to answer.
Over the last four years we've shipped nine production mobile apps. Five on React Native (HipHopGrails, PlaySQOR, VideoShops, GetCashback, OnlyBeaches). Four fully native (RealProfits iOS-first, two internal tools, one client we can't name). The decision framework we use now is shorter than the one we started with, and we've stopped letting it be a religious debate.
The question that actually matters
It's not 'which is faster' or 'which is more performant'. It's: how much of your product's value is in the rendering layer? If the answer is 'most of it' — your product is a camera, a game, a music player, a 3D viewer, anything where the pixels on screen are the product — go native. The savings from a shared codebase will be eaten by the time you spend fighting the framework.
If the answer is 'very little' — your product is a list of things, with screens that fetch data, show it, and let users do CRUD on it (which is 80% of mobile apps including most fintech, e-commerce, content and gaming app shells) — React Native is the right answer. The shared codebase is a real, ongoing 40–60% engineering saving over the life of the product.
Where React Native actually wins
It's not 'write once run everywhere' — that was always a lie. It's three things that compound:
- One product engineering team, not two. The same engineer ships the iOS and Android version of a feature in the same week. Coordination cost goes from O(n²) to O(n).
- Hot reload during development. Native devs underrate this because they've forgotten how slow native rebuild loops are.
- OTA updates via CodePush / EAS Update. Push a bug fix in 30 minutes instead of waiting four days for App Review. For a business-critical app, this is worth real money.
- Hiring liquidity. Senior React engineers outnumber senior Swift+Kotlin pairs by something like 10:1 in the markets we hire from. That's not RN's fault, but it's RN's advantage.
Where native actually wins
Same exercise, opposite direction. Native earns its complexity premium when:
- You need 120fps interactions on complex UI. RN's New Architecture closed most of this gap but didn't eliminate it.
- You need deep platform integration — Live Activities, App Clips, Widgets, HealthKit, ARKit, advanced background tasks. RN can bridge to all of these but you'll write native code anyway, and now you're maintaining a bridge.
- You're shipping a single-platform product. If you're iOS-only for the first 18 months, RN's cross-platform value is zero and you're just paying its cost.
- Your app is a game, a creative tool, or anything where the GPU is doing the work.
The hidden cost of RN — and how we manage it
RN has a real hidden cost: every native module dependency is a long-term liability. The package author can stop maintaining it. The library can break on a Swift toolchain bump. The peer dependency tree can turn into a maze. We've been bitten by this enough times that we now treat every native dependency as a decision that needs justification, the same way we'd justify pulling in a major library on the backend.
Our rule: if a feature needs more than three native modules we don't already use, we re-evaluate whether the feature wants to be native. Sometimes the answer is yes. Sometimes the answer is 'this whole flow should be a native sub-app embedded in the RN shell', which is a pattern that works surprisingly well.
The framework we use now
When a new mobile project lands on our desk, we walk a three-question decision tree:
- 1. Is the rendering layer the product? (Camera, game, 3D, music DSP.) If yes → native. Stop.
- 2. Will this ship on both iOS and Android within the first 12 months? If no → native, on the platform you actually need.
- 3. Does the team need to push fixes faster than App Review allows? If yes → React Native, for the OTA capability alone.
If it's a no-no-yes — RN. If it's a yes-yes-no — native. The other combinations are judgment calls, and we make them with the client in the room.
The honest summary
After nine apps, we don't think there's a winner. There's a fit. The teams that get burned are the ones who picked the framework based on a tweet thread or their CTO's last gig, not the actual product. Pick based on where your product's value lives. The rest is implementation detail — and we've shipped both, several times, and would happily ship either again.