The ViewModel Lie: Why Your Modern Android App is Fragile

Source: Dev.to

We’ve all been there. You’ve built a beautiful app using the latest Jetpack libraries. You’re using MVVM, your code is clean and your ViewModels are handling the data. You test it on your device and it works perfectly. You feel like a “Modern Android Developer”.

But then, a user leaves a review: “The app randomly loses my data”

You check the logs. No crashes. You try to reproduce it. Nothing. You start to think the user is wrong. But they aren’t. Your app is suffering from a silent failure that modern architecture forgot to tell you about: Process Death.

The Comfort of the ViewModel

For years, Google told us that ViewModels were the answer to the Activity Lifecycle headache. We learned that when the screen rotates, the Activity dies, but the ViewModel lives on.

We got comfortable. We started putting everything in the ViewModel: user profiles, search results, form data. We assumed that as long as the app is “running,” that data is safe.

That was the lie.

What Actually Happens in The Wild

In the real world, users don’t just stay in your app. They switch to Instagram. They take a 50 MB 4K photo. They play a heavy game.

When that happens, the Android OS looks at your app sitting in the background and thinks: “I need that RAM.” It kills your app’s process instantly.

When the user comes back, Android is nice enough to recreate your Activity for you. But your in‑memory ViewModel state? It’s brand new. Every variable you had in memory is gone. It’s null. It’s empty. And your app just fell apart.

The Old Way Was Honest

Before ViewModels, we had onSaveInstanceState.

If you’ve been developing for a while, you remember the pain. You had to manually pack every single variable into a Bundle and then unpack it again in onCreate. It was boilerplate‑heavy, it made Activities huge, and it was easy to mess up.

But it had one superpower: It worked. Because the OS forced you to think about that Bundle, your app was naturally resistant to Process Death. You knew exactly what was being saved and restored.

When ViewModels arrived, we all breathed a sigh of relief. We moved our data into these shiny new containers and stopped worrying about Bundles. We thought, “The ViewModel handles the lifecycle now. I’m done.” But we forgot a crucial detail:

ViewModels survive configuration changes, but they do NOT survive process death.

Enter the SavedStateHandle

A few years ago, Google realized we were all losing our data. Their solution was the SavedStateHandle.

The Fragile Way (Data vanishes on Process Death)

class ProfileViewModel : ViewModel() {
    // This is just a variable in RAM.
    // If the OS kills the process, this is wiped.
    var userId: String? = null
}

The Robust Approach (Data survives)

class ProfileViewModel(private val state: SavedStateHandle) : ViewModel() {
    // This is backed by the system Bundle.
    // Even if the process dies, "userId" stays safe.
    val userId: LiveData = state.getLiveData("user_id")

    fun initUser(id: String) {
        state["user_id"] = id
    }
}

Final Thoughts

Building a robust app isn’t about using the newest library; it’s about respecting how the Android OS actually works. Stop trusting your memory, start trusting the SavedStateHandle, and your users will thank you for an app that actually remembers them.

Libraries and best practices change every year, but the way the Android OS manages memory remains constant. We can’t control when the system needs to reclaim RAM, but we can control how our apps recover from it.