Hire React Native developers

React Native builds genuinely native iOS and Android applications from one React codebase, and hiring for it means finding someone who can drop into the native layer when the abstraction runs out.

What React Native actually is

React Native lets you write mobile applications in React that render actual native interface components rather than a web view. It originated at Meta and is now developed with a substantial community around it, including Expo, which has become the default way most teams start a project. The promise is one team and one codebase producing applications for both platforms.

That promise is real and it is not total. A large share of any application, typically the screens, navigation, state and business logic, is genuinely shared. The remainder is not: platform-specific behaviour, native module integration, permissions, background work, push notifications and the release process all differ, and those are exactly the parts that consume time near a launch. Teams that budget for one codebase and discover two release processes are the ones that end up unhappy.

The decisive hiring question is what happens when the abstraction is insufficient. Every non-trivial React Native project eventually needs something the JavaScript layer does not expose, or has to debug a crash that only appears on one platform. A developer who can open the native project, read the stack trace and either fix it or integrate a native module is a substantially different hire from one who can only work above that line.

The part that separates seniors from mid-levels

The architecture matters more than it used to. React Native historically ran JavaScript on a separate thread communicating with the native side through an asynchronous bridge, which was a real performance ceiling for anything involving continuous interaction such as gestures or animation. The newer architecture replaces that with a synchronous interface layer and a rewritten rendering system. Developers who have migrated an application across this boundary have dealt with a genuine change rather than a version bump, and it is worth asking about.

Performance work in React Native is mostly about keeping work off the JavaScript thread. Lists are the classic case: a long scrolling list that recreates components on every frame will drop frames in a way users notice immediately. Animations driven from JavaScript rather than run natively will stutter under load. Candidates who have shipped a polished application can name the list component they use, explain why animations should run on the native driver, and describe profiling on a real low-end device rather than a simulator.

The third area is the release process, which surprises teams coming from the web. There are two app stores with two review processes, two signing arrangements and two sets of platform requirements that change on the platforms' schedules rather than yours. Over-the-air updates can ship JavaScript changes without a review, within limits that are worth understanding precisely. A developer who has actually shipped and maintained an application in both stores brings knowledge that is tedious to acquire and expensive to lack.

Where React Native is used

The label “React Native developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Consumer applications

Products where a single team must serve both platforms and the interface is mostly standard components.

Internal and field applications

Workforce tools where development speed matters more than platform-specific polish.

Commerce and booking applications

Catalogue, checkout and account flows, often sharing logic with an existing React web front end.

Content and media applications

Feed-driven products where list performance is the main technical challenge.

Companion applications

Mobile front ends for an existing web product, where reusing React knowledge is the main argument.

Startup first products

Where reaching both platforms quickly with a small team outweighs the cost of the abstraction.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Which React Native versions are still supported

React Native releases frequently and support for older versions is short, so how current an application is directly determines which libraries and build tools remain available to it.

The table is generated from public release data rather than written by hand, so it states what is supported today rather than what was true when any given article was published. Of the 8 most recent release lines, 3 are still maintained and 5 have passed their published end-of-life date. That distinction is the practical one when you read a job specification: a requirement written against a line that is now out of support tells you the specification is older than the codebase it describes, and it is worth asking which of the two the new developer will actually work in.

Source: endoflife.date public release data, read 2026-09-25.

Two questions follow from this table in an interview. The first is which line the candidate has most recently shipped against, because someone whose last production work was on an unsupported line has not had to deal with the changes since. The second is how they have handled an upgrade. Version migrations are where you see whether a developer reads release notes, writes characterisation tests before changing anything, and knows how to stage a rollout, or whether they upgrade in place on a Friday and hope.

The toolchain around it

Nobody hires for React Native alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

Expo

The default toolchain, covering build, updates and a large set of native capabilities without touching native projects.

TypeScript

Standard in commercial React Native work, particularly across navigation parameters.

React Navigation

Routing and navigation, with platform-appropriate transitions.

Reanimated and Gesture Handler

Animation and gestures that run natively rather than on the JavaScript thread.

FlashList or FlatList

Virtualised lists, which is where mobile performance is won or lost.

TanStack Query

Server state, caching and offline behaviour, which matters more on mobile than on the web.

Sentry or similar

Crash reporting with source maps, since you cannot reproduce every device.

Fastlane or EAS

Build and release automation across two stores.

Related skills that frequently appear on the same specification: Node.js, React, TypeScript, iOS and Swift, Android and Kotlin.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

What they do when the abstraction runs out

The single most important question, because every real project reaches this point.

• Strong answer: Has opened the native projects, read platform stack traces, and either written or integrated a native module.
• Warning sign: Has only worked inside managed tooling and would be blocked by a native crash.

List and render performance

The most visible quality difference between a good and a poor React Native application.

• Strong answer: Uses virtualised lists properly, memoises row components, and has profiled on a real low-end Android device.
• Warning sign: Tests only on a recent iPhone or a simulator.

Animation and the native driver

Determines whether the application feels native or approximately native.

• Strong answer: Runs animations natively, understands why JavaScript-driven animation stutters, and uses the gesture libraries deliberately.
• Warning sign: Animates from JavaScript and has not noticed the difference.

Release and store experience

Tedious, unavoidable, and expensive to learn during a launch.

• Strong answer: Has shipped to both stores, handled a rejection, managed signing, and used over-the-air updates within their limits.
• Warning sign: Has never submitted an application or handled a review rejection.

Platform differences they have hit

Reveals depth of real shipping experience.

• Strong answer: Can name specific divergences in permissions, keyboard behaviour, safe areas, back navigation or background execution.
• Warning sign: Believes the codebase is genuinely identical across platforms.

Offline and unreliable networks

Mobile applications face conditions web applications rarely do.

• Strong answer: Caches deliberately, queues mutations, handles conflict, and has tested on a poor connection rather than assuming.
• Warning sign: Treats the network as reliable and shows a spinner indefinitely.

The new architecture

A genuine change in how the framework works, and a good currency test.

• Strong answer: Knows what changed and has migrated or at least evaluated an application.
• Warning sign: Unaware of it, which suggests experience that has not been refreshed recently.

Warning signs in a React Native codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

Unvirtualised long lists

• What you see: Mapping over a large array inside a scroll view.
• What it costs: Every row mounted at once, memory spikes and dropped frames on anything but a high-end device.
• The fix: Use a virtualised list with stable keys and memoised rows. Test with a realistic number of items.

Animations on the JavaScript thread

• What you see: Animated values updated from JavaScript without the native driver.
• What it costs: Stutter whenever the thread is busy, which is exactly when the user is interacting.
• The fix: Use the native driver or Reanimated so animation runs independently of JavaScript work.

Testing only on iOS

• What you see: Development on a recent iPhone simulator, with Android checked near release.
• What it costs: Android-specific layout, keyboard, permission and performance problems discovered at the worst possible time.
• The fix: Test both continuously, including a genuinely low-end Android device, which is what much of the real user base has.

Ejecting from managed tooling without cause

• What you see: Moving to bare native projects early for a capability that was already available.
• What it costs: Two native projects to maintain, upgrades become manual, and the main advantage of the toolchain is lost.
• The fix: Stay managed until a specific requirement forces the move, then make the decision deliberately.

Treating the network as reliable

• What you see: No caching, no retry, no offline state.
• What it costs: An application that is unusable on a poor connection, which on mobile is a substantial share of sessions.
• The fix: Cache responses, queue mutations, and design explicit offline states. Test on a throttled connection.

Ignoring the upgrade cadence

• What you see: An application several versions behind because upgrades were deferred.
• What it costs: Incompatible libraries, unsupported build tooling, and eventually store requirements that cannot be met.
• The fix: Upgrade regularly and use the published upgrade tooling. Falling far behind is much harder to recover from here than on the web.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a React Native developer.

Junior

Builds screens and navigation in an existing application. Needs review on list performance and platform differences.

Mid-level

Owns a feature across both platforms including offline behaviour and tests. Can profile and fix a dropped-frame problem.

Senior

Owns application architecture, the native module strategy, the release pipeline, and can diagnose a crash that only occurs on one platform.

Staff

Owns the upgrade path, the decision about managed versus bare tooling, the relationship with store requirements, and whether the product should be cross-platform at all.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

New cross-platform application

• Usual team: Two developers plus a designer.
• What governs it: The last twenty percent, covering permissions, notifications, store review and device-specific bugs, takes far longer than the first eighty.

Companion application to a web product

• Usual team: One to two developers.
• What governs it: Sharing logic with a React web codebase is possible and usually less valuable than expected, because the interface layer dominates.

New architecture migration

• Usual team: One senior developer.
• What governs it: Scoped by third-party library compatibility rather than by application code.

Performance remediation

• Usual team: One senior developer with real devices, time-boxed.
• What governs it: Usually lists and animations. Must be measured on low-end Android, not on a simulator.

Native module integration

• Usual team: One developer comfortable in the native layer.
• What governs it: This is where a purely JavaScript-level hire stops being sufficient.

Migration work you may actually be hiring for

A large share of React Native work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

The old architecture to the new architecture

• Why teams do it: Better performance for interaction-heavy applications, and the direction the whole ecosystem is moving.
• What to watch: Third-party libraries are the constraint. Audit which dependencies support it before planning, because one unsupported library in the critical path stops the whole migration.

Bare native projects to Expo's managed workflow

• Why teams do it: Removing two native projects from the maintenance burden and simplifying upgrades.
• What to watch: Custom native code needs to become a config plugin. Worth doing when the native customisation is modest and a poor trade when it is extensive.

Separate iOS and Android codebases to React Native

• Why teams do it: One team instead of two, and features shipping to both platforms at once.
• What to watch: Rarely a full rewrite in practice. Most successful moves embed React Native screens inside the existing native applications and expand from there, which keeps the product shipping throughout.

JavaScript-driven animation to Reanimated

• Why teams do it: Animation that runs independently of the JavaScript thread and does not stutter under load.
• What to watch: A different programming model rather than a drop-in replacement. Convert the interactions users actually notice first instead of everything at once.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a React Native developer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• Whether the application uses Expo or bare native projects, since this changes the required skill set considerably.
• Which architecture the application is on, and whether migrating is in scope.
• What native capabilities are needed: camera, background location, notifications, health data, payments.
• Whether the application must work offline, because that is a design constraint rather than a feature.
• Who owns store submission, signing and the developer accounts, which is often unassigned until it blocks a release.
• Which devices genuinely have to be supported, particularly at the low end of Android.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

React Native work is counted by the US Bureau of Labor Statistics under Software Developers. That classification is broader than the technology itself, so treat the figures as the shape of the market a React Native developer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 1,687,890 people in this occupation, with a median annual wage of $135,980.

The spread matters more than the midpoint. The 90th percentile is about 2.6 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a React Native developer can sit at $82,460 and $214,670 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Software Developers, the gap between the highest and lowest of the 28 metro areas covered here is a factor of about 1.7. San Jose sits at the top with a median of $213,110; Pittsburgh sits at the bottom with $124,500. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. San Jose, San Francisco, Seattle, Washington, D.C., Denver, Austin each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

React experience presented as React Native. The component model transfers; navigation, platform APIs, performance and release do not. Test those specifically.

No native layer capability. Ask what they did the last time something required a native change. This is the most consequential gap.

No store release experience. Ask about a rejection they handled. Learning this during a launch window is expensive.

iOS-only testing habits. Ask what Android device they test on. Much of the real user base is on hardware considerably slower than a developer's phone.

Hiring React Native developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of React Native developer who will be available.

• New York, NY $166,830 median
• Seattle, WA $167,280 median
• San Jose, CA $213,110 median
• Washington, D.C. $154,930 median
• San Francisco, CA $186,640 median
• Dallas-Fort Worth, TX $133,290 median
• Los Angeles, CA $160,920 median
• Boston, MA $166,090 median
• Chicago, IL $134,380 median
• Atlanta, GA $132,960 median
• Austin, TX $134,120 median
• Phoenix, AZ $131,750 median
• Philadelphia, PA $133,040 median
• Minneapolis-St. Paul, MN $130,920 median
• Denver, CO $137,610 median
• Detroit, MI $130,760 median
• Houston, TX $129,440 median
• Charlotte, NC $135,920 median
• San Diego, CA $163,270 median
• Salt Lake City, UT $129,600 median
• Miami, FL $132,650 median
• Portland, OR $156,000 median
• Baltimore, MD $138,900 median
• Tampa, FL $130,450 median
• Orlando, FL $129,620 median
• Raleigh, NC $132,770 median
• Kansas City, MO $124,990 median
• Pittsburgh, PA $124,500 median

Frequently asked questions

Will React Native really let us ship both platforms with one team?

Largely, and not entirely. Screens, navigation, state and business logic are genuinely shared, which is most of the code. Permissions, notifications, background behaviour, store submission and platform-specific bugs are not, and they concentrate near release. Plan for one codebase and two release processes and the approach works well.

React Native or fully native?

React Native when the interface is largely standard components, you need both platforms, and team size is the constraint. Fully native when the application depends heavily on platform capabilities, needs the highest possible performance, or when the product is one platform only. Applications that are mostly lists, forms and content do well cross-platform; applications built around camera, sensors or heavy graphics usually do not.

Should we use Expo?

For most projects, yes, and it is now the default recommendation. It covers a large set of native capabilities, handles builds and updates, and removes the need to maintain two native projects. The case for going without it is a specific native requirement it does not support, and that case is narrower than it used to be.

Can our React web developers build the mobile application?

They will be productive faster than someone starting from nothing, because the component model and hooks transfer directly. What does not transfer is navigation, platform APIs, offline behaviour, performance on constrained devices and the release process. Expect a meaningful ramp and pair them with someone who has shipped to the stores.

Why does our React Native application feel slower than a native one?

Usually lists that are not properly virtualised, or animations running on the JavaScript thread rather than natively. Both are fixable and both are very visible to users. The other common cause is that testing happened on high-end devices, so the problem was never seen by the people building it.

What is the new architecture and does it matter to us?

It replaces the asynchronous bridge between JavaScript and native code with a faster, more direct mechanism and a rewritten renderer. It matters most for applications with heavy interaction. For a typical forms-and-lists application the difference is modest, but the ecosystem is moving there, so staying on the old architecture will eventually limit which libraries you can use.

How do over-the-air updates work?

You can ship JavaScript changes directly to installed applications without a store review, which is genuinely useful for fixes. There are limits: anything touching native code still requires a store release, and the platforms have rules about what may be changed this way. It is a real advantage and not a way to avoid the store process.

How much does maintaining a React Native application cost?

More than teams expect, because the framework, the toolchain and both platforms all move. Platform requirements change on their own schedule and can force work you did not plan. Budget continuous maintenance rather than treating the application as finished at launch, because falling behind is significantly harder to recover from here than on the web.