remember vs rememberSaveable

A user types a long review, rotates the phone to see it better, and the text field is empty. Or they switch to their banking app to copy an OTP, come back, and the screen has reset. Both bugs come from choosing remember where rememberSaveable (or a ViewModel) was needed.

What each one survives

For data that must survive even the user closing the app, such as drafts or settings, persist it with Room or DataStore.

How rememberSaveable works

rememberSaveable stores its value in the saved instance state Bundle, the same mechanism Activities use. The value must therefore be saveable: primitives, Strings, and Parcelable or Serializable types, or you provide a Saver.

@Composable
fun ReviewForm() {
    var text by rememberSaveable { mutableStateOf("") }              // String: saveable
    var rating by rememberSaveable { mutableIntStateOf(0) }          // Int: saveable
    var showTips by remember { mutableStateOf(true) }                // transient UI hint: remember is fine
    // ...
}

Custom types with Parcelize

@Parcelize
data class DateRange(val startEpochDay: Long, val endEpochDay: Long) : Parcelable

var range by rememberSaveable { mutableStateOf(DateRange(0, 0)) }

This requires the kotlin-parcelize Gradle plugin.

Custom Savers

data class Filters(val query: String, val onlyUnread: Boolean)

val FiltersSaver = listSaver<Filters, Any>(
    save = { listOf(it.query, it.onlyUnread) },
    restore = { Filters(it[0] as String, it[1] as Boolean) },
)

var filters by rememberSaveable(stateSaver = FiltersSaver) { mutableStateOf(Filters("", false)) }

Keys: resetting remembered values

@Composable
fun ProductScreen(productId: String) {
    // Recreated when productId changes, otherwise reused
    val formatter = remember(productId) { PriceFormatter(productId) }
    // Saved selection resets when navigating to a different product
    var selectedSize by rememberSaveable(productId) { mutableStateOf<String?>(null) }
}

Limits and when to use a ViewModel instead

• Bundle size is limited. Saving large lists or bitmaps can cause TransactionTooLargeException. Save IDs or small input, and reload data from the repository.
• Business logic doesn't belong in composables. If state needs loading, validation or saving, put it in a ViewModel, using SavedStateHandle for the parts that must survive process death.
• Don't save derived values. Save the inputs and recompute the rest.

How to test process death

1. Run the app, type into the form, then press Home.
2. Run adb shell am kill com.your.package (it only kills background apps), or enable Don't keep activities.
3. Reopen the app from recents. Everything in rememberSaveable and SavedStateHandle should be restored.

Choosing in practice

Frequently asked questions

Conclusion

remember survives recomposition. rememberSaveable also survives configuration changes and process death, via the Bundle. Use saveable state for user input, ViewModels with SavedStateHandle for screen logic, and Room or DataStore for anything that must outlive the session.

Next step: run work at the right time with Side Effects in Compose.