Native or cross-platform? How to choose for your app

Choose by what the app must do, not by preference. Most business apps are made of forms, lists, content, payments, maps and notifications, and for those a cross-platform build is the sensible default: one team and one codebase cover both stores. Choose native when the device itself defines the product: a custom camera pipeline, augmented reality, background Bluetooth, a watch app, heavy graphics, or a need to use new system features the day they ship.

This article is about the decision, not the tools, so it does not repeat the framework comparison. For Flutter against React Native, read [Flutter vs React Native](/blog/flutter-vs-react-native). For plain definitions, see the glossary entries on a [native app](/glossary/native-app) and a [cross-platform app](/glossary/cross-platform-app).

Start with what the app must do on the device

The first question is technical, and you can answer it in an hour: which features touch the hardware or the operating system in an unusual way? Most of what apps do is ordinary, and both approaches handle it. A few things are not, and those few decide the matter.

Be strict about the middle rows. A feature that a package supports in a demo can still fail in the background on a locked phone, or when the operating system limits battery use. Test the exact behaviour you need, on real devices, before you choose.

Product factors that tip the choice

Do not assume the split between iPhone and Android users. It varies by country, by industry and by the kind of user, so check your own analytics, or the market you are entering, before you decide. If nearly everyone you serve holds one platform, a single-platform first release is a legitimate choice, native or cross-platform.

Navigation and gestures differ between iOS and Android: back behaviour, sheets, menus, system dialogs. A native app follows these conventions without effort. A cross-platform app can follow them too, but someone must decide where to adapt and where to keep one brand-led design on both. Make that decision on purpose, during [mobile app design](/services/ui-ux-design/mobile-app-design) rather than testing.

If you are still testing demand, the cheapest build that answers the question wins. That might be a cross-platform [MVP](/glossary/mvp), a no-code prototype or a web app; [when no-code is the smart first version](/blog/when-no-code-is-the-smart-first-version) covers the last two. Native on two platforms is hard to justify before you know the idea works; once demand is proven, native in the right places is easier to defend.

Team factors

The right architecture is the one your team can still maintain in two years. These points usually matter more than any technical detail:

• **Skills you already have.** A team fluent in React or TypeScript, or a web product whose logic you want to share, leans cross-platform. A team of Swift and Kotlin specialists leans native. Avoid asking people to learn a new stack under a deadline.
• **One team or two.** Native needs iOS and Android skills, which usually sit with different people, and two small teams must keep the apps in step: the same features, the same wording, the same bugs fixed.
• **Hiring in your market.** Know who you can actually hire or contract locally, for the first build and for the years after.
• **Who owns it after launch.** If a vendor builds the app and your team takes it over, choose a stack your team can read.
• **Native literacy.** Even a cross-platform project needs someone who can read Swift or Kotlin, for the build and the occasional native module.

What you give up with cross-platform

Cross-platform trades some directness for shared effort. The cost is real, and for business apps it is usually modest. Know the list before you accept it:

• **A layer between you and the platform.** New system features reach the framework after they reach the platform, and sometimes need a native wrapper.
• **Packages maintained by others.** Camera, maps and payment packages depend on volunteers or vendors. Choose maintained ones and review them like any dependency.
• **Native code at the edges.** Unusual features still need Swift or Kotlin, so a cross-platform project is never fully free of native code.
• **Platform feel needs care.** Defaults are close, not identical. Budget design and test time for each platform.
• **Upgrade work.** Each framework release can touch your dependencies, every year, in either approach. Plan it as maintenance; [how much a mobile app costs](/blog/how-much-does-a-mobile-app-cost) lists the upkeep people forget.
• **Size and start-up differences.** An app can be larger or start more slowly than a lean native build, which shows most on older phones.

What you give up with native

• **Two codebases and two skill sets.** Every feature is designed once, built twice, tested twice and fixed twice, by specialists in each platform.
• **Drift.** The apps slowly differ in features and wording unless someone owns parity between them.
• **Slower learning.** Changing an idea takes longer when two apps carry it. That matters most before you know what works.
• **More effort, not double.** Design, backend, API, content and release management are shared work. See [iOS and Android development](/services/mobile-development/ios-android) for how we approach native projects.

In return you get the shortest path to everything the platform offers, the closest fit with its conventions and fine control over performance. For products that depend on those, the extra effort buys something users can feel.

Middle options

The choice is not always pure. Three mixes are common:

• **Cross-platform with native modules.** Most of the app is shared, and the few demanding features are written natively and called from the shared code.
• **Shared logic, native screens.** Some teams share data handling and rules between the platforms and keep each interface native, which suits a product where the interface matters most.
• **A web app first.** If you need neither store distribution nor deep device access, an installable web app can test the idea, though its access to device features is narrower and differs by platform.

Whichever you pick, keep the business rules on the server behind an [API](/glossary/api), not duplicated inside the app. It makes every later change cheaper, including a move from one approach to another.

Questions to answer before you choose

A hypothetical example, not our work: a retailer building a shopping and loyalty app has ordinary features and two platforms to reach, so cross-platform fits. A company building an app that measures rooms with the camera and augmented reality has a camera as its product, so native fits at least that part.

Test the cheapest thing before the big decision

Before you commit, build a small spike of the riskiest feature in the stack you lean toward, on real phones, in Arabic and English. A few days of that often settles a debate that weeks of opinions would not. In our engagements the [discovery sprint](/pricing) ends with a technical approach and a clickable prototype, which is where this choice gets made on evidence rather than taste.