Building a React Native App from Scratch

Create a cross-platform mobile app with React Native (Expo), navigate between screens, and know where official setup docs live.

What you will learn

• Bootstrap an Expo app the supported way
• Build a first screen with core components and styles
• Add stack navigation between screens
• Run on a device/emulator and debug basics

Prerequisites

• Node.js 20+
• Phone with Expo Go, or Android/iOS simulator
• Follow OS-specific setup in React Native environment setup if you leave Expo Go

Scaffold with Expo

npx create-expo-app@latest MyApp
cd MyApp
npx expo start

Scan the QR code with Expo Go, or press the terminal shortcuts for Android/iOS simulators. Docs: Expo Get Started and React Native Getting Started.

First screen

import { StyleSheet, Text, View, Button } from "react-native";

export default function Home() {
  return (
    <View style={styles.container}>
      <Text style={styles.title}>Ship a useful screen first</Text>
      <Text style={styles.body}>Start with layout and copy before native modules.</Text>
      <Button title="Continue" onPress={() => {}} />
    </View>
  );
}

const styles = StyleSheet.create({
  container: { flex: 1, alignItems: "center", justifyContent: "center", padding: 24 },
  title: { fontSize: 22, fontWeight: "700", marginBottom: 12 },
  body: { fontSize: 16, textAlign: "center", marginBottom: 20 },
});

Add navigation

Follow the official install steps for your Expo SDK version: React Navigation — Getting started.

Typical shape:

1. Install navigation packages listed in the Expo-compatible guide

2. Wrap the app in a navigation container

3. Register Home and Details screens in a native stack

4. Call navigation.navigate("Details", { id }) from a button

Project habits that save time

• Keep UI in small components under components/
• Put API calls in a thin lib/ or services/ layer
• Use TypeScript from day one (create-expo-app templates support it)
• Test on a physical device early—emulators hide font/safe-area issues

Practice checklist

• Change the home screen title and reload with Fast Refresh
• Add a second screen and navigate with a param
• Log a tap with console.log and read it in the terminal / Flipper / Expo logs
• Read the Expo docs page for one permission you will need later (camera, notifications, etc.)

Common pitfalls

• Mixing Expo and bare RN setup steps from outdated blog posts
• Ignoring platform differences for permissions and file paths
• Testing only on web when you need native modules
• Pinning random library versions that do not match your Expo SDK

Sources and further reading

• React Native docs
• Expo docs
• React Navigation
• Source: facebook/react-native
• Expo source: expo/expo

Who this guide is for

• React developers building a first mobile application
• Teams evaluating React Native for a product slice
• Mobile engineers defining cross-platform delivery standards

Definition of done

A two-screen React Native application with typed navigation, resilient data state, accessible controls, platform-aware testing, release configuration, and a documented device test matrix.

Finishing the commands is not the same as finishing the guide. Keep the result only when another person can reproduce it, inspect the evidence, and understand the remaining risks.

Professional workflow

Phase 1 — Choose the delivery path

Goal: Match tooling to native requirements and team ownership.

• List required device APIs and native SDKs.
• Choose managed or bare tooling deliberately.
• Define supported OS versions and physical test devices.

Verification: Every required native capability has a supported integration and named owner.

Phase 2 — Build one vertical slice

Goal: Complete navigation, state, loading, error, and success behavior.

• Create typed routes and parameters.
• Use safe-area and keyboard-aware layouts.
• Handle offline, slow, empty, and failed data states.

Verification: The primary journey completes on both target platforms with screen-reader labels.

Phase 3 — Prepare a release candidate

Goal: Prove configuration and lifecycle behavior outside development mode.

• Use environment-specific configuration without bundling secrets.
• Test a release build on physical devices.
• Verify deep links, permissions, app resume, and upgrade behavior.

Verification: The test matrix records device, OS, build identity, result, and unresolved issue.

Review questions before you continue

• Which features require native modules?
• What must work offline?
• How will navigation restore after process termination?
• Who owns signing, store credentials, and release rollback?

If an answer is unknown, record it as an explicit follow-up instead of hiding the uncertainty behind a successful demo.

Troubleshooting decision guide

• A package works on one platform only: inspect native support and autolinking before adding platform forks.
• Layout breaks with the keyboard: test small screens and use keyboard-aware primitives.
• Development works but release fails: compare configuration, permissions, minification, and bundled assets.
• Navigation types drift: define route parameters in one shared type map.

Change one variable at a time, preserve the first useful error, and write down the command or condition that fixed it. That turns a private debugging session into team knowledge.

Production-readiness checklist

• Test on physical iOS and Android devices.
• Keep credentials and signing material out of source.
• Handle permissions with clear rationale and denial states.
• Capture crashes and performance without sensitive user data.
• Document store release, staged rollout, and rollback procedures.

These checks are intentionally stricter than a beginner demo. Use them to decide whether to continue learning, run a controlled pilot, or request specialist review.

Your next 30 minutes

• Complete one vertical slice on two physical devices.
• Run accessibility checks with platform screen readers.
• Build and install a release configuration.
• Record the device matrix and release checklist.

CTA: Pick the first unchecked step, complete it now, and save the evidence in your project README or decision log. Then open the official documentation linked below before adopting the result in production.