Lottie-Windows and the route from After Effects to a native WinUI animation

Windows joins the Lottie family that already covers Android, iOS and web

Lottie-Windows is a library for rendering Adobe After Effects animations natively in a Windows application. The README positions it as the Windows member of the Lottie family of tools, alongside the Android, iOS and Web implementations, all of which consume the same Bodymovin JSON that the After Effects Bodymovin exporter produces.

The value proposition is stated in design terms. Lottie is described as simplifying the design-to-code workflow for bringing interactive vector animations into applications, with improvements in performance, quality and engineering efficiency over traditional approaches such as gifs or manually coded animations. On Windows specifically, the implementation uses the Windows.UI.Composition APIs to provide smooth 60fps animations and resolution-independent vector graphics.

Those two properties are the reason to prefer it over a gif. A gif is a fixed bitmap, so it scales badly, it cannot respond to state changes, and it carries no interactivity. A Lottie animation is vector data driven by the composition engine, so it stays sharp at any scale and can be bound to application state.

The scope is narrower than the design goal might suggest, though. This is a Windows library, and the supported front ends are WinUI 3 and UWP. There is no WinForms, WPF or web target here.

Three products live in the repository, and they serve different stages

The README describes Lottie-Windows as consisting of three related products.

The library is the first, and it is the component that ends up in your application. It parses and translates Bodymovin JSON files.

LottieGen is the second, a command line tool for generating C# or C++ code to be used instead of JSON. This is the interesting one, because it moves the animation out of a data file and into compiled source, which changes the runtime story completely.

The Lottie Viewer is the third, an application for previewing JSON and also for generating code. It is a design tool rather than a runtime dependency, and it means a designer can check an animation and produce the generated code without leaving the toolchain.

The repository also holds the source for the samples, so the sample applications are the executable documentation for how the pieces fit together.

The directory listing backs up the split: `Lottie-Windows/` for the library, `LottieGen/` for the generator, `LottieViewer/` for the tool, `LottieSamples/` for the samples, plus `tests/`, `build/`, `dlls/` and `source/`. There is a solution file, `Lottie-Windows.sln`, and shared build configuration in `Directory.Build.props` and `Directory.Build.targets`, with `global.json` pinning the SDK, `version.json` holding the version, `VERSION_HISTORY.md` recording the history and `stylecop.json` plus a ruleset for style enforcement.

Option one loads JSON at runtime through LottieVisualSource

The README offers two integration options, and the first uses a dynamic loader.

You install the `CommunityToolkit.WinUI.Lottie` NuGet package for a WinUI project, or `CommunityToolkit.Uwp.Lottie` for a UWP project. If you are using C# you may also need `Microsoft.Graphics.Win2D` at version 1.0.5 or below for a WinUI project, or `Win2D.uwp` and `Microsoft.UI.Xaml` for a UWP project.

The XAML then declares a namespace and uses the visual source with a UriSource that points at an asset path or a web link to a JSON file:

        ...
        xmlns:lottie="using:CommunityToolkit.WinUI.Lottie"
        ...
        <AnimatedVisualPlayer>
            <lottie:LottieVisualSource UriSource="<asset path or web link to a json file>" />
        </AnimatedVisualPlayer>

The UWP variant differs in the player element, because UWP uses the Microsoft.UI.Xaml.Controls namespace:

        ...
        xmlns:muxc="using:Microsoft.UI.Xaml.Controls"
        xmlns:lottie="using:CommunityToolkit.WinUI.Lottie"
        ...
        <muxc:AnimatedVisualPlayer>
            <lottie:LottieVisualSource UriSource="<asset path or web link to a json file>" />
        </muxc:AnimatedVisualPlayer>

The UriSource accepting a web link is the detail worth pausing on. It means an animation can be fetched at runtime, which is convenient for remote content and for iterating without shipping a new binary each time a designer tweaks a curve.

Option two generates C# from the JSON, and the README recommends it

The recommended path is code generation, and the difference from the loader is that the JSON stops being a runtime input.

You install the tool with `dotnet tool install lottiegen` in PowerShell, then run the generator with an input file, a target language and a Windows UI version. The README's example is `lottiegen -InputFile MyAnimation.json -Language cs -WinUIVersion 3.0`. For UWP projects you use `-WinUIVersion 2.X`, depending on the version of `Microsoft.UI.Xaml`, and the other language options are `cppwinrt` and `cppcx`.

After that you add the generated source files to the project, install the packages from step two of the loader option if you still need them, and declare the animation in XAML through the generated namespace:

        ...
        xmlns:animatedvisuals="using:AnimatedVisuals"
        ...
        <AnimatedVisualPlayer>
            <animatedvisuals:MyAnimation/>
        </AnimatedVisualPlayer>

The UWP form is the same idea with the Microsoft.UI.Xaml.Controls player:

        ...
        xmlns:muxc="using:Microsoft.UI.Xaml.Controls"
        xmlns:animatedvisuals="using:AnimatedVisuals"
        ...
        <muxc:AnimatedVisualPlayer>
            <animatedvisuals:MyAnimation/>
        </muxc:AnimatedVisualPlayer>

What you gain is that the animation becomes compiled code, with no JSON file to ship and no parsing at startup. What you give up is the ability to swap the animation at runtime. That is why the README marks this option as recommended and the loader as an alternative: most applications have a fixed set of animations, and for those, generated code is simpler to deploy.

The supported SDK floor and the UWP legacy path

The README states one supported SDK requirement: the May 2019 Update, build 18362, and later.

That single line is the whole compatibility story, and it cuts both ways. It means the library does not have to carry workarounds for older Windows builds, which is a real simplification for a project that reaches into the composition engine. It also means the library is useless on a Windows version that cannot be updated.

The dual WinUI 3 and UWP support is the other structural fact. WinUI 3 is the current stack, with `Microsoft.UI.Xaml` and the `AnimatedVisualPlayer` element used directly. UWP is the older one, where the same player lives in the `Microsoft.UI.Xaml.Controls` namespace and the version is selected with `-WinUIVersion 2.X` for codegen, matched to the `Microsoft.UI.Xaml` version in the project.

Carrying both is a maintenance cost for the project and a decision for the consumer. The two packages are published separately, `CommunityToolkit.WinUI.Lottie` and `CommunityToolkit.Uwp.Lottie`, and the README's build status table tracks both, along with LottieGen, with a NuGet version badge for each.

Releases stopped in 2024 while commits kept landing

The release history is where you have to look carefully. The tagged releases are v8.1.240821.1 from 2024-08-27, v8.0.280225.1 from 2024-07-22 and v8.0.280224.1 from 2024-04-11. The repository is not archived and the last push was on 2026-10-01.

That gap between the newest tag and the newest commit is a year of unreleased work, and it means the packages on NuGet are behind the source tree. The `VERSION_HISTORY.md` file at the root and the `version.json` file are the places to look for what has changed since, rather than the tags.

The version naming itself is worth understanding. The suffix encodes the build date, so v8.1.240821.1 is a build from 2024-08-21. That is a pattern designed for shipping on a schedule, and it also means there is no semver minor version to reason about when you take an update.

Continuous integration runs on Azure DevOps rather than GitHub Actions, with one definition per package, and the README's table links a build status badge and a NuGet version badge for each of the three products.

The project is supported by the .NET Foundation and follows the Contributor Covenant code of conduct, with the .NET Foundation code of conduct linked as well.

Where this library does not apply, and how to read its licence

Three limits are worth stating plainly. The first is the platform. The library is built on the Windows.UI.Composition visual layer, and the documented integration paths are WinUI 3 and UWP. A WPF application, a WinForms application or a browser application cannot use it as documented, and would have to look at the Web member of the Lottie family instead.

The second is the dependency constraint. For a C# WinUI project, `Microsoft.Graphics.Win2D` at version 1.0.5 or below is called out as a possible requirement, and that ceiling is the kind of constraint that collides with other packages in a large solution.

The third is the format. The library consumes Bodymovin JSON, which means the animation has to be exported from After Effects in that format. The README does not document which After Effects features survive the export, so the honest test is to export and view, and the Lottie Viewer exists for exactly that.

On the licence, the repository is published under a custom licence that GitHub cannot classify, and the terms live in the `LICENSE.md` file at the root. Since this is a Microsoft project under the .NET Foundation with a public package feed, read that file and the NuGet package terms before you ship a commercial application built on it.

Editorial conclusion

Lottie-Windows is the right choice for a WinUI 3 or UWP application that needs to ship vector animations produced in After Effects, and the code generation path is the one to prefer when the animations are fixed and you want no runtime JSON parsing. It is the wrong choice for a WPF, WinForms, WPF or web front end, since the library targets the Windows.UI.Composition APIs, and for a project that cannot take a dependency on the version of `Microsoft.Graphics.Win2D` pinned at 1.0.5 or below. Verify first that your animations are Bodymovin JSON and not After Effects files with features the exporter does not support, and check the `VERSION_HISTORY.md` file in the repository, since the newest tagged release is v8.1.240821.1 from 2024-08-27 while the last push was on 2026-10-01.

Frequently asked questions

Official sources

1. CommunityToolkit/Lottie-Windows on GitHub
2. Issues
3. Project website
4. README
5. Releases