compose

Everything follows from one property. A composable is a function the runtime may call on any frame, more than once per frame, in any order relative to its siblings, and skip entirely. It is not a lifecycle, it is not a constructor, and it is not a place where things happen once. Every rule above is a consequence: if the body can run at any time, work must not live in it; if it can be skipped, the conditions for skipping matter; if it can be abandoned, cleanup must be explicit.

Developers arriving from the View system carry the opposite assumption, onCreateView runs once onDestroyView runs once, and code between them happens in order. That intuition is what produces the duplicate network call in a composable body.

Why keys are the whole effect API. LaunchedEffect gives you exactly one control: what it restarts for. Everything people get wrong about effects is a key that is too broad or too narrow. Too narrow, and the effect keeps running against a value that has moved on, the classic is an observer still watching the id it was started with. Too broad, and it cancels and restarts on every recomposition, which for a network call is a request per frame and looks, from the server, like an attack.

rememberUpdatedState exists for the case where those two are both wrong: the effect must not restart, but must use the current value. Without it you are choosing between a stale callback and a restarting one.

Why stability is not a micro-optimisation. Compose skips a composable when it can prove the parameters have not changed. A List parameter is an interface, so the compiler cannot prove the instance was not mutated in place, and marks the composable unskippable. That decision propagates: the composable recomposes, so its children are re-invoked, and one changed row becomes every visible row recomposing on every emission.

This is why the fix is a type change rather than a caching layer. You are not making the work faster, you are restoring the runtime's ability to not do it.

Why deferring a state read changes the cost by an order of magnitude. Compose runs three phases: composition, layout, draw. Reading a state value in the composable body means the value is a composition input, so a change re-runs composition, the whole function. Reading the same value inside Modifier.offset { } makes it a layout input, so a change re-runs layout only. For a value that changes every frame, that is the difference between recomposing a screen sixty times a second and moving a rectangle.

Why the text field is the sharpest case in the whole skill. Every other rule here costs frames. This one costs characters. Routing each keystroke out to a state holder and back introduces an asynchronous hop between the keypress and the field's content, and under fast input the field receives values out of order. On a physical keyboard in English it usually looks fine. On a predictive, CJK, Indic or gesture keyboard the composing region is destroyed, and those are the users least able to work around it, and least likely to be on the team.

What changed, if you learned Compose earlier.| Then | Now | |---|---| | TextField(value, onValueChange) for typed input | TextFieldState and snapshotFlow | | collectAsState() | collectAsStateWithLifecycle() | | Modifier.offset(x, y) for animated values | Modifier.offset { }, read in layout | | items(list) | items(list, key = ... contentType = ...) | | @Composable functions returning state everywhere | stateless composable plus a stateful wrapper | | manual LaunchedEffect(Unit) for one-shot events | events consumed from state, cleared by the UI |

• The same request is sent two or three times on one screen open. Work in the composable body or an effect keyed too broadly.
• A callback fires against the previous item. An effect keyed too narrowly, holding the value it started with, rememberUpdatedState is the fix.
• A listener that outlives the screen. Registered without a DisposableEffect, so nothing removed it.
• A scroll position, animation, or generated id that resets at random. The value was not remembered, so it is recreated on recomposition.
• The whole list flashes when one row changes. An unstable parameter made the row composable unskippable.
• Per-row state follows the wrong row after a deletion. Missing or unstable key.
• Every row re-runs its whole subtree while scrolling a mixed list. Missing contentType.
• The screen recomposes sixty times a second during an animation. An animating value read in the composable body rather than in a lambda modifier.
• Text drops or reorders characters, and breaks entirely on a gesture or CJK keyboard. The field round-trips through an asynchronous state hop.
• A component cannot be padded or sized by its parent. The modifier parameter is missing or not forwarded. Or padding applies twice it was applied to two elements.
• One colour stays light in dark mode. A literal instead of a theme value.

This section was missing until 22-Aug-2026. compose and kotlin shipped without one, and two attempts to append the eval-18 record silently did nothing because they anchored on a heading that did not exist. Recorded because a skill with no provenance is one whose claims cannot be checked.

eval 18 was a null, and two of three interop rules are gone. AndroidView's factory/update split (construct once, mutate thereafter) was correct in 12 of 12 task-A runs both models, every arm, with zero violations, its own documentation is the most-copied snippet in Compose interop, and corpus saturation has been an anti-signal every time. Releasing the hosted View was correct in 22 of 24 by outcome, 11 of 12 in each task. Both retired. The third rule (inflation cost in lazy lists) was dropped as an observation rather than a rule: the seed had no layout to inflate, and the task requires an AndroidView in a lazy list, so the rule's own not when covered the case it was written for.

What survives is INTEROP-2, forwarding the host's lifecycle. Sonnet writes the ON_RESUME/ON_PAUSE observer in its control arm, both batches; Haiku writes it in no control and no +core run, and in one of two with the skill. Both models call onCreate and onDestroy unprompted, it is specifically the resume/pause pair, the one that only fails after the app has been backgrounded, that Haiku misses. Kept and recorded as does not land which is a different finding from the model already doing it. See evals/android/eval-18-compose-interop/RESULTS.md.

** Rules EFFECT-* through THEME-1 predate this session's eval record** and carry the evidence described in the project's earlier eval files rather than a per-rule score here.

Compose mechanics, almost all of which follow from one fact: a composable may run on any frame, more than once per frame, in any order, and be skipped entirely.

What was run

1 eval, 24 recorded runs, on Haiku 4.5 and Sonnet 5. Every run is archived: the generated sources, the prompt each arm received, and the model each one reported.

Covering the interop rules. The remaining rules carry evidence from earlier work under a weaker task design and have not been re-run.

What the tested models already handle

Constructing a hosted View once and mutating it thereafter, and releasing it when the composable leaves, were done correctly in nearly every run including controls. AndroidView is among the best-documented APIs in Compose, and its documentation is the corpus these models trained on.

Two rules were dropped as a result.

What survives, and where

Forwarding the host's resume and pause to a hosted View. Both models call create and destroy unprompted; it is specifically the resume and pause pair that Haiku misses, and that pair only fails after the app has been backgrounded, which is not something anyone does while writing the screen. Sonnet writes it unaided.