.onChange/.onAppear/.task run post-apply (SideEffect/DisposableEffect): +1 frame per state relay hop; .task(id:) ids compared by Kotlin equality can over-relaunch

[Aecasorg]

Environment

• skip 1.9.4, skip-fuse-ui 1.17.2, skip-ui 1.57.0
• Fuse app; Kotlin 2.3.0, compileSdk 35

Summary

Two related timing/semantics gaps vs iOS:

1. .onChange (and .onAppear) actions are scheduled via Compose SideEffect, which runs only after the current recomposition applies. A state write inside an onChange is therefore not visible to the frame that detected the change — it schedules another recomposition, adding one frame (~16ms) of latency per hop in any onChange→state→onChange relay. On iOS these writes settle within the same transaction.
2. .task(id:) keys are Any compared with Kotlin equality, so reference-typed ids relaunch the task on identity change rather than value change; and .task bodies start via DisposableEffect (post-apply), so initial task-loaded state lands at least a frame after first compose.

Mechanism

.onChange lowers to a SideEffect:

// View/AdditionalViewModifiers.swift:887–889 (zero-param variant; two-param at :923)
if rememberedValue.value != value {
    rememberedValue.value = value
    SideEffect { action(value) }
}
// :874 — onAppear likewise: SideEffect { action?() }

SideEffect runs after composition applies, so a chain A changes → onChange(A) writes B → onChange(B) writes C settles over three frames instead of one. This also affects OS-driven sources (scenePhase, focus) where app code can't restructure the relay away.

.task:

// View/AdditionalViewModifiers.swift:1434, 1441
task(priority:) → task(id: 0, priority:, action)      // constant key
DisposableEffect(value) { let task = Task(priority) { handler.value() }; onDispose { task.cancel() } }

DisposableEffect starts the Task a frame after first appear; the id parameter is compared by whatever equals the bridged value has — for reference-typed Swift ids this is identity, causing cancel+relaunch when an equal-valued but distinct instance arrives (the opposite of SwiftUI's Equatable contract on task(id:)).

Impact

Multi-hop relays visibly "step": in our app, an alert pipeline (enqueue → stage → promote → present) and a scenePhase→auth→navigation chain settle one frame per hop on Android while being atomic on iOS — sheets flash intermediate states and focus lags. Separately, first-appear .task data pops in a frame late (placeholder flash iOS doesn't show), and a reference-typed .task(id:) caused spurious relaunches mid-scroll until we switched to value-typed ids.

Repro

https://github.com/Aecasorg/skip-fuse-perf-repro — scene 3 (RelayHopScene): a button write relays a → b → c through two .onChange modifiers, logging a millisecond stamp at each hop. On iOS all stamps land in the same transaction; on Android each hop lands ~one frame later.

Suggested direction

• When an onChange action only mutates app state, run it synchronously at detection during composition, or route it through Snapshot.withMutableSnapshot so dependent state becomes visible in the same frame; coalesce chained writes into one snapshot apply. If full parity is impractical, an explicit opt-in (e.g. an immediate variant) plus documenting the post-apply semantics would already help a lot.
• For .task(id:): require/normalize value equality for the id (Hashable/Equatable bridge comparison), matching SwiftUI's contract; document the post-apply start timing.

Offer

The task(id:) value-equality piece and the documentation are small and we'd happily PR them; the synchronous-onChange path likely needs your guidance on where a same-transaction write is safe within your composition model. Would you accept work along these lines?

[Aecasorg]

On-device confirmation (CI-built APK of https://github.com/Aecasorg/skip-fuse-perf-repro scene 3, API 35 emulator, skip-ui 1.59.1): a button write relaying a → b → c through two .onChange modifiers logs

21582.7 ms — write a
21587.2 ms — onChange(a) → write b   (+4.5ms)
21604.8 ms — onChange(b) → write c   (+17.6ms — one frame)
21620.8 ms — onChange(c) settled      (+16.0ms — one frame)

~38ms total for a two-hop relay that settles in one transaction on iOS — one frame of added latency per hop, as described above.

[Aecasorg]

Correction to the .task(id:) half of this report — that part is wrong for current Fuse apps, and I apologise for the noise.

While preparing a PR for it I traced the actual Fuse path: skip-fuse-ui wraps the id via Java_swiftEquatable(for:) (SkipSwiftUI/Fuse/SkipUI.swift), whose signature already constrains T: Equatable, and the Kotlin SwiftEquatable peer overrides equals to delegate across JNI to Swift's == (SkipBridge/SwiftEquatable.swift). Since DisposableEffect compares keys with equals, keyed .task(id:) in a Fuse app already relaunches on value inequality, not identity — exactly the behavior I asked for. My claim was based on reading skip-ui's task(id value: Any) signature in isolation without following the bridge wrapper.

What I believe still stands from the original report:

• The post-apply start semantics (.task/.onAppear via DisposableEffect/SideEffect, .onChange relays costing a frame per hop) — unchanged in current sources, and the frame-per-hop timings we measured on device are in the comment above.
• For transpiled (Lite) apps, task(id: Any) still compares with Kotlin equals, so an id whose type doesn't implement value equality relaunches on identity. That is a much narrower point than what I originally wrote, and arguably just a documentation note.

Feel free to retitle or split this issue accordingly — happy to do that myself if you'd prefer.