Skip to main content
Mobile App Development

Native vs Cross-Platform: The Honest Answer

Everyone has an opinion on this. The real answer depends on the app, the team, and the budget. Here is how we actually decide.

April 5, 20266 min readThe Agaro Team

Every mobile engineering conversation eventually hits this question. Should we build native or cross-platform? React Native, Flutter, Expo, Kotlin Multiplatform, or just straight Swift and Kotlin? The tribal answers are religious. The honest answer is it depends.

Here is the decision tree we actually use.

If the app is going to live on one platform only, native is almost always the right choice. Less abstraction, faster iteration, full access to platform features, easier hiring. The cost savings of cross-platform do not apply if you are only on one platform.

If the app needs to be on both platforms, and the app is mostly forms, lists, and API calls, cross-platform wins. Specifically React Native or Flutter for most of our builds, Expo if we want to move fast. You write one codebase and ship both. The performance hit for this category of app is invisible to users.

If the app needs heavy native features, real-time graphics, platform-specific UI conventions, or deep integration with OS-level services, native starts winning again. The abstraction layer of a cross-platform framework gets in the way more than it helps once you need fine-grained platform control.

If the team is small and has to ship fast, cross-platform usually wins regardless, because the overhead of managing two codebases and two release processes is more than the performance benefit is worth at that team size.

If the team is large and has deep iOS and Android expertise, native wins, because the team can move faster in their native stacks than in any abstraction layer.

The tribe that says "always native" is usually working on apps where native genuinely wins. The tribe that says "always cross-platform" is usually working on apps where cross-platform is fine. Both tribes are right in their own context and wrong when they generalize.

Our default, if I had to pick one, is React Native with a small amount of native code dropped in for the parts that need it. That combination has the best cost-to-outcome ratio for the apps we most commonly build. But we have shipped pure native, pure Flutter, and everything in between, and we pick based on the specific project, not the ideology.

Keep going

Want the version for your business?

We build this for a living. If this post hit close to home, tell us what you are working on and we will tell you honestly whether we can help.

Keep reading