flutter_catalog: a component gallery with side-by-side source, and four quiet years

The whole product is one line of description

The repository description is the entire pitch: an app showcasing Flutter components, with side-by-side source code view. Everything else in the README is distribution, screenshots, or credit.

That makes the design decision clear. This is not a component library you depend on. Nothing here is published to pub.dev as a package you add to a pubspec and call. It is a finished application where each screen pairs a rendered Flutter widget with the Dart that produced it, so you can scroll through an example and read its source in the same view. The value is pedagogical rather than reusable, which shapes every other judgement about the project.

The credits section is worth reading for what it says about lineage. The app was written with reference to the official gallery app, Andrea Bizzotto's YouTube channel, a Tensor Programming playlist, and Eajy's flutter demo repository. That is four external sources named as direct inputs, which tells you the component selection was assembled from existing material rather than invented. If you are evaluating whether the examples are idiomatic, they are curated by one author from those four places, and the two YouTube sources in particular imply a strong preference for how those channels write Flutter rather than for whatever the current documentation recommends.

Three distribution channels, one of them caveated in an issue comment

The README carries two store badges and then a browser announcement, which means this is a tri-platform product in a way most Flutter showcases are not. A Play Store listing sits under the package id io.github.x_wei.flutter_catalog, and an App Store listing exists as well.

The third channel arrived later and is announced with a rocket emoji and an underline about limitations.

The limitations link is the interesting part. It points at a comment on issue 31, not at a section in the README, which means the README's author considered the constraints too detailed or too changeable to keep in the repository. That is a defensible editorial choice and a poor one for a reader evaluating whether the web build fits their use, because a link into an issue comment is a place that can be edited or deleted independently of the README.

So the practical reading is: the web variant is a real build with real limits, and the limits are documented somewhere you have to go and find. Anyone whose decision hinges on the web build should open that comment before anything else, and anyone who just wants to see components rendered will find it works well enough to browse. What the README does not tell you, and cannot tell you from the outside, is whether the web version has kept pace with the mobile ones since it launched.

Four CI badges, seven platform folders

The README opens with four workflow badges, and the badges are specific enough to be useful.

Run Tests
Build Web
Build Android
Build Linux

Now put the tree next to them.

android/
ios/
linux/
macos/
web/
windows/

Seven platform directories exist in the tree, including windows and macos. Four of those have build badges. There is no badge for Apple targets and none for Windows, which means those two platforms can silently stop compiling and nobody watching the badges would learn about it until someone tried to build locally.

This is a normal shape for a Flutter app rather than a defect, since most Flutter projects set up CI for one or two platforms first and expand later. But it changes how you should read the badge row. A green Build Android badge tells you the Android build works, and it tells you nothing about iOS or desktop. For a repository whose purpose is to be a correctness reference for Flutter code, the platforms where correctness is unverified are the platforms you should check yourself, and the ones with badges are the ones you can take at face value.

The test badge is a different kind of signal. It is named Run Tests rather than Build, so the workflow does more than compile. Given that the newest release added unit and widget tests, the ordering matters: those tests arrived in the same release as the CI, which means CI was added to run them.

The tree says Firebase, the README never does

The repository topics include firebase, which is unusual for a component gallery and worth following up. The tree answers.

.firebaserc
firebase.json

Both files are present at the root, and neither is mentioned anywhere in the README. The likely reason is the web build, since a static deployment to hosting is the standard way to publish a browser build of a Flutter app, and those two files are the configuration for it.

That is an inference from the file names rather than a fact the README states, and the distinction matters here. If the web build deploys through a hosting provider, then the browser URL the README links to is served from that provider rather than from GitHub Pages despite the github.io hostname in the link, and the two would have separate refresh and cache behaviour. If it deploys through GitHub Pages instead, the Firebase files serve some other purpose or are leftovers. Nothing in the repository, as far as the README and tree show, settles which.

The check is short: open firebase.json and read the hosting configuration, then look for a public directory or a build output path. That single file will tell you what the web build is and where it lands, and it is also where you will find whether the web build needs credentials to publish. For a reader who only wants to run the app locally, the presence of these two files is harmless. For anyone considering forking the project and republishing, it is the file to read first.

The version numbers say the app moved, and the gap says the catalogue did not

There are three releases in the history and the spacing between them is the most informative thing in the repository.

The first two are close together. Version 2.6.2 added a red dot marking newly added examples and added more examples, then version 3.0.0 six months later did the null safety migration and added more examples. Both are typical catalogue maintenance, and both show the author treating the release as the moment to publish accumulated work.

Then a gap of four and a half years, and a version that jumps from 3.0 to 3.9 with no 3.1 through 3.8 on the releases list. Version 3.9.0 is the substantive one: migrate to latest packages and build with Flutter 3.41.1, add unit and widget tests and GitHub CI actions, refactor and simplify code, migrate the Google ML Kit packages, and add back an edge detection example.

Five bullets, and four of them are infrastructure. That is a project returning after a long absence to do the unglamorous work of making an old codebase build and test again, which is exactly what you would expect and also exactly what leaves the catalogue content itself untouched. The one content change, restoring an edge detection example, is telling in a specific way: adding an example back implies it had been removed, most likely when its dependency changed underneath it.

So draw the line carefully. The app's own currency is high, because it builds against a 2026 Flutter with 2026 packages. The individual examples are of varying age, because a refactor that simplifies code is not the same as revisiting each component's recommended API. A component demo that was correct in 2021 may still render perfectly while using an approach the current documentation has moved past, and nothing in the release notes or the repository tracks per-example age. That is the single most important thing to know before treating this as a current reference.

What the repository does not contain

A few absences are worth naming because they shape what you can do here. No homepage URL is set for the project, so the app's own site is whatever the store listings point at. There is no code fence anywhere in the README, which means there are no run commands, no clone-and-run instructions, and no dependency declarations to copy.

What the tree has instead is tooling configuration. There is an .fvm directory alongside an .fvmrc, which is the Flutter Version Management convention for pinning an exact Flutter version per project, and that is the closest thing to an install instruction the repository offers. If you want a known-good version, read .fvmrc and use that rather than your global Flutter.

Two other files suggest how the project expects to be worked on. GEMINI.md at the root is an instruction file for a coding agent, and devtools_options.yaml is the configuration that seeds pre-filled options into the DevTools menu when the app launches. The second one is a small design signal: this app is meant to be opened with a debugger attached and a populated options menu, which is another way of saying the author expects you to poke at it rather than read it statically.

The remaining structure is conventional. There is a pubspec.yaml and a pubspec.lock, a CHANGELOG.md, a CONTRIBUTING.md, an analysis_options.yaml for lint configuration, a lib directory for the app code, a test directory, a res directory for assets, and a screenshots directory the README pulls from. A packages directory sits alongside lib, which in Flutter means either local path dependencies or code generation, and reading pubspec.yaml will tell you which within a minute.

How to decide whether it is worth your time

If you are learning Flutter, the answer is straightforwardly yes, with one caveat. The side-by-side view is the feature that makes this different from a widget gallery in documentation, because you see the code producing the pixels rather than reconstructing it yourself, and the catalogue has enough breadth that you are likely to find the component you are looking for. The caveat is that examples accumulate, so treat any single component's code as a sample from a point in time rather than as current guidance, and cross-check anything surprising against the official gallery app, which the README names as one of its own references and which is maintained by the framework authors.

If you are looking for a component library to depend on, this is the wrong repository, and the pubspec-based structure will not change that. There is no package to add.

If you are evaluating whether the project is alive, the evidence is mixed and both sides are real. The last push was 2026-05-24, the newest release is v3.9.0 from February 2026, and that release added tests and CI. Against that, the release history shows a four and a half year silence before it, and only three releases exist at all. A project can be alive in the sense that the code builds today, or alive in the sense that it is actively accumulating new content, and this repository is clearly the first and arguably not the second. Decide which one you need before you bookmark it.

Editorial conclusion

flutter_catalog is a good fit if you learn Flutter by reading working code against a running result, and a poor fit if you need current API coverage. The two facts to weigh before downloading are both about currency. The version numbers tell you the app itself moved: 2.6.2 in January 2021, 3.0.0 for null safety in August of that year, and 3.9.0 in February 2026, which covers migration to Flutter 3.41.1, new unit and widget tests, CI, a move of the ML Kit packages, and the return of an edge detection example. So the 3.x line is not stale, it simply did not release for the four and a half years in between. The component list inside it is a different question, because accumulated examples are exactly what ages badly without a per-example signal. Check two things. Look at which platform folders the CI badges actually build, since there are seven platform directories and four build badges. And if you plan to depend on the web variant, read the limitations thread first, because the README points at a comment on an issue rather than describing what those limitations are.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. X-Wei/flutter_catalog on GitHub