withAnimation() leaks into global state on Android

[tifroz]

On Android the withAnimation() scope is global: withAnimation() will animate any pending state changes on the visible screen, instead of executing a closure-scoped transition on the subtree.

I put together a repro skip app - The repro app has 2 sibling UI components, the opacity of each is changed from 1 to 0 for both, but only one component should animate the opacity per the withAnimation() closure.

• Android: both ui components animate
• iOS: only the closure-targeted component animates (expected behavior)

I am happy to attempts a PR, but it looks like an honest long-term fix will require a serious refactor so I am checking in first in case this needs to be handled by someone who is a lot more familiar with this codebase than I am.

[tifroz]

I started the investigating the possibility of a PR, but I am running into a brick wall: a real fix would require the transpiler support to carry transaction metadata with plain animatable values across child view boundaries.

Specifically, Skip needs a way to propagate mutation transaction metadata with values that cross view boundaries:

The needed support is roughly:

// Conceptual shape, not proposed public API
struct TrackedValue<Value> {
    var value: Value
    var mutationTransaction: StateMutationTransaction?
}

When generated Android code evaluates a state-backed expression such as: model.myopacity, it needs to preserve both:

• the value: 0.0
• the last write transaction for that state slot

Then, when that value is assigned into a generated view property or passed through a generated view initializer, the transaction metadata must travel with it until an animatable consumer such as opacity(_:), frame(...), offset(...), or color/style animation asks for the animation decision.

In practical compiler/transpiler terms, we need one of these shapes:

• pass hidden transaction metadata alongside animatable view arguments
• wrap animatable-capable primitive values in an internal tracked value representation during generated view evaluation
• synthesize a side table keyed to generated view property storage so child body evaluation can recover the transaction attached to each stored value

The important requirement is per-value metadata. A global "latest transaction" or frame-level queue is not reliable because unrelated state reads and nested Evaluate calls interleave before toAnimatable(...) runs.

Happy to keep working on this PR if the transpiler can be augmented to accommodate this need (I am also open to alternative options)

Side note (provided for context, this is not related to the transpiler ask)

The PR as it stands would span 3 packages:

• SkipUI
• SkipModel (MutableStateBacking.swift) - where we can keep track of state mutation happening inside an animation transaction
• SkipAndroidBridge (Observation.swift) - to support @Observable properties, the bridge needs to record the active mutation transaction and triggers the Kotlin-side state update + report back the transaction associated with that observed property read.

[dfabulich]

I'm not sure I quite understood your transpiler request, but in other cases, Skip UI passes data between components using internal-only @Environment values, usually starting with _. Would that work?

[marcprux]

Here's a reproduction that can be seen in the Showcase AnimationPlayground.swift:

struct AnimationPlayground: View {
    @State var isOn = false
    @State var unrelatedIsOn = false
    @State var isRepeatOn = false

    var body: some View {
        ScrollView {
            VStack(spacing: 16) {
                Text("Also see the `Transition` playground for view enter/exit animations")

                HStack {
                    Color.green
                        .frame(width: 100, height: 100)
                        .opacity(unrelatedIsOn ? 0.2 : 1.0)
                    Color.red
                        .frame(width: 100, height: 100)
                        .opacity(isOn ? 0.2 : 1.0)
                }
                Button("withAnimation") {
                    withAnimation { isOn.toggle() }
                    unrelatedIsOn.toggle()
                }
                .buttonStyle(.bordered)

I'm honestly not sure what the best fix is here. I'm not sure if transpiler work is needed, but we definitely would need to track more state than we currently are in our withAnimation implementation.

[tifroz]

I'll provide more tangible context here and try to make the argument for transpiler support.

@dfabulich The reason that a global registry by itself is limiting ties directly to the need for transpiler support: transpiled child views know an opacity by its Double value, but they cannot know where that value came from. Without preserving value provenance, child views cannot reliably make use of an animation transaction registry.

@marcprux About the need for transpiler support, I need to explain the envisioned fix in more detail:

At render time, to make a "snap" vs "animate" decision for an invalidated view, we need to be able to answer:

• does this view have an animatable property controlled by a tracked state source?
• was this specific tracked source updated by a withAnimation block?

Let's consider a practical example. Suppose we have a stack view that features a green tile (animated opacity) and a red tile (snap opacity), like so:

struct ParentView: View {
    @State private var greenOpacity = 1.0
    @State private var redOpacity = 1.0

    var body: some View {
        HStack {
            Tile(color: .green, opacity: greenOpacity)
            Tile(color: .red, opacity: redOpacity)
        }
    }

    func runRepro() {
        redOpacity = 0

        withAnimation(.linear(duration: 1.5)) {
            greenOpacity = 0
        }
    }
}

struct Tile: View {
    let color: Color
    let opacity: Double

    var body: some View {
        Rectangle()
            .fill(color)
            .opacity(opacity)
    }
}

Today the transpiled version looks something like this:

class ParentView {
    var greenOpacity: Double
    var redOpacity: Double

    @Composable
    fun body() {
        HStack {
            Tile(color = Color.Green, opacity = greenOpacity)
            Tile(color = Color.Red, opacity = redOpacity)
        }
    }
}

class Tile(
    val color: Color,
    val opacity: Double
) {
    @Composable
    fun body() {
        Rectangle()
            .fill(color)
            .opacity(opacity)
    }
}

In the Compose ParentView, greenOpacity is a mutable state-backed property. SkipUI can detect that the mutation occurred while a withAnimation transaction is current and store that transaction beside the tracked state slot for greenOpacity.

In the Tile view, opacity is an anonymous value (Double) which cannot be traced back to a source (greenOpacity or redOpacity).

So we have enough information while evaluating ParentView.body to make the animate vs snap decision for values read directly there.

In ParentView we can recover the animation transaction at the greenOpacity read site. But the child Tile view registers an animatable opacity modifier using only a stored Double; by that point we have no way to recover the original animation transaction.

In summary, so far:

• With the legacy global _withAnimation frame window, at render time we only know that an animation is present. Any animatable value change that lands in that same window can pick up the animation, even if its write was outside the withAnimation closure.
• With the fix described above, at render time
  • at the parent view level, we have all the information we need to apply animation to select properties at the view level (if the parent view does the rendering, everything works out)
  • at the subtree level, all we have is an anonymous opacity value, so the subviews can't know if they should care about greenOpacity or redOpacity; we inevitably fall into a pattern where we animate everything or animate nothing

The instrumentation confirmed this split:

• during the write, greenOpacity records a non-nil transaction and redOpacity records nil
• during ParentView evaluation, reading greenOpacity records that transaction in StateTracking
• by the time Tile.body calls .opacity(opacity), toAnimatable(...) sees no transaction because opacity is now just a stored Double

A transpiler-assisted version would need to preserve the transaction alongside the animatable value through the subtree:

class ParentView {
    var greenOpacity: Double
    var redOpacity: Double

    @Composable
    fun body() {
        val greenOpacityValue = greenOpacity // The getter/access hook records green's last write transaction in StateTracking
        val greenOpacityTransaction =
            StateTracking.consumeMutationReadForLastStateAccess() // Capture the transaction recorded by the immediately preceding state read

        val redOpacityValue = redOpacity
        val redOpacityTransaction =
            StateTracking.consumeMutationReadForLastStateAccess()  // redOpacity records a nil transaction entry, so this consumes nil

        HStack {
            Tile(
                color = Color.Green,
                opacity = greenOpacityValue,
                opacityTransaction = greenOpacityTransaction  // greenOpacityTransaction not nil, will animate when value changes
            )

            Tile(
                color = Color.Red,
                opacity = redOpacityValue,
                opacityTransaction = redOpacityTransaction  // redOpacityTransaction nil, will not animate
            )
        }
    }
}

class Tile(
    val color: Color,
    val opacity: Double,
    val opacityTransaction: AnimationTransaction?
) {
    @Composable
    fun body() {
        Rectangle()
            .fill(color)
            .opacity(
                opacity,
                transaction = opacityTransaction
            )
    }
}

We could use a different shape, for example a wrapper like so:

data class TrackedValue<T>(
    val value: T,
    val transaction: AnimationTransaction?
)

But the wrapper is only one possible implementation. Hidden parallel fields may be more practical:

class Tile(
    val color: Color,
    val opacity: Double,
    val opacityTransaction: AnimationTransaction?
)

The important requirement is that the transpiler captures transaction metadata immediately after tracked reads and carries it through generated view properties until an animatable modifier consumes it.

Note that the proposed implementation still has limitations. Today it should support @State variables and @Observable variables, but support for plain @Environment values still needs work. The patch relies on a combination of global registries and read/write ledgers, which can be brittle in some corner cases. Multiple-source values would also need some kind of merge rule.

The point of my argument is that without transpiler support, child views are value-provenance blind, and at this time I fail to see how to overcome this limitation within SkipUI alone.

[tifroz]

@marcprux I'd love to get this fixed because it breaks many real-life animations, and the app-side workaround (gating animated Vs non-animated changes) is brittle + messy and would have to be untangled after the bug is addressed.

Happy to contribute in any way I can! Let me know if you have a direction in mind, I can prototype / test / validate assumptions?

[marcprux]

I am definitely supportive of getting this fixed! I do still wonder whether transpilation support is strictly required, and would like to explore options without needing to get the transpiler involved. Also interested in @aabewhite's thoughts.

Could we just have withAnimation { … } set some global flag in skip-model's observation that enacts a special flag for state tracking? I admit I haven't had time to fully think this through, but I do feel like there might a lighter-weight approach to getting animation working correctly.

You are also certainly welcome to file any draft PRs around this (either with or without skipstone-specific support) and we will be happy to iterate on this with you.

[tifroz]

I submitted the main PR to SkipUI, and 2 supporting PRs

• SkipModel
• SkipAndroidBridge

The GH Actions failures for the SkipUI PR are expected because of the cross-dependencies. I will look into the GH Action failures for SkipModel, SkipAndroidBridge

I can't see a way out of some kind of transpiler support at the moment - if there is one, we need to be careful not to trade some (real) additional transpiler complexity for a large complex system in SkipUI: A large & long-lived global registry would be much more brittle than the the tiny, short-lived -still global- registries introduced in this PR.

The net effect of the 3 PRs as-is (without transpiler support) is that none of the animations run (everything snaps). However with added instrumentation it confirms my understanding of how things work and should fix the bug if transpiler support is implemented with the limitations described above (@Environment and Multi-Source values off the top of my head)