Hi everyone, George here. Animation isn’t “nice to have” anymore. It’s how you guide users, show progress, and give feedback without adding more UI. But if you’ve ever tried to ship the same animation across web, iOS, Android, React Native, and Flutter, you’ve probably hit the same wall:

Everything looks perfect in the preview. Then it hits production and feels… off.

Most of the time, you don’t have a Lottie problem.

You have a runtime problem.

A lot of teams are still using old JSON-only Lottie players that don’t know anything about dotLottie, state machines, or theming. Designers see one thing, engineers ship another, and nobody is quite sure where the mismatch comes from.

That’s what dotLottie runtimes are built to fix.

We’ve shipped a unified set of players for Web, iOS and Android, React Native, Flutter, and more. All of them are built on the same engine, tuned for performance, and designed to understand dotLottie out of the box.

Developers are picking them up quickly. Our npm packages have gone past 33 million downloads, and monthly installations grew from about 65,000 in June 2024 to 4.7 million in November 2025, which is over 70× growth in 18 months.

Why runtimes matter more than you think

In most stacks today, “Lottie support” really means:

  • One implementation on the web
  • A different native implementation on iOS
  • Another one on Android

They all try to follow the same spec, but the details drift as gradients render differently, masks don’t match, easing and timing feel slightly off, and performance is unpredictable depending on the device.

That drift becomes expensive: Designers re-export and test the same asset multiple times. Engineers add one-off fixes per platform. QA grows a big matrix of “this breaks only on X + Y combo”.

From the outside, it looks like Lottie is flaky. In reality, the runtimes are just inconsistent.

dotLottie runtimes fix this by sharing the same rendering engine everywhere, so the animation you approve in the preview is the same one that lands in your app.

What dotLottie actually is

Classic Lottie JSON is basically one timeline in one file. It’s great for a single linear animation, but it starts to hurt once you need real UI behavior.

dotLottie (.lottie) treats things as a package instead of just a clip.

A single .lottie file can contain:

  • Multiple animations
  • State machines and their inputs
  • Theme variants (light, dark, brand styles)
  • Fonts, images, and metadata

It’s also compressed, so in many cases a .lottie file is significantly smaller than a bundle of raw JSON plus assets.

Practically, this gives you:

  • One file instead of a bunch of scattered JSONs and images
  • Fewer network requests
  • Easier caching and versioning
  • A format that’s ready for interactive, multi-state UI, not just “play once and loop”

And because a .lottie file is just a ZIP archive with a manifest, you can unzip it, inspect it, generate it, or modify it however you want.

One engine everywhere: ThorVG

All dotLottie runtimes share the same rendering engine: ThorVG.

ThorVG is a small, fast vector renderer that knows how to handle Lottie and SVG. We built it to solve a very specific problem: we needed an engine that was tiny enough to ship everywhere, fast enough to handle real UI workloads, and consistent across platforms.

The core library is around 150 KB. It runs as WebAssembly on the web and through native bindings on iOS and Android.

And since it’s open-source, ThorVG is already in production in places like:

  • Tizen
  • The Godot engine for vector workflows
  • High-scale apps like Canva, where it has delivered big gains in rendering speed and memory usage

Because all the runtimes sit on top of the same engine, you don’t get the usual “iOS looks a bit different from Android” problem. The same animation really does look the same everywhere.

Built for performance, not just “it plays”

A player is only useful if it behaves under real-world constraints: slow devices, busy pages, noisy apps.

dotLottie runtimes are tuned for that.

On the web

  • Uses WebAssembly for fast vector rendering
  • Can run rendering work in a Web Worker so your main thread stays responsive
  • Supports async loading so animations don’t block the critical path

On iOS and Android

  • Native runtimes built for smooth playback and predictable timing
  • Multi-threaded options for heavy scenes
  • Efficient memory usage so you don’t get random spikes

In React Native and Flutter

  • React Native bindings talk to the real native runtimes, not a web fallback
  • Flutter support via dotlottie_flutter, with playback control, theming, and state machines across iOS, Android, macOS, and web

Why engineers like the dotLottie model

The big shift is where the logic lives.

With dotLottie you get loads of advanced features such as state machines, transitions, and themes that live inside the .lottie file. Your app just sends events and toggles inputs, and the dotLottie handles the rest. You don’t have to hand-roll complex animation logic in your own codebase.

Examples:

  • A button animation that moves through hover → pressed → success, driven by a state machine
  • Onboarding flows that change based on which step the user is on
  • Light/dark themes that flip without new exports

This is the point where engineers usually realize they can delete code instead of adding more.

Open format, open runtimes, open engine

Some animation tools bundle the editor, the format, and the runtimes into one closed stack. That can be convenient, but it also causes some issues that may not be apparent right away.

You’re tied to one editor, so you have no hope of switching if that company decides to discontinue a service/feature that you rely on. Also, the format is opaque, meaning you can’t inspect the file to fully understand and debug what’s happening. And don’t forget that the runtime can change terms or behavior in ways you don’t control.

dotLottie takes the opposite approach. The format is open and inspectable, and the runtimes and rendering engine (ThorVG) are both open source. And as an added bonus, it all works with the existing Lottie ecosystem and After Effects workflows.

You can stay in the tools your designers already use, keep control of your pipeline, and still get state machines, theming, and multi-animation packaging.

No black boxes. No proprietary editor requirements. No vendor lock-in.

A simple upgrade path for your team

If you want to move your product to dotLottie runtimes, a lot of teams follow this pattern:

Pick one area

Choose a visible animation (button, loader, onboarding) where consistency or performance matters.

Swap the runtime

Convert the asset to .lottie and replace the existing JSON-only player with a dotLottie runtime.

Compare side by side

Run the old and new players in parallel. Visual consistency and performance differences are usually obvious immediately.

Move logic into the asset

Use Lottie Creator to enable state machines or theming so interaction logic lives in the .lottie file, not app code.

Make it the default

Standardize on dotLottie runtimes and treat legacy players as deprecated.

Once that’s in place, motion feels reliable instead of fragile. It becomes part of your design system, not one-off UI sugar.

Real-world benefits teams care about

Teams using dotLottie runtimes usually talk about the same wins:

  • Faster cold loads, especially on mobile
  • Less QA time spent on “this animation is slightly wrong on X”
  • The ability to update animations without shipping new app binaries
  • Smaller bundles and better performance metrics on the web
  • A stack that’s transparent, open, and not tied to a single vendor

If motion is part of your product, not just decoration, then your runtime matters as much as your design.

Try it in your stack

You can plug dotLottie runtimes into most setups with just a few lines of code.

Key packages: