React Native Developer Setup: A 2026 Launch Guide

You're probably in one of two situations right now. Either you opened a fresh React Native project and hit a wall of setup errors before writing a real feature, or you inherited an app that “works on one laptop” and nowhere else. That's normal. Mobile development punishes vague setup habits faster than almost any other stack.

Most setup guides stop at “install these tools” and leave you alone the moment local development starts working. That's the wrong cutoff point. A good developer setup isn't just about getting Metro to boot. It's about building a machine and workflow that can take code from your editor, through native builds, into a release pipeline, and finally into the App Store and Google Play without drama.

That matters more now because the tooling surface is bigger than it used to be. The global software developer population reached 28.7 million in 2025, and 84% of developers use or plan to use AI tools in their workflow, which makes a clean, modern setup even more important for day-to-day productivity and consistency across teams, according to industry analysis citing Statista and related data.

Table of Contents

• Laying the Foundation for Your Developer Setup
  • Choose based on constraints, not preference
  • Your real target is repeatability
• Installing the Core JavaScript Toolchain
  • Install Node with a version manager
  • Pick one package manager and commit to it
  • Add Watchman and Git before you need them
  • A minimum viable baseline
• Configuring Your macOS Environment for iOS Development
  • Install Xcode first
  • Understand signing before it breaks your build
  • Install CocoaPods and validate the simulator
  • What works and what usually backfires
• Setting Up Android Studio for Cross-Platform Builds
  • Install only what you need
  • Set environment variables once
  • Treat ANGLE settings carefully
  • Emulator setup that doesn't waste your morning
• Automating Your Deployments with EAS Build and Submit
  • Why local success is not enough
  • A practical EAS setup
  • Use cloud credentials instead of tribal knowledge
• The Final Launch-Ready Checklist
  • Code and configuration checks
  • Store submission checks
• Troubleshooting Common Developer Setup Hurdles
  • Xcode problems that waste the most time
  • Android Studio issues that look worse than they are
  • EAS and device-specific problems

Laying the Foundation for Your Developer Setup

The first useful mindset shift is this. React Native setup is not one setup. It's three layers that need to cooperate: your JavaScript toolchain, your native iOS and Android environments, and your build and submission workflow. If one layer is messy, the others inherit the mess.

A lot of beginners ask whether they should choose Expo or the React Native CLI as if that decision determines everything. It doesn't. It determines where you'll spend most of your complexity. Expo usually gives you a smoother starting path, especially if you want fast iteration, simpler native configuration, and easier access to services like EAS Build. The bare React Native path gives you more direct native control earlier, but it also exposes you to Xcode and Gradle problems much sooner.

Choose based on constraints, not preference

Use Expo if your app fits the managed workflow and you want fewer moving parts at the start. Use bare React Native when you know you need custom native modules, lower-level platform work, or a native integration that Expo doesn't cover cleanly for your case.

That's the “what.” The “why” is more important. Your setup choice changes who owns complexity.

Workflow	Best fit	Main trade-off
Expo managed	Faster onboarding, simpler builds, cleaner defaults	Less direct native control at the beginning
Bare React Native	Native customization, existing native codebases, custom modules	More setup friction and more chances to misconfigure iOS or Android

Practical rule: Pick the workflow that removes your next likely blocker, not the one that sounds more advanced.

The second mindset shift is to prepare for both platforms from day one, even if your first release target is only iOS or only Android. Teams that delay one side usually end up discovering avoidable problems late. Asset sizing, permissions, environment variables, package compatibility, and native dependency issues are all cheaper to catch when the app is still small.

Your real target is repeatability

A professional developer setup is boring in the best way. Another developer should be able to clone the repo, install dependencies, run the app, and produce a build without asking for hidden steps in Slack. If your project depends on one teammate remembering which terminal session has the right Node version or which Mac still holds the valid signing certificate, you don't have a setup. You have luck.

That's why this guide closes the loop all the way to submission. Local development is only the first checkpoint. The setup is finished when your release path is also predictable.

Installing the Core JavaScript Toolchain

Before you install anything mobile-specific, fix the layer almost every React Native project stands on: Node, package management, file watching, and Git.

A strong JavaScript environment matters because React Native inherits the strengths and weaknesses of the JavaScript side of your machine. Node.js remains central here. In broader developer usage, Node.js is the most-used web framework globally at 47.12%, followed by React.js at 42.62%, which confirms how central a reliable Node and JavaScript environment is for React Native and Expo work, according to SlashData's developer trends analysis.

Install Node with a version manager

Don't install Node globally and hope for the best. Use nvm so each project can stay on the version it expects.

On macOS, a common path is:

brew install nvm
mkdir ~/.nvm
echo 'export NVM_DIR="$HOME/.nvm"' >> ~/.zshrc
echo 'source $(brew --prefix nvm)/nvm.sh' >> ~/.zshrc
source ~/.zshrc
nvm install --lts
nvm alias default 'lts/*'
node -v
npm -v

On Linux, install nvm using its official script, then install the current LTS release. On Windows, use a Windows-compatible Node version manager rather than juggling one global install across projects.

Why this matters: React Native projects often lag or advance relative to the latest Node release. If one app needs one Node version and another app needs a different one, nvm saves you from dependency chaos.

Pick one package manager and commit to it

You can use npm or Yarn. Both work. The mistake is switching back and forth inside the same repository.

My opinion is simple:

• Use Yarn if the project already uses yarn.lock or if your team works mostly in the React Native ecosystem.
• Use npm if the repository already uses package-lock.json and nobody has a reason to change it.
• Never commit both lockfiles. That invites inconsistent installs and “works on my machine” bugs.

Install Yarn if you need it:

npm install -g yarn
yarn -v

Then respect the lockfile already in the repo. If you join a project and see yarn.lock, use Yarn. Don't “clean it up” by replacing the package manager on day one.

Add Watchman and Git before you need them

On macOS, install Watchman. React Native relies heavily on file watching, and Watchman usually makes reloads and rebuild detection more stable.

brew install watchman
watchman -v

Install and configure Git if it's not already ready:

git --version
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main

Keep your shell simple at first. Fancy prompts and a pile of plugins look nice, but they also create one more unknown when commands fail.

A minimum viable baseline

Before moving on, your machine should pass this quick check:

• Node works: node -v
• npm works: npm -v
• Yarn works if your project uses it: yarn -v
• Git works: git --version
• Watchman works on macOS: watchman -v

If any one of those is broken, stop there and fix it. Don't pile Xcode and Android Studio on top of an unstable foundation.

Configuring Your macOS Environment for iOS Development

iOS development is where many first-time React Native developers lose momentum. Not because React Native is the problem, but because Apple's toolchain is strict, layered, and unforgiving when one piece is slightly off.

The good news is that the setup is manageable if you think in order. Don't start with certificates. Don't start with provisioning. Start with a working Xcode installation and a simulator that boots.

Install Xcode first

Install Xcode from the Mac App Store. After that, open it once and let it finish its first-run tasks. Then install or verify the command-line tools:

xcode-select --install
xcode-select -p

If multiple Xcode versions are installed, make sure your terminal points to the one you intend to use:

sudo xcode-select -s /Applications/Xcode.app/Contents/Developer

This fixes a surprising number of “tool not found” and build path issues. I've seen developers spend an afternoon debugging a React Native project when the actual problem was that the shell still pointed to an old Xcode beta.

Understand signing before it breaks your build

Most new iOS developers treat signing as ritual. That's a mistake. You don't need to memorize every Apple term, but you do need the mental model.

Here's the short version:

• A development certificate identifies you for local development and testing.
• A distribution certificate is used for release builds that go to users.
• A provisioning profile connects your app, your certificate, and allowed devices or distribution method.
• Your bundle identifier must stay consistent across Xcode, App Store Connect, and your app configuration.

If those pieces don't line up, Xcode throws errors that look more mysterious than they really are.

A workable approach for a junior developer is to let Xcode manage signing for local development first. In Xcode, open the iOS workspace, select the app target, go to Signing & Capabilities, choose your team, and enable automatic signing. That won't solve every release scenario, but it removes a lot of early friction.

iOS signing errors usually aren't random. They come from one mismatch between app ID, team, certificate, or profile.

If you're on a team, ask one clear question early: Who owns Apple credentials and release signing? If nobody can answer that, release week will be ugly.

Install CocoaPods and validate the simulator

Most React Native iOS projects depend on CocoaPods. If you skip this, the JavaScript side may install fine while the iOS build fails immediately.

Install CocoaPods:

sudo gem install cocoapods
pod --version

Then, inside your project's ios directory:

pod install

From there, open the generated .xcworkspace file rather than the .xcodeproj when CocoaPods is involved. That one detail trips up a lot of people.

After the install, try the simulator path:

npx react-native run-ios

Or, for Expo-based projects that have native directories available, use the workflow your repo expects.

A quick visual walkthrough can help if the simulator side is still unfamiliar:

What works and what usually backfires

The cleanest iOS setup habits are boring but effective:

• Open Xcode after updates: Let it finish install tasks before you build from the terminal.
• Keep one active Xcode path: Multiple versions are fine. Multiple active assumptions are not.
• Let Xcode manage local signing first: Manual signing too early usually creates more confusion than control.
• Treat bundle IDs carefully: Renaming them casually late in the process often cascades into credential and capability issues.

What usually doesn't work is copying certificates between machines with no naming convention, sharing one Apple login loosely across too many people, or clicking through signing warnings until the app builds once. That kind of setup feels faster. It isn't. It just postpones the failure until release time.

Setting Up Android Studio for Cross-Platform Builds

Android setup feels different from iOS. Xcode is opinionated and centralized. Android Studio gives you more switches, more SDK versions, and more ways to install things you don't need. That flexibility is useful once you know your project requirements. At the start, it mostly creates noise.

Install only what you need

Install Android Studio, then open SDK Manager before touching the project. The goal is to install a practical baseline, not every Android package on the list.

At minimum, most React Native setups need:

• An Android SDK Platform that matches the project's compile target
• Android SDK Build-Tools
• Android SDK Platform-Tools
• Android Emulator
• Android SDK Command-line Tools

You usually don't need every historical platform version. If the project already exists, look in the Android build files and match what the app expects. If it's a fresh project, install the current platform required by the template and one emulator image you'll use.

That saves disk space, but more importantly, it reduces ambiguity. The more SDK versions you install without a reason, the harder it gets to tell which one Gradle is trying to use.

Set environment variables once

A lot of Android errors trace back to one missing environment variable. Set them early.

On macOS or Linux, your shell config often includes something like this:

export ANDROID_HOME=$HOME/Library/Android/sdk
export PATH=$PATH:$ANDROID_HOME/emulator
export PATH=$PATH:$ANDROID_HOME/platform-tools

Then reload the shell:

source ~/.zshrc

Verify the path is available:

echo $ANDROID_HOME
adb --version

If adb isn't recognized, stop and fix that before trying a build. Otherwise you'll get secondary errors that hide the actual cause.

Treat ANGLE settings carefully

Android has one especially annoying category of problems: graphics issues that look like app bugs but are really device or rendering configuration problems. A hidden source of build and runtime failures is incorrect ANGLE graphics engine configuration. Public documentation often misses newer GN build arguments such as angle_enable_vulkan = true, which are now standard in Android 15 builds, as shown in the ANGLE Android development setup documentation.

For most React Native and Expo developers, the practical lesson is simple. Don't start toggling graphics-related developer options on physical devices unless you know exactly why you're doing it. If a Samsung device starts showing rendering glitches after an experiment in developer options, revert those changes before debugging your app code.

Field note: When Android rendering goes strange on one device only, suspect device graphics settings before rewriting UI code.

Emulator setup that doesn't waste your morning

Create one Android Virtual Device with a recent system image and test there first. You don't need a zoo of emulators on day one.

A clean startup flow looks like this:

1. Create an AVD in Android Studio's Device Manager.
2. Start the emulator and wait until it fully boots.
3. Verify adb devices shows it.
4. Run the app with your project's expected command.

Useful checks:

• If Gradle can't find the SDK, your environment variables are probably wrong.
• If the emulator is painfully slow, give it hardware acceleration and close other heavy tools.
• If the build fails after dependency updates, try cleaning Gradle and rebuilding rather than stacking more changes.

A stable Android developer setup comes from restraint. Install what the project needs. Name your emulator clearly. Keep your SDK paths explicit. Most Android pain comes from drift, not from Android itself.

Automating Your Deployments with EAS Build and Submit

A local build proves that your code can run on your machine. It doesn't prove your team can release reliably. Those are different standards, and too many developer setups stop at the easier one.

EAS Build and EAS Submit earn their place by turning release work from a laptop ritual into a repeatable process. That matters because a proper CI/CD pipeline reduces human error and can accelerate release cycles by 40% to 60%, while elite teams with strong automation keep change failure rates under 1% and manual processes often push that figure over 15%, according to CA One's software delivery best practices analysis.

Why local success is not enough

Manual release flows usually look like this: one developer builds locally, hunts for the right signing setup, exports an artifact, logs into store dashboards, uploads by hand, and hopes they didn't miss a configuration toggle. That process is survivable for one rushed release. It's a terrible foundation for a product.

The pain points are always the same:

• Credentials live on one machine
• Build steps exist only in memory
• Release artifacts aren't reproducible
• Store submission becomes a specialist task instead of a team capability

EAS solves a lot of that by moving builds into a managed, cloud-based workflow that fits React Native and Expo projects well.

A practical EAS setup

Start by installing the CLI:

npm install -g eas-cli
eas --version

Then log in:

eas login

In your project root, initialize EAS:

eas build:configure

That creates or updates your eas.json. Keep the file simple at first. Typically, only a few profiles are needed, such as development, preview, and production.

A typical pattern is:

• Development profile for internal testing and emulator or device installs
• Preview profile for QA or stakeholder review
• Production profile for store-ready binaries

The key is consistency. Don't create five profiles because the file allows it. Every extra branch in your release config is another place to forget a setting.

Use cloud credentials instead of tribal knowledge

The biggest practical win with EAS is credential handling. iOS certificates, provisioning profiles, and Android keystores are exactly the kinds of assets teams misplace, rename, or keep on one senior developer's laptop. EAS gives you a cleaner operating model by managing those release credentials in a more centralized way.

Once the app config is in place, builds are straightforward:

eas build --platform ios
eas build --platform android

And submissions can follow with:

eas submit --platform ios
eas submit --platform android

If releasing your app depends on one person being awake and near one specific laptop, your deployment process is still manual.

What works well is setting up EAS while the app is still young. What doesn't work is delaying automation until your first urgent release. By then, credential debt and undocumented steps have already piled up.

A strong developer setup closes the loop. You write code locally, validate it on simulators and emulators, build in the cloud, and submit through the same workflow. That's what turns setup from a checklist into infrastructure.

The Final Launch-Ready Checklist

Right before submission, teams often focus on the dramatic parts like certificates and binary uploads. In practice, simpler issues block launches just as often. Wrong environment variables. Missing privacy links. Bad screenshots. Debug leftovers in production. This last pass is about catching the quiet mistakes.

Code and configuration checks

Run through the app as if you didn't build it.

• Check environment targeting: Make sure production builds point to production APIs and services. A staging endpoint in a live app is an avoidable self-own.
• Remove development noise: Strip console spam, unfinished feature flags, and temporary test screens that were useful during setup but shouldn't ship.
• Validate assets: Confirm app icons, splash screens, and branding assets are correct on both platforms and look right across device sizes.
• Review permissions: If the app asks for camera, photos, notifications, or location, the prompts and store disclosures should match what the app does.

Store submission checks

Many technical teams underestimate the non-code work.

Area	What to verify	Why it matters
Listing copy	Title, subtitle, description, keywords, category	Sloppy metadata creates confusion and slows review
Privacy policy	Publicly accessible, current, matches app behavior	Reviewers and users both look for this
Screenshots	Correct sizes, current UI, no placeholder text	Old or incorrect images make the app look unfinished
Compliance forms	Platform-specific privacy and data declarations	Inconsistent answers create review friction

Submission failures often start outside the codebase.

Before you hit submit, do one final install of the exact release candidate on real devices if possible. Tap through onboarding, authentication, purchases if relevant, notification prompts, deep links, and account deletion or sign-out flows. Release builds behave differently from debug builds often enough that this check is worth the time every single launch.

Troubleshooting Common Developer Setup Hurdles

Even clean setups fail. The difference between a junior and senior response usually isn't knowing every fix in advance. It's knowing how to narrow the problem fast and not panic when the error message is ugly.

One pattern matters across all tools: when something breaks, undo recent changes before making new ones. Don't update Node, reinstall Xcode, delete Gradle caches, and rotate credentials all in the same hour. That only destroys evidence.

Xcode problems that waste the most time

A common iOS error is effectively: command-line tools are missing or pointing to the wrong Xcode.

When that happens, check the selected developer directory:

xcode-select -p
sudo xcode-select -s /Applications/Xcode.app/Contents/Developer

If builds fail after an Xcode update, open Xcode itself once. Accept any license prompts and let it finish post-install tasks.

Another frequent class of failure is provisioning profile mismatch. You'll usually see language about no matching provisioning profile, missing signing certificate, or a bundle identifier conflict. The fix is rarely exotic. Confirm the selected team, bundle ID, and signing mode in Xcode, then verify you're building the workspace and not the project file if CocoaPods is involved.

Android Studio issues that look worse than they are

Android's classic failure is some variation of SDK location not found or ADB unavailable. Start with environment variables and path validation. If the shell can't see the SDK, Gradle can't either.

When the emulator launches but the app won't install, check whether the device is visible:

adb devices

If it isn't, restart the emulator before changing project files. If Gradle gets stuck after dependency changes, a clean build often helps more than random package reinstalling.

Performance problems are another trap. Developers often blame React Native when the actual issue is an underpowered or misconfigured emulator. Test on a physical device if the emulator feels suspiciously bad.

EAS and device-specific problems

EAS problems usually fall into one of three buckets:

• Authentication issues: You're logged into the wrong account or missing access.
• Credential issues: The app identifiers or signing assets don't match the project.
• Configuration issues: app.json, app.config.js, or eas.json doesn't reflect the intended package names, bundle IDs, or build profile behavior.

The best fix is to read the first meaningful error, not the last screenful of logs. Cloud build logs can be noisy, but the root cause usually appears earlier than people expect.

Then there's the category most generic guides ignore: device-specific graphics weirdness. A 2025 YouTube tutorial about enabling the ANGLE graphics engine on Galaxy devices drew over 53,000 views, while Reddit threads warn people not to enable it because it can break things, which points to real confusion around device-specific setup risk, as noted in this Galaxy ANGLE tutorial reference. If one Samsung device shows rendering glitches after developer-option changes, revert those graphics settings before blaming React Native, Expo, or your animation code.

A final troubleshooting checklist I trust:

• Reproduce on a second machine if possible
• Check tool versions before reinstalling everything
• Revert experimental device settings
• Fix one layer at a time
• Document the resolution in the repo or team docs

That last point matters more than people think. Every solved setup issue should make the next developer faster.

---

If your app is built but the launch process still feels messy, LetsDeployIt can handle the App Store and Google Play approval work end-to-end for React Native and Expo apps, including store assets, privacy policy hosting, compliance checks, EAS Build and Submit wiring, reviewer responses, and resubmissions. It's a practical option when you want your developer setup to end in an actual release instead of another week of submission friction.