Choosing Between Native Android and React Native/Expo for a New Mobile Product
Every mobile project starts with the same question, usually asked in the first thirty minutes of the first call: "should this be native, or can we do it cross-platform?" The honest answer is that it depends on what the app actually needs to do well — not on which stack is trendier this year.
Start from the constraint, not the stack
We shipped Universal Remote as native Android with Kotlin, and that wasn't a default — it was a decision. The app's entire value proposition is low-latency device control: the gap between a tap and a response has to be small enough that it feels instant. That kind of timing-sensitive, hardware-adjacent behavior is exactly where native still has a real edge — you're closer to the platform's actual scheduling and I/O behavior, with fewer layers between your code and the device.
WakeForge is a different kind of app. An alarm and wake-up experience lives and dies on reliability of background scheduling, not on shaving milliseconds off a UI interaction. We also built it native, but for a different reason: Android's background execution limits (Doze mode, battery optimization, exact-alarm permissions) are subtle enough that we wanted direct control over how the app negotiates with the OS, rather than trusting a cross-platform abstraction layer to get every edge case right on every OEM's modified Android build.
Where cross-platform genuinely wins
None of this means cross-platform is a compromise. For a product that's primarily a UI over an API — most business apps, most MVPs, most internal tools — React Native or Expo gets you to a working iOS and Android build from one codebase, and that matters more than any native-only capability you're unlikely to use. The calculus changes again if your team is already a web/React team: the learning curve to productivity is shorter, and you can share real logic (not just vibes) between your web and mobile codebases.
The mistake we try to avoid is treating this as an ideological choice made once, in a kickoff meeting, based on what the last project used. It's a per-product decision, and the right question isn't "which is better" — it's "what does this specific app need to be good at, and which stack gets you there with the least fighting."
A practical checklist
When we're scoping a new mobile product, the things that actually move the needle toward native are: hard real-time or low-latency requirements, deep background-execution needs, heavy use of platform-specific hardware APIs, or a UI that needs to feel exactly like the platform's own apps. Everything else — most CRUD-heavy, content-heavy, or workflow-heavy apps — is usually better served by getting to market faster with a cross-platform codebase, then reaching for native modules selectively if a specific feature genuinely needs them.
If you're scoping a mobile product and aren't sure which side of that line you're on, that's a reasonable thing to bring to a first call — it's usually clearer once you write down what the app has to be good at, not just what it has to do.