Hire React Native Developers: Rates, Vetting, and Red Flags

The React part is about 40 percent of the job

A React Native developer is not a React developer who happens to target phones. The JavaScript looks familiar, and then the job turns into Gradle, CocoaPods, Xcode signing certificates, provisioning profiles, Hermes bytecode, Metro resolver config, and a Play Console listing that keeps rejecting your privacy declaration. The React part is maybe 40 percent of the work. The other 60 percent is the native seam.

The pattern we see on rescue projects goes like this. Six weeks in, the contractor demos on Expo Go. It is smooth, the animations are clean, everyone is happy. Then someone asks for a TestFlight link. Suddenly the camera library needs a config plugin, the app crashes on launch in a release build because Proguard stripped a class that only reflection touched, and the push notifications never arrive because nobody uploaded an APNs key. The demo was never the app. It was a preview running inside somebody else's binary, with somebody else's native modules already compiled in.

The second failure mode is version drift. A team builds on React Native 0.71, ships, then goes quiet for a year. Now you are three minor versions behind, react-native-reanimated needs a major bump, your two custom native modules were written against the old bridge and nobody has touched the codegen path for TurboModules, and the upgrade that "should take a week" eats two months. Good React Native developers treat upgrades as routine maintenance with the React Native Upgrade Helper diff open. Weak ones treat every upgrade as a rewrite.

The third is performance. Someone renders 800 rows in a FlatList, keeps every row subscribed to a global store, animates without the native driver, and the JS thread sits at 12 frames per second on the mid range Android device your actual users own. The person who wrote it tested on an iPhone 15 Pro.

Four ways to buy React Native work

In house hire. Fits when the app is your product, not a channel. You need someone who owns the release train, the crash rate, the store listings, the Sentry backlog, and the yearly iOS and Android SDK deprecations. The catch: React Native people who have actually shipped and maintained a store app are thin on the ground, and you are competing with companies that have an app team already. Expect a slow search and a real ramp.

Freelancer. Fits a defined slice: build the app, add Stripe or in app purchases, fix the list performance, migrate to Expo Router. A strong freelancer is fast and cheap relative to output. What breaks is bus factor and store access. When the freelancer disappears, the Apple Developer account access, the keystore, and the EAS project often disappear with them. If you go this route, own the Apple and Google accounts yourself from day one, and hold the Android upload keystore.

Agency. Fits when you need design, mobile, backend, and store submission handled as one thing, and you would rather buy an outcome than manage people. You pay for the coordination and the fact that someone has already fought Apple guideline 4.2 and 3.1.1 before. The trade is that you are one client among several, and the person who wrote your Reanimated worklets may not be there in month nine.

Staff augmentation. Fits when you have engineering leadership but no mobile bench. You get one or two React Native engineers inside your standups, your repo, your Jira, on your process. It costs more per hour than a freelancer and less than in house all in, and continuity is the vendor's problem, not yours. It is the shape most funded startups end up at, usually after trying the other three.

What React Native developers cost

These are Digital Heroes delivery numbers and what we see in the market we hire from. Rates vary hard by region and seniority, and anyone quoting you a single global average is selling something.

• Offshore and nearshore contract: roughly $25 to $60 per hour. The bottom of that band is a mid level engineer who can build screens against a defined API. The top is someone who writes Swift and Kotlin native modules and owns the release pipeline.
• Onshore US, UK, Western Europe contract: roughly $80 to $160 per hour, higher for specialists in areas like Skia rendering, Vision Camera frame processors, or background geolocation.
• Full app build, iOS and Android, with backend integration and store submission: commonly $12,000 to $45,000 in our work. Under $12,000 usually means a thin wrapper. Over $45,000 usually means real native work, offline sync, or hardware integration.
• Ongoing maintenance: budget for it. Two OS releases a year, SDK target bumps forced by Google, plus dependency upgrades. A dormant React Native app is a depreciating asset.

On the in house side, base salary is the number people quote and the least useful one. In our own budgeting, benefits, payroll taxes, equipment, software seats, and overhead push the true cost meaningfully above base, typically by about a quarter to 40 percent depending on country and how you count. Then add recruiting, whether that is an agency fee or your engineering leader burning weeks on screens. Then add ramp: even a strong React Native engineer needs four to eight weeks before they are shipping confidently in your codebase, and the mobile specific part of that ramp includes getting them into your Apple Developer team, your Google Play access, your signing setup, and your CI. Search to productive is realistically three to five months. Compare that against a pod that can open a pull request in week one before you decide in house is cheaper.

How to vet a React Native developer

Skip the React trivia. Everything below is mobile specific on purpose.

Ask about the New Architecture. "Have you shipped with Fabric and TurboModules enabled, and what broke?" Someone who has done it will talk about libraries that had no Fabric support, interop layers, and codegen. Someone who has not will say it is "basically the same."

Ask about Expo, honestly. "Expo managed, bare, or React Native CLI, and why?" The 2019 answer, that Expo is for toys, is a tell that they stopped reading. A current answer covers config plugins, expo-dev-client, prebuild, and when continuous native generation is the wrong call. If they use Expo Application Services, ask how they handle build profiles and secrets.

Ask about a real release. "Walk me through your last App Store submission." You want to hear about certificates, provisioning, App Store Connect, TestFlight groups, the privacy nutrition label, and at least one rejection they had to argue through. Then the Android half: keystores, Play App Signing, target SDK requirements, staged rollouts.

Ask about a crash they only saw in production. The good answer involves source maps, Hermes symbolication, Sentry or Crashlytics, and a bug that only reproduced in a minified release build on one Android OEM.

Ask about over the air updates. "When do you push JS over the air and when do you cut a store build?" A serious person knows OTA cannot ship native code, knows the store rules about materially changing your app, and knows to gate updates by runtime version.

Portfolio review beats a take home. Ask for a live App Store or Play Store link they personally shipped, install it, and screen record yourself using it on a cheap Android phone. Then ask them to walk the repo: how navigation is structured with React Navigation or Expo Router, how lists are virtualized, where state lives, whether animations run on the UI thread through Reanimated worklets, whether there is a Detox or Maestro flow for the login path.

If you do want a take home, make it small and mobile shaped: a scrollable list of 5,000 items from a paginated API, with pull to refresh, offline cache, and a detail screen with a shared element transition. Four hours, timeboxed, paid. You will learn more from FlashList versus FlatList choices and how they cache with MMKV or AsyncStorage than from any algorithm puzzle.

Red flags

• Everything demoed in Expo Go, nothing on a device build. Better question: "Send me a TestFlight or internal testing build I can install." Watch how fast the excuses start.
• Cannot name a single native module they wrote or patched. Every real app eventually needs one, or a patch-package fix against a stale library. Better question: "Show me a patch you have applied to a node_modules dependency and why."
• Only tests on iOS. Ask what mid range Android device they test on and what their worst Android specific bug was. If the answer is "Android works the same," you will find out otherwise at launch.
• Wants to rewrite instead of upgrade. A developer whose answer to React Native 0.7x is "let us start fresh" cannot read a diff. Better question: "Walk me through your last two React Native version upgrades and what took longest."
• Holds the keys. Signing certificates in their personal Apple account, keystore on their laptop, EAS project under their handle. Say this before any contract: "Everything ships under our Apple and Google accounts, and we hold the keystore. Confirm."

When React Native is the wrong hire, and how we staff it

React Native is the right call when you want one team and one codebase across iOS and Android, your UI is mostly standard, and your differentiator is product, not rendering. It is the wrong call when you are building something that lives or dies on native capability: heavy real time video processing, ARKit driven experiences, tight watchOS or widget integration, or a game. In those cases hire Swift and Kotlin engineers and stop trying to save money on headcount. It is also the wrong call when your "app" is a form and a dashboard your customers open twice a month. That is a progressive web app, and the honest advice is to skip the stores entirely.

At Digital Heroes we staff React Native as a pod, not a body: an engineer who owns the JS and TypeScript layer, someone who owns the native seam and the pipeline, and design and QA drawn in as the build needs them. Clients keep the Apple and Google accounts, the repo, and the signing keys from the first commit. We start with the hardest problem in the scope, usually the native integration or the performance ceiling, because that is where estimates break, and we would rather find that in week one than month four.