Owns navigation, and the one process per live screen that serves it.

Which stacks exist, which is active, and one Mob.Screen.Server per live screen — this process starts them, stops them, and restarts one that crashes. It keeps the :mob_screen registered name, so the native layer's enif_whereis_pid lookups (back gesture, alert actions, launch notifications) are unaffected.

Not in the per-message path

A screen handling an ordinary message never touches this process. Native events reach a screen directly: Mob.Listener unwraps the envelope and sends to the screen's own pid, the screen renders, and Mob.Sender commits. The router hears only about navigation.

That is the property MOB-113 exists to guarantee, and it is what makes one process per screen affordable. An earlier costing of this design assumed a router in the loop and concluded per-screen processes could not escape a hop per message; splitting the router from the sender is what dissolved that.

Mob.Screen delegates its public API here, so callers keep using Mob.Screen.dispatch/3 and friends.

A navigation entry

%{module:, pid:, params:, ref:}.

params is carried because a restart has to reproduce the screen exactly — one that mounts on %{id: id} cannot come back from %{}.

ref identifies the screen to Mob.Sender, and is unique per screen, not per stack. Every screen is a live process that repaints on any message it receives, including the ones below the top of a stack; keyed by stack, a timer tick in a screen the user cannot see would commit its tree — tap table included — over the screen they can. The sender only commits the tree whose ref is active. The ref survives a restart, because the replacement is the same logical screen.

See decisions/2026-08-28-screen-processes-and-supervision.md.