Someone has told you to build your app in React Native. Maybe it was the developer you’re about to hire, maybe it was a lead on your own team, or maybe you read enough articles that it started to feel like the default answer. Before you sign off, you want to know whether it’s the right tool for the app you’re actually building, and that’s a different question from whether it’s the cheapest way onto both app stores.

Most of what turns up on this search doesn’t help much with that. The explainer pages, like Netguru’s glossary entry on React Native, walk through how the framework works under the hood, show a wall of famous apps that use it, and leave the drawbacks for a short paragraph near the end. The agency guides lead with a cost table and close with a pitch. Both kinds tend to quote confident percentages for savings and code reuse without saying where those numbers came from, and neither gives you a way to look at your own app and decide. That’s what we’ll try to do here.

React Native is a framework that lets developers write one app, in JavaScript or TypeScript, and ship it to both iPhones and Android phones. The app uses each platform’s real interface components, so it looks and behaves like a normal app on either phone, and most of the code that decides what the app does is shared between the two. It comes from the same family as React, a widely used way of building websites, which matters more to your project than it might first appear, and we’ll come back to it below.

That’s about as deep as you need to go on the internals. If you’re weighing it against Flutter specifically, our post on Flutter v React Native covers what separates the two.

The quickest way to sort your app is to set the budget aside for a moment and describe what the app does all day. Write down the five or six things a user will do most often, and then look at what each of those asks of the phone.

For a large share of business apps, the answer is very little beyond a screen and a network connection. If your list is mostly made of things like these, React Native fits comfortably:

• Filling in forms, submitting requests, and checking where they stand
• Browsing content, a catalog, or a feed
• Buying products, booking appointments, or managing what they’ve paid for
• Logging in to see an account, a dashboard, or a history of records
• Messaging, approvals, and other back-and-forth between your users and your team

Apps like these spend most of their time showing data that lives on a server and sending changes back to it. The effort goes into the server they talk to and into getting the workflows right, and the framework on the phone is rarely what holds them back.

The other side of the list is shorter, but it matters more, because when your app lands there the cost comparison stops being the deciding factor. Fully native development pulls ahead when an app leans heavily on device hardware or on features that belong to one platform, and in practice that tends to look like this:

• An app whose main job happens through the camera, such as scanning, measuring, or working with live video
• Augmented or virtual reality, where the experience depends on the platform’s own frameworks
• Heavy work that has to keep running in the background, such as continuous location tracking or long processing jobs
• A capability that Apple or Google only exposes through its own native tools, especially a recently released one

React Native can call into native code when it needs to, so a single camera screen or one background task doesn’t rule it out. The question is whether that kind of work sits in a corner of your app or at the center of it. If it’s at the center, you’ll spend much of the project writing native code anyway, and you’ll be maintaining the connection between the two halves on top of that. At that point building natively from the start is usually the cleaner choice, whatever the quotes say.

Watch for an app that’s mostly from the first list with one item from the second, because that’s a common shape. Ask how the vendor plans to handle that one piece before you decide, since the answer tells you whether it’s a contained bit of native work inside a React Native app or a sign that the whole app belongs on native.

A lot of the research on this topic is framed as React Native against Flutter, and our own comparison post is one of those. That comparison is useful once you know you want a cross-platform app, but it assumes the earlier question has already been answered. Choosing React Native over Flutter tells you which cross-platform framework you prefer, but it doesn’t tell you whether a cross-platform framework was the right call for your app to begin with.

So if you’ve already ruled out Flutter, run the sorting exercise above anyway. An app built around the camera or around a platform-only feature has the same problem in either framework, and settling the framework debate first makes it easy to skip the step that would have caught it.

We build our own mobile work in React Native and start there unless something about the app gives us a reason not to. Most of the reason comes from outside the app itself. If you’re also paying for a web surface, whether that’s an admin panel for your team or a web application for your customers, the app and the website can share a foundation, so the rules that decide how your product behaves get written once instead of twice.

We make that case in more detail in the section of our Flutter v React Native post called “How this fits the rest of what you’re building”, and it carries over here with one practical note. If your product has no web side at all and none planned, that advantage shrinks, and the decision rests more heavily on the sorting exercise. If it does have one, give the shared foundation real weight, because it affects every feature you ship after launch.

If a vendor recommends React Native, that’s a reasonable default, and it’s the one we’d reach for too. A few questions will still tell you whether the recommendation was made for your app or out of habit.

1. What in my app specifically makes React Native the right fit? A good answer names your workflows, while a weak one talks in general terms about covering two platforms with one team.
2. Which parts of the app will need native code, and who on your team writes it? Most apps have at least a little, and you want to hear that they’ve already found yours.
3. Who maintains the app once your original engineers move on? Apple and Google change their operating systems on their own schedule, so the app keeps needing work after launch, and the answer should describe someone you could realistically hire.
4. What would make you change your recommendation? If they can describe the app that wouldn’t fit React Native, you can check whether yours looks like it.
5. What happens if we learn partway through that a feature has to be native? Listen for a plan to build that piece natively inside the app, along with an honest account of what it adds to the work.

None of these are trick questions, and a vendor who knows the framework well will be glad you asked and should be able to answer each one without going away to check.

If the sorting exercise says your app fits and you’re now gathering quotes, our post on mobile app development cost explains why published ranges disagree so widely and what makes two quotes comparable. If you already have a vendor recommending a stack and would like an independent read on it, a second opinion on technical decisions like this one is part of what our fractional CTO engagements cover.

Either way, the most useful next step is a short conversation about what your app does. Book an intro call and bring that list of the things your users will do most often.