An intermediate course for learners who already know React and want to build mobile apps. You will compare native and cross-platform development, set up Expo and run your code on your own phone with the free Expo Go app, and learn how React Native's View, Text, Pressable and StyleSheet replace HTML and CSS. The second module covers stack and tab navigation, where state should live, loading remote data into a FlatList with proper loading and error states, and installing a real build on your phone. The last module covers mobile UX (touch targets, thumb reach, safe areas, the keyboard), storing data on the device with an offline outbox queue, and asking for device permissions with a fallback when the user says no. Every lesson has a reading, free videos and a quiz; the JavaScript exercises run in your browser, and the hands-on steps use your own computer and phone. Running apps in Expo Go is free; publishing to the stores needs paid developer accounts (Apple $99 per year, Google Play $25 one-off; checked on 2026-10-23). Prerequisite: React Fundamentals.

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

Mobile Development Basics

## Why this choice matters

Before you write a line of mobile code, someone on the team decides how the app will be built. That decision shapes which languages you need, how many codebases you maintain, how fast features ship and how the app feels in the hand. As a mobile developer you will be asked to explain the trade-offs, so it pays to understand them clearly rather than repeat opinions from the internet.

There are three broad options:

1. **Native**: one app per platform, written with the platform's own tools. iOS apps use Swift (older code uses Objective-C) and Apple's SwiftUI or UIKit in Xcode. Android apps use Kotlin (older code uses Java) with Jetpack Compose or Android Views in Android Studio.
2. **Cross-platform**: one codebase that produces apps for both platforms. The two big frameworks are **React Native** (JavaScript or TypeScript, React components) and **Flutter** (the Dart language, its own widget toolkit). Kotlin Multiplatform is a newer option that shares business logic in Kotlin while each platform keeps its own UI.
3. **Web-based**: a mobile website or a Progressive Web App (PWA), sometimes wrapped in a thin native shell. Cheapest to build, but with the most limited access to device features and store distribution.

## How React Native works

This course uses React Native because you already know React. In React Native you still write components, props, state and hooks, but instead of rendering HTML elements you render **native views**. A `<View>` becomes a real `UIView` on iOS and an `android.view.View` on Android; a `<Text>` becomes a native text view. Your JavaScript runs in a JavaScript engine (Hermes by default) inside the app, and React Native's renderer turns your component tree into the platform's own UI widgets.

That is the key difference from a web view: the buttons, scrolling and text input are the platform's real controls, so they behave the way users expect. Since React Native 0.76 the "New Architecture" is the default: JavaScript talks to native code through JSI (a direct C++ interface) instead of the old asynchronous "bridge", which makes calls into native code faster.

Flutter takes a different route. It does not use the platform's widgets at all; it draws every pixel itself with its own rendering engine. That gives very consistent visuals across platforms, at the cost of re-implementing platform look and feel.

## Comparing the options

| Concern | Native (Swift / Kotlin) | React Native | Flutter |
|---|---|---|---|
| Codebases | Two | One (plus small native parts) | One |
| Language | Swift, Kotlin | JavaScript / TypeScript | Dart |
| UI controls | Platform's own | Platform's own, via React | Drawn by Flutter |
| New OS features | Available on day one | Usually needs a library update | Usually needs a plugin update |
| Team fit | Separate iOS and Android skills | Web and React developers | Teams willing to learn Dart |

A worked example makes this concrete. Imagine a small team building a booking app for a gym: class lists, sign-in, push reminders and payments. They have two web developers who know React. A cross-platform framework lets them ship to both stores with one codebase, and React Native lets them reuse their React knowledge, so React Native is a sensible choice.

Now imagine a different team building a professional photo editor that uses the newest camera APIs, custom GPU filters and Apple Pencil pressure on iPad. Here the app lives on platform-specific features and heavy graphics, and the team would likely go native, at least for the editing screens.

Most real decisions are not all-or-nothing. Many React Native apps contain some native modules written in Swift or Kotlin, and many native apps embed a few web views for help pages. You will meet "when to go native" again in Mobile App Production.

## Common mistakes

- **"Cross-platform means write once, run everywhere with no extra work."** You still test on both platforms, handle platform differences (back button on Android, gestures on iOS, permission dialogs) and sometimes write platform-specific code with `Platform.OS`.
- **"Cross-platform apps are always slow."** For typical business apps (lists, forms, navigation) a well-built React Native or Flutter app feels native. Performance problems usually come from how the app is written, such as rendering huge lists badly, not from the framework itself.
- **Choosing a stack by hype.** Choose by the team's skills, the features the app needs and how long it must be maintained.
- **Forgetting the web.** If users only need to read content once in a while, a responsive website may be enough and skips store review entirely.

## Quick recap

- Native means one app per platform in Swift or Kotlin: the most direct access to the platform, at the cost of two codebases.
- React Native renders real native views from React components written in JavaScript; Flutter draws its own UI with Dart.
- Pick based on team skills, required device features, performance needs and long-term maintenance.
- Real apps often mix approaches: cross-platform for most screens, native modules where needed.

## Try it

Open the Do tab and take the quiz to check that you can explain the trade-offs to a teammate.


Compare native, cross-platform and web approaches and explain when each one fits.

Native vs cross-platform

React Native in 100 Seconds

React Native vs Flutter - I built the same chat app with both

Install the current Node.js LTS from nodejs.org and check it with `node --version`.

Install Expo Go on your phone from the App Store or Google Play. No phone? Install Android Studio and create an Android emulator instead.

Run `npx create-expo-app@latest my-first-app`, then `cd my-first-app`.

Run `npx expo start` and scan the QR code (Expo Go on Android, the Camera app on iOS). If it cannot connect, restart with `npx expo start --tunnel`.

Open the home screen file in the `app/` folder, change a line of text and save. Watch the phone update.

Introduce a deliberate error (delete a closing tag), save, and read the red error screen. Then fix it.

Press `j` in the terminal to open the debugger and find your component in the tools.

## Why setup matters

The first hour with a new platform decides whether you keep going. Mobile setup has a reputation for pain: SDKs, emulators, signing certificates. The good news is that you do not need any of that to start. With **Expo**, a free, open-source framework and toolset around React Native, you can run your own code on your own phone in a few minutes. You will add the heavier tools (Android Studio, Xcode) later, only when you need them.

## The pieces

- **Node.js** (an LTS release) runs the development tools on your computer.
- **create-expo-app** generates a new project with sensible defaults.
- **The Expo CLI** (`npx expo start`) runs the development server (Metro), which bundles your JavaScript and serves it to the phone.
- **Expo Go** is a free app from the App Store and Google Play. It loads your project from the development server, so you do not need to build or sign anything to try your code.
- Optional: **Android Studio** gives you an Android emulator on Windows, macOS or Linux. **Xcode** (macOS only) gives you the iOS Simulator. Neither is required for this lesson.

You do **not** need a paid developer account to run apps in Expo Go. Store accounts only matter when you publish, and they cost money: the Apple Developer Program is $99 per year and a Google Play developer account is a one-off $25 fee. Checked on 2026-10-23. Prices change, so check apple.com/developer and play.google.com/console before you pay.

## Worked example: your first project

In a terminal:

```bash
node --version            # should print an LTS version, e.g. v22.x
npx create-expo-app@latest my-first-app
cd my-first-app
npx expo start
```

The last command prints a QR code and a menu. On Android, open Expo Go and scan the code. On iOS, scan it with the Camera app, which hands it to Expo Go. Your phone and computer must be on the same Wi-Fi network. If they cannot see each other (school or office networks often block this), stop the server and run `npx expo start --tunnel` instead.

The default template uses **Expo Router**, which turns files in the `app/` folder into screens. Open `app/(tabs)/index.tsx` (the name may differ slightly between template versions), change some text and save. The app on your phone reloads within a second or two. This is **Fast Refresh**, and it keeps component state where it can.

A tiny screen of your own looks like this:

```javascript
import { View, Text } from "react-native";

export default function HomeScreen() {
  return (
    <View style={{ flex: 1, alignItems: "center", justifyContent: "center" }}>
      <Text>Hello from my phone</Text>
    </View>
  );
}
```

## Useful commands in the Expo CLI

While `npx expo start` runs, press:

- `r` to reload the app,
- `j` to open the JavaScript debugger,
- `m` to open the developer menu on the device (you can also shake the phone),
- `a` to open an Android emulator, or `i` for the iOS Simulator, if you installed them.

Errors appear both in the terminal and as a red screen on the phone. Read the first line of the error and the file name it points to; that usually tells you exactly what broke.

## Common mistakes

- **Phone and computer on different networks.** The QR code points at your computer's local address. Use the same Wi-Fi or `--tunnel`.
- **Old Node.js.** Very old versions fail with confusing errors. Install the current LTS from nodejs.org.
- **SDK mismatch.** Expo Go from the stores supports the newest Expo SDK. If you open an older project, Expo Go may say it is incompatible; create a fresh project or upgrade the project's SDK.
- **Installing packages with plain npm when Expo expects specific versions.** Use `npx expo install <package>`, which picks versions that match your SDK.
- **Editing the wrong file.** With Expo Router, the screen you see comes from the `app/` folder; components elsewhere only show up if a screen imports them.

## Quick recap

- Expo lets you run React Native code on a real phone without building or signing anything.
- `npx create-expo-app@latest`, then `npx expo start`, then scan the QR code with Expo Go.
- Fast Refresh reloads your changes almost instantly.
- Emulators and simulators are optional; store accounts cost money and are only needed to publish.

## Try it

The Do tab walks you through creating a project and running it on your own phone (or an emulator if you do not have one).


Create an Expo project and run it on your own phone with Expo Go.

Setting up your environment

How to create your first Expo app | Universal App tutorial #1

Expo in 100 Seconds

## Why it matters

You already know React for the web, where JSX becomes HTML: `<div>`, `<p>`, `<button>`. React Native uses exactly the same JSX syntax, components, props and hooks, but there is **no HTML and no CSS** on a phone. Your JSX must use React Native's components, and styles are JavaScript objects. Knowing the mapping saves you an afternoon of "why is nothing rendering?".

## The core components

| Web habit | React Native | Notes |
|---|---|---|
| `<div>`, `<section>` | `<View>` | A box for layout. It cannot hold raw text. |
| `<p>`, `<span>`, `<h1>` | `<Text>` | **All** text must be inside `<Text>`. |
| `<img>` | `<Image>` | Needs a `source` and usually a width and height. |
| `<button>`, clickable `<div>` | `<Pressable>` (or `<Button>`) | `onPress`, not `onClick`. |
| `<input>` | `<TextInput>` | `onChangeText` gives you the string directly. |
| page scrolling | `<ScrollView>` or `<FlatList>` | Views do not scroll by themselves. |

The most common error for web developers is putting text straight into a `View`:

```javascript
// Crashes with "Text strings must be rendered within a <Text> component"
<View>Hello</View>

// Correct
<View>
  <Text>Hello</Text>
</View>
```

## Styling with StyleSheet

Styles are plain objects with camelCase property names, and numbers are density-independent pixels (no `px`):

```javascript
import { StyleSheet, View, Text, Pressable } from "react-native";

export default function Card({ title, done, onToggle }) {
  return (
    <View style={styles.card}>
      <Text style={[styles.title, done && styles.done]}>{title}</Text>
      <Pressable onPress={onToggle} style={styles.button}>
        <Text style={styles.buttonText}>{done ? "Undo" : "Done"}</Text>
      </Pressable>
    </View>
  );
}

const styles = StyleSheet.create({
  card: { padding: 16, borderRadius: 12, backgroundColor: "#fff", flexDirection: "row", alignItems: "center" },
  title: { flex: 1, fontSize: 18 },
  done: { textDecorationLine: "line-through", color: "#666" },
  button: { paddingVertical: 8, paddingHorizontal: 12, borderRadius: 8, backgroundColor: "#2563eb" },
  buttonText: { color: "#fff", fontWeight: "600" },
});
```

Three things to notice:

1. **Style arrays.** `style={[styles.title, done && styles.done]}` combines styles. Later entries win, and falsy entries (`false`, `null`, `undefined`) are ignored. That is how you apply conditional styles without string class names.
2. **Flexbox by default.** Every `View` is a flex container, and the default `flexDirection` is `column` (on the web it is `row`). `flex: 1` makes a child fill the remaining space.
3. **No cascade.** Styles do not inherit from parents, except that nested `<Text>` inherits text styles from an outer `<Text>`. You cannot set a font on a `View` and expect the text inside to use it.

`StyleSheet.create` mostly helps by keeping styles in one place and validating property names in development. React Native also exports `StyleSheet.flatten`, which merges a style array into one object; it is handy for tests and for reading the final value of a style.

## Worked example: merging styles by hand

To understand how style arrays work, imagine writing the merge yourself. Given `[base, isActive && active, { opacity: 0.5 }]`, you walk the array left to right, skip falsy entries, flatten nested arrays and copy each object's properties over the result:

```javascript
function merge(style) {
  if (!style) return {};
  if (Array.isArray(style)) {
    return style.reduce((acc, s) => Object.assign(acc, merge(s)), {});
  }
  return { ...style };
}
```

That small function is the whole idea behind `StyleSheet.flatten`. You will write your own version in the Do tab.

## Common mistakes

- Raw text in a `View`, or a string with a stray space between components. Wrap it in `<Text>`.
- Units in strings: `padding: "16px"` is invalid. Use numbers (`16`) or percentages as strings (`"50%"`).
- Expecting `onClick`. Use `onPress` on `Pressable`.
- Expecting the page to scroll. Wrap long content in `ScrollView`, and use `FlatList` for long lists.
- Expecting CSS inheritance. Set text styles on the `Text` itself (or a parent `Text`).

## Quick recap

- Use `View` for boxes, `Text` for every piece of text, `Pressable` for touches, `TextInput` for typing and `Image` for pictures.
- Styles are objects; combine them with arrays where later entries win and falsy ones are ignored.
- Layout is Flexbox with `column` as the default direction.

## Try it

In the Do tab you will write two helpers: one that maps an HTML tag to the React Native component you would use, and one that flattens a style array exactly like `StyleSheet.flatten`. The exercise is plain JavaScript (no JSX), so it runs in your browser.


Build screens with View, Text, Pressable and StyleSheet instead of HTML and CSS.

JSX without HTML

React Native Tutorial - 7 - Core Components

React Native Tutorial - 20 - StyleSheet API

Native versus cross-platform, your Expo setup, and building screens with View, Text and StyleSheet.

React Native Tour

## 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.

Your First Real App

## Why it matters

A phone is used with a thumb, often with one hand, on a bus, in sunlight, with notifications popping in. A layout that looks fine in a desktop browser can be frustrating on a phone: buttons too small to hit, text hidden under the notch, a keyboard covering the field you are typing in. Mobile UX is a set of small, concrete rules that make an app comfortable to use, and most of them are easy to check.

## Touch targets

A fingertip is much less precise than a mouse pointer. Platform guidelines set minimum sizes for anything tappable:

- **Apple Human Interface Guidelines:** at least **44 x 44 points**.
- **Material Design (Android):** at least **48 x 48 dp**.
- **WCAG 2.2** (the web accessibility standard, often applied to apps too): 2.5.8 asks for at least 24 x 24 CSS pixels or enough spacing (level AA); 2.5.5 recommends 44 x 44 (level AAA).

The visible icon can be smaller than the target. In React Native, `hitSlop` extends the touchable area without changing the layout:

```javascript
<Pressable
  onPress={onClose}
  hitSlop={12}                 // adds 12 points on every side
  accessibilityRole="button"
  accessibilityLabel="Close"
>
  <CloseIcon size={20} />      {/* 20 + 12 + 12 = 44 points */}
</Pressable>
```

Keep targets apart too: two small icons side by side invite mis-taps. Give important actions more room.

## Thumb zones and layout

On a large phone the bottom-middle of the screen is easy to reach with one thumb and the top corners are hard. That is why primary actions often live in a bottom tab bar or a full-width button at the bottom, while rare or destructive actions (delete, sign out) sit further away. Put the thing users do most where the thumb already is.

## Safe areas

Modern phones have notches, camera cut-outs, rounded corners, a status bar and a home indicator. The **safe area** is the part of the screen that none of these cover. Content outside it can be clipped or hard to tap.

Use `react-native-safe-area-context` (included with Expo templates):

```javascript
import { SafeAreaProvider, SafeAreaView, useSafeAreaInsets } from "react-native-safe-area-context";

export default function App() {
  return (
    <SafeAreaProvider>
      <SafeAreaView style={{ flex: 1 }} edges={["top", "bottom"]}>
        <Home />
      </SafeAreaView>
    </SafeAreaProvider>
  );
}

function Footer() {
  const insets = useSafeAreaInsets();
  return <View style={{ paddingBottom: 16 + insets.bottom }}>{/* buttons */}</View>;
}
```

React Native also has a built-in `SafeAreaView`, but it only works on iOS and is deprecated in recent versions, so prefer the library. Navigation libraries already pad their headers and tab bars; you mainly need insets for custom headers, footers and full-screen layouts.

## The keyboard

When a text field is focused, the on-screen keyboard covers roughly the bottom half of the screen. Make sure the field and its submit button stay visible:

- wrap forms in `KeyboardAvoidingView` (with `behavior="padding"` on iOS) or put them in a `ScrollView` with `keyboardShouldPersistTaps="handled"`, so a tap on a button is not swallowed by the keyboard dismiss,
- set `keyboardType` (`"email-address"`, `"numeric"`, `"phone-pad"`), `autoComplete` and `textContentType` so the right keyboard and autofill appear,
- use `returnKeyType="next"` to move between fields.

## Feedback and platform conventions

Every tap should respond immediately: a pressed state (`Pressable` gives you `pressed` in its style function), a spinner for slow actions, and a message when something fails. Respect each platform's habits: Android users expect the system back button to work everywhere; iOS users expect to swipe back from the left edge. Support Dynamic Type and font scaling: `Text` scales with the user's font size setting by default, so test your layouts at a large size instead of turning scaling off.

## Worked example: reviewing a screen

A sign-in screen has a 24-point "X" close icon in the top-right corner, email and password fields, and a small "Sign in" text link under the fields. Applying the rules:

1. The close icon is only 24 points: add `hitSlop={10}` to reach 44.
2. The top-right corner is hard to reach on a big phone, which is fine for a rare action like close.
3. "Sign in" is the main action but is a small link: make it a full-width button near the bottom, padded by the bottom safe-area inset.
4. The email field shows the default keyboard: set `keyboardType="email-address"` and `autoComplete="email"`.
5. When the keyboard opens, the button disappears: wrap the form in `KeyboardAvoidingView`.

## Common mistakes

- Tiny icon buttons with no `hitSlop`.
- Content under the notch or home indicator because no safe-area padding was applied.
- Forms the keyboard hides.
- Disabling font scaling (`allowFontScaling={false}`) instead of fixing the layout.
- No pressed state, so users tap twice.

## Quick recap

- Touch targets: 44 pt (Apple) or 48 dp (Android); use `hitSlop` for small icons.
- Put frequent actions within thumb reach.
- Respect safe areas with `react-native-safe-area-context`.
- Keep inputs visible above the keyboard and choose the right keyboard type.

## Try it

Take the quiz in the Do tab, then open any app on your phone and look for one target that is too small.


Apply touch-target sizes, thumb reach, safe areas and keyboard handling to a real screen.

Mobile UX patterns

Touch targets - Accessibility on Android

Complete React Native Tutorial #11 - Safe Area View

## Why it matters

Phones lose connectivity all the time: lifts, tunnels, flights, patchy rural signal. Users also expect an app to remember things: their settings, the draft they were writing, the list they downloaded yesterday. An app that forgets everything on restart, or shows a spinner forever offline, feels broken. Local storage and a little offline thinking fix both.

## Your storage options

| Option | Good for | Notes |
|---|---|---|
| `@react-native-async-storage/async-storage` | Small key-value data: settings, flags, small caches, drafts | Asynchronous, strings only, **not encrypted** |
| `expo-sqlite` | Larger structured data you query | Real SQL database on the device |
| `expo-secure-store` | Secrets: tokens, credentials | Uses the iOS Keychain and Android Keystore; small values only |
| `expo-file-system` | Files: downloads, images | Paths inside the app's sandbox |

Rule of thumb: settings and small JSON go in AsyncStorage, lots of rows go in SQLite, and anything secret goes in SecureStore. Never put tokens or passwords in AsyncStorage.

## Worked example: remembering settings

AsyncStorage stores strings, so you serialize with JSON and always guard the parse:

```javascript
import AsyncStorage from "@react-native-async-storage/async-storage";

const KEY = "settings:v1";
const DEFAULTS = { theme: "system", reminders: true };

export async function loadSettings() {
  try {
    const raw = await AsyncStorage.getItem(KEY);
    return raw ? { ...DEFAULTS, ...JSON.parse(raw) } : DEFAULTS;
  } catch {
    return DEFAULTS;              // corrupt or unreadable: fall back, do not crash
  }
}

export async function saveSettings(settings) {
  await AsyncStorage.setItem(KEY, JSON.stringify(settings));
}
```

Three habits are visible here. The key has a **version** (`v1`) so a future format change can migrate cleanly. Loading **merges over defaults**, so a new setting added in a later release still has a value. And a bad value **falls back** rather than crashing the app on launch, which would be impossible for the user to fix.

Install it with `npx expo install @react-native-async-storage/async-storage`. It works in Expo Go.

## Offline first, in one idea

"Offline first" means the app reads from and writes to the device first, and syncs with the server when it can. For reading, show cached data immediately and refresh in the background (you will build this properly in Mobile App Production). For writing, use an **outbox queue**:

1. When the user does something (adds a note, likes a post), update the UI at once and add an action to a queue saved in storage.
2. When the network is available, send queued actions **in order**.
3. Remove an action only after the server confirms it. If one fails, stop and try again later, so later actions do not overtake earlier ones.

```text
queue: [add "Buy milk", add "Call Sam", delete "Old note"]
send #1 ok  -> remove
send #2 fails (offline) -> stop; queue is now [add "Call Sam", delete "Old note"]
```

The `@react-native-community/netinfo` library tells you when connectivity changes, so you can flush the queue when it comes back. Give each action an id, so if a response is lost and you send it twice, the server can recognise the duplicate.

## Common mistakes

- **Storing secrets in AsyncStorage.** It is plain text on the device. Use SecureStore.
- **Unguarded `JSON.parse`.** One corrupt value crashes the app at startup forever.
- **Saving on every keystroke.** Debounce saves, or save when the screen loses focus.
- **Dropping failed actions.** If a send fails, keep the action and retry; users assume what they saw on screen was saved.
- **Treating "connected to Wi-Fi" as "online".** A captive portal or a down server still fails. Handle request errors even when NetInfo says you are connected.

## Quick recap

- AsyncStorage for small key-value data (strings, JSON), SQLite for lots of structured data, SecureStore for secrets.
- Version your keys, merge over defaults and guard every parse.
- Offline writes go into an ordered outbox queue that is flushed when the network returns and only shrinks on success.

## Try it

In the Do tab you will build the outbox: `enqueue`, `flushQueue` and safe `parseQueue`, as pure functions you can test without a phone.


Persist data on the device and queue changes so the app keeps working offline.

Storage and offline

Asyncstorage React Native | Async Storage Tutorial

Local-first vs Offline-first in 100 Seconds

In your Expo project run `npx expo install expo-camera` and add the `expo-camera` plugin with a clear `cameraPermission` message to `app.json`.

Create a screen that uses `useCameraPermissions()` and shows a short explanation plus an "Allow camera" button before calling `requestPermission`.

When permission is granted, render `<CameraView style={{ flex: 1 }} />` and check the preview on your phone.

Add a fallback button ("Enter details by hand" or a photo picker with `expo-image-picker`) that works without camera permission.

When `permission.canAskAgain` is false, show an "Open Settings" button that calls `Linking.openSettings()`.

Test the denied path: in your phone's Settings, turn off camera access for Expo Go (or your build), reopen the screen and confirm the fallback and Settings button appear.

Turn camera access back on in Settings and confirm the screen recovers when you return to it.

## Why it matters

Cameras, location, contacts, notifications and the photo library make mobile apps powerful, and they are also private. Both iOS and Android make apps **ask permission** before using them, and users can say no, or say yes and change their mind later in Settings. An app that crashes, nags or dead-ends when permission is denied gets uninstalled and earns bad reviews. Good apps ask at the right moment, explain why, and keep working without the permission.

## How permissions work

- You **declare** what you might use. On iOS each permission needs a usage description string (for example `NSCameraUsageDescription`) shown in the system dialog; on Android permissions are listed in the manifest. With Expo you set these in `app.json`, usually through a library's config plugin.
- At runtime you **check** the current status and **request** it. The system shows its own dialog; you cannot change its wording, but you control when it appears.
- The result can be **granted**, **denied**, or (on iOS for photos and location) **limited** or **approximate**. If the user denies and the system will not ask again (`canAskAgain` is false), only the Settings app can change it.
- Ask **in context**: request the camera when the user taps "Scan receipt", not on first launch. Many teams show a short explanation screen first ("We use the camera to scan receipts. Nothing is uploaded without your OK.") and then trigger the system prompt.

## Worked example: camera with a fallback

`expo-camera` gives you a hook that returns the current permission and a function to request it:

```javascript
import { CameraView, useCameraPermissions } from "expo-camera";
import { Linking, Pressable, Text, View } from "react-native";

export default function ScanScreen({ onPickFromLibrary }) {
  const [permission, requestPermission] = useCameraPermissions();

  if (!permission) return null;                      // still loading the status

  if (!permission.granted) {
    return (
      <View>
        <Text>We use the camera to scan receipts. Photos stay on your phone.</Text>
        {permission.canAskAgain ? (
          <Pressable onPress={requestPermission}><Text>Allow camera</Text></Pressable>
        ) : (
          <Pressable onPress={() => Linking.openSettings()}><Text>Open Settings</Text></Pressable>
        )}
        <Pressable onPress={onPickFromLibrary}><Text>Choose a photo instead</Text></Pressable>
      </View>
    );
  }

  return <CameraView style={{ flex: 1 }} facing="back" />;
}
```

And the matching declaration in `app.json`:

```json
{
  "expo": {
    "plugins": [
      ["expo-camera", { "cameraPermission": "Allow $(PRODUCT_NAME) to use the camera to scan receipts." }]
    ]
  }
}
```

The fallback is the important part. Denied users can still pick a photo from the library (which, with the system photo picker, often needs no permission at all) or type the details by hand. The feature degrades; the app does not break.

In Expo Go the permission prompt names Expo Go rather than your app, because Expo Go is the app on the phone. In your own build it names your app and uses your description.

## Other device APIs, same pattern

- **Location** (`expo-location`): ask for "while using the app" first; background location needs a strong reason and extra store review.
- **Notifications** (`expo-notifications`): ask after the user has seen value, for example after they create their first reminder.
- **Photos** (`expo-image-picker`): the picker lets users choose specific photos, often without full library access.
- **Haptics, sharing, clipboard**: usually no permission needed.

## Common mistakes

- **Asking for everything at first launch.** Users deny permissions they do not understand.
- **No usage description on iOS.** Store review rejects it, and the app can crash when it requests the permission.
- **Dead ends after denial.** Always offer a fallback or a way to Settings.
- **Assuming granted stays granted.** Users can revoke permissions at any time; check status each time the feature opens.
- **Collecting more than you need.** Approximate location is often enough; privacy labels in the stores must list what you collect.

## Quick recap

- Declare permissions (usage strings, manifest entries) and request them at runtime, in context.
- Handle granted, denied and "cannot ask again"; offer `Linking.openSettings()` and a fallback path.
- The same pattern covers camera, location, notifications and photos.

## Try it

The Do tab has you add a camera feature to your app with a proper explanation, a denial fallback and a Settings link, then test all three paths on your phone.


Request a device permission in context and keep the app useful when the user says no.

Device APIs and permissions

Permissions in React Native for absolute beginners

Touch-friendly layouts, local storage and offline queues, and device permissions with fallbacks.

Mobile Development Basics

About this course

Course content

React Native Tour

Your First Real App

Mobile UX and Device Features

Where this course leads

Next course on the path

Careers that use it