# forui: a shadcn-style widget set for Flutter, and what it costs to adopt

> Forui is Duobase's Flutter UI library of over 50 shadcn-inspired widgets with a theme builder, a codegen CLI and localization generation. Adopting it means accepting a Flutter 3.47.0 floor and a design language you are meant to restyle rather than extend.

**duobaseio/forui** — Duobase's Flutter UI library

- Repository: https://github.com/duobaseio/forui
- Website: https://forui.dev
- Stars: 2,362 · Forks: 136
- Language: Dart
- License: NOASSERTION
- Published: 2026-09-30 · Updated: 2026-09-30 · Language: en
- Canonical page: https://hysenlabs.com/projects/duobaseio-forui

## What Forui is, and what it copies

Forui is a Flutter UI library that describes itself as a set of beautifully designed, minimalistic widgets, heavily inspired by shadcn/ui and fully customizable. That origin matters more than it might appear. shadcn/ui is a distribution model where you copy component source into your own project rather than installing a black-box dependency, and a Flutter library inspired by it inherits a different philosophy from Material or Cupertino: the visual language is the product, and you are expected to restyle it rather than accept it.

The README lists over 50 widgets, an interactive theme builder that exports themes through Forui Create at create.forui.dev, a bundled CLI for generating theme and styling boilerplate, and I10n support. Documentation, a widget gallery, the pub.dev API reference and a public roadmap are all linked from the top of the repository.

The intended reader is a Flutter team that has decided against Material's default look, or a team porting a shadcn-styled web design system to mobile. What Forui offers is the component layer of that port plus the tooling to keep theme code out of your feature files.

## The Flutter version floor is 3.47.0

The README opens with a flagged note rather than burying the constraint: Forui 0.26.0 and later requires Flutter 3.47.0 or newer, and it tells you to check with `flutter --version`.

```bash
flutter --version
```

That is a recent toolchain for a library that is on its 0.27.x line, and it has consequences for adoption. A team pinned to a Long Term Support Flutter release cannot take the current version without moving its toolchain, which is a project-level decision rather than a dependency bump. A team already tracking Flutter can take it, and the README says Forui is part of Flutter's customer test registry and is tested against every Flutter change, which cuts the other way: the library is exercised by upstream changes that most other packages never see.

So the trade is explicit. You get a package validated against upstream churn, at the price of riding that churn yourself. The `customer_test.bat` and `customer_test.sh` scripts at the repository root, along with their setup counterparts, are how that registration is exercised in CI.

## Adding Forui to a pubspec.yaml

The stable package is published on pub.dev as `forui`, and the documentation at forui.dev/docs is the intended starting point. The README does not show a hosted dependency snippet, only the nightly one, so the exact form for a stable release is left to the pub.dev page.

What the README does give verbatim is the git dependency for the nightly branch.

```yaml
dependencies:
  forui:
    git:
      url: https://github.com/duobaseio/forui.git
      ref: nightly
      path: forui
```

Note the `path: forui` line. The repository root is not the package, the package lives in the `forui/` subdirectory, and the same shape applies to the other packages in the tree. That monorepo layout is the first thing to understand about this project.

The README is direct about the nightly risk: those builds are not guaranteed to be stable and are to be used at your own risk. Pin a specific nightly commit if you take that route, since the branch ref moves under you.

## The Makefile shows how the monorepo is built

For contributors, the Makefile is the map of the project. Each target has a long name and a short alias, and the chain runs top to bottom.

The `install` target is a single command.

```bash
flutter pub get
```

The `generate` target is a chain of three: `build_runner`, `l10n` and `snippets`, and `bootstrap` is those two combined. The build_runner step runs in two directories rather than one.

```bash
cd forui && dart run build_runner build
cd docs_snippets && dart run build_runner build
```

So code generation runs over the library and over the code samples embedded in the documentation, which is why a documentation snippet and the widget it demonstrates cannot drift apart silently.

Release tasks take parameters. `prepare` takes `package=<name>` and `version=<version>`, `release` takes the same pair, and `release-all` takes a single `version=<version>` for the whole set.

That last pair of targets is worth noting on its own. Packages in this repository do not all share a version, and a release can be cut for one package without cutting for the others.

## Theme generation: Forui Create and the bundled CLI

The design workflow is the part of Forui that goes past widget APIs. The README describes an interactive theme builder that you use visually and then export, with Forui Create at create.forui.dev named as the export path, plus a bundled CLI whose job is to generate theme and styling boilerplate.

In a Flutter codebase this addresses a familiar problem. Hand-written `ThemeData` subclasses drift, a designer tweaks a colour, and every screen needs revisiting. A theme builder plus generated theme source means the design decision is edited once in a tool and compiled into Dart.

The repository layout supports the claim. Alongside `forui/` and `forui_hooks/` there are `forui_cli/`, `create/`, `design_docs/` and `docs/`. A separate `create/` package matching the create.forui.dev domain suggests the builder is a first-class artifact rather than a documentation page.

The I10n support claim fits the same pattern. The `l10n` Make target generates localization files as part of `make generate`, which means a theme and a string catalogue are both produced artifacts of the build rather than hand-maintained assets.

## Six packages, one repository, version skew

The tree at the repository root holds several distinct packages: `forui`, `forui_hooks`, `forui_lucide`, `forui_phosphor`, `forui_internal_gen`, and `forui_cli`, plus a `spotlight/` directory and `create/`. `forui_hooks` exposes all controllers as Flutter Hooks, which the README calls first-class integration with the `flutter_hooks` package.

The recent releases show how those versioning lines drift apart. Forui 0.27.2 was published on 2026-09-25 and Forui 0.27.1 on 2026-09-24, while `forui_phosphor` reached 0.27.0 on 2026-09-21. The icon package trails the library by two patch releases while carrying the same minor number.

Two practical consequences follow. If your app depends on `forui` and a separate icon package, you should expect to manage two version constraints rather than one. And because `forui_internal_gen` is a published-looking directory, it is worth checking whether your dependency graph pulls in a package whose name marks it as internal.

## Three licences in one repository

The README splits licensing three ways: code under the MIT License in `LICENSE`, fonts under the Open Font License in the same `LICENSE` file, and icons under the ISC License. The first two point at one file and the third at a link to that same `LICENSE` path on the main branch.

That is where it gets awkward. A single file cannot be simultaneously MIT, the Open Font License and ISC, yet the README references one path for all three. The repository metadata classifies the licence as a custom licence GitHub cannot categorise, which is consistent with a repository whose licence situation is genuinely mixed rather than mislabelled.

This is not legal advice, and the resolution is simple: read the `LICENSE` file to see which terms actually apply to which asset. What is worth flagging for an adopting team is that the mapping is not unambiguous from the documentation, and that a font shipped under the Open Font License carries its own conditions separate from the code around it.

The MIT terms for the code itself are the permissive end of the spectrum and pose no obstacle to commercial use.

## Where Forui is the wrong choice

Four situations rule it out, and all four are visible in the repository rather than guessed.

First, Flutter 3.47.0 is a hard floor from 0.26.0, so a team on an older toolchain is stuck at 0.25.x or earlier. Second, the visual language is shadcn-derived and opinionated. Forui is a good answer if you want that look and a poor one if you want Material or Cupertino behaviour with nicer widgets, because the whole point of the library is a different aesthetic. Third, this is a single-vendor library. The organisation behind it is Duobase, and while the last push was on 2026-09-28 and the README says the project has been actively maintained since 2024, there is no foundation or multiple-maintainer structure described anywhere in the repository.

Fourth, being in Flutter's customer test registry is a double-edged position. Your UI library is validated against every upstream Flutter change, which also means upstream changes reach you early and without a compatibility shim between versions. Widgets for a static design system would avoid that entirely.

## Conclusion

Adopt forui when you are building a Flutter app that needs a non-Material design system and your team already tracks Flutter 3.47.0, and treat the theme builder plus make generate as the reason to choose it over assembling widgets by hand. Do not adopt it if you need Material semantics or an older toolchain. Verify first that the LICENSE file resolves the MIT, Open Font License and ISC split that the README describes with a single link, and pin the icon package separately from forui itself.

## FAQ

### What is Forui and how is it different from Material?

Forui is a Flutter UI library with over 50 widgets, heavily inspired by shadcn/ui and described as fully customizable. The distinction from Material is aesthetic and structural: Forui exists to give you a non-Material design language with source you are expected to restyle.

### What Flutter version does Forui require?

Forui 0.26.0 and later requires Flutter 3.47.0 or newer, according to the README, which tells you to run flutter --version to check. On an older toolchain you are limited to 0.25.x and earlier.

### How do I install a nightly build of Forui?

Add a git dependency in pubspec.yaml pointing at the nightly branch, with ref: nightly and path: forui because the package lives in the forui subdirectory of the repository. The README warns that nightly builds are not guaranteed to be stable.

### How does Forui integrate with Flutter Hooks?

Through the companion forui_hooks package on pub.dev, which the README describes as first-class integration exposing all controllers as hooks.

### What licence applies to Forui's code, fonts and icons?

The README states code is MIT, fonts are under the Open Font License and icons under ISC, though it links the same LICENSE path for more than one of them. Check the LICENSE file in the repository for the actual terms; this is not legal advice.

### How do Forui's packages share version numbers?

They do not always. Recent releases show Forui 0.27.2 on 2026-09-25 alongside forui_phosphor 0.27.0 on 2026-09-21, so icon and hook packages can trail the main library even while sharing the minor number. Expect to manage more than one version constraint.

## Sources

- [duobaseio/forui on GitHub](https://github.com/duobaseio/forui)
- [Issues](https://github.com/duobaseio/forui/issues)
- [Project website](https://forui.dev)
- [README](https://github.com/duobaseio/forui/blob/main/README.md)
- [Releases](https://github.com/duobaseio/forui/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/duobaseio-forui