Flutter Flavorizr: one yaml file for Android, iOS and desktop flavors

Five platforms, one description of what changes

The premise is that a Flutter application often needs to exist under more than one identity, and that the differences are boring to express by hand. flutter_flavorizr describes those differences once, in yaml, and generates what each platform needs.

The yaml file lists flavors, and for each flavor an app object with the display name, then a section per platform. Here is the shape from the README, with two flavors named apple and banana:

flavors:
  apple:
    app:
      name: "Apple App"

    android:
      applicationId: "com.example.apple"  
    ios:
      bundleId: "com.example.apple"
    macos:
      bundleId: "com.example.apple"
    linux:
      applicationId: "com.example.apple"
    windows: {}
  banana:
    app:
      name: "Banana App"
  
    android:
      applicationId: "com.example.banana"
    ios:
      bundleId: "com.example.banana"
    macos:
      bundleId: "com.example.banana"
    linux:
      applicationId: "com.example.banana"
    windows: {}

The naming is worth noting because it is not uniform. Android and Linux use applicationId, while iOS and macOS use bundleId, and Windows is left as an empty object in the example, which suggests it is handled by a separate mechanism or not at all in this shape.

The values that differ per flavor are the ones that matter commercially. The application identifier decides which app a user downloads and which listing it belongs to, and the display name is what appears under the icon. Everything else in a Flutter project, the Dart code, the assets, the feature set, is shared, which is why the tool can describe the whole build matrix in one small file.

Two config shapes, and the one that is on its way out

There are two ways to place the configuration, and the README is clear about which one you should use.

The current form puts the flavors at the top level of the file, under a key called flavors, as the example above shows. The alternative is to add a new key named flavorizr and define a sub item named flavors inside it:

flavorizr:
  flavors:
    apple:
      app:
        name: "Apple App"

      android:
        applicationId: "com.example.apple"
      ios:
        bundleId: "com.example.apple"
      macos:
        bundleId: "com.example.apple"
      linux:
        applicationId: "com.example.apple"
      windows: {}

That second form, where the whole block sits under a flavorizr key, is what the README says will be deprecated in versions 3.x. So the top level form is the one to write today, and the nested form is the one that will be removed.

That deprecation note is the sort of thing that is easy to miss and expensive to discover later, because the nested form still works in the 2.x line and nothing warns you. A project that adopts the nested form now is a project that has to edit its configuration when it moves to 3.x.

The field reference also has a wrinkle. The table lists the flavorizr key as an Object and the flavors key as an Array, while the examples show flavors as a mapping of names to objects rather than an array. The examples are the more reliable guide to what the tool actually reads, but the discrepancy is a small sign that the documentation table is less carefully maintained than the samples.

Instructions, and the steps that touch your project files

The configuration file takes an instructions array, which is where you say what the tool should actually do. The available instructions are listed with a category each.

The assets instructions are the miscellaneous group: assets:download downloads the assets zip from the network, assets:extract extracts the downloaded zip in the project .tmp directory, and assets:clean removes the assets from the project directory.

The Android instructions do the platform specific work. android:flavorizrGradle adds the flavors to the Android flavorizr.gradle file, android:buildGradle imports that file into the build.gradle file, android:androidManifest changes the reference of the app name in the AndroidManifest.xml, android:dummyAssets generates some default icons for your custom flavors, and android:icons creates a set of icons for each flavor according to the icon directive. There are Flutter instructions as well, including flutter:flavors, which creates the Flutter flavor configuration file, and flutter:app, which the README table cuts off mid-sentence.

Read together, the list describes a tool that edits your Gradle files, your manifest and your icons, and that can fetch an archive from the network to do it. That is a lot of authority for a development dependency, which is why the instructions are opt-in rather than implied.

Two related settings sit alongside the instructions. assetsUrl is the URL of the zip assets file, and its default points to a release asset on GitHub, so the default behaviour involves a network fetch. The ide setting names the IDE the app is being developed in, and the README says it currently supports only vscode or idea, which is a small but real constraint on a tool that has to guess at your project layout.

Installing it as a development dependency

The package is intended to support the development of Flutter projects, so it belongs in dev_dependencies rather than in the normal dependency list. The README says to put it under dev_dependencies in your pubspec.yaml:

dev_dependencies:
  flutter_flavorizr: ^2.6.0

and packages can be installed from the command line with:

pub get

That placement matters more than it looks. Because the tool is only needed at development time, keeping it out of dependencies means it never reaches a release build, and a tool that edits your Gradle and manifest files has no business being in your application bundle.

The version constraint shown is 2.6.0, which matches the current release. The package is published on pub.dev, and the homepage in the repository metadata points at the same pub.dev listing, so the documentation and the package live in one place.

The repository itself is a Dart package with a lib directory, a bin directory, a doc directory, an assets directory, a blank directory that looks like a template, a build.yaml, an analysis_options.yaml, an .fvmrc pinning the Flutter SDK version, a test directory and a test_resources directory. The example directory is a complete Flutter application with its own flavorizr.yaml and platform folders for Android, iOS, Linux, macOS and Windows, which is the fastest way to see what the generated output looks like in a real project.

It expects a clean project, and the README says so

The prerequisites section contains the most important warning in the README, and it is easy to skim past because it is phrased as a side note. The tool works better on a new and clean Flutter project, and since some processors reference some existing files and a specific base structure, it could be possible that running Flutter Flavorizr over an existing project could throw errors.

That is a real constraint rather than caution for its own sake. The instruction set includes operations that read from files the tool expects to be in a particular state, and the Flutter flavor configuration file it creates has to match what the rest of the project expects. An application that has been flavored by hand, with Gradle product flavors, an Xcode configuration and a manifest already pointing at the right label, is a different starting point from a fresh flutter create output.

The migration path in that case is to let the tool generate its configuration and then reconcile, which is more work than the fresh case but still less than hand editing five platform folders for every new brand.

A second limitation follows from the assets design. The default assetsUrl points at a release asset on GitHub, and the instructions can download and extract that archive into the project .tmp directory. That means a build that depends on the tool can depend on the network, and on a specific archive the project does not pin by hash.

MIT, pub.dev and a 2.x line moving steadily

The licence is MIT, with the file at the root of the repository, and the badge in the README matches. For a development tool that is the straightforward choice, and it means the generated output is yours without attribution obligations on the application itself.

The release history shows a project that ships steadily. The recent tags are v2.6.0 on 2026-07-15, v2.5.0 on 2026-05-23 and v2.4.2 on 2026-02-24, so roughly a minor version every two months. The last push to the repository was on 2026-10-16, so work is continuing on the branch.

The pipeline and coverage badges point at a GitHub Actions workflow and Codecov, and the repository carries a CHANGELOG.md, a renovate.json for dependency updates and an analysis_options.yaml for the Dart analyzer, which is the standard set of files for a Dart package that wants to be taken seriously.

One last thing to know before you start. The tool has two configuration shapes, and the one the README documents as current is the top level flavors key, while the nested flavorizr key form is stated to be deprecated in versions 3.x. That is the kind of change that passes unremarked in a project that has not yet reached 3.x, and it is the single most likely thing to surprise a team that adopts the tool today and upgrades it in a year.

Editorial conclusion

Adopt flutter_flavorizr if you ship the same Flutter application under several brands or tenants and want one yaml file to describe the differences instead of hand editing Gradle, Xcode and manifest files for every target. Do not adopt it to retrofit an existing project that has already been flavored by hand, because the README warns that some processors reference existing files and a specific base structure and that running it over an existing project could throw errors. Verify first that the generated identifiers match what your store listings and signing keys already use, since changing an application identifier is not reversible by re-running a generator, and check which of the instructions you actually want, because the defaults download and extract an assets archive from the network into the project.

Frequently asked questions

Official sources

1. AngeloAvv/flutter_flavorizr on GitHub
2. License: MIT
3. Project website
4. README
5. Releases