React vs React Native: which should you use?

Short answer by starting point

Do not rewrite a working web product because React Native sounds more native. Name the user outcome the current architecture cannot deliver, then test that outcome.

React and React Native share concepts, not the renderer

React is a library for building interfaces from components. On the web, React commonly renders DOM elements such as div, button and input and uses browser layout, events and accessibility APIs.

React Native uses the React programming model but renders platform views through components such as View, Text, Image and TextInput. CSS files, DOM components and most web UI libraries do not move directly into a React Native screen.

Our default for an existing product: web plus Capacitor

For most products we have operated, a responsive web application packaged with Capacitor is enough. The web product remains the source of truth while Capacitor creates owned iOS and Android projects around it.

• Web, iOS and Android share the same interface and product behavior
• Existing routes, forms, validation and backend integration remain useful
• Most feature changes are implemented once
• Xcode and Android Studio projects remain available for signing and native configuration
• Native APIs are connected through plugins
• Custom Swift, Java or Kotlin functionality can be exposed through a focused plugin
• The team can continue normal web deployment where appropriate

Capacitor describes itself as a native runtime that can be dropped into an existing modern JavaScript project. It is not limited to placing a bookmark on the home screen.

What web plus Capacitor can do

A shared web interface does not mean the installed application must be read-only or disconnected from the device.

Native capability availability is not the same as a complete product flow. Every permission, callback and failure state must still be designed and tested on real devices.

When Capacitor is the wrong default

Code reuse is valuable only while the underlying web experience can satisfy the product.

• Complex gestures and transitions are central to repeated use
• The interface must sustain demanding animation, canvas, video or graphics workloads
• Large parts of the product run continuously in the background
• Offline-first local data and conflict resolution define the application
• Native navigation and platform-specific screens dominate the experience
• A required SDK expects direct native view composition throughout the interface
• The existing web interface performs poorly on mobile and needs a fundamental redesign
• The team intentionally wants different mobile and web products

One hard native feature does not always require a complete React Native rewrite. Test whether a focused plugin or one native screen can isolate the requirement.

When React Native wins

React Native is strongest when the product should feel mobile-first and the company accepts a distinct mobile client.

• Navigation, gestures and transitions are part of the product advantage
• The team wants native host views while sharing most iOS and Android application logic
• The required device libraries have maintained React Native support
• Mobile releases matter more than reusing the web interface
• The application needs deeper integration with background services or native UI
• The team can operate JavaScript, iOS and Android dependencies together

React Native 0.76 enabled its New Architecture by default. That architecture uses a new renderer and module system, supports modern React capabilities and removes the old asynchronous bridge in favor of direct native interfacing. The practical implication is not “every app is now fast.” Library compatibility, interface design and application code still determine the result.

React Native versus native Swift and Kotlin

React Native renders native host views and can call native modules, but it still adds a cross-platform runtime and JavaScript application layer. Swift and Kotlin use each platform toolchain directly.

Choose fully native when direct platform access and interaction quality justify implementing and testing the product twice. Choose React Native when sharing the mobile client creates more value than complete platform independence.

Use Expo as a production workflow, not only a preview app

Expo provides a practical React Native toolchain, native configuration model and hosted EAS services. Expo Go is useful for learning and quick prototypes, but Expo documentation describes development builds as the production-grade path.

• Create a development build with the native libraries the app actually uses
• Rebuild the development client when native code or configuration changes
• Use config plugins or generated native projects for platform setup
• Use EAS Build or local Xcode and Android Studio builds
• Separate development, preview and production variants
• Manage runtime versions when using over-the-air JavaScript updates
• Use EAS Submit to upload binaries, then complete store listings and review separately

EAS can manage signing credentials if requested and can automate builds and uploads. It does not remove product QA, privacy declarations, reviewer access or store-policy ownership.

Be honest about code sharing

React web and React Native can share more than nothing, but less than a single web plus Capacitor application.

A monorepo can make shared packages explicit, but it does not turn web components into native screens automatically.

The backend can remain shared

Choosing React Native does not require rebuilding the backend. Web and mobile clients can use the same API, authentication system, database and entitlement service if their contracts are designed for multiple clients.

• Version API behavior so installed older builds continue to work
• Keep authorization on the server or database boundary
• Use stable error codes and not only human-readable messages
• Separate browser redirects from mobile deep-link callbacks
• Map web and store purchases to one customer entitlement model
• Record client platform, app version and request correlation
• Plan rate limits and retry behavior for unreliable mobile networks

The client framework cannot compensate for an unsafe authorization model or an API that assumes every user runs the latest version.

Compare performance with a real workload

“Native performance” is too vague to choose an architecture. Define what must remain responsive and under which device and data conditions.

• Cold start and time to usable interface
• Navigation and transition responsiveness
• Large-list scrolling and image loading
• Keyboard and form interaction
• Animation frame stability
• Memory use during long sessions
• Battery and network behavior in background work
• Offline launch and synchronization recovery

React Native’s New Architecture improves native interfacing and rendering capabilities, but the official documentation explicitly notes that enabling it does not automatically improve every application. Measure the bottleneck in the product you are building.

Account for mobile UX, accessibility and platform conventions

A technically functional wrapper can still feel poor, and a React Native application can still ignore platform behavior. Architecture does not replace product work.

• Test small and large devices with real system font settings
• Verify screen-reader labels and focus order
• Handle keyboard appearance and input errors
• Use platform-consistent back, share and permission behavior
• Design empty, loading, offline and denied states
• Test links that leave and return to the application

Plan purchases, push and deep links before choosing

These release features expose architecture differences early and make good release-spike candidates.

Both paths can implement these features. The deciding question is which path makes the complete lifecycle easier to test and maintain for this product.

Maintenance economics usually decide the result

The first build is only one part of the cost. Compare how a normal product change reaches the web, iOS and Android six months later.

React Native can be the correct investment when mobile quality creates enough value. It is not the cheaper default merely because the team already knows React.

Migration path from React web to React Native

If the release spike proves React Native is justified, migrate around product outcomes rather than copying files screen by screen.

1. Extract shared types, schemas, API contracts and business rules.
2. Choose Expo workflow, navigation, storage and environment strategy.
3. Create a development build with the required native libraries.
4. Implement one complete user journey including loading, error and analytics states.
5. Connect authentication, deep links and server authorization.
6. Test purchases, notifications or the hardest native capability.
7. Install through TestFlight and a Google Play testing track.
8. Measure UX and maintenance cost against the Capacitor spike.
9. Migrate the next journey only after the first one is operationally sound.

Keep the existing web product live until the mobile client can complete a useful outcome reliably.

Run a release spike before deciding

A two-sided release spike is more useful than a framework debate. Implement the hardest requirement with the smallest plausible architecture.

• Package the current responsive flow with Capacitor
• Prototype the same critical journey in Expo and React Native only if needed
• Use signed development or testing builds on real devices
• Test auth callback, deep link, permission and one failure state
• Measure interaction quality and performance under realistic data
• Estimate how the next product change ships across all platforms
• List native dependencies and their upgrade ownership
• Choose the path with the best total release economics, not the prettiest demo

For managed implementation, see the mobile app creation service.

Decision checklist

• We know whether the mobile product should match or diverge from web
• We can name the requirement that Capacitor cannot satisfy cleanly
• The hardest native capability has been tested in a signed build
• The existing web interface has been evaluated on a real phone
• React Native libraries support the current architecture and OS targets
• Backend contracts support installed older clients
• Auth, deep links, purchases and push have explicit designs
• The team can own Xcode, Android, native dependencies and store releases
• We compared the next twenty releases, not only version one
• The chosen architecture has a measurable acceptance criterion

Official references

• React documentation
• React Native core components and APIs
• React Native New Architecture
• Capacitor documentation
• Expo development workflow
• Expo development builds
• EAS Build
• Expo distribution

Related release paths

• Convert an existing website to a mobile app
• Custom mobile app development
• Best mobile app builder comparison
• Mobile app launching checklist
• App development cost guide