Interruption
The session can end at any instant without warning, so state has to be safe continuously.
The Phone Is Not a Console
A desktop game or a console title has a contract with its player: sit down, stay awhile. The phone has no such contract. A call arrives. A train door opens. A child falls over. The session can end in the middle of a tap, mid-animation, between the moment a reward is granted and the moment it is acknowledged. No warning, no grace period, no save prompt.
This is not an edge case. Research into how people actually use their phones in public, such as Steven Hoober's work on how they hold and touch them, suggests that mobile sessions are routinely fractured — started, dropped, resumed — in ways that bear almost no resemblance to dedicated computing sessions. The phone lives in a context that interrupts it constantly, which means every state transition in a mobile game is potentially the last one.
State has to be safe at every instant, because the session can end mid-move.
Photo: JÉSHOOTS / Pexels
The implication is architectural. State has to be safe not at the end of a round, not on exit, but continuously. Every action that matters — a level completed, a resource earned, a timer started — must be committed to persistent storage the moment it happens, not batched to a save slot later. Games that fail this lose real progress, and players who lose real progress tend not to come back.
What Has to Survive
There are at least three categories of state that must survive interruption cleanly.
The session can end at any instant, so the design that assumes otherwise loses the player every time.
Lifted out of the flow
Progress state is the obvious one: which level, how far through it, what was earned. Losing a completed level because a call came in before the results screen fully loaded is the kind of friction that appears clearly in retention curves — early-day drop-off that looks like boredom but is actually punishment.
Timer state is less obvious and more treacherous. Any mechanic that runs on real-world time — a cooldown, a regenerating life, a crop growing — continues to run while the app is not in the foreground.
Nothing destructive belongs where a thumb rests as the phone is put away.
Photo: Brett Jordan / Pexels
When the player returns, the timer must reflect real elapsed time, not the time the app was active. Get this wrong and a player who waited two hours for a building to finish discovers it has not finished because the clock only ran while they were looking at it. That is a trust failure.
Session context — where in the UI the player was, what was mid-flight — matters more subtly. A well-designed return drops the player back into an orientation they can read immediately, without requiring them to reconstruct where they were. Resumption is its own discipline, but it depends entirely on interruption having preserved enough context to make re-entry legible.
The Design Response
The practical answers are not glamorous but they are specific. Writes to persistent storage happen on every significant event, not on exit. Background timers use device time, not session time. UI state is shallow and recoverable — a player should need at most one tap to understand where they are. Transitions that could be interrupted mid-animation are designed so that either endpoint of the animation represents a coherent state.
Progress state — level completion, resources earned, objectives reached
There is also a softer design response: structuring the session so that natural pause points occur frequently and feel resolved. Completing a small unit of play — a puzzle solved, a wave cleared, a harvest collected — gives the player a moment where interruption costs nothing, because there is genuinely nothing in flight.
Jesper Juul's observation in A Casual Revolution that casual games fit discontinuous play is partly a design claim: the unit of progress is small enough that any interruption falls between units rather than inside them.
Also worth having to hand
Lifted out of the flow
Core concepts
- Continuous state persistence — committed on event, never batched to exit
- Timer state vs session time — real-world clock must govern timers, not app-active time
- Interruption as architectural constraint, not UX edge case
Design vocabulary
- Timer state — real-world countdown continuing while app is backgrounded
- Session context — the UI position and in-flight state a player returns to
- Natural pause point — a resolved micro-unit of play where interruption is costless
This is not an accident of casual design being "simpler." It is a deliberate architectural response to a device that does not ask permission before it ends the session. The game has to be designed around the phone's real social life — pocketed mid-tap, handed to someone else, silenced and ignored — not the idealised focused session a designer might prefer.
The console asks for an hour. The phone gets what it gets. Every second of that session has to count, and every state that exists in that second has to be safe to abandon.