“Our React developers can do mobile” is where this goes wrong.
The component model transfers. Navigation, native modules, signing, store releases and debugging a crash that only happens on one manufacturer's firmware do not. That gap is the whole job.
Where web React knowledge stops.
The transferable part is real and substantial: components, hooks, state, and the general shape of a React codebase. A web React engineer will be building screens within days, which is exactly what creates the false confidence.
The wall arrives at the first thing that is not a screen. Navigation is a different model with its own lifecycle. Lists need virtualisation to behave on a three-year-old Android device. Anything touching the camera, background location, biometrics or a payment SDK needs a native module or a well-chosen package, and choosing badly there is a decision you live with.
Then there is everything after the code. Signing and provisioning, two store submission processes with different reviewers and different rules, staged rollouts, and over-the-air updates and their limits.
And when it crashes on a device you do not have, in code you did not write, the stack trace is native. An engineer who cannot read Swift or Kotlin at all is stuck at that point, and it is not a rare situation.
What we ask a React Native engineer.
Almost none of it is React. That is deliberate, the React half is the half you can already assess.
What is in the stores, and can we install it?
Links, not descriptions. Shipping is the skill and it is binary.
Expo or bare, and why?
A current, reasoned answer. Expo's managed workflow has changed enough that outdated objections reveal when someone last shipped.
Have you written a native module?
Swift or Kotlin, bridged. The boundary where React Native ends and where most projects eventually arrive.
How do you make a long list smooth?
Virtualisation, item layout, image handling. The most common performance complaint in every React Native application.
Walk us through your release process.
Signing, provisioning, submission, staged rollout, and what happens when a release has to be pulled.
Tell us about a crash only on real hardware.
Native stack traces, symbolication, device-specific behaviour. This separates people who have owned an app from people who have contributed to one.
Whether React Native is the right answer at all.
Worth ten minutes before a hiring decision. Two questions decide it, and neither is about the framework.
Deep platform use, no React
Hardware, background processing, platform-specific design. Two native codebases will be cheaper than fighting the bridge.
Deep platform use, React team
The React advantage does not survive heavy native work. Choose on design requirements instead.
Simple app, no React
If there is no hardware requirement and no real need to be in a store, a responsive web application is cheaper on every axis. Asked far too rarely.
Simple app, React team
The case is strong here: shared language, shared people, shared types with your API.
What a working mobile team looks like.
The most common staffing mistake is one React Native engineer and an assumption that the web team covers the rest.
- One engineer who has shipped to both stores. Non-negotiable. Somebody has to own signing, submission and the release process or it becomes nobody's job at the worst moment.
- Your existing React engineers, on screens. Genuinely productive here, and this is where the shared-skills argument does pay off — see React developers.
- Native reading ability somewhere on the team. Not a full native developer, but somebody who can follow a Swift or Kotlin stack trace when the crash reports arrive.
- A device matrix, not just simulators. A small set of real Android devices catches most of what emulators hide, and costs less than one wasted sprint.
- A designer who knows both platforms. Users notice when an app feels like the other platform, even when they cannot say why.
Rates, notice and how we interview, on one page.
The commercial mechanics are the same whichever role you are hiring, so they live in one place, not being restated on every page.
Hiring React Native engineers.
The three that most often change a plan.
Can our React web developers just learn it?
For screens, yes, and quickly, days rather than weeks, because the component model and state management transfer directly. For the rest of it, that plan is how mobile projects lose a quarter. Somebody has to own navigation architecture, the decision about Expo or bare, native module choices, signing and provisioning, two submission processes, and the crashes that only appear on real hardware. None of that is learnable from web experience and all of it arrives at once, usually about six weeks in when the first release is due. The arrangement that works is one engineer who has shipped before, with your React team alongside them on screens. That is cheaper than a full mobile team and far cheaper than discovering the gap late.
Expo or bare React Native?
Expo, unless you have a specific reason not to, and most of the objections we hear are several years out of date. The managed workflow now supports custom native code through development builds, handles a great deal of build and release complexity that teams otherwise maintain by hand, and its over-the-air update mechanism is useful for fixes that do not need a store review. Bare makes sense when you have substantial existing native code, a native SDK with unusual integration requirements, or an organisational requirement to control the entire build. A candidate who dismisses Expo without a current reason is telling you when they last shipped.
How do we handle app store releases?
Somebody has to own it, and that is a staffing decision instead of a process one. The work is signing and provisioning across a team, two store accounts with different rules and different reviewers, release notes and screenshots, staged rollout, and the judgement about when a fix goes out over the air and when it needs a submission. On the engagements that run smoothly, one named engineer owns all of it and automates most of it in the first month. On the ones that do not, it is shared, which means it is nobody's and the first urgent release is a bad day. We would rather agree the owner before starting.