One of the first questions every founder asks before writing a line of code is whether to build native (separate Swift/Kotlin codebases for iOS and Android) or cross-platform with something like React Native. There's no universally correct answer, but there is a correct way to think about it.
Start with your constraints, not the technology
Most early-stage teams don't have the budget or headcount to maintain two native codebases in parallel. If you're validating a product idea, shipping to both App Store and Play Store from one codebase means faster iteration and a single bug to fix, not two. That's the case for React Native for the majority of startups we work with.
Native still wins when your app leans heavily on platform-specific capabilities — deep custom animations, heavy background processing, or bleeding-edge OS features the day they ship. If that's your core product, not a nice-to-have, native is worth the overhead.
What cross-platform actually costs you today
The old argument against React Native was performance and access to native modules. Both have largely been solved: the Expo ecosystem now covers the vast majority of device APIs founders need — camera, biometrics, push notifications, background location — without writing native code. Performance is indistinguishable from native for the kind of CRUD-heavy, form-and-list apps most startups build.
- One codebase, one team, one release cadence across iOS and Android
- Faster iteration cycles when you're still validating the product
- A large, mature ecosystem (Expo) that covers most native device APIs
- Easier to hire for than two separate native specialties
Our default, and when we break from it
We build almost everything in React Native and Expo because it's the stack that gets founders to a store-approved release fastest without painting them into a corner later. If a technical assessment turns up a hard requirement that genuinely needs native — we'll tell you plainly, before you've spent a cent on the wrong architecture.