remember vs rememberSaveable in Jetpack Compose - What's the Real Difference?

This article expands on the basic difference between remember and rememberSaveable in Jetpack Compose and explains how state, lifecycle, and configuration changes interact under the hood.

---

1. Why state management matters in Compose

---

Jetpack Compose is declarative. This means UI is a function of state. If the state changes, the UI recomposes. If the state disappears, the UI resets.

That makes correct state handling one of the most important Compose concepts.

Many beginners assume that once a value is stored in state, it will live forever — but that is not how Android works.

---

2. The problem: configuration changes

---

A configuration change is any situation where Android recreates your Activity:

• Screen rotation

• System theme change (dark / light)

• Language change

• Font scale change

• Multi‑window mode

When this happens:

• The Activity is destroyed

• The Composable tree is rebuilt

• In‑memory state is lost

Unless you explicitly save it.

---

3. remember — what it really does

---

remember stores data only in memory (RAM).

Example:

var counter by remember { mutableStateOf(0) }

This state:

• Survives recomposition ✅

• Does NOT survive configuration changes ❌

• Does NOT survive process death ❌

remember is recomposition-safe, not lifecycle-safe.

Use remember for:

• Animation states

• UI-only temporary flags

• Scroll positions inside a single session

• Calculated values that are cheap to recompute

---

4. rememberSaveable — what changes

---

rememberSaveable extends remember by automatically saving state to a Bundle.

Example:

var counter by rememberSaveable { mutableStateOf(0) }

This state:

• Survives recomposition ✅

• Survives configuration changes ✅

• Survives Activity recreation ✅

Under the hood, rememberSaveable uses:

• SavedStateRegistry

• onSaveInstanceState

• Bundle serialization

---

5. Practical comparison

---

remember:

• Faster

• Memory-only

• Temporary

• No serialization

rememberSaveable:

• Slightly more overhead

• Uses Bundle

• Restored automatically

• Needs savable types

---

6. What types can be saved

---

rememberSaveable supports:

• Int, Long, Boolean, Float

• String

• Parcelable

• Serializable

• Lists / Maps of supported types

If your type is unsupported, you must create a custom Saver.

---

7. When NOT to use rememberSaveable

---

Avoid rememberSaveable for:

• Large data objects

• Bitmaps

• Network responses

• Cached repositories

• Business logic state

Those belong in:

• ViewModel

• Repository layer

• Local database

---

8. State hierarchy rule (important)

---

Think of state in layers:

UI-only, short-lived: → remember

UI state user cares about: → rememberSaveable

Business / screen state: → ViewModel + StateFlow

Persisted data: → Database / DataStore

---

9. The most common beginner mistake

---

Using remember everywhere and wondering why values reset on rotation.

If losing the value would feel like a bug to a user, you almost always want rememberSaveable.

---

10. Final rule of thumb

---

remember: "I can lose this, no problem"

rememberSaveable: "Losing this would annoy the user"

---

TL;DR

remember = temporary, RAM-only rememberSaveable = configuration-safe Rotation recreates Activity Choose API based on user expectations