Appainter, a Material theme editor that outputs Flutter code

Configure and preview, then take the code away

Appainter is described as a Material theme editor and generator for Flutter, used to configure and preview the overall visual theme of a Material app. That phrase sets the scope precisely, and it is worth staying inside it.

This is a tool for the theme layer of a Flutter application, the part that decides colour, and the overall look of the interface. It is not an app builder, it does not generate screens or navigation, and nothing in the project description suggests it does anything for Cupertino or for a bespoke design system. If your app is Material, the visual editor is a plausible way to make those decisions. If your app is not Material, this is the wrong tool.

The output is the interesting part of the design. This is a generator, not a live preview service, and the README says the generated theme is something you then use, pointing to a USAGE.md file for the instructions on how to use it. So the workflow is: configure in the editor, get theme code out, put that code in your project. You end up owning the result, which is the right shape for a tool that touches your source.

The target audience is Flutter developers who spend time on visual design decisions and would rather see a screen than read a ThemeData constructor. The repository topics match that reading exactly, listing dart, flutter, flutter-theme, theme-editor and theme-generator.

Web build, desktop binaries, and the source tree

There are three ways to get Appainter, and the choice is mostly about who runs it.

The web build is hosted, and the README links to it directly at zeshuaro.github.io/appainter/. Nothing to install, and it is the fastest way to see whether the tool fits your workflow. The trade-off is that the hosted version is the author's build, running on the author's infrastructure, and it is a web app rather than a native one.

For Mac, Windows and Linux, the README points at the GitHub releases page for downloads. Desktop builds are the sensible choice when you want the tool to feel local, or when the network path to the hosted site is restricted.

Third is the source, which the repository is set up for. It is developed and built with Flutter, and the project ships platform directories for android, ios, linux, macos, web and windows alongside lib/, assets/ and images/. There is an example/ directory that holds a full Flutter app with its own pubspec.yaml, fonts, assets and platform folders, plus integration_test/, test/ and test_driver/ directories at the root for testing, and a packages/ directory, which suggests the code is split across more than one Dart package rather than a single lib/ tree.

A few housekeeping entries tell you about the toolchain. There is a .fvm/ directory, which is the Flutter version manager pinning a specific Flutter SDK for the project, and a .nvmrc file, which suggests some part of the release tooling runs on Node. The pubspec.lock is committed, and analysis_options.yaml with the flutter_lints style is what the style badge refers to.

Three commands to run it from source

The development section is short, and the reason it is short is that the project relies on code generation, so there is a step between fetching dependencies and running the app.

The first step, after forking and cloning, installs the dependencies:

    flutter pub get

The second runs the code generation:

    flutter pub run build_runner build --delete-conflicting-outputs

The third starts the app:

    flutter run

The build_runner step is the one people miss. Appainter uses generated code, so launching it before running the generator either fails or starts against stale output, and --delete-conflicting-outputs is there so that regenerated files do not collide with the previous ones. If you are contributing, run it after changing any annotated model.

The three-command shape tells you something about the project's size. This is a Flutter application of moderate size with a code generation step, not a script. The presence of an example/ application with platform folders, an integration_test/ directory and a test_driver/ directory says the project treats itself as a real application with end-to-end coverage, and the codecov and Codacy badges in the README show coverage is measured rather than assumed.

Releases run through semantic-release, and the root package.json is not the app

The top level of the repository contains a package.json, and it is easy to misread it. It is not the Flutter app's manifest. The Flutter manifest is pubspec.yaml, with pubspec.lock beside it. The package.json describes a package named appainter at version 2.7.7, authored by Joshua Tang, licensed AGPL-3.0-or-later, and its only meaningful content is a devDependencies block.

Every entry in that block is part of the release pipeline: semantic-release itself at 25.0.3, the conventional-changelog plugin, the changelog and git plugins, the exec plugin, the GitHub Pages plugin from @qiwi, the pub plugin semantic-release-pub, and semantic-release-stop-before-publish.

That last plugin name explains the arrangement. semantic-release-pub publishes the Dart package to pub.dev, and semantic-release-stop-before-publish is what lets the pipeline compute the version and changelog, commit them, and create the GitHub release, while stopping before the publish step so the two ecosystems are not published in one irreversible action. The release config files support that reading, with build.release.config.js, common.release.config.js and publish.release.config.js sitting next to a build.sh script, and yarn.lock next to .nvmrc for the Node side of those scripts.

So a version bump in this project is a machine action. The version in package.json and in the pubspec sidecar matching the release tag is a symptom of that automation, and it also means the changelog and the version are generated from commit messages rather than written by hand. The CHANGELOG.md at the root is the record of what that produced.

AGPL-3.0-or-later, and a web app you do not host

The licence is AGPL-3.0-or-later, recorded in the package.json and with the LICENSE file at the repository root. For a design tool, that is a heavier choice than the MIT or BSD licences most Flutter tooling uses, and it is worth a paragraph rather than a footnote.

The distinction that matters in practice is between the tool and its output. The generated theme becomes part of your application, and your application is your own code. The licence terms attach to Appainter itself, the program, and to how you distribute it. Whether you have an obligation to publish source for a modified Appainter, and whether running a modified version on a server as a web service counts as conveying it, are questions of fact about your deployment and your licence that I am not in a position to answer for you.

What is worth doing is raising it early. If your organisation has a standing policy about AGPL in tooling, that conversation is cheap now and expensive after you have built a fork around your own theme pipeline. If you use the hosted web build as a service for your own team, that is a different arrangement from running a modified copy, and it deserves its own look.

There is also a lighter point about the hosted version. The web build is published from the project, which means the version you get from zeshuaro.github.io/appainter/ is the author's build of his code. The desktop downloads come from the same releases. If reproducibility of the exact tool version matters to you, build from the tagged source and pin it.

Recent work, and what the README does not tell you

On maintenance the record is healthy. The repository is not archived, the last push was on 2026-10-18, and the listed releases are v2.7.7 on 2026-04-19, v2.7.6 on 2026-04-05 and v2.7.5 on 2026-03-01. A 2.x version line with patch releases inside it is a sign of an actively used tool, and the CI surface in the README backs that up, with a GitHub Actions workflow, codecov coverage reporting and a Codacy grade badge. renovate.json at the root of the tree handles dependency updates, which is the part of maintenance that decays fastest.

Now the gaps, because the README is genuinely thin for a tool of this size. It does not list which theme properties are configurable. It does not document the format of the generated output, only that there is a USAGE.md with the instructions for using the generated theme. It does not say whether the generated theme covers the full ThemeData surface or a curated subset, whether it handles light and dark variants, or whether it emits the Material 2 and Material 3 colour schemes separately. Those are exactly the questions a person evaluating the tool will have, and the answers live in USAGE.md and in the example application rather than in the README.

For a maintainer, that is a documentation cost that grows with the tool. For an adopter, it is a five-minute read of USAGE.md that decides whether the tool covers your case, and it is the first thing to do after opening the app.

Where the editor stops and hand-written ThemeData starts

The honest alternative is to write the theme yourself in Dart, because ThemeData is a normal constructor call and Flutter's own tooling, including the debug paint and the widget inspector, already gives you a live view of what your code produces.

The difference in approach is where the decisions live. Hand-writing means every colour and every text style is in your source, reviewable in a diff, versioned with your app, and editable by anyone on the team without a separate tool. The editor means you decide visually, quickly, and then maintain a generator step in your workflow to produce the code.

For a designer working in code, the editor is faster. It is a tool for the part of the work where you are choosing values rather than wiring behaviour, and its value is in the preview rather than in the output. For a team where the theme is small, stable and set once, the editor adds a step without adding much.

The other boundary is scope. Appainter configures the overall visual theme of a Material app, and the README makes no claim about Cupertino, about custom painters, about typography beyond the theme surface, or about per-screen theming. It also says nothing about importing an existing theme, so if your project already has a ThemeData that you need to refine rather than start from, check that before you commit to a workflow around the tool.

Editorial conclusion

Adopt appainter if you build Flutter apps with Material and want to settle colours and typography in a visual editor instead of by editing ThemeData in code, and if you would rather use the hosted web build than install a desktop binary. Do not adopt it for a Cupertino app or a project with a bespoke design system, since it is scoped to the overall Material theme. Verify first what the generated theme actually contains by reading USAGE.md in the repository, and check the AGPL-3.0-or-later terms with your compliance reviewer before you fork it, because that licence is a deliberate choice and not an accident.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. zeshuaro/appainter on GitHub