React Native or native development?

01

Understand what changes between the approaches

React Native lets you build a mobile application with React, using JavaScript or TypeScript and components backed by native platforms. In this article, native development means a dedicated iOS implementation and a dedicated Android implementation, using their respective tools. The server, business rules exposed through APIs and design work can remain shared in either approach.

On Apple platforms, SwiftUI creates interfaces in Swift and can work alongside UIKit. On Android, Jetpack Compose is a toolkit for native interfaces with Kotlin APIs. These examples help explain the ecosystems; they do not cover every possible architecture or existing codebase.

02

Start with usage and the devices to support

Begin by describing a complete action: booking a service, sending a request, viewing a record or logging a visit without a connection. Identify the users, the information they need and the expected outcome. A list of screens does not yet explain the application’s constraints.

Then establish which devices are actually involved. A team using only iPhones and a public service for both iOS and Android raise different questions about shared code. Also specify supported operating system versions, connectivity conditions, accessibility requirements and device features. This gives prospective delivery teams a comparable scope.

03

When React Native is worth considering

React Native is worth evaluating when a product must evolve on iOS and Android with similar journeys: accounts, content, forms, bookings or request tracking, for example. A shared codebase can help coordinate common changes, provided the required integrations are understood and the team can maintain that codebase.

Sharing does not mean every line must be identical. React Native explicitly supports platform variants through mechanisms such as the Platform module and iOS or Android specific files. Identify useful differences during design rather than pursuing a theoretical code sharing target.

Ask for demonstrations of important journeys on both systems. Examine forms, the keyboard, navigation, permissions and error states. Assess shared development through the work actually reused and the quality delivered to users.

04

When to investigate native development further

Give native development particular attention when the product’s value depends on a platform specific SDK, demanding hardware processing or substantially different iOS and Android journeys. Investigate these questions with a prototype and the supplier’s documentation, rather than drawing conclusions from a feature name alone.

React Native also connects native code to the application through native modules and components. A particular feature therefore does not automatically rule it out. Check the available implementation, its compatibility and who will maintain it.

If the uncertainty warrants it, compare two implementations of the critical requirement: an integration in a shared application and an implementation directly in the native environment. Assess what works, observed limitations and maintenance effort. An existing stable, maintainable application also deserves examination before a rewrite decision.

05

Measure performance on real user journeys

React Native documentation recommends testing performance in release builds because development mode adds runtime overhead. A useful comparison therefore needs builds representative of those you will distribute, following the same test protocol.

Define what to measure: time until a screen becomes usable, list smoothness, response after an action, memory use or behaviour during an extended session. Test devices representative of your audience, including the least powerful ones you intend to support, with realistic data and network conditions.

Then investigate the observed problem: an overloaded screen, images, server requests, local processing or a particular integration. Changing mobile technology will not fix a slow API. Identify necessary optimisations before attributing a difference to React Native or native development.

06

Compare budget and maintenance over time

A shared codebase does not automatically halve a budget. Scoping, design, the server, integrations, testing and publication still need planning. Conversely, two native applications can share API contracts, design rules and some monitoring tools. Compare actual work with the same deliverables and quality criteria.

For each option, ask about dependencies, support for operating system updates, incident handling and release responsibilities. A team familiar with React for the web still needs to demonstrate mobile skills. A native team needs to explain how it coordinates changes across platforms.

The budget should also make work after the first release visible: new journeys, technical adaptations, changes to external services and handover to another team. Plan access to source code, publication accounts, environments and documentation. These arrangements matter as much as the initial technology choice for retaining control of the product.

07

Decide using six criteria and supporting evidence

For each criterion, record the requirement, available evidence and remaining uncertainty. An essential requirement without validation should trigger a test, even when other criteria look favourable. Understanding a blocking constraint is more useful than adding up scores that suggest false precision.

The following two situations are fictional and only illustrate the process. They do not describe client results and cannot determine the technology choice for another project.

08

Validate the critical requirement before committing to delivery

A technical prototype should resolve a specific uncertainty: SDK behaviour, synchronisation after connection loss, video processing or operation on a target device. A clickable mockup helps test journeys but does not prove these technical constraints are resolved.

At the end of this step, keep test results, limitations and decisions. The recommendation should explain why the chosen option fits the scope, which skills it needs and what might lead you to reassess it. You can then commit to a first release with shared acceptance criteria and adjust subsequent work based on observed usage.