Rive Flutter: setup, renderers, and native integration

What Rive Flutter adds to a Flutter application

Rive Flutter solves the runtime problem created when animation artwork is authored in Rive but displayed through Flutter. It is intended for Flutter developers building applications or games that need more than static vector assets, including assets with runtime control over artboards, state machines, layouts, data binding, and loading behavior. The README points to separate Rive documentation for each of those subjects rather than presenting all controls as a single API.

The project occupies the client-side portion of Rive's workflow. Designers can work with `.riv` files in the Rive Editor, while application code loads those files and exposes their runtime behavior inside Flutter. The repository describes Rive as a stateful graphics format and identifies this package as its Flutter runtime. It does not provide a Flutter editor or replace the Rive Editor. Developers still need suitable Rive assets, and the Rive Flutter documentation is the authoritative reference for the APIs that operate on them.

This runtime is most relevant to teams that already standardize on Rive assets or specifically need interactive graphics shared across Flutter targets. It is a less obvious choice for a conventional Flutter screen composed mainly of built-in widgets, ordinary images, or Flutter-native vector drawing. Those needs do not inherently require a cross-platform stateful animation format, and the package adds a dependency on `rive_native` plus platform libraries.

How asset loading and renderer selection work

The documented entry point is a Rive `File` loaded from the Flutter asset bundle. Renderer selection occurs while that file is created through the `riveFactory` argument. Every graphic subsequently created from that `File` instance is documented as using the renderer chosen at load time.

The README lists `Factory.rive` for the Rive renderer and prints `Factoy.flutter` for the Flutter renderer. The README contains a spelling error in the second identifier, displaying it as `Factoy.flutter`. That exact spelling is preserved here because this review does not correct undocumented API names. The linked Rive documentation on specifying a renderer should be checked before writing production code.

The runtime supports iOS, Android, macOS, Windows, Linux, and Web. The support table marks both the Flutter renderer and the Rive renderer as available on every listed target. That does not mean their rendering results are identical. The README specifically warns that Flutter 3.10 and later use Impeller by default on iOS, which can expose visual or performance discrepancies not previously seen with Skia.

The repository also separates higher-level runtime tasks from native packaging. Rive Flutter depends on `rive_native`, whose libraries are normally downloaded during `flutter run` or `flutter build`. The Dart layer therefore does not represent the whole runtime stack. Platform packaging, downloaded native binaries, renderer selection, and Flutter's own graphics backend all affect what reaches the screen.

Installing the published package and running the example

The README recommends using the published `rive` package from Pub for normal work. Its example on GitHub may refer to an unpublished version of `rive_native`, which is why the documented setup first unpacks the published package and enters its example directory. These commands create Flutter platform folders, resolve dependencies, and launch the app on the configured target.

dart pub unpack rive
cd rive/example
flutter create .
flutter pub get
flutter run

A successful run should create the platform files in `rive/example`, fetch the declared dependencies, and start the example through the active Flutter toolchain. The README does not specify a required Flutter version for installation, so the package configuration in `pubspec.yaml` is the appropriate place to check compatibility before treating this sequence as reproducible across machines.

The bundled `example/assets/` directory contains the repository's sample assets, while `example/lib/` contains its Flutter code. The README does not give a minimal widget file for the first animation, so it would be misleading to invent one here. For a first real use beyond the example, follow the linked Getting Started with Rive in Flutter documentation and use an asset already present in the example rather than assuming an arbitrary `.riv` file has matching artboard and state-machine names.

Loading a Rive file with an explicit renderer

This repository example demonstrates the part of runtime initialization that should be verified first. It loads `assets/rewards.riv` asynchronously and passes `Factory.rive` through `riveFactory`. The non-null assertion means the code assumes that loading succeeds; production code would still need to account for failure rather than blindly reproducing that assumption.

final riveFile = (await File.asset(
  'assets/rewards.riv',
  // Choose which renderer to use
  riveFactory: Factory.rive,
))!;

The asset path is repository-specific and must be registered through the Flutter asset configuration before it can be loaded. The repository's `example/pubspec.yaml` is the reference for how its sample assets are declared. The README does not show the subsequent widget code that places the file's artboard on screen, so the linked Flutter runtime documentation should supply the rest of the example.

Renderer choice should be made at file creation rather than changed casually later. Because the documentation assigns the renderer to each `File` instance, code that needs different rendering behavior should organize separate file-loading paths deliberately. Comparing both factories on the actual target devices is more informative than choosing from desktop preview behavior alone.

Impeller discrepancies and Flutter renderer troubleshooting

The clearest runtime risk documented here is the interaction between Rive Flutter and Impeller. Since Flutter 3.10, Impeller has replaced Skia as the default on iOS and may become the default on other platforms over time. The README warns that this transition may reveal rendering and performance discrepancies that were absent under Skia.

The first diagnostic command disables Impeller for a local run:

flutter run --no-enable-impeller

If the discrepancy disappears with Skia, the README says that may indicate an Impeller rendering bug, but it asks developers to test the latest Flutter master channel before reporting the issue upstream. If the problem remains on the latest master branch, its documented next step is a detailed, reproducible Flutter issue report.

This troubleshooting sequence separates asset and state-machine issues from graphics-backend behavior. It does not prove which side owns every mismatch. A missing state, wrong artboard, or invalid asset path should not be diagnosed as an Impeller defect merely because the command works differently under Skia. The useful evidence is a comparison that changes one variable at a time: Flutter backend, selected Rive factory, asset, and target platform.

Native-library setup and the cost of controlling the build

The usual installation path is automated. The README states that required native libraries are downloaded during a Flutter build or run. When setup fails, it gives a clean and dependency-refresh sequence before suggesting direct control over `rive_native`.

flutter clean
flutter pub get
flutter run

Developers who need platform-specific setup can invoke the package setup script directly. The documented macOS invocation cleans previous setup and downloads the libraries selected by `--platform`:

dart run rive_native:setup --verbose --clean --platform macos

Prebuilt libraries are the default. Building them locally adds `flutter clean`, dependency resolution, and a `--build` variant of the setup command. The README gives this exact macOS sequence:

flutter clean
flutter pub get
dart run rive_native:setup --verbose --clean --build --platform macos

That choice affects release engineering. Automatic downloads simplify ordinary development, but teams with restricted build environments, reproducible dependency policies, or platform-specific native changes may need control over how libraries are obtained or built. The repository includes platform directories for the example, but adopters must still validate native linking on every target they package. The MIT license covers the project, although it does not remove the operational work of managing runtime versions, native artifacts, and platform builds.

Release history, maintenance, and adoption boundaries

The repository is not archived, and its last push was on 2026-10-05. However, the listed package releases are much older: versions `0.8.2`, `0.8.3`, and `0.8.4` were published in January and March 2022. The repository state and the listed release history therefore tell different stories. Code changes after the last tagged package release may matter to anyone considering a direct Git dependency, while Pub users need to determine which version is actually available there.

The README does not document a migration policy, rollback procedure, or compatibility matrix for specific Flutter versions. It also does not say how Flutter package versions map to native library revisions. These omissions matter because the package depends on `rive_native` and can be affected by changes in Flutter's graphics backend.

The README also lists a Flutter-renderer option, printed as `Factoy.flutter`. The approach differs at runtime: Rive can load and control a stateful `.riv` asset, while `Factory.flutter` renders supported Rive graphics through Flutter rather than the dedicated Rive renderer. Teams needing Rive state machines or Rive-specific runtime behavior have a reason to prefer the package. Teams wanting ordinary Flutter rendering can test `Factory.flutter` before accepting native-runtime overhead.

Editorial conclusion

Adopt Rive Flutter when a Flutter application or game needs interactive Rive assets and you can test rendering on every target platform you ship. Do not assume the package is a drop-in replacement for Flutter's standard renderer without checking `rive_native` downloads, platform notes, and assets under Impeller. The first step should be checking the linked renderer documentation, followed by a visual comparison on each supported platform.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. rive-app/rive-flutter on GitHub