Don't Panic — Mobile Application Architecture

A mobile app is a guest in somebody else's operating system. The host controls the process, screens, memory, background time, and occasionally the timing of its exit. Architecture is the arrangement that keeps the app intelligible when that hospitality becomes brief: it assigns state, effects, and platform work to owners with lifetimes that match the job.

The useful picture is a loop, not a stack of fashionable folders. An event arrives from a tap or the system. A state holder turns it into a transition or sends it toward a rule. New immutable UI state comes back for the view to render. State travels toward the screen; events travel toward whoever is allowed to change the state. This stops two screens from quietly becoming rival historians.

Data deserves an adult in the room. A repository presents one contract while it coordinates storage, network services, or a device source. It is where cache choice, retry, conflict, and write policy belong. The view is allowed to show a pending save and forward Retry. It is not appointed chief negotiator with the network merely because it has a button nearby.

The phrase source of truth sounds grander than its job. It means that one owner is authoritative for one kind of data. A local database can hold the copy higher layers read, while a server remains authoritative for shared account data. Once connectivity, queued writes, and conflicts appear, success is no longer one cheerful moment. It is a series of states: pending, syncing, saved, failed, or conflicted.

The operating system adds its own plot twists. Lifecycle means a screen can be recreated and the process can disappear before a request finishes. Durable drafts belong in persistent storage, not in a view's private memory. Background work is a scheduled opportunity with limits, not a permanent worker wearing a tiny hard hat. The architecture must say what survives, what retries, and what the screen can honestly report.

Shared code changes the boundary; it does not make platform behavior evaporate. Adapters keep permissions, background execution, accessibility, signing, and delivery differences at the edge of shared policy. Native and cross-platform choices are therefore trade-offs about where code lives and how much platform-specific behavior remains visible, not a referendum on whether one framework is morally superior.

Read the intro when the full event-and-state loop needs a careful map. Use the slides to compare ownership, lifetime, patterns, and sharing boundaries at a glance. Keep the cheatsheet close when reviewing a write policy or tracing a failure. Then use the exercise to make one draft save survive an offline interruption. That is where the folders stop posing and start answering questions.