Life Happens at the Till: Auditing Your App for Real-World Interruptions

You know the scene. You are third in the queue at Tesco, phone in one hand, basket in the other, card reader beeping somewhere to your left. Your app asks you to sign in again. Then a call comes through. Then the lift drops signal. Then the battery warning appears. By the time you look back, the app has forgotten what you were doing.

That is not an edge case. It is Tuesday. Most apps are still tested in a quiet room with good Wi-Fi, a charged handset and nobody asking for a meal deal. The gap between that demo and real UK usage is where trust gets lost. So before you ship, run an interruption audit. Not a journey map with tidy arrows, but a proper look at what happens when life barges in.

Map the interruptions, not just the flow

Start by listing the things that will genuinely happen to a user mid-task. An authentication prompt. A phone call. A push notification they tap. A train tunnel. A supermarket basement. Low Power Mode. An older handset that decides to reclaim memory. A user who simply puts the phone down for ten minutes and comes back.

Then mark the points in your app where losing state would be expensive. Checkout is obvious. So are address entry, booking a delivery slot, uploading documents, choosing a seat, and anything involving a reference number. The audit should ask one blunt question at each point: if the user vanishes now, what exactly will they lose?

Draft state is a promise, not a nice-to-have

If your app collects information over more than one screen, it should preserve that information on the device as the user goes. Not only in memory, because memory is the first thing the operating system takes when it needs room. Write the draft to local storage, timestamp it, and decide how long it stays valid.

When the user returns, do not silently drop them into a pre-filled form with no explanation. Show a short, plain banner: 'We saved your basket. Pick up where you left off?' Give them a way to start again if the draft is stale. That matters in the UK where delivery slots, prices and stock can change while someone is distracted by a card reader.

Test the draft after a force quit, not just after pressing home. Test it after an OS update if you can. Test it on the cheapest handset you support. A draft that only survives a gentle backgrounding is not really a draft.

Auth prompts should not wipe the path

Session expiry is a security feature. It should not feel like punishment. If the user is midway through checkout and the app asks them to sign in again, they should come back to the same step, with the same draft, and a clear reason why they were asked.

Store the return route and the user's intent before sending them to authentication. After sign-in, restore both. If they cancel the prompt, keep the draft and offer a way back in later. Where the flow allows it, let them continue as a guest rather than forcing an account at the worst possible moment. And never quietly retry a payment after an auth prompt. Ask first.

Biometrics and passkeys help here, but they are not a complete answer. A user with a cracked screen, wet hands or a phone in a supermarket queue may still fail. The recovery path matters as much as the fast path.

Decide what ten minutes means

Every app needs a policy for the user who disappears. A short background pause should probably keep the session alive. A longer absence might need a soft lock, but it should still preserve the draft. For time-sensitive tasks, tell the user what changed: the slot was taken, the price moved, the ticket hold expired. For less sensitive tasks, simply resume and let them review.

Do not pretend nothing happened. A quiet reset to the home screen is more confusing than an honest message. Something like: 'Your session timed out for security. Your draft is safe. Sign in to continue.' That is clear, calm and respects the fact that the user was probably doing something else.

Low battery and older handsets are part of the design

Battery saver modes change how apps behave. Background sync slows, animations stutter, and longer tasks become risky. If your app has a heavy step, warn before it starts rather than failing halfway through. Keep local writes small and frequent. Defer non-essential network calls. Avoid making a map or a video preview the only way to complete a task.

On older handsets, memory pressure is the quiet killer. The app may be killed while the user is answering a call. If the draft lives only in memory, it is gone. Run your audit on a device that is two or three years old, not just the newest phone in the office. A mid-range Android handset from a UK network shop is a better test bed than you might think.

The field test script

Give yourself thirty minutes and a real queue. Start a checkout or booking flow. Take a call. Lock the phone. Walk into a lift or a basement. Turn on Low Power Mode. Force quit the app. Reopen it after ten minutes. Sign in when prompted. Then check four things: is the draft there, is the navigation restored, did the app explain what happened, and can the user finish without starting over?

Log each failure as a product bug, not a testing inconvenience. Add analytics events for draft restored, auth return and session recovery. Watch them after launch. If recovery events are high, your flow is probably too fragile, or your session policy is too aggressive.

Interruption handling is not glamorous. It will not make the App Store screenshots. But it is the difference between an app that works in a demo and one that works when someone is holding a basket, a phone and a card reader at the same time. In the UK, that is the only test that really counts.