The decision that costs the most to reverse
Native vs cross-platform mobile development is the call that defines the next two to four years of your app. Pick wrong and you spend the second year fighting the framework instead of shipping features. We have built apps in all four modes (Swift, Kotlin, React Native, Flutter, Kotlin Multiplatform) for production clients across healthcare, construction, and B2C. The honest answer is: it depends, but there is a useful framework.
When to go fully native
Fully native (Swift for iOS, Kotlin for Android) is the right call when the value of the app lives in platform-specific surfaces. HealthKit and CareKit, ARKit, widgets, App Clips, Live Activities, background processing, complex camera or sensor pipelines, deep audio work. If your roadmap mentions any of those in the next year, native pays for itself. The team cost roughly doubles compared to cross-platform, but you ship native performance and you do not get blocked when a new OS feature lands.
When cross-platform earns its keep
Cross-platform is the right call when the app is mostly screens, forms, lists, network calls, and shared business logic with conventional native behavior. This is where most B2B internal tools, marketplace clients, and content apps live. Flutter and React Native both ship production-grade results here. Pick Flutter if your team values strict layout control and you have no existing React investment. Pick React Native if your web team already runs React and you want code reuse across surfaces.
The middle ground: Kotlin Multiplatform
Kotlin Multiplatform (KMP) is the option people forget. You share business logic, networking, and data layers in Kotlin while keeping native UI on each platform. The upside: production-grade native UX with 50-70% code reuse on the parts that matter. The downside: it requires two platform teams that can cooperate. KMP wins for serious B2C apps where you want native feel but also a consistent business core.
Team structure decides more than you think
The framework conversation is downstream of team structure. If you have one developer, cross-platform is the only realistic answer. If you have two developers and you can hire a third, native pays back within a year. If you have a web team that already knows React deeply, React Native lowers training cost dramatically.
Performance reality check
For 80% of business-app workloads, cross-platform performance is indistinguishable from native. For the other 20% — high-frequency animations, real-time sensor data, complex list virtualization, on-device ML — the gap is visible and worth the native cost. Test the hot paths early with a prototype rather than betting the whole app on a framework promise.
App Store and Play Store compliance
Native gets you fastest access to new Apple and Google requirements. Cross-platform frameworks lag by weeks to months on major OS releases. If your industry has strict compliance timelines, factor this in.
Our default recommendation
For a new B2B app with a small team and a roadmap that does not require deep platform integration, we usually recommend Flutter. For a serious B2C product that needs to scale across iOS and Android with native feel, we usually recommend native iOS plus native Android with a Kotlin Multiplatform shared core. For a quick MVP that the team will later rewrite, React Native if the team already knows React, Flutter otherwise.
None of this is religious. The right answer for your app depends on your team, your roadmap, and your tolerance for framework risk. Get those three right and the technology choice gets a lot smaller.
