Anatomy of an app

To build mobile apps, you need a mental model of what an app is made of — its anatomy. A mobile app isn't a single blob of code; it's a structure of screens, components, navigation, state, and connections to data. Understanding these parts and how they fit together gives you the framework to reason about any app you build or use. Let's dissect an app. Let's see what an app is made of.

The parts of an app

THE ANATOMY OF A MOBILE APP — the main parts (concepts that apply across
frameworks):

- SCREENS (views/pages) — the distinct "pages" a user sees (a login screen, a
  home feed, a profile, a settings screen). An app is a set of screens the user
  moves between.

- UI COMPONENTS — the reusable building blocks that make up screens: buttons,
  text, images, lists, inputs, cards, etc. Screens are composed of components
  (often nested + reusable). (Modern frameworks are COMPONENT-based.)

- NAVIGATION — how the user MOVES between screens (tabs, a stack of screens with
  back, a drawer/menu, modals). The structure connecting the screens (a whole
  lesson later).

- STATE + DATA — the app's data + what's currently happening: user input, fetched
  data, whether you're logged in, loading/error states, UI state. STATE DRIVES
  THE UI (a whole lesson) — the UI reflects the current state.

- LOGIC — the code that responds to user actions, processes data, + decides what
  happens (event handlers, business logic).

- DATA LAYER / BACKEND CONNECTION — most apps talk to a SERVER/API for data
  (fetching + saving), plus LOCAL storage on the device (a later lesson).

- PLATFORM APIS / DEVICE FEATURES — access to camera, GPS/location, notifications,
  storage, sensors, etc. (via the framework).

- ASSETS — images, icons, fonts bundled with the app.

The anatomy of a mobile app (concepts that apply across frameworks): screens (views/pages — the distinct "pages" a user sees: a login screen, a home feed, a profile, settings — an app is a set of screens the user moves between), UI components (the reusable building blocks of screens — buttons, text, images, lists, inputs, cards — screens are composed of components, often nested and reusable; modern frameworks are component-based), navigation (how the user moves between screens — tabs, a stack with back, a drawer, modals — the structure connecting the screens), state + data (the app's data and current situation — user input, fetched data, logged-in status, loading/error states — state drives the UI: the UI reflects the current state), logic (the code that responds to actions, processes data, and decides what happens — event handlers, business logic), data layer/backend connection (most apps talk to a server/API for data — fetching + saving — plus local storage on the device), platform APIs/device features (access to camera, GPS, notifications, storage, sensors via the framework), and assets (images, icons, fonts bundled with the app).

How the parts fit together

HOW THE PARTS WORK TOGETHER (the app's architecture, simplified):

  App
   └─ Navigation (connects screens)
       ├─ Screen (composed of Components)
       │    ├─ reads STATE -> renders the UI
       │    ├─ user interacts -> triggers LOGIC (event handlers)
       │    └─ LOGIC updates STATE and/or calls the BACKEND/API
       └─ ... more screens

THE CORE LOOP:
- The UI (screens + components) DISPLAYS the current STATE.
- The user INTERACTS (taps, types) -> triggers LOGIC.
- LOGIC updates STATE (and/or fetches/saves data via the backend).
- The changed STATE -> the UI RE-RENDERS to reflect it.
(This "state drives UI, interactions change state, UI updates" loop is the heart
of modern app frameworks — a whole lesson later.)

COMPONENT-BASED THINKING:
- Build UIs from small, REUSABLE components, composed into screens. (Same idea as
  modern web frameworks like React.)
- Keep components focused; reuse them; pass data in + events out.

GOOD ARCHITECTURE (why it matters):
- SEPARATE concerns: UI (components/screens), state/logic, and data (API/storage)
  should be organised, not tangled together. This makes apps maintainable +
  scalable.
- Keep it organised from the start; a well-structured app is far easier to build
  + change than a tangled one.

Understanding this anatomy lets you REASON about apps: where does this data live?
which screen? what state drives this? how do I navigate here?

How the parts fit together (the app's architecture, simplified): an App contains Navigation (connecting Screens, each composed of Components), where a screen reads state → renders the UI, the user interacts → triggers logic (event handlers), and logic updates state and/or calls the backend/API. The core loop: the UI displays the current state; the user interacts → triggers logic; logic updates state (and/or fetches/saves data); the changed state → the UI re-renders to reflect it. (This "state drives UI, interactions change state, UI updates" loop is the heart of modern frameworks — a whole lesson later.) Component-based thinking: build UIs from small, reusable components composed into screens (the same idea as web frameworks like React) — keep components focused, reuse them, pass data in and events out. Good architecture matters because you should separate concerns — UI (components/screens), state/logic, and data (API/storage) should be organised, not tangled (this makes apps maintainable and scalable) — keep it organised from the start (a well-structured app is far easier to build and change). Understanding this anatomy lets you reason about apps: where does this data live? which screen? what state drives this? how do I navigate here?

The mistake beginners make

The mental-model mistake is not having a clear mental model of an app's parts — treating an app as mysterious or a single blob, so you can't reason about where things go (which screen? what state? how to navigate? where does data live?). Understand the anatomy (screens, components, navigation, state, logic, data) — it's the framework for building and debugging. The second mistake is tangling everything together (poor architecture) — mixing UI, logic, and data-fetching all in one place, producing a tangled mess that's hard to maintain, change, or scale. Separate concerns (UI vs state/logic vs data) and use reusable components — organise from the start. The third mistake is not thinking in components — building monolithic screens instead of composing them from small, reusable components, missing the reuse and clarity that component-based frameworks provide. Think in components (focused, reusable, data-in/events-out). And not understanding the state-driven loop (which the next lessons build on). Build a clear mental model of the app's anatomy, separate concerns (avoid tangling), think in reusable components, and grasp the state-driven UI loop.

Your turn

---

Your turn

1. Learn the parts: identify the main parts of a mobile app — screens (pages), UI components (reusable building blocks), navigation (moving between screens), state + data, logic, backend/data layer, platform APIs, and assets.
2. Trace the core loop: understand that the UI displays the current STATE, user interactions trigger LOGIC, logic updates STATE (and/or calls the backend), and the changed state re-renders the UI.
3. Think in components: recognise that screens are composed of small, reusable components (buttons, lists, cards) — the same component-based idea as modern web frameworks like React.
4. Sketch an app's anatomy: pick an app you use and map its screens, the navigation between them, and roughly what state/data drives each screen — practising reasoning about app structure.
5. Value good architecture: understand why separating concerns (UI vs state/logic vs data) and organising from the start makes an app maintainable and scalable versus a tangled mess.

Key points

• A mobile app's anatomy (across frameworks): screens (pages the user sees), UI components (reusable building blocks — screens are composed of them), navigation (how the user moves between screens), state + data, logic (responds to actions/processes data), a data layer/backend connection, platform APIs (camera/GPS/notifications), and assets.
• The core loop: the UI displays the current STATE -> the user interacts -> triggers LOGIC -> logic updates STATE (and/or calls the backend) -> the changed state re-renders the UI (the heart of modern frameworks — 'state drives the UI').
• Think in components: build UIs from small, focused, reusable components composed into screens (data in, events out) — the same idea as web frameworks like React.
• Good architecture SEPARATES concerns (UI/components vs state/logic vs data/API/storage) and stays organised from the start — making apps maintainable + scalable rather than a tangled mess.
• The mistakes: no clear mental model of the parts (can't reason about where things go), tangling everything together (poor architecture — separate concerns), not thinking in components (monolithic screens), and not understanding the state-driven loop.