Preserving State Across Reloads

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 87cfb886f00d · 16 Oct 2026Report an issue or request a re-scan

• Publisherskydoves GitHub userOwner of the repository this skill is read from
• Source folderskydoves/compose-performance-skills/hot-reload/preserving-state-across-reloadsThe exact folder we audited
• LicenceApache-2.0As the repository states it
• Commit pinned for this verdict87cfb886f00dA new audit runs when the source changes
• Repository statusNot archivedLast push 121 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Use this skill to keep Jetpack Compose state alive across HotSwan hot reloads by understanding the three escalating tiers Compose HotSwan uses (tier 1 targeted recomposition, tier 2 composition reset, tier 3…

---
name: preserving-state-across-reloads
description: Use this skill to keep Jetpack Compose state alive across HotSwan hot reloads by understanding the three escalating tiers Compose HotSwan uses (tier 1 targeted recomposition, tier 2 composition reset, tier 3 Activity.recreate) and choosing edits and state holders that stay inside tier 1 where scroll position, lazy items, dialog state, and per-composable remember values all survive. Explains which edits force escalation, which state holders survive each tier, and how to hoist transient UI state when the iteration loop must escalate. Use when the developer says "scroll jumped to top after a hot reload", "lost dialog state", "lazy column re-fetched", "tab selection reset", asks why HotSwan reload escalated to tier 2 or 3, plans a refactor and needs to know which scope it touches, or wants to know which state holders survive composition reset.
license: Apache-2.0. See LICENSE for complete terms.
metadata:
  author: Jaewoong Eum (skydoves)
  keywords:
  - jetpack-compose
  - performance
  - hot-reload
  - hotswan
  - state-preservation
  - remember-saveable
  - recomposition
  - composition-reset
---

# Preserving State Across Reloads: keep edits inside HotSwan tier 1

Compose HotSwan applies every hot reload through three escalating tiers. Tier 1 (targeted recomposition) preserves the most: scroll position, navigation back stack, `remember` and `rememberSaveable` values, `ViewModel` state, lazy layout items, dialog and bottom sheet state. Tier 2 (composition reset) disposes and recreates compositions, dropping per-composable `remember`. Tier 3 (`Activity.recreate()`) restarts the Activity and only state held by `ViewModel` or `SavedInstanceState` survives.

The iteration loop is fastest and least surprising when every reload stays inside tier 1. This skill covers which edits trigger which tier, which state holders survive each tier, and how to hoist transient UI state when an edit must escalate.

## When to use this skill

- The developer reports "scroll jumped to top after a hot reload", "lost dialog state", "lazy column re-fetched", or "tab selection reset to zero".
- The developer is about to refactor a composable and wants to know which recomposition scope the change touches.
- The HotSwan tool window status shows a tier 2 or tier 3 reload and the developer wants to understand why it escalated.
- The developer asks which state holders survive `Activity.recreate()` versus a composition reset.
- The user mentions "tier 1", "tier 2", "tier 3", "composition reset", "HotSwan state preservation", or "rememberSaveable across reload".

## When NOT to use this skill

- The change was rejected as a schema violation entirely (added a parameter, changed a constructor, added a new resource ID) and HotSwan fell back to a full incremental build. See `../understanding-hot-reload-limits/SKILL.md`.
- HotSwan is not installed or the watcher is not running. See `../setting-up-compose-hotswan/SKILL.md`.
- The developer wants an AI agent to drive the loop autonomously. See `../iterating-with-ai-and-mcp/SKILL.md`.
- The recomposition itself is too wide independent of hot reload (a parent invalidating a whole subtree on every state tick). Diagnose with `../../recomposition/debugging-recompositions/SKILL.md` first.

## Prerequisites

- Compose HotSwan installed and `WATCHING` against the running app. Setup lives in `../setting-up-compose-hotswan/SKILL.md`.
- Familiarity with Compose recomposition scopes; cross-link `../../recomposition/debugging-recompositions/SKILL.md` for the underlying mechanics.
- Familiarity with `rememberSaveable` for state that must survive process death and (in this context) composition reset.

## The three tiers

| Tier | Mechanism | Preserves | Loses | Triggered when |
|---|---|---|---|---|
| 1. Targeted recomposition | recomposes only the affected scopes in place | navigation back stack, scroll position, `remember`, `rememberSaveable`, `ViewModel`, lazy layout items, dialog and bottom sheet state | nothing | simple body change inside one composable scope |
| 2. Composition reset | dispose and recreate all compositions from scratch | Activity, `ViewModel`, navigation (via `NavController`), `rememberSaveable` (depends on retention) | per-composable `remember` values not retained by a `Saveable`, scroll position not held by a saveable state holder | tier 1 unavailable (theme change, root-scope structural change) |
| 3. `Activity.recreate()` | recreate the entire Activity | `ViewModel`, `SavedInstanceState` | scroll, transient dialog state, anything not saved | composition fails or schema mismatch detected |

The tier that ran is reported in the HotSwan tool window status after every reload. Read it after each edit to confirm the loop stayed where it was supposed to.

## Workflow

### 1. Read the tier from the tool window after every reload

The HotSwan tool window prints the tier (1, 2, or 3) for each reload. If the developer expected tier 1 and the status reports tier 2 or 3, the edit touched a wider scope than intended. Read the tier before deciding whether the lost state is a configuration problem or expected behaviour.

### 2. If state was lost on tier 2, audit the offended state holder

Tier 2 disposes per-composable `remember` blocks. Walk the composable that lost state and convert its local `remember` to `rememberSaveable` for any value that the developer wants to keep across reloads that may escalate. This is the single highest-leverage change for a HotSwan-driven iteration loop.

### 3. Hoist user-facing transient state into a `ViewModel` for long iterations

When the developer is iterating on a screen for a long stretch and individual edits keep escalating to tier 2 or tier 3, hoist transient UI state (selected tab, expanded item, scroll position, dialog open) into a `ViewModel`. `ViewModel` survives all three tiers, so the iteration loop never loses the workbench state.

### 4. Avoid theme and root `CompositionLocal` mutat

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/skydoves/compose-performance-skills
git -C compose-performance-skills checkout 87cfb886f00d

Works in

1. 2026-10-16
   ✓SAFE B 89 / 100

   first audit · source 87cfb886f00d

Questions about Preserving State Across Reloads

• github.com/skydoves/compose-performance-skills/tree/main/hot-rel — the audited source at commit 87cfb886f00d and every finding aboveObserved · 16 Oct 2026

Spotted something wrong? Report a correction · Methodology