Skip to content
All articles

· 3 min read

Native or Cross-Platform? An Honest Decision Guide for 2026

Swift and Kotlin or React Native? We have shipped both for years. Here is when each approach wins, without the tribal thinking.

Author: Philip Marienfeld

Hardly any question comes up as often in first conversations as this one: "Should we build native or cross-platform?" And hardly any question gets answered with as much dogma and as little reasoning. We have shipped both over the years: native apps in Swift and Kotlin as well as cross-platform projects with React Native and Expo. Here is the answer we give our own clients.

The short answer

There is no winner. There is only a fitting choice for your product, your team and your budget. Anyone who tells you "always native" or "always React Native" is usually selling you what they happen to be best at, not what your project needs.

When cross-platform wins

React Native with Expo has grown up. By 2026, the New Architecture is the default, over-the-air updates are production-grade, and the EAS toolchain removes a lot of infrastructure work. Cross-platform is our recommendation when:

  • The app is fundamentally about content, forms and workflows. That covers most business and B2B apps. Lists, detail views, input forms, push notifications: nobody needs two separate codebases for that.
  • Time-to-market matters. One codebase, one team, one release process. For MVPs and products whose market is still being validated, that is a real advantage.
  • The budget doesn't support two native teams. Maintaining two platforms natively costs close to double, not just to build, but across years of maintenance.
  • A web app is planned anyway. If you have React in-house, you can reuse knowledge, components and sometimes even code.

When native wins

Swift and Kotlin remain the right choice when the app reaches deep into the platform:

  • Bluetooth, background processing, sensors. We spent years building apps for keyless car access over Bluetooth LE; projects like that live and die by precise control over background behavior. Every abstraction layer in between costs reliability.
  • The highest bar for UI and feel. If the app should feel 100% like iOS or Android respectively, including day-one support for new platform features, there is no way around SwiftUI and Jetpack Compose.
  • Compute-heavy work. Audio processing, image analysis, real-time rendering: every millisecond counts, and native code has the edge.
  • Only one platform is planned. If you are only shipping iOS anyway, cross-platform gives up its main advantage while you still pay the abstraction tax.

The questions that actually decide it

Instead of arguing about frameworks, we ask three questions in every project:

  1. Which platform features will the product need in two years? Not just today. Switching approaches later is expensive.
  2. Who maintains the app long-term? An in-house team with React experience points to React Native. An iOS team points to Swift.
  3. What does a failure cost? In a content app, a UI glitch is annoying. In an app that unlocks cars, reliability is non-negotiable.

Our verdict

For the majority of business apps we see in 2026, React Native with Expo is the economically sensible choice: the technology is mature, the ecosystem is stable, the savings are real. But as soon as hardware proximity, background reliability or an uncompromising platform feel are required, we build native, and we have never regretted it.

If you are unsure where your project falls: ask us. We have walked both paths to the end often enough to give you an honest assessment, and if the answer is "it depends", we will at least tell you clearly what it depends on.

Ready for lift-off?

Tell us about your project with no strings attached and no detours. You talk directly to the developers who will build your product.