Build and run a React Native app on your own phone with Expo: components, navigation, data, storage and device features.

Mobile Development Basics

## Why it matters

A web app has a URL bar and a back button supplied by the browser. A mobile app has neither, so the app itself must keep track of where the user is and how they got there. Getting navigation right is what makes an app feel solid: the back gesture returns where users expect, tabs remember their place, and the details screen shows the item they tapped.

## The mental model: a stack of screens

Most mobile navigation is a **stack**. Opening a screen pushes it on top; going back pops it off. Tabs are several stacks side by side, one per tab.

```text
push("Details", { id: 42 })        pop()
[Home]  ->  [Home, Details#42]  ->  [Home]
```

Each entry in the stack is a **route**: a screen name plus its **params** (the data the screen needs, like an id). Navigation state is just data, and the screen you see is a function of that data. That should sound familiar from React: UI = f(state).

## Two libraries you will meet

**React Navigation** is the long-standing library. You declare navigators in code:

```javascript
import { createNativeStackNavigator } from "@react-navigation/native-stack";
const Stack = createNativeStackNavigator();

function App() {
  return (
    <NavigationContainer>
      <Stack.Navigator>
        <Stack.Screen name="Home" component={HomeScreen} />
        <Stack.Screen name="Details" component={DetailsScreen} />
      </Stack.Navigator>
    </NavigationContainer>
  );
}

function HomeScreen({ navigation }) {
  return <Button title="Open 42" onPress={() => navigation.navigate("Details", { id: 42 })} />;
}

function DetailsScreen({ route }) {
  return <Text>Item {route.params.id}</Text>;
}
```

**Expo Router**, used by the default Expo template, is built on React Navigation but uses files as routes, like Next.js. A file `app/details/[id].tsx` is a screen; you navigate with `router.push("/details/42")` or a `<Link href="/details/42">`, and read the param with `useLocalSearchParams()`. Layout files (`_layout.tsx`) declare whether a folder is a stack or tabs.

Both give you native transitions and the platform's back behaviour (the Android back button, the iOS swipe from the edge) for free.

## Screen state versus app state

Navigation raises the question every React app faces: where does state live?

- **Local screen state** (`useState` inside the screen) is for things only that screen cares about, like the text in a search box. It is lost when the screen is popped.
- **Params** pass small, serializable values between screens: ids, not whole objects. Pass `{ id: 42 }` and let the details screen look the item up, so it never shows stale data.
- **Shared app state** (lifted state, context or a reducer at the top) holds things several screens need, such as the signed-in user or a cart.

A reducer is a good fit for shared state because every change is an explicit action you can test without a phone:

```javascript
function cartReducer(state, action) {
  switch (action.type) {
    case "add":
      return { ...state, items: [...state.items, action.item] };
    case "clear":
      return { ...state, items: [] };
    default:
      return state;
  }
}
```

## Worked example: a navigation reducer

Navigation libraries are, underneath, reducers over a stack. Writing a tiny one yourself shows what `push`, `pop`, `replace` and `reset` really do:

- `push` adds a route on top.
- `pop` removes the top route, but never the last one (there must always be a screen).
- `replace` swaps the top route, which is what you want after a login screen so that back does not return to it.
- `reset` replaces the whole stack, for example after sign-out.

Each returns a **new** state object and leaves the old one untouched, just like any React reducer.

## Common mistakes

- **Passing whole objects as params.** They can go stale and must be serializable for deep links and state restoration. Pass ids.
- **Pushing the login screen on top of the app.** After a successful sign-in, `replace` or `reset` so the back gesture does not return to the login form.
- **Duplicated screens.** Tapping a button twice quickly can push two copies; disable the button or use `navigate`, which reuses an existing route with the same name in React Navigation.
- **Mutating state.** `state.stack.push(...)` changes the old state in place and React may not re-render. Return new arrays.

## Quick recap

- Mobile navigation is a stack of routes (screen name + params); tabs are stacks side by side.
- React Navigation declares navigators in code; Expo Router derives them from files.
- Keep local state local, pass ids as params, and put shared state in a reducer or context.

## Try it

In the Do tab you will write `navReducer`, a small stack navigator as a pure function, plus a helper that reads the current screen. It runs in your browser with no phone needed.


Move between screens with a navigation stack and decide where each piece of state lives.

Navigation and state

Using a Stack Navigator with Expo Router

Using a Tab Navigator with Expo Router

## Why it matters

Almost every real app shows data that lives on a server: posts, products, messages. Loading it well is what separates a demo from an app people trust. Users on a train go through tunnels, servers are slow and requests fail, so a screen must handle **loading**, **success**, **empty** and **error** states, not just the happy path.

## Fetching in React Native

React Native ships the same `fetch` API you know from the browser. The usual pattern is an effect that runs when the screen mounts:

```javascript
import { useEffect, useState } from "react";
import { ActivityIndicator, FlatList, Text, View, Pressable } from "react-native";

export default function UsersScreen() {
  const [state, setState] = useState({ status: "idle", items: [], error: null });

  async function load() {
    setState((s) => ({ ...s, status: "loading", error: null }));
    try {
      const res = await fetch("https://jsonplaceholder.typicode.com/users");
      if (!res.ok) throw new Error(`HTTP ${res.status}`);
      const users = await res.json();
      setState({ status: "success", items: users.map((u) => ({ id: String(u.id), title: u.name })), error: null });
    } catch (err) {
      setState((s) => ({ ...s, status: "error", error: err.message }));
    }
  }

  useEffect(() => { load(); }, []);

  if (state.status === "loading" && state.items.length === 0) return <ActivityIndicator />;
  if (state.status === "error") {
    return (
      <View>
        <Text>Could not load users: {state.error}</Text>
        <Pressable onPress={load}><Text>Try again</Text></Pressable>
      </View>
    );
  }
  return (
    <FlatList
      data={state.items}
      keyExtractor={(item) => item.id}
      renderItem={({ item }) => <Text>{item.title}</Text>}
      ListEmptyComponent={<Text>No users yet.</Text>}
      refreshing={state.status === "loading"}
      onRefresh={load}
    />
  );
}
```

Note `res.ok`: `fetch` only rejects on network failure. A 404 or 500 still resolves, so you must check the status yourself.

## Why FlatList and not map

On the web you might write `items.map(...)` inside a scrolling `div`. In React Native, a `ScrollView` with `map` renders **every** row at once, which is fine for 20 items and painful for 2,000. `FlatList` renders only the rows near the screen and recycles the rest. It needs:

- `data`: the array,
- `renderItem`: a function that receives `{ item, index }`,
- `keyExtractor`: a function returning a **string** key per item (React Native warns about missing or duplicate keys),
- optional `ListEmptyComponent`, `ListHeaderComponent`, `onRefresh` + `refreshing` for pull-to-refresh, and `onEndReached` for loading more pages.

## Shape the data before the UI sees it

API responses rarely match what a list row needs. Convert them once, in a plain function, so the component stays simple and the conversion is easy to test:

```javascript
function toListData(users) {
  return users
    .filter((u) => u && u.id != null && u.name)
    .map((u) => ({ id: String(u.id), title: u.name, subtitle: u.email || "" }));
}
```

The same idea applies to the request state itself. Instead of several `useState` calls that can disagree (loading is false but data is missing), keep one object and change it through a reducer with `start`, `success` and `failure` actions. Keeping the old items during a refresh means the list does not flash empty while new data loads.

## Device networking gotchas

- **localhost is not your computer.** On a phone, `localhost` means the phone. Use your computer's LAN address (for example `http://192.168.1.20:3000`); in the Android emulator, `10.0.2.2` reaches the host machine.
- **Plain HTTP is blocked by default.** iOS App Transport Security and Android 9+ refuse cleartext `http://` in production builds. Use HTTPS for real servers.
- **Requests can outlive the screen.** If the user leaves before a response arrives, ignore the result (keep an `ignore` flag in the effect cleanup, or use an `AbortController`).

## Common mistakes

- Forgetting to check `res.ok`, so error pages are parsed as data.
- Numeric keys: `keyExtractor` must return a string.
- Showing a blank screen on error with no way to retry.
- Rendering a long list with `ScrollView` and `map`.

## Quick recap

- Use `fetch` in an effect, check `res.ok`, and model loading, success, empty and error states.
- Use `FlatList` with `keyExtractor` for lists; add pull-to-refresh with `onRefresh`.
- Convert API data with small pure functions and keep request state in one reducer.

## Try it

In the Do tab you will write `requestReducer` and `toListData`, the two pure pieces behind the screen above.


Load remote data with fetch, handle loading and error states, and render it with FlatList.

Wire up the screens

React Native Tutorial - 52 - FlatList

React Native Fetch Data From API and Render FlatList

In `app.json`, set `name`, `slug`, `version`, an `icon`, `ios.bundleIdentifier` and `android.package` (reverse-domain, for example `com.yourname.studytimer`).

Create a free account at expo.dev. Install the CLI with `npm install -g eas-cli` and run `eas login`.

Run `eas build:configure`, then edit the `preview` profile in `eas.json` to add `"distribution": "internal"` and `"android": { "buildType": "apk" }`.

Android: run `eas build --platform android --profile preview`, wait for the cloud build, open the link on your phone and install the APK. Free-plan builds can queue; that is normal.

iPhone: if you have a paid Apple Developer membership ($99/yr, checked on 2026-10-23), run `eas device:create` and then `eas build --platform ios --profile preview`. Otherwise, open the app in Expo Go and skip the build.

Launch the app from the home screen icon (or Expo Go) with the development server stopped, and check that every screen still works.

Write down one thing that behaves differently from development (startup time, missing dev menu, API address).

## Why it matters

Running in Expo Go is perfect for learning, but Expo Go is not your app: it is Expo's app hosting your JavaScript. To give your app to a friend, test features that Expo Go does not include, or eventually publish, you need a **build**: a real installable binary with your name, icon and native code.

## The three ways to run your code

| Option | What it is | When to use it |
|---|---|---|
| Expo Go | Expo's app loading your JavaScript | Learning, quick prototypes, apps that only use libraries bundled in Expo Go |
| Development build | Your own app with developer tools built in | Once you add native libraries Expo Go does not include |
| Preview / production build | Your app as users will get it | Testing with others, then the stores |

A **development build** is like your own private Expo Go: it contains exactly the native code your project needs and still connects to `npx expo start` for fast refresh. A **preview build** has no developer tools and behaves like the store version.

## What goes into an app identity

Before building, set these in `app.json` (or `app.config.js`):

```json
{
  "expo": {
    "name": "Study Timer",
    "slug": "study-timer",
    "version": "1.0.0",
    "icon": "./assets/icon.png",
    "ios": { "bundleIdentifier": "com.yourname.studytimer" },
    "android": { "package": "com.yourname.studytimer" }
  }
}
```

The `bundleIdentifier` (iOS) and `package` (Android) are your app's permanent unique ids in reverse-domain form. Choose them carefully: once an app is published they cannot change.

## Worked example: an Android build you can install

**EAS Build** (Expo Application Services) builds your app on Expo's servers, so you do not need Android Studio or a Mac. It has a free plan with a limited number of builds per month; check expo.dev/pricing (checked on 2026-10-23). A free Expo account is enough.

```bash
npm install -g eas-cli
eas login
eas build:configure
```

`eas build:configure` creates `eas.json`. Edit the `preview` profile so Android produces an `.apk` file you can install directly, instead of the `.aab` bundle the Play Store expects:

```json
{
  "build": {
    "preview": {
      "distribution": "internal",
      "android": { "buildType": "apk" }
    }
  }
}
```

Then:

```bash
eas build --platform android --profile preview
```

The build runs in the cloud and finishes with a link and a QR code. Open it on an Android phone, download the APK and install it (Android asks you to allow installs from that source). Your app now has its own icon on the home screen and runs without the development server.

## What about iPhone?

Apple is stricter. To install your own build on an iPhone outside Expo Go you need either:

- a **paid Apple Developer Program membership** ($99 per year; checked on 2026-10-23), which lets EAS create an internal ("ad hoc") build for registered devices, or TestFlight builds for testers; or
- a **Mac with Xcode** and a free Apple ID, which can install a build directly to your own connected iPhone for personal testing, with signing that expires after a few days.

If you have neither, keep using Expo Go on the iPhone; it is a fine way to finish this course. Publishing to Google Play also costs money (a one-off $25; checked on 2026-10-23), and is covered in Mobile App Production.

## Common mistakes

- **Expecting a build to pick up code changes.** A preview build contains the JavaScript from when it was built. Rebuild (or use over-the-air updates, covered later) to change it.
- **Leaving development URLs in the build.** A build cannot reach `localhost` or your laptop. Point API calls at a real HTTPS server, using environment variables for different builds.
- **Committing secrets.** Anything in your JavaScript bundle can be extracted from the app. Never put private API keys in it.
- **Changing the bundle id later.** Pick a stable reverse-domain id before the first release.

## Quick recap

- Expo Go is for learning; development builds add your own native code; preview and production builds are what others install.
- Set the app name, icon, version and bundle ids in `app.json`.
- `eas build --platform android --profile preview` with `buildType: "apk"` gives you an installable Android app on the free plan.
- iPhone installs outside Expo Go need a paid Apple membership or a Mac with Xcode.

## Try it

The Do tab walks you through giving your app an identity and installing a build (Android) or a polished Expo Go version (iPhone).


Give your app an identity and install a real build on your phone.

Ship to your phone

How to create and share internal distribution builds | EAS Tutorial

How to create and run a cloud build for Android | EAS Tutorial

Navigation and state, loading remote data into lists, and installing a build on your phone.