Shipping to both stores with four people
Parity between iOS and Android is a staffing decision disguised as a technical one. How a small team ships to both without doubling.
The question we get asked is which framework to use. The question that actually determines the outcome is how many people you can afford to keep on the app twelve months after launch.
Two native codebases need two specialists who each know their platform deeply, and they need to stay. If one leaves, half your product stops moving. On a team of four, that is not a risk you can carry, and it is the single strongest argument for a shared codebase.
So we run React Native with a shared TypeScript core, and we write native modules only where the platform genuinely differs — secure storage, background tasks, camera pipelines. Roughly ninety percent of the code is shared and the ten percent that is not is where the interesting bugs live anyway.
The discipline that makes it work is release engineering, not architecture. One Fastlane pipeline, one version number, one release train every two weeks, staged rollout on both stores, and a kill switch for anything risky. If the two platforms drift onto different release cadences, you have two products again.
Testing is where small teams cheat and pay for it later. We keep a device matrix weighted towards the cheap Android handsets our clients' users actually own, and we run the critical journeys on real hardware before every release. Simulators do not surface the memory ceiling.
The cost is real: some interactions feel a fraction less native, and you occasionally wait for the ecosystem to catch up with a new OS feature. For most products that trade is obviously worth it. For a product whose entire value is a platform capability, it is not, and we say so.