React Native or native: what to choose for your app

Choosing between React Native and native is often habit or someone else’s holy war — not the product’s actual job. Below are criteria that separate a typical service client from a scenario that needs a native stack. The piece draws on WAPP’s mobile development practice: the studio ships both React Native and SwiftUI. Project floor — from RUB 1.5M.

Two real examples: when the stack matched the job

The “React Native vs native” debate easily becomes faith: some remember Airbnb leaving React Native; others cite Discord or Shopify. Other people’s experience without context is useless. It is more useful to look at the concrete task and at what is already in the portfolio.

A native job — a payment SDK. The YandexPayProxySDK refactor for Beeline is a payment SDK for iOS in a high-load app on SwiftUI: adaptation and refactoring for the operator’s and acquirer’s requirements. You need direct control over the native payment-screen UI and the binary SDK — a cross-platform wrapper does not close that loop.

React Native — an online-lesson client. Glinka Digital is a music online-lesson app on React Native: Matrix chat, custom WebRTC for calls, Laravel backend. Where standard React Native modules were not enough — for example switching to the ultra-wide camera for hand placement — parts of the SDK were extended with native modules. One shared codebase for iPhone and iPad, point native where the lesson scenario requires it.

The shared mistake when choosing

The mistake is not that “React Native is bad” or “native is always more expensive.” The mistake is picking a stack before a scenario map: without answering where you have typical UI and server logic, and where you have hardware, a media stream, or a payment SDK. The rest of this article is criteria and a matrix so you lock the approach before development starts — not after the first failed release.

Cross-platform and native development: the practical difference

Before you choose how to build mobile apps, it helps to understand how the two main options differ in practice — not on marketing slides, but at the level of code, team, and day-to-day work.

Native development: two apps, two worlds

Native development means separate code for each platform in its “home” language. For iOS that is Swift (or SwiftUI as the UI framework); for Android — Kotlin. Two repositories, two developer teams, two parallel testing and release processes.

The main trait: native apps get full access to every device API and feature as soon as new OS versions ship. Camera, Bluetooth, ARKit, HealthKit, payment services — all without layers and hacks. Performance is maximal because code compiles directly for the platform.

But you pay for that — and not only in budget. Every new feature must be implemented twice, tested twice, supported twice. Any bug fix is a change in two codebases. Finding and retaining developers for two separate stacks is harder too.

Cross-platform development: one codebase, two platforms

Cross-platform development lets you build apps for iOS and Android from a single codebase. Popular cross-platform frameworks in 2026 are React Native, Flutter (from Google, Dart language), and Kotlin Multiplatform. Xamarin has effectively left the stage for .NET MAUI, which is also used less often.

The idea is simple: the team writes code once, and the framework adapts the result to different platforms. In practice you can share source for business logic, UI elements, and data work across devices. Building cross-platform apps reduces workload, but saying “half the cost” is an exaggeration. Some code still has to be native: biometrics, complex screen animations, payment SDK integration. How that affects development cost is covered later in this article.

What changed by 2026: old comparisons no longer work

If someone cites 2019–2021 articles claiming React Native “lags” — that data is outdated. The main technical shift: React Native moved to a new architecture with JSI (JavaScript Interface) instead of the old bridge. Previously every call between JavaScript and native code went through an asynchronous bridge with data serialization, creating a bottleneck. Now JSI lets JavaScript call native functions directly — fast, synchronously, without extra processing.

Flutter did not stand still either: the Impeller renderer fixed the long-standing first-frame jank problem, and web and desktop support left experimental status.

Result: building mobile apps with cross-platform tools in 2026 is no longer a compromise for savings alone. For a large set of tasks, the cross-platform approach delivers quality comparable to native. But the zones where native is irreplaceable have not disappeared — and we cover them next.

The double-savings myth: what a shared codebase really costs

One code — two apps — half the price. That formula is repeated so often it became an axiom. In practice, cross-platform mobile development saves meaningfully — just not by half. If you budget for twofold savings, the project risks running out of money near the finish line.

Where savings are real

A shared codebase does reduce work. Business logic, catalogue screens, auth forms, personal accounts, order lists — the team writes once in JavaScript or Dart, and the code runs on both iOS and Android. For apps with typical UI — most delivery services, marketplaces, corporate portals — the reusable share can be large. Instead of two separate developer teams (Swift/Kotlin), one team on React Native or Flutter is enough. That lets you ship a first product version on both platforms quickly and shorten time to market.

Where the “saved” money goes

The problem is that building an app is more than UI components and framework logic. Here is what stays outside the shared codebase:

• Native modules. Biometrics, Bluetooth, push notifications, camera work — all need separate solutions per OS. Some libraries are ready, but under a concrete task you often write wrappers by hand.
• Testing on two OSes. One code file does not guarantee identical behaviour on different devices. The app must be checked across dozens of iOS and Android version combinations, screen resolutions, and chipsets. That is a separate budget line, and it is no smaller than in native development.
• UX pattern adaptation. iOS users expect gestures and navigation elements different from what Android users are used to. The Back button, swipe behaviour, modal styles — all must be adapted per platform. A “one size fits all” UI looks foreign and hurts conversion.
• App Store and Google Play review. Stores have different requirements, review timelines, and update policies. Preparing builds, screenshots, and descriptions is double work regardless of development approach.
• Platform API and service integration. HealthKit, Google Fit, NFC, ARKit — these capabilities are tied to a specific system and need native code even if the rest of the project is React Native.

Count the support horizon

The main trap is estimating development cost only up to launch. After release, apps live for years: new OS versions, API changes, dependency updates. With a shared codebase, changes are easier and faster because a fix in one place lands on both platforms. Supporting two native apps costs more: two teams, two toolchains, two bug streams.

It is over distance — one, two, three years — that the cross-platform approach delivers the greatest advantage. But the concrete savings percentage depends on the project: integration complexity, number of native modules, update intensity. There is no universal number. More on what makes up the budget — in our breakdown of mobile app development cost.

For projects from RUB 1.5M, the cross-platform vs native choice is not “save or not.” It is about where resources go: duplicating code, or polishing the features that make the product useful to customers.

When React Native covers the job

Most mobile apps on the market do the same thing: pull data from a server, show it as lists, cards, and forms, send it back. No heavy on-device computation, no real-time video processing. Load sits on the API and backend; the client handles display and navigation. For those scenarios React Native fits well.

Scenarios where cross-platform development covers the job

MVP to test a hypothesis. When you need to reach the market quickly and see whether users will pay, writing two native apps is wasteful. One codebase lets you launch iOS and Android versions together, shorten timelines, and keep budget for marketing. If the hypothesis fails, losses are smaller. If it works — you can scale on the same base.

Personal accounts and internal company services. UI elements here are standard: input forms, order lists, contacts, transaction history. These apps live on backend data, and a cross-platform framework handles that without compromise.

Product catalogues and marketplaces. Cards, filters, cart, checkout screen. Payment processing logic sits on the server; the client keeps only UI. Discord and Shopify, for example, have used React Native in production for years on similar work.

Delivery and logistics services. Map, order status, courier chat. Performance depends on API quality and map SDK integration, not on device compute power.

Content platforms and blog apps. Article feeds, subscription management, push notifications. Building such apps on cross-platform frameworks is simpler and faster than separate clients per OS.

A real example

Glinka Digital is a music online-lesson client on React Native: one codebase for iPhone and iPad, Matrix chat, custom WebRTC for video. Where standard modules were not enough (ultra-wide camera, instrument audio without aggressive noise suppression), part of the logic moved into native modules. That is not a pure UI catalogue — and not a reason to write two fully native clients: a shared React Native layer, point native for the lesson scenario.

Which projects this is enough for

If the product’s main job is to show data and let users work with it conveniently, React Native usually closes the loop without quality loss. Scenarios that need native are covered next.

When you cannot do without native

Those projects share one trait: the app must work close to the hardware or squeeze the maximum from the device. Here is a concrete list of scenarios where native development remains the only reasonable option.

Deep hardware work

Camera with a custom processing pipeline, Bluetooth Low Energy for medical devices, NFC for access systems, advanced sensors — all APIs implemented differently per platform. React Native can reach them through bridges, but when you need fine control — frame-by-frame camera focus, parsing non-standard BLE characteristics — the bridge becomes a bottleneck. Code has to be written in Swift or Kotlin separately for iOS and Android, and the cross-platform wrapper becomes an illusion of a shared codebase.

Real-time media processing

Video editors, apps with AR scenes, audio processing with minimal latency. Performance is critical: every extra layer between code and GPU adds milliseconds, and users see dropped frames or audio desync. Neither Flutter nor React Native gives direct access to Metal on iOS or Vulkan on Android without native modules. If media is the product core, it is simpler to develop in each platform’s native language from the start.

Payment SDKs and fintech

Banks and payment systems ship SDKs with hard requirements: a specific Xcode version, certificate signing, no binary modification. Wrapping such an SDK in a JavaScript bridge creates a fragile construct that breaks after every update. From the portfolio: refactoring and adapting YandexPayProxySDK for Beeline — a payment SDK for iOS in a high-load app on SwiftUI. You need direct control over the native payment UI and the SDK itself; a cross-platform framework does not close that job.

Games, 3D, and complex animations

60 fps rendering of 3D scenes, physics, shaders — that is native-engine territory. Mobile games use Unity or Unreal; interactive 3D UI elements use SceneKit, RealityKit, OpenGL ES. Cross-platform frameworks are simply not competitors here: they were designed for business-app UI, not real-time rendering.

Apps with elevated security requirements

Banking, client data storage, biometrics at the OS level. When confidentiality policy and regulatory requirements dictate using Keychain, Secure Enclave, and Android Keystore directly, without intermediate layers, the native approach closes those tasks faster and more reliably. Some companies undergo security audits, and auditors want to see direct system API calls, not wrappers.

An honest position

Choosing native does not mean “always more expensive.” It means the concrete task needs a concrete tool. Do not confuse real necessity with over-insurance: many “native only” requests are closed by React Native when the product is a typical service client. Native development is justified when a technical trait of the product lands in the list above. In all other cases, count resources and timelines.

Native modules inside a cross-platform project: hybrid reality

In practice, cross-platform development is almost never “pure.” Any mid-complexity project eventually hits a point where JavaScript on React Native cannot reach a needed OS function directly. Then you write native modules — pieces of Swift, Kotlin, or Objective-C that bridge the cross-platform layer and device hardware.

That is not a framework bug. That is reality.

Where cross-platform ends and native begins

For a typical app with catalogue, cart, and personal account, most of the code is usually shared across both platforms. Screens, forms, navigation, business logic — React Native covers that without trouble. Here is what regularly needs separate native modules for iOS and Android:

• Biometrics (Face ID, fingerprint) with custom scenario handling
• Bluetooth Low Energy for external devices
• Complex UI animations tied to gestures
• Push notifications with non-standard logic (for example, Rich Notifications with interactive elements)
• Camera and AR features tied to a platform’s APIs
• Payment SDKs shipped only in native form

Ready libraries cover part of these tasks. But when you need a concrete integration for a concrete service — for example, a payment SDK for a telecom operator — you drop to native code and write the module by hand.

What this means for the team

The main trap: companies hire a React Native team and assume that is enough. Then it turns out a Bluetooth module needs someone who understands CoreBluetooth on iOS and BluetoothGattServer on Android. Two different APIs, two approaches to connection management, two code versions.

Hence the rule: in any cross-platform project beyond “screens + forms,” you need at least one developer with native experience. Not necessarily a full-time hire — sometimes point engagement is enough. But if that person is missing entirely, the project risks stalling on the first non-trivial feature.

That is why WAPP keeps both React Native and SwiftUI in stack: mobile app development in practice is a hybrid approach, not choosing one tool forever. The cross-platform framework takes the bulk of the work; native development point-closes what the framework cannot carry.

That is normal — and here is why

Some treat the need for native modules as a failure of the cross-platform approach. They think: “If we still write native code, why choose React Native at all?” In practice this is a normal hybrid: the shared layer covers screens and business logic on both platforms, and native modules point-extend hardware and SDKs. Shared-logic updates land once; native modules are tested in isolation — without fully duplicating two clients.

It sounds simple, but in practice you should bake hybridity into the architecture from day one. If the project is designed so native modules plug in as isolated blocks, new features can be added quickly without refactoring the whole app. If not — every native module becomes a crutch, and product quality drops.

Support cost: expenses people forget at the start

Architecture quality at kickoff is checked not at launch, but six months later. That is when the first OS updates arrive, third-party libraries break, and users start asking for new features. And that is when the cross-platform vs native choice affects budget more than at build time.

What goes into mobile app support cost

Every year Apple and Google ship new iOS and Android versions. That is not a formality. Changes hit APIs, privacy policy, UI element requirements, background services. An app that worked fine in June may start crashing on fresh devices by October. You need to adapt code, test, and push store updates.

If the project is native on Swift and Kotlin, the team does that work twice: once per platform. Two developers, two QA cycles, two releases. Support resources double — and this is annual, not one-off. With a shared React Native or Flutter codebase, adaptation is easier: most changes land once in the shared code. But there is a catch.

Dependency on the framework ecosystem

Cross-platform frameworks themselves change quickly. React Native moved to the New Architecture; Flutter updates Dart and the rendering engine. Those changes sometimes break compatibility with third-party libraries the app relies on. Result: the developer updates not only their source, but also digs into why popular packages stopped working after a framework migration.

Native development is not immune either, but dependency on foreign code is usually lower. SwiftUI or Jetpack Compose is supported by the platform vendor, and backward compatibility is a priority. In a cross-platform project an extra abstraction layer sits between the app and the OS, and any failure in that layer lands on the support team.

What this looks like in practice

In WAPP’s practice one scenario shows up most often: the client launched a mobile app, spent the budget to the last coin, and did not reserve support resources. A new iOS version ships — the app stops rendering screen elements correctly or loses camera access. The fix costs money that was never planned.

Second scenario: the project uses five or six third-party JavaScript libraries, one of which the author stopped maintaining. You either write a replacement or fork the repo and maintain it yourself. Both options are expensive.

Third: the team wants to add features, but the architecture is not ready to grow. Every feature needs refactoring, timelines slip, and annual support cost can match the cost of building the app. That is the main early mistake: counting only the launch budget and forgetting the app lives for years. Stack choice determines not only first-release speed, but the full cost cycle over the product’s life. More on budgeting across development stages — in the WAPP blog.

Choice matrix: project type → recommended approach

Let’s collapse everything above into one practical tool. Below is a matrix that links project type to a mobile development approach. It does not replace a full audit, but it helps you orient on stack choice before the first meeting with a development team.

How to read the matrix

Rows are typical business scenarios clients bring. Columns are the recommended approach and the main reason for it. Cross-platform is marked “CP,” native “Native,” hybrid (shared codebase + native modules for selected features) “Hybrid.”

Why the matrix is a guide, not a verdict

The main mistake is treating such tables as a finished answer. They are not. Cross-platform e-commerce apps may still need native modules if the project has complex animations or AR try-on. And a native banking app sometimes makes sense to start as a cross-platform MVP to test demand, then rewrite later.

Stack choice depends on the concrete situation: team resources, business timelines, features planned in six months. The matrix gives direction. The final call belongs to those who know the project context from inside. If you need help assessing, more on mobile development services and the working process — on the WAPP site.

Frequently asked questions about cross-platform development

Below are the questions people ask most often before a project starts. Each without fluff.

Is it true that cross-platform apps are slow?

This myth dates to the early 2010s, when frameworks like Xamarin and early React Native really lost to native apps on speed. In 2026 the picture is different. React Native with the New Architecture and JSI (JavaScript Interface) removed the old “bridge” between JavaScript and native code. Platform API calls go directly, without serializing data to JSON. Result: UI animations run at 60 fps; cold start is comparable to native. For most business apps — catalogues, delivery services, personal accounts — users will not notice a performance difference. Slowdowns appear where cross-platform is used for the wrong job: real-time video processing, heavy 3D graphics, complex on-device computation without server support.

Can you move from React Native to native if you hit limits?

Yes — and it is not a catastrophe if the architecture is sound. React Native supports a modular approach: business logic lives in separate layers, screens are independent components. When one part of the app outgrows the framework, you rewrite it in Swift or Kotlin without demolishing the whole codebase. The same hybrid pattern appears in Glinka Digital: a shared React Native client, native modules where camera and audio need control. Main recommendation: design for modularity from the start so changes do not force a full rewrite.

Flutter or React Native — what to choose in 2026?

Both frameworks are production-ready; both let you build iOS and Android apps from one codebase. Differences are in the details. Flutter uses Dart and draws UI with its own engine, which gives more design control but can complicate integration with native platform libraries. React Native sits on each OS’s native elements, and the JavaScript developer ecosystem is wider. At WAPP we bet on React Native: the JS talent market is larger, project support costs less, and new native APIs from Apple and Google connect quickly. But if the team has strong Dart experience or you need a non-standard UI with custom drawing — Flutter is a solid fit.

How much does cross-platform app development cost?

Development cost depends on product complexity, screen count, external integrations, and design requirements. The entry floor for mid-level mobile apps is from RUB 1.5M. A simple MVP with auth, catalogue, and cart costs less than a service with loyalty, a Telegram bot, management systems, and analytics. The cross-platform approach saves development budget versus two separate native apps — but not by half: some work stays unique per platform: testing, adaptation, store publishing. A detailed pricing breakdown is in the article on mobile app development cost.

Do you need separate iOS and Android developers with a cross-platform approach?

A full staff of two different teams is not required. Most code is written by one React Native team in JavaScript. But native expertise is hard to avoid: when the app needs Bluetooth, biometrics, OS-specific APIs, or complex animations — someone on the team must write native modules in Swift and Kotlin. In practice one or two specialists with native experience per project is enough, not separate teams per platform. That cuts resources and timelines while keeping quality across devices.

Conclusions

Choosing between React Native and native development is not “which is better.” It is “what fits the concrete task, budget, and planning horizon.” There is no universal answer, and anyone who claims otherwise is usually selling a single approach.

Here are three takeaways from this article.

Savings from cross-platform development are real, but not twofold. A shared codebase reduces work and speeds launch on iOS and Android together. But testing on different devices, adapting UI to each platform, native modules for Bluetooth or biometrics — all of that eats part of the savings. The outcome depends on product type: for a catalogue or personal account the difference is tangible; for an app with real-time video processing the savings may be an illusion.

Most business apps are fine on React Native. Catalogues, delivery services, marketplaces, corporate programs — all work cross-platform without noticeable compromise for users. But native modules are part of reality, not an exception. In almost every mid-complexity project the team must write Swift or Kotlin for selected features. That is normal, and you should be ready for it from day one.

Count cost over a two-to-three-year horizon. A cheap launch can turn into expensive support; an expensive native start can mean stable, predictable operations. OS updates, new framework versions, API changes — all affect post-release budget. The main mistake is choosing a stack looking only at the first invoice.

If you are unsure which approach fits a concrete project, the WAPP team can unpack the task and help choose a stack — without locking to one tool. Leave a request for a consultation and get a recommendation based on eight years of mobile work on React Native and SwiftUI.