Difference between remember and rememberSaveable

WHAT THIS TESTS: Whether you understand the boundary between ephemeral UI state and state that must survive system-initiated destruction. Interviewers want to see that you know remember is tied to the Composition lifecycle while rememberSaveable hooks into the Activity or Process saved state mechanism via Bundles.

A GOOD ANSWER COVERS: First, the scope difference. remember keeps state across recompositions but loses it when the activity is recreated or the process dies. Second, rememberSaveable uses the SavedStateRegistry to write values into a Bundle, which the system restores after configuration changes and process death. Third, the type constraints. rememberSaveable only works with types the Bundle can store, such as primitives, Strings, Parcelables, Serializables, and arrays or lists of those. For custom objects you must supply a Saver or autoSaver. Fourth, the right scenarios. Use rememberSaveable for small UI state that the user would expect to survive rotation or background killing, such as form input, expanded or collapsed sections, or scroll position. Do not use it for large data sets or business logic state that belongs in a ViewModel backed by repository or disk.

COMMON WRONG ANSWERS: Saying rememberSaveable persists to disk or uses Room or DataStore. Claiming it survives everything including explicit user back navigation or finish, which it does not. Stating that remember survives process death. Using rememberSaveable for heavy objects like bitmaps or large lists, which can crash with TransactionTooLargeException. Saying it relies on a ViewModel under the hood.

LIKELY FOLLOW-UPS: How would you save a custom class with rememberSaveable? The expected answer is implementing a Saver object using listSaver or mapSaver. What happens if the Bundle size limit is exceeded? The app throws TransactionTooLargeException, so large state belongs in persistent storage, not saved state. Why not just put everything in a ViewModel with SavedStateHandle? The interviewer wants to hear that ViewModel is for screen-level state while rememberSaveable is appropriate for leaf composable local UI state.

ONE CONCRETE EXAMPLE: A search screen with a text field and a filter chip row. The query text should use rememberSaveable so it survives rotation. The list of search results should live in a ViewModel and be fetched from the network or database, not stored in rememberSaveable, because results are large and can be reloaded. The expanded or collapsed state of a filter section can use rememberSaveable because it is a boolean and the user expects it to remain after rotation.

Source: developer.android.com