React Native
One app for iPhone and Android is the pitch. Here's what it actually shares.
The short answer
React Native is a free, open-source toolkit for building one mobile app that runs on both iPhone and Android. The app is real: it drives each platform's own controls rather than showing web pages inside a shell. The code is mostly shared. The design work, the store accounts and the release process are not.
Somebody quoted you a single app for both phones and the number looked better than two. That part is usually true. What tends to go unsaid is which half of the work the sharing covers, and which half you pay for twice regardless. The difference is how you read the rest of the quote.
A real app, not your website in a shell
Settle this first, because both get quoted in the same words and they are not the same product.
A web view wrapper puts your existing website inside an empty app and submits that to the stores. It is quick, it is cheap, and people can feel it. The scrolling is slightly wrong, the keyboard behaves oddly, and it is often obvious to a reviewer at Apple before it is obvious to your customers.
React Native is not that. The app gets written once, in the language most web work is already written in, and React Native drives the platform's own controls with it. The list that scrolls is the real list. The switch is the real switch. Somebody using it cannot tell what it was built with, which is the entire point.
It is free and open source under the MIT licence, started and maintained by Meta with a large outside community. No seat to buy, and no vendor who can change the terms underneath you. The cost lands in the building and the keeping.
Your app's code
Shared
The screens, the rules, the wording. Written once in JavaScript or TypeScript, and this is the part that genuinely runs on both phones.
React Native
The toolkit
Translates that code into the controls each platform already has, so a list, a switch and a keyboard behave the way that phone's owner expects them to.
The platform's own controls
Native
Real iOS and Android components doing the drawing. This is why the result does not feel like a website in a frame.
Native modules
Written twice
Small pieces of Swift or Kotlin for anything the toolkit does not already reach. Written per platform, and each one needs somebody who can read it.
One codebase, and how much of it is really one
The saving is real and it is not half. What shares is the code: the screens, the logic, the wording, most of what you would point at if somebody asked to see the app.
Design does not fully share, because the two platforms disagree. Back on Android is a system gesture. On iPhone it is something you draw. Permission prompts, notifications, share sheets and payment flows each have their own conventions, and an app that ignores them reads as foreign on one of the two.
Testing does not share either, across two operating systems, several years of versions still in daily use, and a spread of Android screen sizes that iPhone does not have. Nor does release: two accounts, two review processes, two sets of rules.
So the honest number sits well below two apps and comfortably above one. Ask a quote which of those parts it has counted.
React Native, one codebase
Two native codebases
- Building a screen
React Native, one codebase: Written once and it appears on both. Where the platforms differ, somebody writes the difference in by hand.
Two native codebases: Written twice, and each one fits its own platform without an argument.
- Who has to be available
React Native, one codebase: One team, in the language most web developers already use. Anything deep still needs somebody who writes Swift or Kotlin.
Two native codebases: Two specialists, or two firms. Neither can cover for the other when one goes quiet.
- A brand-new phone feature
React Native, one codebase: Wait for the community to reach it, or pay for a native module now.
Two native codebases: Available the day the platform ships it, which matters on roughly one build in twenty.
- Keeping it alive
React Native, one codebase: One codebase to upgrade, and it moves quickly. Both stores still force their own changes on you.
Two native codebases: Two codebases on two timetables, each set by a platform that did not ask you.
The stores decide when your fix goes out
This catches out anyone who has only shipped websites. A website change is live when you say so. An app change is live when Apple and Google agree, which is usually quick, occasionally is not, and is never on your schedule.
React Native softens that in one specific way. Your app's own code is interpreted rather than baked in, so a change to it can go straight to phones without a fresh store submission, inside the limits the stores set. It can correct and adjust, not turn the app into something else. Anything touching the native side still goes through review, and this needs arranging in advance.
The other half is that old versions stay on people's phones for as long as they like. A website you replace is gone the moment you replace it. An app you shipped in the spring is still out there in the autumn, still talking to your systems, unless something in it tells people to update. That belongs in the first release rather than the third.
The accounts outlast whoever built it
An app lives inside two accounts, and by default they are not yours. Apple's developer program and Google Play hold the listing, the ratings, the reviews and the right to publish an update. Whoever owns those accounts owns the ability to change your app.
Agencies often set them up, because it is faster and they have done it before. It is also how a business ends up asking permission to update its own product. Transferring later is a process rather than a favour, so it is worth the twenty minutes now.
The same goes for the signing key that proves an update came from the same source as the original. Google will hold one for you and Apple's runs through the account, which is why ownership settles most of it. Ask where both live before the first submission, not after somebody leaves.
Where it stops
Anything drawing its own world every frame belongs elsewhere. Games, heavy 3D, live video effects. Tools for that exist and they are not this one.
So does anything whose value is a platform feature released last month. React Native reaches new hardware and new operating-system features after the platform does, sometimes months after. If your product is the first thing to use a new sensor, you are either waiting or writing native code anyway.
Then the question underneath all of it, which is whether this needs to be an app. An app earns its place when it needs the camera, has to work with no signal, sends notifications people act on, or gets opened several times a week. If none of those are true, a site that works properly on a phone reaches more people, costs less to keep, and does not need anyone's approval to change.
Worth knowing before you start
Ask which parts of the quote are shared and which happen per platform. Design, testing and release are usually the three that are not, and they are why a one-app quote comes back bigger than it looked.
Ask whether you are being quoted React Native or a website inside an app shell. They get described in similar words at a similar price and they are different products. If the answer takes a while, it is the second one.
Put the Apple and Google accounts in your own company's name before the first submission, then add whoever is building it. Doing it afterwards is a transfer process, not a setting.
Ask how a small fix reaches a customer's phone without waiting on a store review. React Native can do it, it has to be arranged in advance, and it is worth proving once while nothing is on fire.
Ask what happens to somebody still running the version you shipped a year ago. App versions do not disappear the way an old website does, and something has to tell those people to move.
Common questions
Real. The app is written once and React Native drives each platform's own controls with it, so the scrolling and the keyboard are the phone's rather than an imitation of them. What to check is that you are being quoted React Native and not a web view wrapper, which does put a website inside an app shell and often costs about the same.
The thinking, not the screens. React Native shares React's language and its ideas, so your developers are not starting cold and the business rules can often be reused. The interface gets rebuilt, because a phone is not a small desktop. If a mobile quote is cheap on the grounds that the web app is already React, ask which files actually move.
They answer the same question differently. Flutter draws every control itself, with its own engine and its own language, so both platforms end up looking identical and slightly apart from each one's native behaviour. React Native uses the controls each platform already has, in the language most web teams already write. If you have web developers, that second point usually decides it.
Yes, and it is often the right call. You still build in React Native, ship to whichever store your customers are actually on, and add the second when it earns its keep. What you defer is the second review process, the second round of testing and the second set of conventions, not the code. Which one goes first is a question about your customers.
Every few months rather than every few years. React Native releases often, and both stores require an app to be rebuilt against recent tools before they will accept an update at all. An app nobody has touched for two years usually needs a week of unglamorous work before a one-line change can ship.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.