Somewhere near the start of a mobile project, a decision gets made that quietly shapes everything after it: whether to build twice, build once in a cross-platform framework, or pick a middle path. It rarely gets the attention it deserves, because it looks like a technical preference. It is closer to a business decision about budget, timeline, and who will maintain the thing in two years.
Here is how the three common routes compare, and who each one tends to suit.
Native iOS and Android, built separately
This is two codebases, two teams or one team working twice, and two release cycles. It is the most expensive route and the slowest to reach feature parity, because every change happens twice. What you get in return is the closest possible fit to each platform: the gestures, the animations, the camera and sensor behaviour, the things users feel rather than see.
It suits products where the phone is the product and performance is the differentiator — heavy media, real-time interaction, anything where a dropped frame is a lost user. It also suits organisations that already have separate iOS and Android teams and no reason to merge them. If neither is true, the cost is hard to justify.
React Native, one codebase leaning on native
React Native lets a team write most of the app once and drop into native code where it matters. The practical appeal is speed of iteration and a shared skill set with web work, which matters for startups that need to move and for teams already comfortable in JavaScript and TypeScript.
The tradeoff is that the seams show if nobody owns the architecture. A React Native build can feel indistinguishable from native, or it can feel like a web page in a phone-shaped window. The difference is not the framework; it is whether the team treats performance and device testing as part of the job. It suits product teams shipping a focused app on a realistic budget, with someone senior enough to make the right calls about what stays shared and what goes native.
Flutter, one codebase drawing its own interface
Flutter renders its own UI rather than borrowing platform components, which gives tight control over how the app looks and behaves on both platforms. That consistency is genuinely useful for design-led products, and the framework has a strong story for animation and custom interfaces.
The cost is a different ecosystem and skill pool, and a look that is consistent by design rather than native by default. It suits teams with a strong design vision and a willingness to commit to the framework's way of doing things, and products where visual identity matters more than platform mimicry.
What none of them fix
No framework choice saves a project from being tested only on simulators, or from being handed over without documentation and a clean repository. Those failures look like framework problems and are not. A good result in any of the three routes looks the same from the outside: it opens fast, scrolls smoothly, behaves properly on an older handset, and the team that inherits it can read the code.
The full guide, including how the decision is actually made and what a properly built cross-platform app ships with, is on the mobile app development page for London teams.
Top comments (0)