You’ve already decided the app will be built in React Native, maybe because you read through the tradeoffs yourself or because someone you trust made the call, and now the question in front of you is who builds it. That turns out to be the harder question, and most of the vendor pages that come up for this search are written to get you past it as quickly as possible. They list years in business, project counts, how fast a consultant can start and what an hour costs. Those numbers describe the size of the company, but they say very little about whether the team will get right the handful of React Native decisions that determine what owning this app feels like two years from now.

We read through vendor pages ranking for this search in November 2026, and the ones we looked at closely share the same gaps. None of them mention native module risk, the choice between letting Expo generate the native projects and maintaining them by hand, how the vendor keeps up with React Native’s release schedule, what devices the app gets tested on, or who can maintain the code once the engagement ends. That’s where React Native projects under an outside team tend to go wrong, so those are the topics worth raising before you sign anything.

If you’re still deciding whether React Native is the right framework at all, start with our piece on whether your app actually fits React Native or the Flutter and React Native comparison. This one assumes that decision is behind you.

The phrase gets used for at least four different engagements, and it helps to know which one you’re buying because the right questions differ for each.

An architecture review happens before anything is built. You bring a product plan and the consultant tells you how they’d structure the app, which libraries they’d lean on and where the risky parts are. A code audit happens after something exists, often when a previous team has left and you want to know what you inherited. We’ve written about what a week-one codebase audit actually finds, and most of that applies to a mobile codebase as much as a web one. A build engagement is the one most people mean, where an outside team writes the app. And ongoing maintenance is the long tail after launch, where someone keeps the dependencies current, handles operating system releases and ships fixes.

A team can be good at one of these and weak at another. A shop that excels at fast initial builds may have little interest in the third year of upgrades, so ask directly which of these engagements they do most often and what a typical one looks like from their side.

A React Native app is JavaScript running on top of native iOS and Android code, and most of the features people care about reach into that native layer. Camera access, payments, maps, push notifications, biometrics and background location usually come from third-party libraries that ship their own native code alongside the JavaScript. Each of those libraries has its own maintainers and its own release schedule, and some of them are maintained by a single person in their spare time.

This matters more than it used to, because React Native replaced its original asynchronous bridge between JavaScript and native code with a new architecture built on the JavaScript Interface (JSI), and that new architecture has been enabled by default in every project since version 0.76. Libraries had to be updated to work with it, and a library whose maintainer moved on can become the thing that blocks your next upgrade.

So ask the vendor to walk you through the libraries this particular app will need. For each one, who maintains it, when was it last released, and what would they do if it stopped being maintained? A good answer names the libraries, admits which ones are a risk and says whether they’d fork it, replace it or write the native piece themselves. If all you hear is something vague about “using well-supported packages,” it usually means nobody has looked yet.

Expo is a framework and toolset built around React Native, and any vendor you talk to will have a view on whether to use it. You may have heard the choice described as “managed” versus “bare” workflow, but Expo’s documentation now frames it around Continuous Native Generation, which is the more useful way to think about it.

With Continuous Native Generation, the team doesn’t keep the iOS and Android project folders in the repository at all. Expo generates them from configuration when the app is built, and any native customization lives in config plugins, which are small functions that modify the generated projects during that step. Expo’s own documentation calls upgrading React Native the “number one weakness” of React Native development and positions this approach as the fix, since an upgrade starts to look more like updating a JavaScript dependency. The catch is that anyone who edits the generated native folders by hand risks losing those changes the next time the projects are regenerated.

The alternative is to keep the native projects in the repository and edit them directly, which gives the team full control of the native code and makes every React Native upgrade a manual merge of native project changes.

Either choice can be right, and what you want to hear is that the vendor made it on purpose for this app. Ask which approach they’d use and why, what native customization they expect to need, and how that customization will be recorded so the next developer can find it. If the answer is “we always do it this way,” press a little, because a default applied without thought is how apps end up with native changes that only one person knows about.

React Native ships a new minor version roughly every two months. Version 0.87 was released on August 11, 2026 and 0.88 followed on October 15. The project’s stated policy is that it maintains only the latest three minor series, which means a version stops getting fixes about half a year after it ships.

An app that sits untouched for a year falls out of support without anyone deciding it should, and the upgrade that eventually has to happen spans several versions at once. React Native’s Upgrade Helper will show the changes between any two versions, but jumping several at a time means untangling more breaking changes together, along with whichever third-party libraries also need updating. Expo recommends upgrading its SDK one version at a time for exactly that reason, because it makes it easier to see which change broke what.

Ask the vendor how often they upgrade the apps they maintain, who pays for that time and how they’d handle a project they inherited two or three versions behind. A team that upgrades on a schedule can usually tell you how often and how long it takes, while a vague answer tends to mean upgrades get quoted as a separate project once something breaks.

Simulators and emulators are fast and they catch a lot, but they run on a developer’s computer, and several things behave differently on a phone in someone’s hand. Performance on an older mid-range Android device, camera and Bluetooth behavior, push notification delivery, memory pressure and how the app handles a weak network connection all need physical hardware to test properly. Android in particular runs on a wide spread of manufacturers and OS versions, and a layout that looks fine on a recent Pixel can break on an older phone.

Ask what physical devices the team tests on before a release, which iOS and Android versions the app will support, and whether that list was chosen from your audience or from whatever happens to be on their desks. If they use a cloud device lab, ask which one and how much of the test pass runs there.

The last question is about what you’re left with. The source code should live in a repository your company owns, with the vendor added as collaborators, from the first commit. The build configuration, signing credentials and any Expo account the app builds under should belong to you as well, so that a new team could clone the repository and produce a release without asking the old one for anything.

There’s a second layer underneath the code, which is the App Store and Google Play accounts the app is published under. We wrote a whole piece on who holds the account your app ships under, because moving an app between accounts after launch is a formal process with its own rules, and it’s much easier to set up correctly at the start.

A useful test is to ask the vendor what a handoff looks like when a client leaves them. A team that’s done it before can walk you through what they hand over, from the documentation to the signing credentials and account access, and roughly how long the transition takes.

Before you talk to any vendor, write down which of the four engagements you need and list the native features your app depends on, such as payments, maps or Bluetooth. Then put the questions above to every team on your shortlist and compare the answers side by side, paying closest attention to which teams name specific libraries, devices and versions for your app.

If you’d like a second set of eyes on a proposal or a codebase you’ve inherited, you can book a call with us and we’ll go through it with you.