Interruption recovery in Flutter: how I handle lost state after a phone call

cabraule ketchanga — Mon, 08 Jun 2026 14:58:10 +0000

The invisible problem

I've seen this happen dozens of times in my analytics. A user opens the app, starts a checkout, fills in their name, their address, picks a delivery method. They're on step 3 of 4. And then their phone rings. They pick up. A 5 minute call with their mom, a colleague, whatever. They hang up, go back to the app.

And there it is, the home screen, state completely gone. Flutter did its job, it freed the memory when the process stayed backgrounded too long. Totally normal. Totally invisible to the user.

What the user sees is that they have to start over. Name, address, delivery method. Three minutes of typing gone. No error message, no explanation, just nothing.

The business cost is direct: checkout abandonment. Not a bug. Not a crash. Just the absence of memory between two states. And when you look at your data closely, you realize that window, the background then the return, is a black hole nobody really watches.

The question I asked myself: is this really unavoidable, or did we just get used to doing nothing about it?

Why Flutter doesn't handle this
Flutter gives you the tools to observe the lifecycle, not to manage it for you. WidgetsBindingObserver throws callbacks at you: paused, inactive, resumed, detached. You know when the app goes to background. You know when it comes back. What Flutter doesn't do is decide what to save, or how. That's intentional. The framework's philosophy is to give you full control over state. Good philosophy for a general purpose framework. Bad news when you have a 4 step checkout.

class _MyAppState extends State<MyApp> with WidgetsBindingObserver {
  @override
  void didChangeAppLifecycleState(AppLifecycleState state) {
    if (state == AppLifecycleState.paused) {
      // OK but... where do we save what exactly?
    }
  }
}

So you go looking. shared_preferences, too limited for complex state. Provider, Riverpod, Bloc, great for orchestrating state in memory, but they die with the process. Hive works, but you write the serialization by hand for every screen. The Flutter Restoration API looks promising on paper, fragile in practice across versions. I tried all these approaches. And every time I hit the same wall: saving state is the easy part. The hard part is deciding when to restore it, how to offer it to the user, and how long you keep that data. A silent restore and the user lands on a screen without understanding why. A badly worded confirmation and they tap "No" out of reflex. And if they come back two days later, do you rehydrate anyway? The real problem isn't technical. It's semantic.

What I tried (and what didn't work)

My first implementation was clean on paper. I saved state to Hive on every input change, and on resume I reloaded it silently. No modal, no confirmation, just a transparent restore. I told myself: minimal UX, zero friction.

A beta tester wrote to me three days later: "I thought your app had a bug, I was on a step I didn't remember reaching." That's the problem with silent restoration, it's worse than no restoration at all. The user is disoriented, they don't understand why they're there, and they associate it with the app behaving weird.

Attempt 2. I add a modal on resume: "Want to resume your session?" Yes button, No button. Most users tapped No. Not because they didn't want to resume, but because the modal showed up on an empty screen, no context, no way to see what there was to resume. A user who doesn't see their cart, their total, the exact step they were on, recognizes nothing. They say No out of reflex.

Attempt 3. I tell myself: OK, I'll keep the state for 7 days, that way even users who come back late can resume. Except one user came back 4 days later with a shipping address that had changed and an item out of stock. I restored stale data into a live checkout. Dangerous.

Three tries, three fails. The lesson: saving is easy. Restoring is where it gets hard.

The approach that works: checkpoints + TTL

After those three failures, I changed the question. I stopped asking "how do I save the state" and started asking "what are the moments of coherence in this flow?" A 3 step checkout has exactly 3 moments where the state is clean, complete, valid. That's where you checkpoint. Not on every keystroke.

That gave me three concrete rules.

Snapshot per completed step, not per change. When the user validates step 1 (address), we persist. When they validate step 2 (delivery), we persist. Never in between. The saved state is always coherent because we capture it at a moment when the user themselves said "this is good."

Short and contextual TTL. 15 minutes for a checkout, not 7 days. After 15 minutes an e-commerce cart can have changed (stock, price, expired promo, etc.). We refuse to restore potentially stale data. The TTL isn't a technical limit, it's a business decision.

Confirmation with visible context. Never a blind modal. If we offer to "resume," we show the cart, the total, the exact step. The user recognizes what they were doing, they decide with full knowledge.

The concrete pattern I use, the one I ended up wrapping into Morph, the SDK I'm building, looks like this:

// On every completed checkout step
context.morphSetCheckoutMultiStepContext(
  workflowId: _workflowId,
  step: _currentStep,
  totalSteps: 3,
  cartData: {
    'total': cart.total,
    'itemCount': cart.itemCount,
  },
  savedData: _savedStepData,
  strategy: RecoveryStrategy.confirm,
  ttl: const Duration(minutes: 15),
);

workflowId identifies the checkout session. step + totalSteps automatically generate the message "You were on step 2 of 3." cartData is what we show in the confirmation card.strategy: confirm makes sure we never impose anything silently. And the 15 minute ttl kills the snapshot before it becomes dangerous. Why does this work where the other approaches failed? Because the user lands on a card that looks like theirs, their cart, their step, their context. They don't go through a mysterious restore. They recognize, they decide. And if they say no, that's their choice, the SDK learns from that too, and stops offering recovery if they refuse systematically. Now let's see what this looks like in practice on a real 3 step checkout.

Real case: a 3 step checkout

Let's take Alice. She opens the app, starts her checkout.

Step 1: she enters her address, validates. The snapshot is taken silently.

Step 2: she enters her card number, halfway through typing. Her phone rings. A 5 minute call. She hangs up, goes back to the app. The OS killed the process. What happens on the return is exactly what we designed. The app detects that a snapshot exists, that it's less than 15 minutes old, and that it belongs to a multi step workflow. A card slides up from the bottom of the screen, not a blocking modal, not an aggressive popup. Just a discreet surface with what's needed: "Resume your order?" 2 items, $47.50, step 2/3 (Payment), [Continue] or [Start over]. Alice immediately sees what she was doing. She recognizes her cart, her step, her total. She's not lost. She doesn't wonder why she's there. She taps "Continue." The SDK loads the step 1 snapshot from the chain, the address is already there. The Payment screen opens. She picks up her typing right where she left off. 30 seconds later, her order is placed. Without Morph, she would have started from scratch, or she would have abandoned. That's the delta that matters. Not the technical feat, the completed checkout instead of the abandoned one.

I rebuilt this whole flow in an open source Flutter e-commerce demo (MIT) that you can clone and modify freely: https://github.com/polarismorph-code/morphui-flutter-ecommerce. The interruption recovery code is in lib/features/checkout/checkout_screen.dart. If you want to dig in, open an issue, or adapt the pattern to your own flow, that's what it's there for.

Conclusion
What I learned in 8 months on this topic: the best UX optimizations are invisible. The user doesn't know they were about to abandon their checkout. They finish it, that's all. There's no success notification, no "wow" moment. Just an order completed where there would have been a silent abandonment.

Interruption recovery isn't a detail you add after v1. It's an architecture decision to make early, because retrofitting it onto an existing flow is painful.

If you work on multi step flows in Flutter, checkout, KYC, onboarding, I'm curious how you handle this on your side. Same pattern? Different approach? Comments are open. And for the curious: Morph also covers React. Everything's on morphui.dev.

DEV Community: cabraule ketchanga

Interruption recovery in Flutter: how I handle lost state after a phone call