material-motion-compose ports the Material motion system to Compose

What the library actually provides

material-motion-compose is a library for implementing a motion system in Material Components for Jetpack Compose and Compose Multiplatform, and the motion system it targets is the one Material itself documents.

That word, motion system, is the important one. A motion system is not a set of animations; it is a defined set of named patterns with fixed durations and fixed easing curves, so that a fade and a shared axis transition in two different screens behave the same way. The reference the library implements is the documentation Material publishes for the motion system, and the patterns are the units the library exposes.

The Core module is described as a library which provides motion patterns support for Jetpack Compose and Compose Multiplatform, and the documentation for it is published at fornewid.github.io/material-motion-compose/core.

The scope is narrow on purpose. The library does not provide theming, layout or components; it provides the motion vocabulary, and you compose it into your own components. That is a sensible division for a design system library, because the failure mode of motion libraries is usually a component library that owns your UI.

The project is written in Kotlin, is licensed under Apache 2.0, and the documentation site is fornewid.github.io/material-motion-compose. The repository carries a core/ directory for the library, a sample/ directory with a working example per platform, a docs/ directory with a mkdocs.yml and a generate_docs.sh script, build-logic/ for Gradle convention plugins, a release/ directory, and a spotless/ directory for formatting.

Adding the dependency, and the version matrix

The core artifact is published on Maven Central, and the README gives the Gradle snippet:

repositories {
    mavenCentral()
}

dependencies {
    implementation "io.github.fornewid:material-motion-compose-core:<version>"
}

The group is io.github.fornewid and the artifact is material-motion-compose-core, so the coordinates are those of a GitHub hosted package rather than a company domain.

The version to use is not a single number, and this is the part of the README that a reader has to study rather than skim. There are two compatibility tables, one for Jetpack Compose and one for Compose Multiplatform, and each Compose generation has its own published version of the library.

For Jetpack Compose, the mapping runs from 1.0.x at 0.7.7, which is the one line served by JitPack rather than Maven Central, through 1.1.x at version prefix 0.8, 1.2.x at 0.9, 1.3.x at 0.10, 1.4.x at 0.11, 1.5.x at 1.0, 1.6.x at 1.1 and 1.7.x at 1.2.

For Compose Multiplatform there are two entries: 1.4.0 at 0.12 and 1.6.10 at 2.0.

So the library version does not track the Compose version. A team on Compose 1.5 uses the 1.0 line of the library, and a team on Compose Multiplatform 1.6.10 uses the 2.0 line. The release tags confirm the pattern, with v2.0.1 and v2.0.0 in June 2024 and v1.2.1 a few days earlier.

The practical instruction is to read the table and pick the row that matches your Compose version, because the number in the dependency coordinate is not something you can guess from your own build file.

The platform coverage, and the wasm entry

The platform table is short and the last row is the interesting one.

The platform table lists four targets, and all four are marked as supported: Android, Desktop (JVM), iOS and Wasm.

Four targets, and the WebAssembly entry is the one that distinguishes this from a typical Android-only animation library. The Compose Multiplatform versions listed in the table, 1.4.0 and 1.6.10, are both in the range where the wasm target was being stabilised, so supporting it was a deliberate choice rather than a freebie.

That matters because animation code is exactly the kind of code that is easy to write for one platform and subtly wrong on another. Anything that depends on frame timing, on the clock, or on how the platform composes frames behaves differently under Wasm, where the browser owns the render loop, and a motion library that has been run against all four targets is at least aware of the differences.

The sample directory is organised by platform, with sample/android/, sample/desktop/, sample/iosApp/, sample/shared/ and sample/web-wasm/, which is a good sign for a library that claims multiplatform support: the example application is built for each of them, so the API is exercised on each rather than merely compiled.

The repository also has a kotlin-js-store/ directory, which holds lock files for Kotlin JavaScript dependencies, and a docs/ directory with a generate_docs.sh script, so the API documentation is generated rather than written by hand.

The repository as a build project

The build setup is worth a look, because it shows the project's conventions.

There is a build-logic/ directory, which in a modern Gradle project usually means included builds holding convention plugins, so that the same configuration is applied to every module without repeating it. There is a build.gradle at the root alongside settings.gradle, and a gradle.properties file, the gradle/ directory and the gradlew wrapper with its Windows counterpart gradlew.bat.

The spotless/ directory is the formatting gate. Spotless is the Gradle plugin that runs a formatter over the source, and in a library that publishes to Maven Central it is usually wired into the check task so that a build fails on unformatted code rather than on a style opinion. The .editorconfig file at the root handles the editor side of the same problem, and there is a .github/ directory with the build workflow, whose badge appears at the top of the README.

The release/ directory suggests a scripted release process, and the .idea/ directory and debug.keystore at the root are the residue of Android Studio usage, which is unsurprising for a library that started as a Jetpack Compose project.

The primary language of the repository is recorded as Kotlin, and the topics list names android, compose-animation, compose-multiplatform, jetpack-compose, material-design and material-motion, which is an accurate summary of what the library is for.

Where material-motion-compose fits, and where it stops

The comparison worth making is with two alternatives: the Compose animation APIs directly, and another design system's motion implementation.

Against the Compose APIs directly, the difference is that Compose gives you the mechanics and you supply the values. animateDpAsState, animateFloatAsState and the transition and updateTransition APIs will do the animation, but the duration and the easing curve are arguments you pass. The Material motion system says specific things: this pattern uses this duration and this easing, and this pattern is the spatial or expressive variant. The library encodes that table so the choice is a named pattern rather than a pair of numbers you looked up.

The value is consistency and correctness at the same time. Consistency, because the same pattern gives the same result in every screen, which is what the specification is for. Correctness, because the easing curves in that system are not all standard curves; several are spring-like or multi-segment, and reimplementing them from a description is where hand-rolled animations usually drift from the spec.

Against another design system, the answer is simple. These are the patterns the Material specification defines. A team working to a different design system's motion specification, or one that has defined its own, gets no benefit from this library at all, and would be better served by encoding their own patterns in the same way, which is the pattern of usage this library demonstrates.

The limits are visible in the version table. The compatibility matrix stops at Jetpack Compose 1.7.x and Compose Multiplatform 1.6.10, and the newest tagged release is v2.0.1 from June 2024, with the last push on 2026-05-28. So a project on a current Compose version is likely to be on a library version that was published against an older one, and the maintenance signal is thin: the repository is not archived, but there is no recent release to point at.

The other limit is scope. The library provides motion patterns and nothing else, so a team that also wants a theme, a set of components or a full design system still has to source those elsewhere. That is a reasonable design, and it is also the reason the core module is the only download shown in the README.

Editorial conclusion

material-motion-compose suits a team that wants its Compose animations to follow the Material motion specification rather than hand-picked easing curves, since the library encodes the named patterns and publishes them per Compose version on Maven Central. It is the wrong choice if you need the motion behaviour of another design system, since the patterns are Material's, and the wrong choice if you need the newest Compose features immediately, since each Compose generation has its own published version of the library. Before adopting it, pick the version line that matches your Compose version from the compatibility table in the README, and check that the core artifact is the one you need before adding a second module.

Frequently asked questions

Official sources

1. fornewid/material-motion-compose on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases