Figma shipped native Motion. A real animation timeline, right inside the file.
When that landed, a lot of people emailed me some version of the same question: "is MotionKit dead now?"
Fair question. My honest first reaction was a quiet "...maybe." But the more I used native Motion, the clearer it got — it's genuinely good, and it's not trying to be everything. No physics. No frame-by-frame. No Lottie export. No morphing. So the move was never to compete with it. The move was to bridge to it — let the two tools hand work back and forth, and let MotionKit be the power layer that does the stuff native Motion can't.
So that's what this update is. A two-way bridge between MotionKit and Figma's native Motion.
Here's everything it does, and exactly how to use it.
The short version
Four moves, one little control in the header:
- Import native Motion into MotionKit as real, editable keyframes
- Live sync (read-only by default) so changes in Figma Motion flow into MotionKit as you work
- Link for export so your native Motion renders inside a Lottie without duplicating anything
- Push MotionKit keyframes back into native Motion — including motion you baked from the physics engine
And the headline trick: bake a real physics drop in MotionKit, then push it into Figma Motion as native keyframes. Native Motion has no physics engine. Now it kind of does.
First, find the bridge
Look at the top-right of the toolbar, next to the Pro star. There's a small badge: the MotionKit diamond, an arrow, and the Figma logo.
That little arrow is the status. You don't have to open anything to read it:
- faint dotted line → not connected
- arrow pointing into MotionKit → reading from Figma, live, read-only
- arrows on both ends → two-way, MotionKit also writes back
If there's native Motion sitting on the current frame but you haven't connected, you'll see a small purple dot on the Figma side — that's "hey, there's something here to import." Click the badge to open the bridge.
That's the whole mental model. Direction of the arrow = direction of the data. I rebuilt this specifically so you never have to remember what some toggle does.
Import: pull native Motion in as editable keyframes
This is the one most people want first. You (or a teammate) animated something in Figma Motion, and you want it as proper MotionKit keyframes — to refine the curves, add morphs, export to Lottie, whatever.
- select the animated frame
- open the bridge and hit Import from Figma Motion
- pick how conflicts resolve — Figma wins (native overwrites) or Keep mine (native only fills gaps)
- done. you get a little report of what came across, what got an approximated easing, and what was skipped
It pulls transforms, opacity, size, corner radius, stroke weight, auto-layout spacing, solid fills and strokes, drop and inner shadows, and blur — as real keyframes you can grab and move. Position and scale come in as proper X/Y so you can edit each axis on its own.
One honest note: once MotionKit owns a transform, MotionKit drives it during preview. That's the trade for editability. If you'd rather native Motion stay in charge of movement, keep reading — Link is for exactly that.
Live sync: read-only by default, on purpose
Turn the direction control to Read and MotionKit keeps pulling changes from Figma Motion as you work. Tweak a curve natively, it shows up here.
The important part: read-only is the default, and it will never touch your Figma file unless you explicitly switch to Two-way. Sync turning on used to scare people because an early version could write back when you didn't expect it. Not anymore — Off, Read, and Two-way are one clear three-way switch, and Read is a one-way street into MotionKit.
Link for export: native Motion in your Lottie, zero duplication
This is the cleanest option and honestly the one I'd reach for most.
When you Link Figma Motion for export, MotionKit references the native animation instead of copying it. Nothing gets added to your timeline. Nothing moves on the canvas. No duplicate rows, no two engines fighting over the same layer and sending it twice as far as it should go.
Then when you export to Lottie, MotionKit folds the native Motion in at render time and ships one animation — your MotionKit layers and the native Motion together. Your MotionKit keyframes always win on any property you actually animated; native just fills the rest.
- open the bridge
- hit Link Figma Motion for export
- animate the rest in MotionKit like normal
- export to Lottie — the native motion is baked into the file
If you go back and edit the Figma path afterward, just hit Link again to refresh the snapshot.
The fun one: bake physics in MotionKit, push it into Figma Motion
Native Motion can't simulate physics. MotionKit can — and it bakes the result into normal keyframes. So you can author a real physical bounce in MotionKit and then hand those keyframes to native Motion.
Here's the full loop:
- drop in the layer you want to throw or bounce
- add a Physics modifier — set gravity, bounce, mass, and mark whatever's the floor or a wall as a collider
- hit Bake. MotionKit runs an actual rigid-body simulation and writes it back as real position/rotation keyframes (re-bake as much as you want — it always replays from the top)
- happy with the drop? open the Figma Motion bridge
- expand Advanced → Push to Figma Motion
- confirm (back up your file first — every push is backed up and revertable, but still), and the baked bounce now lives as native Figma Motion keyframes
Now the motion is native. It plays with Figma's own Motion engine, lives in the file, and anyone can open it without the plugin. You used MotionKit purely as the physics authoring tool. That's the whole idea of the bridge — each tool doing the part it's best at.
Push writes the round-trip-safe subset (transforms, opacity, size, color, shadows, blur, and friends), so a tumbling, bouncing object's position and rotation transfer cleanly. Easings without an exact native match get approximated, and the report tells you which.
Bonus: nested frames animated in Figma Motion
If a child frame inside your frame is animated natively, MotionKit can pull it in as a previewable clip — so it actually plays inside your timeline, with its own loop mode you control per clip. When MotionKit spots one, you'll get a one-click "import as clips" prompt. Handy for building a scene out of pieces other people animated natively.
What survives the trip (the honest table)
Trust matters more than hype, so here's the real list.
Round-trips both ways: position, scale, rotation, opacity, size, corner radius, stroke weight, auto-layout spacing, solid fill & stroke color, drop & inner shadow, layer & background blur.
MotionKit-only (stays here, reported as skipped on push): text animation, shape morphing, frame-by-frame, gradient-stop animation, the beta noise/texture/glass effects, and expression-driven properties. These are the things native Motion has no slot for — so MotionKit keeps them, and uses Link-for-export when you need them in a final render.
No silent data loss. The bridge always hands you a report of what mapped, what got an approximated easing, and what it couldn't translate.
The one real limitation
Figma's plugin API lets me read and write Motion keyframes, but it can't move native Motion's playhead or evaluate it at an arbitrary time. So I can't show you Figma's native render and MotionKit's preview playing in perfect lockstep on the same canvas — that part isn't possible yet.
That's why Link-for-export is a snapshot you re-link after edits, instead of a live mirror. The day Figma adds a "give me the value at time t" call, that seam flips to live and most of this gets even better. I've already filed it as the number one thing I want from the Motion API.
Where this is going
The direction is simple: MotionKit as the Pro power layer that sits on top of native Motion. Native Motion handles the clean, file-native basics. MotionKit handles physics, frame-by-frame, morphing, expressions, and Lottie — and the bridge moves work between them without you redoing anything.
And as always — if something feels off or breaks, tell me. Half of every release is just people telling me what annoyed them.
happy animating.
Top comments (0)