To hire a React Native developer: shortlist people with apps live on both the App Store and Google Play, check they have shipped native module work rather than only JavaScript, ask how they handle version upgrades, and make sure the store developer accounts are in your name before anyone writes code. The generic hiring advice applies too, but those four are where React Native projects specifically go wrong.
Why "cross-platform" is the thing to probe
React Native is chosen because one codebase ships to two platforms. That is real, and it is also where the misunderstandings live.
The parts that are genuinely shared: most screens, most logic, most of the app. The parts that are not: anything touching the device deeply, anything platform-specific in the design, and the entire process of getting each app through each store. A developer who has only ever shipped the JavaScript half is not the same hire as one who has taken an app through Apple review twice.
So the single most useful filter is not a CV. It is store listings.
Ask for the store links, then open them
Ask for both: the App Store listing and the Google Play listing, for apps they built.
Then spend five minutes actually using one:
- Does it feel like a native app, or like a website in a frame? Scroll behaviour and transitions give this away immediately.
- What happens with no connection? Airplane mode, then open it.
- Is it on both stores, or did they only ever ship one? A single-platform history in a two-platform framework is worth asking about.
- Check the update history on the listing. An app updated over a couple of years has been maintained, which is a different skill from launching.
If someone can only show you a repository or a video, that is not the same claim. Plenty of React Native work never reaches a store, and the last ten percent before it does is where the difficulty concentrates.
Four questions that separate people
"Have you written or debugged a native module?" At some point almost every real app needs something React Native does not cover: a specific SDK, a permission, a camera behaviour. The answer you want is a specific story, ideally an annoying one. "Not yet" is honest and fine for a simple app, but you should know it going in.
"How do you handle React Native version upgrades?" Upgrading a React Native app is well known for being painful, and how someone talks about it tells you whether they have maintained an app or only started them. Look for a process, and for an opinion about how far behind is acceptable.
"Expo or bare, and why for my project?" There is no correct answer, and that is the point. What you want is a reasoned trade-off rather than a reflex. Someone who says "always Expo" or "never Expo" without asking what your app does has not engaged with your project.
"What breaks first when this app has ten thousand users?" Anyone who has run something in production has an answer. Anyone who has only built demos does not.
Get the accounts right before anyone starts
This is the most common expensive mistake in mobile work, and it is entirely preventable.
The Apple Developer account and the Google Play developer account must be yours, in your company's name, paid on your card. Invite the developer to them. Do not let an app be published under someone else's account "for convenience while we get started".
Both stores do let you move an app to another developer account later, and the ratings and reviews go with it (Apple, Google, checked in October 2026). The catch is who has to start it. On Apple's side only the Account Holder of the account the app is in now can begin a transfer, and on Google's the request also comes from the current account. If that account belongs to a freelancer who has stopped replying, nobody can move the app you paid for.
The signing keys follow the same logic. With Play App Signing, a lost Android upload key can be reset from the Play Console, so nobody is locked out of the app for good. But only someone with access to that Play Console can ask, which is one more reason it should be yours.
Budget for the parts that are not code
Mobile projects carry costs that web projects do not, and they surprise people:
- Two store developer accounts, one of them an annual fee.
- Review time. Apple review is usually fast now, but a rejection and a resubmission can cost you a week, and it always seems to happen the week you needed to launch.
- Store assets: icons, screenshots for several device sizes, a privacy declaration.
- Two platforms means two sets of bugs. Some things only break on one.
The project cost estimator has "mobile, iOS and Android" as a base and shows the setup and launch line separately, which is the part most quotes leave out.
Where the actual hiring happens
Everything in how to hire a freelance developer without Upwork or Fiverr applies: shortlist from work you can open, write a brief that can be declined, structure the first engagement small enough to fail cheaply, and check that the person is who they say they are.
React Native just makes the first step easier than usual, because the work is sitting in two public stores with dates, review counts and update histories attached. That is more verifiable evidence than most fields ever get. Use it.
Shipfolks lists independent builders with their shipped apps and live store links, so you can open the work before you talk to anyone. Browse the builders open to work and start from something you have actually used.