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