Every mobile project starts with the same question: cross-platform or native? The honest answer is that it depends on the app, and we'd rather tell you that upfront than default to whichever we happen to prefer building.
The case for cross-platform
React Native and Flutter let you write the interface and business logic once and ship to both iOS and Android. For a fairly standard business app, forms, lists, a feed, basic device features, this gets you feature parity on both platforms at meaningfully lower cost than building two native apps. You're not maintaining two codebases that drift apart, and a bug fix written once applies everywhere.
For most business apps we're asked to build, this is the right default. The user doesn't experience a meaningful difference in day-to-day use, and the client gets to both stores faster.
Where it falls short
Cross-platform frameworks bridge to native code for anything platform-specific: camera access, biometrics, background processing, brand-new OS features. That bridge is another layer that can introduce friction, and it means waiting on the framework to support something Apple or Google shipped yesterday.
We recommend native instead when:
- The app is performance-critical: heavy animation, real-time processing, or anything where dropped frames are actually noticeable.
- You need a platform feature the day it ships, not after a cross-platform framework catches up.
- You genuinely only need one platform. Building cross-platform for a single-platform app adds abstraction you don't need.
How we actually decide
We ask what the app needs to do before we ask what it should be built with. If the answer is "standard CRUD app with a few platform integrations," cross-platform is the practical choice nine times out of ten. If the answer involves ARKit, heavy background processing, or an experience where every millisecond of render time matters, we say so, even though it's the more expensive path and a longer conversation than just saying yes to whatever was assumed going in.
The wrong move, in our view, is deciding the tech stack before understanding the problem. We've turned down "just build it in React Native" requests when the app genuinely needed native performance, because building it wrong the first time costs more than the harder conversation upfront.