FlutterUnit: a 500+ widget gallery you can run, read and copy

What FlutterUnit solves, and who it is actually for

Flutter ships a large widget catalogue with uneven documentation. Some widgets have a clear API page and a sample; others are mentioned once and left to the reader. FlutterUnit exists to close that gap by collecting widgets into one running application. The README states the project has gathered more than 500 components, each with at least one demonstration and a code view, and that the author rates them by personal judgement because the Flutter ecosystem has no unified classification standard.

The audience is narrower than the tagline suggests. This is for people who learn by poking at a running UI: beginners mapping names to visuals, and working developers who want to see how an unfamiliar widget behaves before wiring it into a screen. It is not a package you import. Nothing in the README describes publishing to pub.dev, and the repository is an application with android/, ios/, macos/, windows/, linux/ and web/ platform folders. If you were hoping for a dependency that renders a widget gallery inside your own app, this is the wrong shape.

How the widget gallery is organised

The README describes the structure in layers. The entry list holds the collected components. A detail page exists for 213 components, and the README notes that important widgets get a fuller treatment with the demo widget and its properties shown together. Related widgets are linked to each other, so you can jump sideways from one component to a neighbour without returning to the list. The README calls this a way to satisfy curiosity and says adding a missing link is a matter of adding a number.

The detail pages are the interesting design decision. The README states that all demonstrations are built from real Flutter widgets rather than screenshots, which is what makes them interactive. A screenshot cannot be dragged, tapped or resized. A live widget can, and for gesture and animation components the README says the project provides interactive demonstrations. The code panel is the other half: an icon on the right expands or collapses the source behind the effect, the code can be shared, and the highlight style is configurable. That combination, live widget plus its own source, is the whole product. Where the README is silent is on how demos are registered or how a contributor adds a new component; there is no documented contribution path for the gallery itself, only the note that you can contact the author.

Installing and building FlutterUnit from source

The README gives the toolchain it was built against: Flutter 3.38.3 on the stable channel, with Dart 3.10.1 and DevTools 2.51.1. It does not state a minimum supported version, so matching that toolchain is the safe reading rather than a documented requirement.

To build from source, clone the repository and enter it:

git clone https://github.com/toly1994328/FlutterUnit.git
cd FlutterUnit

The README then lists one build command per platform. For Android it uses an ABI split, which produces separate APKs instead of one universal file:

flutter build apk --release --target-platform android-arm64 --split-per-abi -v

The same section gives `flutter build ios`, `flutter build windows`, `flutter build linux` and `flutter build web` for the other targets. If you only want to look at the gallery, the README points at prebuilt downloads first: an APK from the v3.4.2+2014 release, an iOS listing on the App Store, a .dmg for macOS, an .exe for Windows, and a web build at toly1994.com/flutter. Installing a release build is faster than a first Flutter build, and it is the honest way to decide whether the gallery is useful to you before you spend time on the toolchain.

Where FlutterUnit stops being the right tool

The clearest limitation is scope. FlutterUnit is a catalogue of widgets, not of Flutter as a whole. State management, networking, persistence, platform channels and build tooling are outside what the README describes, and the component list is explicitly curated by one person's judgement rather than by any standard. A widget you need may simply not be in the 500, and the 213 detail pages mean most entries are shallower than the important ones.

Second, the project is an application, so it carries application-level weight. Building it pulls in six platform folders and the full Flutter toolchain. If you want a reference you can consult in a browser tab, the web build and the prebuilt desktop releases are cheaper than a local build.

Third, the README does not document testing, CI, or how the gallery data is generated. The repository does contain test/, integration_test/ and .github/ directories, but the README says nothing about what they cover or how to run them. Anyone expecting the project to double as a source of unit testing examples will not find that in the documentation. Finally, the licence is GPL-3.0. If you plan to copy demo code into a closed-source product, that is a question for your own legal review, not something this article can settle.

How it differs from the official widget catalogue

The obvious alternative is the official Flutter widget catalogue and API documentation. The difference is in what each one optimises for. The official catalogue is authoritative: it is maintained alongside the framework, it covers every public widget, and it is where you go to confirm the exact signature and defaults of an API. FlutterUnit is experiential: it puts many widgets in one running app so you can compare them side by side, and it shows the demo source next to the demo, which the API pages do not do in the same view.

That trade-off cuts both ways. FlutterUnit can lag the framework, because it is a separate project tracking a moving target, and its descriptions reflect one developer's understanding rather than the framework team's. The official catalogue cannot lag itself. Use FlutterUnit to discover and compare; use the official API pages to confirm. Neither replaces the other, and the README's own framing supports this: it describes the app as a place to experience Flutter, not as a specification.

Maintenance, releases and the GPL-3.0 licence

The repository is not archived, and the last push was on 2026-09-21. The release history is active: v3.4.3+2019 and v3.4.2+2018 both landed on 2026-09-06, and v3.4.2+2014 on 2026-08-30. The README still titles the project as v3.4.2, so the documentation trails the newest tag by one release. That is a small but real signal: expect the README, not the release page, to be the stale artefact.

Upgrade cost is mostly on the Flutter side. The README pins its build environment to Flutter 3.38.3 and Dart 3.10.1, and a Flutter application has to move when the framework moves. If you only consume the released APK, .dmg or .exe, that cost is the maintainer's. If you fork it, it becomes yours, and a fork also inherits GPL-3.0. The licence permits use, modification and redistribution under the same terms; it does not permit dropping the copyleft. Whether that matters depends on what you do with the code, and the LICENSE file at the repository root is the document to read.

Editorial conclusion

Adopt FlutterUnit if you are learning Flutter widgets or want a browsable reference next to your editor; the releases page gives Android, iOS, macOS and Windows builds, so you can evaluate it before cloning anything. Do not treat it as a widget library or a source of unit testing examples, because it is an application and its own tests are not documented. Before relying on it, check the GPL-3.0 implications for your use, confirm the Flutter 3.38.3 and Dart 3.10.1 versions still match your toolchain, and read the component detail page for the widget you care about to see whether that demo is interactive or only visual.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. toly1994328/FlutterUnit on GitHub