Konfetti: a confetti particle system for Android views and Compose

Three modules, and the core one is not Android

Konfetti is a confetti particle system for Android, and the packaging is the first thing to understand about it. There are two front end modules and one core.

For a Compose project, with a minimum API level of 21:

dependencies {
    implementation 'nl.dionsegijn:konfetti-compose:2.2.0'
}

For a view based XML project, with a minimum API level of 15:

dependencies {
    implementation 'nl.dionsegijn:konfetti-xml:2.2.0'
}

Both pull in konfetti-core and konfetti-image automatically. The core is plain Kotlin with no Android dependency, which the README points out explicitly as a way to use the library on its own to build a custom renderer. That is the most interesting fact in the packaging, because it means the particle logic and the configuration are separated from the drawing, and a team that wants confetti somewhere other than a standard Android view, a custom Compose renderer, a preview tool, or a test harness, can build it on the core without inheriting the Android surface.

The repository layout matches that split, with a konfetti/ directory for the modules, samples/ for four example apps, a buildSrc/ directory, and the usual Gradle files. The samples cover compose-kotlin, xml-kotlin, xml-java and a shared module whose Presets.kt file holds reusable configurations.

The Party object holds the whole configuration

All the configuration lives in a single object called Party, and the design goal stated in the README is that almost all of its properties have a default, which is what makes the common case a one-liner.

The minimum viable configuration is an emitter, which says how often and how many confetti spawn:

Party(
    emitter = Emitter(duration = 5, TimeUnit.SECONDS).perSecond(30)
)

Everything else is optional, and the property list shows how much of the behaviour is exposed. Angle is an Int with a default of 0 and gives the direction of the shot, with presets such as Angle.TOP, Angle.RIGHT, Angle.BOTTOM and Angle.LEFT, and the note that Angle.RIGHT equates to 0 degrees with larger values moving clockwise. Spread is an Int defaulting to 360, and the documentation is explicit that 1 shoots in a straight line while 360 forms a circle.

The physics side is three floats. speed is the start speed at creation and defaults to 30f, maxSpeed is 0f by default and set to -1 to disable it, and damping at 0.9f is the rate at which the speed decreases right after the shot. The README is clear that a random speed between speed and maxSpeed creates a more natural and realistic look.

The rest covers appearance and lifetime: size as a list of SMALL, MEDIUM and LARGE, colors as a list of Int values, shapes as a list of Shape, timeToLive in milliseconds defaulting to 2000, fadeOutEnabled defaulting to true so a particle that runs out of time fades instead of vanishing, position as a Position that can be Absolute, Relative or between random locations, delay in milliseconds before rendering starts, and rotation for the 3D spin.

Custom polygons are points on a unit square

Beyond the built in shapes, which are Square, Circle and Rectangle, there are polygons. Three come built in:

shapes = listOf(Shape.Polygon.STAR, Shape.Polygon.TRIANGLE, Shape.Polygon.DIAMOND)

The polygon shapes spin, flip and fade like the other shapes, which is the part that matters visually, since a static shape would break the illusion immediately.

A custom star is one function call away, with the point count and the arm width as parameters, where Shape.Polygon.star(points = 6, innerRadius = 0.5f) makes one with 6 points and wider arms. A polygon of your own is built from a list of Shape.Polygon.Point values, each one naming a coordinate inside the particle.

The coordinate system is the detail to note. Each point is a fraction of the confetti's own square, with (0, 0) at the top-left corner and (1, 1) at the bottom-right one. That means a polygon is resolution independent and scales with the particle's size setting, which is why a shape defined that way works at SMALL, MEDIUM and LARGE without redrawing the artwork.

There is also a drawable option, Shape.DrawableShape, for using your own image as the particle. The three built in polygons plus the point constructor plus the drawable option cover most of what a celebration animation needs, and the whole list is a set of data rather than a hierarchy of subclasses.

Emitters decide when and how much, presets save the rest

The emitter is the part of the configuration you will touch most, and it has two forms. Emitter(duration, timeUnit).max(amount) produces a single burst, and Emitter(duration, timeUnit).perSecond(amount) produces a continuous stream for the length of the duration. The duration is a number and a TimeUnit together, which is why the minimal example reads as duration = 5, TimeUnit.SECONDS with .perSecond(30) applied to it.

A burst and a stream are genuinely different effects, and the choice is what turns a single pop into a celebration that lasts. A burst suits a moment like a completed purchase, and a stream suits a moment that has a duration, such as a screen the user is meant to keep looking at.

For the rest of the visual work, the samples directory holds a shared module with a Presets.kt file, and the README links it alongside the compose, xml-kotlin and xml-java samples. Presets are the practical answer to the fact that the Party object has a lot of properties, because a preset captures a whole look, the colors and shapes and angle and speed together, in one name. The four sample applications cover the two rendering paths and both supported languages, which means the example code you will actually copy is written in the language your project uses.

One customisation the emitter interacts with is delay, the number of milliseconds to wait before rendering starts. Combined with a burst emitter, that gives you the effect of a short pause before the confetti appears, which is often the difference between a celebration that feels timed and one that feels late.

Version 2.0 changed the API and the modules

The README carries a prominent note about version 2.0.0, and it is the kind of change that breaks existing code silently at compile time. The note says 2.0.0 is released with Jetpack Compose support, improved animations and an improved API, and links to a migration guide for the 2.x line.

The consequences are visible in the module names. konfetti-compose and konfetti-xml are the two entry points, and a project that was on the single pre-2.0 artifact has to pick one of them and change how it hosts the particle view. The Compose path needs API 21 and the XML path needs API 15, so an application supporting older devices can still use the library through the view module, which is the more compatible of the two.

The release history shows how fast this is moving. v2.2.0 was published on 2026-10-18, v2.1.0 on 2026-10-17 and v2.0.8 on the same day, and the last push to the main branch was on 2026-10-19. Three releases inside two days is fast enough that pinning a version rather than tracking a floating one is the sensible habit.

The licence is ISC, which is a short permissive licence, and the README carries the badge for it. The project is by Daniel Martinus, and the repository has a CI workflow, an.idea directory and a scripts/ directory, with the sources laid out under konfetti/ and the examples under samples/.

Editorial conclusion

Adopt Konfetti when you want a celebration animation on a success screen and you would rather configure a particle system than import a game engine, because the whole surface is a Party object with defaults for almost every property and the core has no Android dependency at all. Do not adopt it if you need confetti in a plain JVM or a web canvas without an Android renderer, since the shipped modules target Android views and Compose, and remember the 2.0 rewrite, because the API changed and the migration guide is the first thing to read. Before you upgrade, check which of konfetti-compose or konfetti-xml matches your project, and note that the minimum API level differs between them, 21 for Compose and 15 for the XML module.

Frequently asked questions

Official sources

1. DanielMartinus/Konfetti on GitHub
2. Issues
3. License: ISC
4. README
5. Releases