Manifest files are loaded in following order

• pubspec.yaml
• assets.yaml
• assets-<platform>.yaml
• assets-<flavor>.yaml (only for local package)
• assets-<platform>-<flavor>.yaml (only for local package)

assets, fonts and use-material-design parameters are overridden at each loaded file.
When an assets file is not present, the next one is loaded without overriding parameters from previous steps.

Assets file format is the same as pubspec.yaml.

TODO

• YamlMap is immutable in _createFromPathWithAssets from packages/flutter_tools/lib/src/flutter_manifest.dart
• Add --flavor and --target-platform options in packages/flutter_tools/gradle/flutter.gradle
• Add --flavor and --target-platform options in packages/flutter_tools/bin/xcode_backend.sh

See sample project here:
https://github.com/sestegra/flutter_assets_flavors

Feel free to comment.

@sestegra thanks for the proposal! I think before we land a change to our project structure and manifest files, we need to think more about all the use cases we plan to support and come up with a comprehensive way to do so. For example, we're likely going to want to support asset resolution based on:

• locale
• screen size / pixel density
• platform
• text direction
• flavor

See also the discussion in #16015

Since you've obviously thought about this problem some, would you be willing to write up a proposal for how to tackle this more comprehensively (in prose, not in code) as an informal RFC? We're thinking about how to formalize a Flutter RFC process, but we don't have one yet 😄

This pull request was more a POC than an implementation (missing tests...)

I'm quite busy right now, but I took some time to initiate the request.
So, I won't be able to drive or follow this RFC.

I guess the RFC process could be managed in a more collaborative way: I mean outside this thread.

Basically, it's only a draft from scratch and it could be a starting point to other contributors to collaborate.

Assets Management and flavoring RFC

Assets Management and flavoring References

Issues

• specify assets that are for development only #5813 - specify assets that are for development only
• Platform specific assets #8230 - Platform specific asset
• Align asset storage with underlying platform #16015 - Align asset storage with underlying platform
• Flutter needs a way to manage image assets by locale #16816 - Flutter needs a way to manage image assets by locale
• Unable to launch app on ios simulator #21335 - Unable to launch app on ios simulator
• Support different set of assets depending on --flavor xxx #21682 - Support different set of assets depending on --flavor xxx
• Support different set of assets depending on platform and flavor parameters #25487 - Support different set of assets depending on platform and flavor parameters

Articles and projects

• Creating flavors of a Flutter app (Flutter & Android setup)
• Flavoring Flutter
• A flutter app to show flavors in flutter
• Support different set of assets depending on platform and flavor parameters

Localization

• Localization vs. Internationalization
• Android - Localize your app
• iOS - Build Apps for the World

Device screen size / pixel density / form-factor

• Android - Support different screen sizes
• Android - Create resizable bitmaps (9-Patch files)
• iOS - Adaptivity and Layout

Use cases

Assets like images, text or raw data could be diversified regarding many use cases, some of these use cases are presented below.

Debug / Staging / Production

In order to install debug, staging and/or production flavor of your application on the same device, they need to have different ApplicationId/BundleId. For instance, to avoid public leakage of production assets, it could be useful to have different assets per flavor. Debug/Staging assets could be only placeholders or mocked data.

Free / Paid version

Free and paid version could differ in the assets they need.

Localization / Text direction

Text and graphics containing references to objects, actions or ideas which, in a given culture, may be subject to misinterpretation or viewed as insensitive.

Security / Compliance

For security and/or compliance reasons, some assets could not be exposed before production, but should be tested with placeholders or mocked data.

Device screen size / Pixel density

Assets density is already addressed by current Flutter assets management.

Platform / Layout

Flutter is currently supporting android, iOS and Fuschia platform.
Regarding last announcements, Flutter would support more platform like Web and Desktop.
In that perspective, it would be preferable to select assets per platform.
In fact, different factors could influence the assets: like User eXperience, device screen size, pixel density and dynamic layout (resize on multi-tasking and rotation for instance).

Possible variables

Regarding previous use cases, the following variables should be taken into account to develop assets management and flavoring:

• Embedded vs downloaded assets
• Same vs different ApplicationId/BundleId
• Flutter platform, flavor and target options

Possible solutions

• Propagate flavor option in all Flutter tools
  It's one of the goal of this pull request
• Manage assets from possible variables
  This pull request only addresses platform and flavor
• Add a tool to manage flavors from command line, to ease the flavor management with Flutter (i.e. no manual edition of configuration files)
  I developed a POC flutter-flavor. It's only Bash based, because XCode file parsing is a mess.

#5813 is also an interesting related requirement

This would be a great advantage for Flutter. Any updates?

Working through our backlog:

This is a good proposal, and I agree that it would be great to have both #8230 and #21682 supported.

I don't think this PR is the way to go about doing so however. I see a lot of opportunities where we could accidentally end up caching the wrong assets, failing to delete older assets, or not copying them as needed. It may work incidentally as we disabled most build caching, but as I work to re-enabled this in the next few months it will become another issue.

The second concern is that with the current build system this will lead to more build invalidations than necessary. For example, switching flavors would cause build/flutter_assets to get overwritten, and so switching back would lose the cache.

Finally, this PR has no tests. We simply cannot accept major feature additions without tests. I'm going to close this PR , but I would love to solve it differently this year.