Every mobile game is designed for a session it will almost never get. The design doc imagines an unbroken stretch of attention; the phone delivers ninety seconds between a boarding call and a boarding gate, interrupted twice. A call lands in the middle of a move. The screen locks itself in a pocket. The operating system, quietly and without asking, reclaims the memory of the app you switched away from forty minutes ago. Treat those as edge cases and you will ship a game that loses the player’s progress, their patience, or both — and you will lose them in exactly the moment when they had come back. Treat them as the normal case, and design around them from the start, and interruption stops being a failure state you patch and becomes a courtesy the player never has to think about. That is the whole craft here: build for the fragment, not the session.
The session is a fiction; the fragment is real
The word “session” quietly smuggles in an assumption — that play is a continuous block with a start, a middle, and a deliberate end. On a console that is roughly true. On a phone it almost never is. The real unit of mobile play is the fragment: the stretch of attention between one interruption and the next, often a minute or two, rarely uninterrupted to the finish. A player opens the game in a lift, plays four floors, pockets the phone, and the “session” you imagined was actually six fragments spread across a day, each one entered and left mid-thought. Design for the block and every fragment boundary becomes a place progress can leak. Design for the fragment and every boundary becomes a save point.
This reframes what “good pacing” means. A game built for fragments has natural resting places close together — the end of a hand, a solved region, a cleared wave — so the player is rarely more than a few seconds from a clean place to stop. Puzzle games get this almost for free: a half-finished grid is a perfectly legible thing to walk away from and come back to, which is part of why the form travels so well in pockets. Our own Sudoku by WizusLabs is built to be set down mid-grid and picked up hours later with the board, the pencil marks, and the timer exactly where you left them — because the alternative, losing a half-solved puzzle to a phone call, is the kind of small betrayal that ends a habit. The first fragment matters most of all; we wrote about earning it in the first sixty seconds, and everything below is the argument for keeping every fragment after it.
Three interruptions, three different failures
“Interruption” is not one event, and lumping them together is how games get this wrong. There are three, and they fail in three different ways. The soft pause is the common one: the player swipes to another app, the screen locks, a banner drops down. The game loses the foreground but stays alive in memory. The failure mode here is a game that keeps running while nobody is watching — a timer draining, a boss still swinging, a match lost to an empty screen. The mid-action yank is sharper: an interruption arrives in the exact instant of input, the half-second a piece is falling or a card is mid-flight. The failure mode is an input that half-registers, a move committed the player never confirmed, a state caught between two frames. And the hard kill is the quiet one: while the app sat backgrounded, the OS decided it needed the memory and terminated the process outright. No warning fires, no “are you sure.” The failure mode is the cruellest — the player taps the icon expecting to resume and gets a fresh title screen, their progress simply gone.
The hard kill is the one that separates games that respect the player from games that merely work on the test bench. It rarely shows up in development, because a developer’s phone has memory to spare and the app is the thing in focus. It shows up constantly in the wild, on a three-year-old device with forty apps open, which is precisely the device most of your players are holding. Building only for the soft pause — the one you can see on your own screen — is how a game ships a bug that only its poorest-provisioned, most numerous players ever hit.
Save on the way out, never on quit
The single most important rule follows directly from the hard kill: persist the player’s state when you lose the foreground, not when the app is closing. There is a tempting place to put a save — the “app is terminating” callback — and it is a trap, because on mobile that callback is not guaranteed to run. When the OS reclaims memory it can kill the process without giving the app a clean shutdown; the code you carefully wrote to save on exit never executes. The reliable moment is earlier, the moment you can actually trust: the transition to the background, when the platform tells you the app is no longer front-most. That signal does fire on the way to a soft pause, and it is the last thing you are promised before a possible kill. Write the player’s state to disk there, every time, whether or not a kill ever comes. A save that only runs “on quit” is a save that skips exactly the case it exists for.
Two disciplines make that save trustworthy. First, save often and incrementally, not just at the fragment boundary — a move placed, a region cleared, a level entered — so that even a kill between background-signal and disk-write costs at most a beat, never a session. Second, write state atomically: to a temporary file, then rename over the real one, so a process killed mid-write leaves the last good save intact rather than a corrupt half-file that reads as a fresh start. The platforms hand you the hooks to do this — a lifecycle state stream in Flutter, the background-transition callbacks on iOS, the save-instance-state and stop callbacks on Android — and the whole game of surviving a kill is won or lost on whether you treat the background signal, not the quit signal, as your commit point.
Pause honestly, resume gently
Saving protects progress; pausing protects fairness. The rule is blunt: the instant the game is no longer in focus, nothing that can harm the player may keep running. Stop the clock, freeze the hazards, halt the simulation. A game that lets a boss keep attacking a backgrounded screen, or a countdown keep draining while the player takes a call, has decided that its own rules outrank the player’s life — and the player will not forgive losing to an opponent they could not see. This is the same courtesy we described for sound: our games go quiet the moment they leave the foreground rather than pretending to be music apps, which we argued in designing audio players don’t mute. Silence on backgrounding and stillness on backgrounding are the same principle — a game that keeps making noise, or keeps taking damage, after you have looked away is a game doing something nobody asked for.
Resuming is the half everyone under-designs. Dropping a returning player straight back into a live moment — the boss mid-swing, the piece already falling — punishes them for the interruption a second time, because their hands and eyes need a beat to re-acquire a situation they left minutes or hours ago. The fix is a small, deliberate re-entry: come back paused, not live. Show the board in its resting state with a clear tap-to-continue, and where the game is real-time, give a short, visible count-in before control returns — the same three-two-one a match uses after a disconnect. It costs a second and it buys back all the fairness the interruption spent. The test is simple and worth running by hand: put the game down mid-action, wait, come back, and ask whether the first thing that happened was under your control. If it was not, the resume is a bug.
The clock keeps running — say out loud what that means
Interruption gets genuinely hard the moment real time is part of the design. If the game has a solve timer, an energy bar that refills over hours, a daily streak, or a leaderboard scored on speed, then “what happens to wall-clock time while the player is away” is a design decision, not a technical detail — and the only wrong answer is to leave it implicit. A speed-scored puzzle must pause its timer on backgrounding, or a phone call quietly ruins a run the player was proud of. An energy or streak system, by contrast, is meant to track real time whether the app is open or not, and trying to “pause” it would break the feature. The two cases pull in opposite directions, and the honest move is to decide each one deliberately and make the rule visible to the player, so that time away never produces a surprise they will read as the game cheating.
There is a security corollary worth stating plainly, because it is where naive implementations break: never trust the device clock for anything the player benefits from skipping. A timer read from local device time can be wound forward by changing the phone’s clock — the classic way to “skip” a wait. If a wait genuinely matters, it belongs on time the client cannot freely rewrite. For a single-player puzzle the stakes are low and local time is fine; the point is to know which case you are in rather than discover it after the fact.
The interruption we author ourselves
Not every interruption arrives from outside. Some we insert on purpose — and honesty requires naming that. Our games are free and ad-supported, with a single optional Pro purchase that removes ads; we are not claiming an ad-free product, because that would be false. An interstitial ad is, structurally, a self-inflicted interruption: for a few seconds the game hands the screen to something else, then hands it back. Which means we owe the player the exact same courtesies we demand of the phone. State is saved before the ad shows, so a network hiccup or a mis-tap that closes the app during the ad costs nothing. The game returns paused, not live, so a rewarded ad never drops the player back into a hazard mid-animation. And the interruption is rationed — placed at fragment boundaries, where the player was already at a resting point, not dropped into the middle of a move. An ad the player chose, at a moment that was already a pause, is a fair trade; an ad that interrupts the action and loses their progress is two betrayals wearing one banner.
The honest close: the resume nobody notices
Done well, none of this is visible. There is no screen that announces “your progress was saved,” no reward for surviving a kill, no review that praises a game for being exactly where the player left it. The payoff is an absence: the fresh title screen that never appears, the lost run that never happens, the small betrayal that never gets a chance to end a habit. That is the strange economics of this corner of the craft — it is nearly invisible when you get it right and instantly, memorably infuriating when you get it wrong. The three moves are cheap to make and expensive to skip: build for the fragment rather than the session, commit the player’s state to disk the instant you lose the foreground rather than trusting a clean exit, and pause honestly on the way out so you can resume gently on the way back. A game that respects the interruption respects the life the interruption belongs to — and that is the life your players are actually living while they play. The rest of the WizusLabs Engineering blog works through the neighbouring parts of the same craft, from the first minute to the feedback that makes an action feel alive.
Notes
This is a first-hand craft piece, and it deliberately contains no usage statistics. We have not cited figures for how often mobile sessions are interrupted or how frequently backgrounded apps are killed: the numbers that circulate vary widely by device, OS version, and memory pressure, and quoting a rate we cannot stand behind would undercut the point of the piece. Where the essay describes interruption as the normal case, it is describing a design reality we build around, not a measured frequency. The lifecycle behaviours discussed — that a terminating app is not guaranteed a clean shutdown callback, that the background transition is the reliable save point, that apps are expected to yield on losing focus — are drawn from the platform documentation cited below. Our own games are free and ad-supported, with a single optional Pro purchase that removes ads — the self-inflicted interruption named above.
Sources
- Flutter API Documentation — AppLifecycleState (the foreground/background/paused lifecycle states an app observes).
- Android Developers — The activity lifecycle (onStop / onSaveInstanceState, and why work is saved on the way to the background rather than on process death).
- Apple Developer Documentation — Managing your app’s life cycle (background transitions and the expectation that apps save state and yield when they leave the foreground).
These support only the platform-lifecycle statements; the post makes no statistical claims.
Keep reading: all posts on the WizusLabs Engineering blog.