Rinf: Rust Business Logic Behind a Flutter UI

The gap Rinf fills between Dart and Rust

Flutter gives you one codebase that compiles to Linux, Android, Windows, macOS, iOS and Web. Dart is pleasant for widgets and object-oriented app code, but the README argues its non-native garbage collection "may not always meet demanding performance requirements" and that its data manipulation packages are thinner than Rust's. Rust gives you threads, crates and predictable memory, but its GUI story is the weak side: the README says Rust's GUI ecosystem "is far from being mature" compared with Flutter's widgets, hot reload and debugging tools.

Rinf is the seam between those two positions. You keep Flutter for everything the user sees and Rust for everything the user waits on. The README frames the target audience implicitly: teams building cross-platform apps who already know both languages and do not want to choose one. It is not a general-purpose binding generator, and it is not a way to call arbitrary Rust functions from Dart. It is a message-passing layer with generated types, and the whole design follows from that choice.

How the Rust-to-Dart message channel actually works

The mechanism is a signal. On the Rust side you define a message struct, derive the traits Rinf expects, and call a method that sends it. The README's example sends a struct with an integer and a boolean:

MyMessage {
  current_number: 7,
  other_bool: true,
}
.send_signal_to_dart();

On the Dart side the same message arrives as a stream. A StreamBuilder subscribes to a static stream on the generated class, checks whether a packet has arrived yet, and reads the typed field off it:

StreamBuilder(
  stream: MyMessage.rustSignalStream,
  builder: (context, snapshot) {
    final signalPack = snapshot.data;
    if (signalPack == null) {
      return Text('Nothing received yet');
    }
    final myMessage = signalPack.message;
    return Text(myMessage.currentNumber.toString());
  },
)

Two details matter here. First, the Dart class MyMessage and its camelCase field currentNumber are generated, not written by hand; the README states that all Dart classes are generated by Rinf in a type-safe way and that you define the schema through derivable traits in Rust. Second, the direction is reversible: the README says messaging from Dart to Rust is also possible in a similar manner. The transport is native FFI with no webview, no local web server and no hidden threads, which the README presents as the reason there is no unnecessary memory copying. The trade-off is that your Rust side is event-driven rather than a set of callable functions, so request-response patterns have to be built on top of the signal stream yourself.

Installing Rinf and sending your first signal

The README does not print a step-by-step install sequence; it points to the documentation site at cunarist.github.io/rinf and to the example app under flutter_package/example in the repository. The repository layout shows the split clearly: rust_crate holds the Rust library, rust_crate_proc holds the procedural macros that generate the Dart classes, rust_crate_cli is a separate binary crate excluded from the workspace, and flutter_package holds the Dart side. The workspace Cargo.toml patches crates.io so that rinf and rinf_proc resolve to local paths during development.

Because the README gives no command list, the honest first step is to read the documentation and copy the example. What the README does show is the shape of the code you will write once the package is in place. On the Rust side, a message is a struct that you send:

MyMessage {
  current_number: 7,
  other_bool: true,
}
.send_signal_to_dart();

On the Dart side you consume it through the generated stream, as shown in the communication example earlier. The README claims setup takes "about a minute or two", which is a claim about the template rather than a measured figure, and it is worth treating as such until you have run the example yourself. The repository also carries a Python automation workspace: pyproject.toml defines a uv workspace over automate and documentation, and its comment says scripts are run with `uv run automate [command_type]` and that shell scripts are avoided because they are platform-dependent. That is where build and test automation lives, not in a Makefile.

Where Rinf stops being the right tool

The clearest limitation is stated by the project itself, in a notice at the top of the README: the maintainers say they are "currently unable to dedicate as much time as this project deserves" and are looking for someone to take over with full authority over the API design and build system. That is a governance risk, not a bug, and it does not show up in a test run. It means the API you build against today is the API a future maintainer is free to redesign.

A second constraint is the message-passing model. If your app is mostly a thin Rust library with a few screens, the generated-class workflow and the signal stream add ceremony compared with calling a function directly. If your Rust side needs to expose a large existing API surface unchanged, Rinf is the wrong shape: it wants you to define messages.

A third is platform scope. The README marks Linux, Android, Windows, macOS, iOS and Web as tested and supported, and lists eLinux through sony/flutter-elinux as experimental. If you are targeting an embedded Linux device, you are outside the tested set. The README does not document a rollback path for a failed release, and it does not describe what happens to generated Dart classes when a message schema changes incompatibly; the CHANGELOG.md file exists in the repository, but the README does not summarize a deprecation policy.

Rinf compared with a direct Flutter-Rust binding

The obvious alternative is flutter_rust_bridge, which the search data around this project keeps pairing with Rinf. The difference is in what gets generated. flutter_rust_bridge is built around exposing Rust functions and types to Dart as callable API, so you write a Rust function and call it from Dart much as you would call any other function. Rinf inverts that: you define message structs, Rinf generates matching Dart classes, and the two sides exchange signals asynchronously over FFI. Neither approach is a superset of the other. If your Rust code is already a library of functions you want to invoke on demand, the function-call model fits without restructuring. If your Rust code is a long-running engine that pushes state changes outward, the signal model fits, and the README's claim that hundreds or thousands of message APIs stay manageable is aimed at exactly that case.

The README's own framing of Rinf as "a very thin wrapper around Dart and Rust" is the useful test: it does not try to be a runtime, a scheduler or a plugin system. Anything you need beyond message passing comes from the Flutter and Rust ecosystems you already use.

Licence and the cost of keeping up

Rinf is MIT licensed, which is permissive and places few obligations on how you distribute a compiled app. The repository's LICENSE file is the authoritative text; nothing here is legal advice, and if your organisation has a policy on third-party licences, read that file rather than this paragraph.

The upgrade cost is harder to pin down. The release history shows v8.10.1 on 2026-08-15, following v8.10.0 on 2026-03-09 and v8.9.1 on 2026-02-18, so the project is on a major-version sequence that has moved more than once. The README does not describe a migration process between major versions, and it does not promise API stability. The last push to the default branch was on 2026-09-03, which is recent, but the maintainer notice at the top of the README is the more important signal for anyone planning a multi-year dependency: you are adopting code whose future design authority is unsettled. Pin both the pub package and the crate version, and read CHANGELOG.md before moving either.

Editorial conclusion

Adopt Rinf if your app already leans on Flutter for UI and you want the heavy data work in Rust without hand-writing FFI glue, and if you are comfortable depending on a project whose README asks for a new maintainer. Do not adopt it if you need a documented deprecation policy, a migration guide, or a maintainer with spare capacity, because the README offers none of those. Before committing, verify three things: that your target platform is in the tested list, that the generated Dart classes cover the message shapes you need, and that the version pinned in your pubspec and Cargo.toml matches a release whose changelog you have actually read.

Frequently asked questions

Official sources

1. cunarist/rinf on GitHub
2. Issues
3. License: MIT
4. README
5. Releases