One codebase. Two stores.
And an honest list of the exceptions.
Cross-platform saves real money on the eighty per cent that is screens and forms. Our engineers know exactly where the other twenty per cent starts — and they say so before you have built on top of it.
iOS
Android
Share it, share it carefully, or go native
We fill this in for your app in the first week, before any code. The rows marked “go native” are the ones that decide whether React Native is the right choice at all — and we would rather lose that argument early than bill you for it late.
Ninety per cent of most apps. One codebase, platform-idiomatic navigation, no compromise worth arguing about.
Shared logic, but the setup diverges. Budget a day per platform for certificates and channels, not an afternoon.
Fine until you need frame processing or a specific codec. Android device fragmentation is the real cost here, not React Native.
Both platforms fight you. Anything genuinely long-running belongs on your server with a push, not in the app.
Writeable through a bridge, but you are writing Swift and Kotlin either way. Hire accordingly.
This is where we tell clients not to use React Native. We would rather say it in the first call than the fourth month.
The five things that separate an app from a demo
Anyone can build the screens. These are the parts that decide whether the app survives its second year and its fourth OS upgrade.
Expo or bare, chosen deliberately
Expo for speed and over-the-air updates; bare when you need a module Expo will not host. Migrating between them late is expensive, so it is a week-one decision.
Over-the-air updates
JavaScript fixes reach users in minutes instead of waiting on a store review — with a rollback and a staged rollout, not a blind push.
Release engineering
Signing, provisioning, TestFlight, Play internal track, phased release and the metadata that keeps a submission from being rejected.
Crash-free rate as a metric
Sentry or Crashlytics wired on day one, with a target on the dashboard and a triage habit — not a screenshot at the end of the quarter.
Startup time budget
Cold start measured on a real mid-range Android, not a simulator. Hermes on, bundle split, and the splash screen honest about what it is hiding.
The native boundary is a seniority question
If your app needs a native module, that is a senior hire. If it is screens, forms and an API, mid-level is genuinely enough and costs a third less.
- Lead time
- 6–10 days
- Minimum term
- 1 month
Mid-level
3–5 yrs$28–34/hrBuilds screens and flows in an existing app. Comfortable with navigation and state; leans on others for the native side.
Senior
5–8 yrs$34–42/hrOwns the app. Writes a native module when needed, runs the release train, and knows which Android devices will embarrass you.
Lead
8+ yrs$42–56/hrSets the architecture, the update strategy and the native boundary — and tells you when React Native is the wrong answer.
Send us your feature list
We will fill in the parity table for it and tell you whether one React Native engineer covers it or you need a native specialist beside them.