remember vs rememberSaveable

Jetpack Compose Junior Kotlin 2.0+ API 23+ Reviewed By Best Latest Apps

Predict the output

The user types 'hello' into both fields, then rotates. What remains?

@Composable
fun Form() {
    var a by remember { mutableStateOf("") }
    var b by rememberSaveable { mutableStateOf("") }
    Column {
        TextField(value = a, onValueChange = { a = it })
        TextField(value = b, onValueChange = { b = it })
    }
}
Options
Hint 1 of 1

Is the Activity recreated on rotation?

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A The first field is empty, the second shows hello

Correct. Rotation recreates the Activity; only rememberSaveable restores from the Bundle.

Why not the others?
  • B Both show hello. remember is lost when the Activity is recreated.
  • C Both are empty. rememberSaveable restores its value.
  • D The app crashes because String isn't saveable. String fits in a Bundle.
Two scenarios for a screen with two text fields: rotate, and process death. The grid shows which values survive.

Illustrative, based on Compose and Android rules; not a device recording

Text version

Rotate

  1. A onPause
  2. A onStop
  3. A onSaveInstanceState
  4. A onDestroy
  5. A' onCreate
  6. A' onStart
  7. A' onResume

Process death

  1. A onPause
  2. A onStop
  3. A onSaveInstanceState
  4. (process killed: no more callbacks)
  5. A' onCreate (with saved Bundle)
What survives
StateRotateProcess death
local var✕ lost✕ lost
remember✕ lost✕ lost
rememberSaveable✓ kept✓ kept
ViewModel✓ kept✕ lost
SavedStateHandle✓ kept✓ kept
Room / disk✓ kept✓ kept

30-second answer

remember keeps a value across recompositions but loses it when the composable leaves composition or the Activity is recreated, such as on rotation. rememberSaveable also saves the value into the saved-instance-state Bundle, so it survives rotation and process death. Use it for small UI state like text input or a selected tab.

Practise saying it · 30 s. No recording, just a timer

Explain remember vs rememberSaveable.

Say your answer out loud, then check which of these points you covered:

  • remember survives recomposition only
  • rememberSaveable survives rotation and process death
  • Bundle is small
  • Screen data belongs in a ViewModel

Deep dive

rememberSaveable works with types a Bundle can hold; for others, write a Saver or use @Parcelize.

The Bundle is small (the whole saved state should stay well under 1 MB), so don't save lists of data; keep those in a ViewModel or database.

In a LazyColumn, item state is kept while scrolled off-screen only with rememberSaveable.

Neither is a substitute for a ViewModel holding screen data loaded from the network.

Common mistakes

  • Storing a whole list of items in rememberSaveable.
  • Expecting remember to survive rotation.
  • Using rememberSaveable for an object that isn't saveable and crashing.

Senior take & follow-ups

Mention size limits and the ViewModel boundary; that shows judgement, not just API knowledge.

Follow-up questions

Think of your answer first, then open the hint.

  1. Where does rememberSaveable store values?

    Show hint

    In the Activity's saved instance state Bundle.

  2. What survives process death?

    Show hint

    rememberSaveable, SavedStateHandle and disk; not remember or plain ViewModel fields.

Similar on iOS: @State vs a plain var SwiftUI's @State survives re-renders but not app termination; @SceneStorage is the closest to rememberSaveable.

Related questions

Suggest a fix if something here is wrong or out of date.