React Native vs native: how to choose for your first mobile app

There are three realistic ways to put a product on a phone. A cross-platform framework such as React Native builds iOS and Android apps from one codebase. Fully native development builds each app separately, in Swift for iOS and Kotlin for Android. A progressive web app is a website that behaves like an app. The right choice depends on what the app has to do, not on which technology is fashionable.

What is the difference between React Native and native?

A native app is written in the platform's own language against the platform's own tools. You get every device feature the day it is released, and you maintain two codebases.

A React Native app is written mostly in TypeScript. It renders real native interface components, so buttons, lists and navigation look and behave like the platform's own. Most code is shared between iOS and Android. Where a feature needs it, native code can still be added for one platform.

Side by side

	React Native	Fully native	Progressive web app
Codebases	One	Two	One, shared with the site
Languages	TypeScript	Swift and Kotlin	TypeScript or JavaScript
App Store and Google Play	Yes	Yes	Limited
Push notifications	Yes	Yes	Yes on Android, more limited on iOS
Access to device hardware	Most features	All features	Some, varies by browser
Typical cost for both platforms	Lower	Highest	Lowest

When is React Native the right choice?

For most business and consumer apps: booking, ordering, messaging, dashboards, marketplaces, account management. These are mostly screens, lists, forms and network requests, which is exactly where sharing code pays off.

It is a particularly good fit when you already have a web app in React or TypeScript. Business logic, API clients and type definitions can be shared between web and mobile, so a rule changed in one place changes everywhere.

Tools such as Expo also allow small fixes to be delivered over the air, without waiting for a full store review each time.

When should you go fully native?

• Games and graphics-heavy apps
• Augmented reality
• Apps built around deep hardware use: advanced camera pipelines, Bluetooth devices, background processing
• Apps that must adopt new platform features the week they launch
• Teams that already have experienced Swift and Kotlin engineers

If the app's main value is something the phone itself does, native is usually worth the extra cost.

When do you not need an app at all?

More often than people expect. A fast, mobile-friendly website is enough when:

• People use it occasionally, not daily
• They arrive from a search or a link
• You do not need notifications or offline access

An app has to be found, downloaded and kept. That is a lot to ask for something a person uses twice a year. Build the website well first, and build the app when your regular users ask for it.

What about performance?

For typical apps, users cannot tell the difference. The performance problems people associate with cross-platform apps usually come from how the app was built, such as long unvirtualised lists or too much work on one thread, not from the framework.

What else should you plan for?

Whichever route you take, budget time for the parts that are not code:

• Apple and Google developer accounts, in your company's name
• Store listings, screenshots and privacy declarations
• Review, which usually takes a few days and sometimes ends in a rejection that needs a fix
• A release process, so updates are routine and not an event

The short answer

Start with a mobile-friendly web app if you are still testing the idea. Choose React Native when you need to be in both stores with one team. Choose native when the hardware is the product.

We build with React Native and Expo. If that fits what you are planning, see our mobile app development service, or read what to cut from your MVP before you scope it.