Native vs. cross-platform app development: how to choose the right technology

If you need both iOS and Android and your app is built from lists, forms, payments, maps or chat, choose cross-platform. If your product depends on platform-only technology such as augmented reality, on-device machine learning, continuous camera work, or complex 3D, or you are shipping to one platform and staying there, choose native. Almost every mobile project we quote falls cleanly into one of those two sentences.

Some projects sit between those two sentences, and that is what the rest of this article is for: what each approach costs at Ronas IT, the six questions we use to settle the choice, the point where we recommend native over React Native, and how a real client made the call on a project we shipped. We build both, so we have no reason to push you toward one.

Native vs. cross-platform at a glance

Native development means one app per platform, written in that platform's own language: Swift for iOS, Kotlin for Android. Cross-platform means one codebase that ships to both stores. The table below compares the two on the criteria that actually move a decision, using our own published starting prices rather than industry averages. Those prices are floors for a defined scope, and a larger feature set moves them.

Read the price row carefully, because it is the one most comparisons get wrong. The saving is not confined to the first build. A native product commits you to two codebases for as long as the app lives, and that recurring cost is usually larger than the difference in the initial quote.

What native app development gives you

A native app is compiled for one operating system and talks to it without anything in between. That buys you three things: first access to new platform features on release day, the deepest possible use of device hardware, and interface behaviour that matches the platform exactly, because you are using the platform's own interface toolkit.

Native iOS: Swift and SwiftUI

We build native iOS apps in Swift with SwiftUI, in Xcode. Native iOS is the right call when your audience is on iPhone and iPad and the product leans on Apple frameworks: ARKit for augmented reality, VisionKit for document and text scanning, CoreML for on-device models, HealthKit for health data. Our published starting point is $25,000 and from 8 weeks.

Native Android: Kotlin and Jetpack Compose

Native Android means Kotlin with Jetpack Compose, in Android Studio. We price it the same way as native iOS, from $25,000 and 8 weeks. The complication is device variety. Where an iOS build targets a short list of Apple devices, an Android build has to behave on phones and tablets from Samsung, Google, Xiaomi and others, across several versions of the operating system. That widens the testing effort more than the coding effort.

The cost of native is structural, not a matter of skill. Two codebases mean two hiring problems, two release calendars, and every feature specified, built and tested twice. Teams underestimate the second part far more often than the first.

What cross-platform app development means in 2026

Cross-platform means one codebase producing an app for both stores. We were building cross-platform apps before React Native was a mature option: our first stack was Ionic and Cordova, which wrapped a web page in a native shell, the exact complaint that still follows cross-platform development today. The important change since then is that the two frameworks that matter now avoid that complaint from different directions: neither wraps a web page in a shell, and neither settles for a rough approximation of native widgets. One framework that used to appear in every comparison is gone.

React Native

React Native uses JavaScript and TypeScript and renders real native components. Meta has maintained it since 2015, and its New Architecture, the default since 2024, replaced the old bridge between JavaScript and native code that caused most of the lag older comparisons complain about. Shopify's 2025 migration of two of its largest apps onto it improved launch time by about 10% on Android and 3% on iOS. React Native is the stack we use, and it sits in the Adopt ring of our internal tech radar. Since 2020 we have shipped more than 20 React Native apps.

That Adopt ring is not a title we award casually: 90 of the radar's 426 entries are React Native, and 22 of those, including a starter kit we built ourselves, are still stuck in Hold. Legend List and Unistyles made it all the way to Adopt; Tamagui and NativeWind did not.

We build on Expo, the toolchain layered on top of React Native rather than a competing framework. Its EAS Build service compiles the iOS and Android binaries in the cloud, so a build does not depend on any one developer's laptop having a matching Xcode and Android Studio setup. Continuous Native Generation (CNG) generates the native ios and android project folders from a config file instead of you hand-editing and committing them, so a version upgrade or a new native module does not turn into a merge conflict with your own patches. Expo Router handles navigation from the file structure. All three sit in the Adopt ring of the same tech radar.

Two practical properties matter to a buyer. EAS Update can push eligible JavaScript changes over the air without waiting for a store review, which shortens the path from a reported bug to a fixed app. And because the code and patterns are close to React on the web, a mobile app and a web app can share logic and components.

Flutter

Flutter is Google's framework. It uses Dart, compiles to native machine code and draws its interface with its own rendering engine, which keeps its visuals consistent across platforms. It is a real option and it is not our stack. If your team already writes Dart, Flutter keeps your stack while React Native adds a new one, and in that case we would point you to an agency that specializes in Flutter.

Xamarin: no longer a choice

Microsoft ended support for every Xamarin SDK, including Xamarin.Forms, on 1 May 2024. The toolchain stopped at Android API 34 and the Xcode 15 SDK, which is below what Google Play and the App Store now require, so a Xamarin app cannot be patched back into compliance. If a comparison you are reading still offers Xamarin as the third option, it was written before that date. The supported migration path is .NET MAUI, and it is a project rather than an upgrade.

Kotlin Multiplatform and Skip: adjacent, not competing

Two more names come up in 2026 comparisons, from different directions. Kotlin Multiplatform shares logic by default: networking, data models and validation run once in Kotlin, while each screen stays a separate native build, SwiftUI on iOS and Jetpack Compose on Android. Through Compose Multiplatform it can share the interface too, since its iOS UI support became stable in 2025. Skip goes further: you write the whole app once in Swift and SwiftUI, and it compiles that into native Jetpack Compose for Android, so both apps are genuinely native with no embedded runtime. We have tested tools in this space, and neither is where we put production work today. Our own cross-platform page says it plainly: we work only with React Native, not Flutter, Ionic, or KMM. We started on something else, and we have tested plenty since; React Native is simply the one that, after years of comparing, still gets a client's app to both stores fastest without asking them to bet on a newer, thinner-tested toolchain.

Six questions that decide the choice

These are the questions we work through with a client, in this order. The first two settle most projects on their own.

Do you need both platforms at launch?

If the answer is yes, cross-platform is the default, because the alternative is paying for two builds of the same product. If you are launching on one platform and expect to stay there, native is reasonable: you get direct platform access and you are not carrying a shared abstraction you never use. Be honest about the word "expect": if Android is genuinely in the plan, one cross-platform build costs less than the second full project that a native start turns it into.

Is a platform-only technology the product, or one screen in it?

A React Native app can reach any platform API through a native module, so having one such feature is not a reason to rule cross-platform out. The test is centrality. A booking app that scans a document once during sign-up is a cross-platform app with one native module. A measuring app whose whole value is live ARKit tracking is a native app. When the platform framework is the product, keep the product in that framework.

How quickly do you need to fix things after release?

If a broken screen costs you money every hour, over-the-air updates matter. React Native can deliver eligible JavaScript fixes to users without a store review. A native app goes through review for every change. Apple review usually takes 1-7 days, and that is time you do not control, while a rejection restarts the clock.

Will you need a web version?

If your roadmap includes a web app or an admin panel, a React Native app can share business logic, state handling and parts of its component library with a React web front end. That is not automatic and it has to be planned from the start, but it turns two products into one codebase with two front ends. Native gives you no reuse here at all.

“Planned from the start” means a monorepo with the shared code in libraries both front ends import, and boundaries that stop mobile-only code leaking into the web build. We do that often enough to have automated it: our Nx generators for React Native and Next.js monorepos are public, and they set up the library structure, the shared state and API layer, and the linting rules that keep the boundaries honest. Worth knowing before you decide, because retrofitting this onto two separately built products is most of the saving gone.

What does year two look like?

This is the question skipped most often. Compare the ongoing cost, not the launch quote: how many developers keep the app current, how many releases you cut per feature, how you handle an operating system update that breaks something. One codebase means one answer to each of those. It is also the reason a cheaper native quote can end up more expensive by the second year.

What does your team already know?

If you have in-house developers who will eventually own the app, their stack should weigh heavily. A React team can maintain a React Native app. A team of Swift and Kotlin engineers should not be handed a JavaScript codebase, and a Dart team should be building in Flutter.

Tell us what your app needs to do, and we will come back with a scope, a price range and our honest recommendation on native or cross-platform.

Get a rough estimate

When we recommend native over React Native

We are a React Native team, so it is worth being specific about where we say no to our own default. There are three situations.

The product is a platform framework. Live augmented reality, continuous camera or video processing, on-device machine learning as a core loop, or complex 3D. Wrapping these in a native module means writing the hard part twice anyway, once per platform, with a bridge in the middle. In that case we recommend native iOS or native Android, and we will tell you so on the first call rather than after you have paid for a build.

You are shipping to one platform and staying there. A field-service app for a company that issues every employee an iPhone does not need a shared codebase, and going native means platform features land on release day instead of waiting on a native module.

Your team writes Dart. Then the answer is Flutter, and it is not us. We would rather tell you that at the first call than take on a project your own developers cannot maintain after we hand it over.

“These three situations usually show up on the first call, before a client has paid for anything. Telling them then that native is the right call sometimes means losing a project we could have built in React Native instead. We would rather lose that project than build the wrong thing and call it a win.”

Evgeny Leonov, CTO at Ronas IT

How the choice played out on a real project

Lainappi is a Finnish rental service that lets people and businesses rent items to each other. The client came to us planning a native iOS app first, with an Android version to follow later. During planning they changed the approach: to keep the budget down and reach users on both platforms at the same time, they chose a cross-platform rental app instead.

We built it in React Native, using react-native-maps and expo-location for the map and location features, and React with Redux for state, which mattered because item filtering had to stay consistent across several screens. The lower budget had a useful side effect: it forced every feature through a test of whether it was core, so the first release shipped quickly with only what users needed.

It also cost us something. Early in development we hit bugs around animations, where the same components behaved differently on iOS and Android, and we fixed them in later updates. That is the cross-platform tax in practice: platform differences surface in small details, and someone has to find and resolve each one. The apps themselves were not slow. We stayed on as Lainappi's partners and kept developing the service afterwards.

What the well-known migrations show

Three migrations get quoted in most discussions of this decision, usually without their dates. Shopify committed to React Native in 2020 and moved its largest app onto it. Discord rebuilt its Android app on the framework in August 2022, having already used it on iOS. Airbnb, the case raised most often against React Native, published its reasons for sunsetting it in June 2018, years before the New Architecture, and it was maintaining a large existing native app rather than building a new one. All three are decisions about hundreds of engineers, so if you are commissioning a 4-to-12-week app, treat them as context rather than a verdict. The dated evidence behind each of them, and the numbers those teams published, is in our list of the best apps built with React Native.

What the analysis phase costs

This decision gets settled properly in a paid analysis phase. Our software development pricing page lists it at $2,000 to $3,000 over 1 to 2 weeks, and it produces user stories, a technical feasibility check and a scope document with a sharper budget and timeline. It is also the cheapest place to find out that your product needs native code. For how the build figures move with scope, see what affects React Native app cost at each stage and how long app development takes.

How to decide, in order

Work through this before you request quotes, and bring the answers with you.

1. Write down which platforms you are launching on, and whether the second one is funded or only intended.
2. List every feature that touches the camera, sensors, augmented reality or on-device models, and mark which of them your product could not exist without.
3. Decide how fast a post-release fix has to reach users, in hours. That answer alone often settles over-the-air updates as a requirement.
4. Check your roadmap for a web app or an admin panel in the next 18 months.
5. Estimate your year-two team: who maintains the app, and which language they are already productive in.
6. Compare two-year totals, not launch quotes, and ask any agency to price ongoing maintenance alongside the build.
7. Book an analysis phase before committing to the full build. Treat a supplier who cannot name a case where they would recommend against their own stack as a warning sign.

If you would like our read on your project, our React Native development covers the work from analysis through store submission, and we take on native iOS when that is the better answer for your project.

Not sure which side your project falls on? Send us the feature list and we will tell you which approach we would recommend, including when that recommendation is native.

Talk to our team