Native vs cross-platform apps

Cross-platform frameworks save you a second codebase. One team writes the screens, the business logic, the API calls, and the tests once, and both stores get the same features in the same release. For an app that is mostly lists, forms, accounts, payments, and notifications, that is most of the work, and the saving is large.

What it does not remove is platform work. Push notification setup, in-app purchases, deep links, permissions, store listings, and review rules are still per platform. A good cross-platform team knows each platform well enough to handle those, and plans early for the parts that need native code.

Pick native when the app is built around something the platform does: home screen widgets, Apple Watch or Wear OS companions, Live Activities, deep background processing, or custom camera and audio pipelines. Those parts are written in Swift or Kotlin in a cross-platform app anyway, and if they are most of the app, the framework is overhead.

Pick native when you ship on one platform only. If your users are all on iPhone, there is no second codebase to save, and SwiftUI gives you the platform directly.

And pick it when on-device performance is the product: real-time graphics, heavy on-device machine learning, or audio processing where every millisecond is felt.

Pick cross-platform when you need both stores and one team. For most business apps, member apps, marketplaces, and companion apps for a web product, users cannot tell the difference, and you ship features to everyone at once.

Pick it when you have a web app. With React Native, a React or Next.js team can share types, API clients, and logic between web and mobile, and move between them.

And pick it when the budget is fixed. Building twice is roughly twice the cost to build and to maintain, and for an app whose value is in the data and the workflow, that money is better spent on the product.

The choice is rarely all or nothing. A React Native app can include native modules for the one feature that needs them: a widget, a custom media player, or a specific SDK. That keeps one codebase for the ninety percent of the app that is ordinary, and full native access for the rest.

Going the other way also works. A native app can embed a few shared screens. What matters is drawing the line on purpose, early, so you do not discover in month six that a core feature fights the framework.

We have shipped a native iOS app in SwiftUI and three cross-platform apps in React Native with Expo. We have not shipped a native Android app in Kotlin or Jetpack Compose, so on Android our production experience is through React Native. If your project needs a native Android specialist, we will tell you that before you sign.