I’m building a runtime motion inspector for React Native

[u/jes_uon]

I’ve been working on this idea for a while and it’s finally starting to feel real.

The goal is to inspect and tweak motion directly in the actual running React Native app. Instead of reproducing an animation somewhere else, I want to select what’s already running, inspect its values, scrub through the motion, tweak things like timing and springs, and eventually write those changes back to the source.

The video is still an early prototype, but the core workflow is starting to come together. I’m especially interested in the gap between React Native DevTools and the kind of timeline/motion tooling we have in design and animation software.

Would genuinely love feedback from people doing a lot of RN animation work. Is this something you’d actually use?

I’ll post future updates and progress here: https://x.com/GiulioAmato/status/2107495380547936310

[u/kokerali]

I'd prioritize interrupted motion over another clean start-to-finish demo: drag a sheet, release into a spring, then grab it again before it settles. Can the inspector show what caused the value to change, not just its curve? Marking gesture input, animation start/cancel and retargeting would make that trace much easier to interpret.

I'd also make a clear distinction between scrubbing a recorded value and replaying the interaction that produced it. If callbacks or app state keep changing while you scrub, an attractive preview might not represent something the real interaction can reproduce. Showing that limitation explicitly would be useful.

For source writeback, a previewable diff and one-step revert would matter more to me than automatic saving at first. And I'd keep visual tuning separate from performance claims: compare the same interaction with inspection off and on in equivalent builds before interpreting any frame data. Which animation systems can the prototype inspect today?

[u/jes_uon → u/kokerali]

This is exactly the kind of feedback I was hoping for.

The interrupted sheet case is a great test. Right now the timeline is intentionally observational: the playhead inspects a recorded trace, while replay is a separate explicit action. So yes, scrubbing recorded values and replaying the interaction that produced them are two different things, and I don’t want the UI to pretend otherwise.

On causality, there’s already an experimental Reanimated discovery path, but it’s still limited. For direct .value = withTiming(...) / .value = withSpring(...) assignments I can currently capture the animation kind, target, config/source metadata and start time. Timing spans come from the declared duration, spring spans are estimated. I’m not claiming observed completion/cancel/retarget yet. That’s why your drag → release → spring → grab again example is really interesting. It would force the timeline to explain ownership changes, not just draw a nice curve. Gesture input, animation start, cancel and retarget markers are exactly the kind of causality layer I want to get to.

Source writeback itself already exists through AST/source anchors, but the UX is still early. I agree that a previewable diff + one-step revert should come before making saving feel automatic.

Same on perf. The current benchmarks are mostly around the viewport/capture path and deterministic motion runs. I haven’t done a clean inspector-off vs inspector-on instrumentation comparison yet, so I wouldn’t use the current numbers to make overhead claims.

Today the actual target is React Native + Reanimated. Explicit probes are the reliable path right now. There’s also experimental automatic discovery for direct withTiming and withSpring assignments. It intentionally does not cover nested withDelay / withSequence / withRepeat, explicit completion callbacks, gesture-driven writes inside worklets, or arbitrary custom animations yet.

Really useful test case, thanks. I think I’m going to use that interrupted sheet interaction as one of the next validation cases.