Updated 27 September 2026. Originally published in 2022; revised to focus on practical hiring decisions rather than yearly market predictions.
Define the role before comparing candidates
A developer who can implement a well-specified feature inside an established app may need support with architecture, backend design or store releases. A sole technical owner needs a wider brief. Write down which responsibilities belong to this hire and which already have an owner.
- Product: the user, the main task and the smallest useful release. Include sketches of the difficult screens.
- Starting point: new application or existing repository, current React Native and Expo versions if applicable, and known build problems.
- Platforms: iOS, Android or both, supported devices and the devices available for testing.
- Integrations: existing API, authentication, payments, maps, camera, Bluetooth or other hardware requirements.
- Ownership: who supplies design, backend changes, testing, store accounts and release approval.
- Constraints: budget range, dependencies, communication overlap and any fixed external deadline.
If you already have a web product, first decide whether you need a separate mobile client. Our Laravel-to-mobile guide compares the options. That decision can change the role you should hire for.
What skills should a React Native developer have?
React Native is a framework for building mobile applications with React and native platform capabilities. JavaScript is a language used to write the application; TypeScript adds a type system. React is a UI library. The official introduction to React Native components explains how React components connect to native views.
Look for competence in the layers your project actually uses. Treat the following as an interview plan, not a requirement that every candidate be an expert in every area.
| Area | What to examine | Useful evidence |
|---|---|---|
| JavaScript, TypeScript and React | Async requests, component state, effects, types and readable boundaries. | A walkthrough of one feature, including stale responses and error states. |
| Mobile interaction | Navigation, keyboard behaviour, lists, permissions and accessibility. | A device demonstration with a denied permission, enlarged text or slow connection. |
| API and authentication | Session lifecycle, server authorization, retries and safe handling of credentials. | An explanation of expiry, sign-out and a failed request without exposing real secrets. |
| Native integration | Library compatibility, native build diagnosis and platform-specific changes. | A past integration problem, its investigation and the candidate's own contribution. |
| Testing and delivery | Meaningful automated checks, device coverage, builds and release ownership. | A release checklist and an example of a defect caught before or after distribution. |
Sharing application code does not remove platform differences. Ask how the candidate decides what stays shared and what belongs in a platform-specific implementation; React Native documents both platform checks and separate platform files.
When do native iOS or Android skills matter?
Make deeper native experience a priority when the project depends on a custom SDK, unusual hardware, background behaviour or an existing native application. React Native supports native modules and native components, but the hiring question is who can diagnose and maintain your particular integration.
For a conventional app, a developer may use established libraries successfully without writing every native layer themselves. Ask them to identify where specialist help would be needed. For an existing app, give shortlisted candidates the relevant dependency list and ask what compatibility checks they would run before an upgrade.
Expo experience can be relevant, too. Ask candidates to explain the difference between Expo Go and a development build, and how they would test the required native dependency. Expo's development-build documentation describes an app-specific build that can include native libraries and configuration. A demonstration inside Expo Go alone does not establish that your complete app can be built and released.
Interview for decisions and evidence
Choose one previous project and follow a feature from requirement to release. A store listing demonstrates that an app exists; it does not establish which parts the candidate delivered. Ask about their role, colleagues, decisions and what changed after feedback. Accept a sanitized walkthrough when client work is confidential.
- “Describe a request that failed on a real device.” Listen for reproduction steps, logs, network conditions and how the fix was checked.
- “What happens when a user signs out or their session expires?” Look for an account of token handling, cached data and server-side permissions. Private service credentials must not be shipped in the app; the React Native security guide explains that application bundles can be inspected.
- “Show a performance problem you measured.” Ask what was slow, on which device, and how the measurement changed. A list of optimization techniques is less useful than a concrete investigation.
- “What did you own in the last release?” Separate feature coding from build configuration, signing, testing, submission and monitoring.
- “What would you investigate first in this project?” Give them your brief and assess whether their questions find real uncertainty.
A candidate who names a limitation and proposes a small investigation gives you useful planning information. Treat confident estimates made before seeing a broken build or critical integration as assumptions to examine.
A small paid React Native assessment
The following is a hypothetical assessment, not client work or a production app. Agree a paid three-hour limit and a short review call. Supply a working starter project, a simple screen sketch and a mock API with three records, an empty result, a delayed response and a switchable failure. Specify one target platform and provide access to a suitable test environment. For a less experienced role, reduce the scope before starting.
Brief: build a task list and a task-detail screen. A user can open a task, return to the list and retry a failed load. No real login, backend deployment, payment integration or store submission is required.
- Show loading, empty, success and failure states using the supplied fixtures.
- Keep an earlier request from overwriting the currently selected task when responses arrive late.
- Give controls readable labels and demonstrate navigation on the agreed device or emulator.
- Add an automated check for one important interaction, such as retry after failure.
- Record what was completed, what remains and what must be checked on the other platform.
Expected artifacts: source changes, setup and run instructions, the test command, a short demonstration and a brief decision note. Agree the rules for documentation, libraries and AI assistance in advance. During review, ask the candidate to explain the submitted code and make one small change; evaluate their understanding and verification, not typing speed.
| Area | What a strong submission shows |
|---|---|
| Behaviour | The agreed flow works; loading, empty and failure states are deliberate. |
| Async correctness | Delayed or failed requests do not leave misleading data on screen. |
| Maintainability | The candidate can explain the types, component boundaries and dependencies. |
| Verification | The interaction check runs, and device observations are distinguished from assumptions. |
| Handover | Another developer can run the project and identify unfinished work. |
Use 0 for missing or unworkable, 1 for partial evidence and 2 for clear evidence: a maximum of 10 points. Set the expectations for the role before reviewing submissions. The score supports a discussion; it does not establish readiness to own authentication, native integrations or releases. Assess those separately when they belong to the job.
JavaScript component tests also have a boundary: they do not execute the native code behind the interface. The React Native testing guide distinguishes these checks from testing a built app on a device or simulator. Ask candidates what their assessment did and did not verify.
Choose an engagement that covers the missing responsibilities
An individual developer can fit a defined backlog when you already have technical review, product decisions and release support. If you hire a dedicated React Native developer, specify who reviews their work and provides those dependencies.
A delivery team can fit a project where mobile development, backend changes, testing and coordination all need owners. Confirm the actual people and responsibilities in the proposal; an agency label alone does not tell you what is included.
A scoped technical review can precede either arrangement when an existing app has unstable builds, an uncertain upgrade or a difficult integration. Define its output: a reproducible baseline, the main risks and a prioritized plan with explicit assumptions.
Compare proposals against the same scope. Include review time, devices, backend work, release preparation, third-party services and maintenance in the discussion. An hourly rate by itself does not tell you the total cost of delivering a working release.
Agree delivery and handover before work begins
- Access and ownership: the client controls the repository, store accounts and relevant service accounts, with appropriate team access.
- Acceptance: named workflows, devices, error cases and the person who approves each milestone.
- Builds: documented versions, environment setup, signing responsibilities and a repeatable way to produce a test build.
- Backend contract: an owner for API changes, authorization rules, test data and compatibility with already installed app versions.
- Release: responsibility for testing, store materials, submission, review responses and monitoring after distribution.
- Handover: setup instructions, architecture notes, known issues, access transfer and the terms of ongoing support.
If the backend is still undecided, use our React Native backend selection guide to make those responsibilities explicit before estimating the mobile work.
For a project discussion with Nomadic Soft, bring your brief, current repository status and the hardest integration to our React Native development service. Scope, responsibilities and availability should be agreed around the actual project.