Repository: flutter
Issue: Allow to provide compile-time variables for native platforms from a file
Labels: c: new feature,tool,customer: crowd,P2,team-tool,triaged-tool

An **update** from @christopherfujino, tech lead for the Flutter CLI tool:

I recognize that there were many users who started using variables provided via `--dart-define-from-file` in their native build configurations who were then broken with the Flutter 3.16 release when this behavior was removed. I take personal responsibility for this, as I both reviewed the PR which introduced this behavior and the follow-up that removed it. I sincerely apologize both that your builds were broken and that we failed to communicate this change in behavior in the release notes. I am taking a personal action item after this to be more cognizant in how changes to tool behavior may affect users' builds and--if we decide it is worth making these breaking changes, to ensure they're communicated in official Flutter release notes.

As for how to move forward, I see that there is a lot of interest in this feature from the community, which is great. In order for this feature to be merged, someone will need to write a design document. Please see https://github.com/flutter/flutter/wiki/Design-Documents for the process of writing and sharing a design document. In particular, I have the following questions which I think a design document should answer:

1. What platforms would be supported? If it is not all of the platforms Flutter supports, do we need to warn the user about when they use an unsupported platform?
2. What is the method of implementing this for each platform? (e.g. gradle properties, environment variables)
3. Is there a risk of namespace collisions? If so, what should the tool do to handle this?
4. How do we document this feature for users?

The fact that there were these outstanding questions is why we reverted this behavior. Indeed, I had missed that this behavior was introduced in the original PR--had I noticed it, I would have asked these questions then before the behavior was introduced.

I am locking discussion on this issue as too heated, and because I feel they largely do not align with the guidance on how to interact on our issue tracker outlined in https://github.com/flutter/flutter/wiki/Issue-hygiene#comments. Feel free to write a design doc and file a tracking issue for it per https://github.com/flutter/flutter/wiki/Design-Documents and I will be sure to read and provide feedback for it. In addition, for further context, you can discuss this more on our [Discord server](https://github.com/flutter/flutter/wiki/Chat), under the #hackers-tool channel.

**End of update**

---

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

### Use case

Flutter currently has an ability to define compile time variables for dart code using dart-defines and dart-define-from-file . But there is no easy way to do the same for native like iOS and Android. Originally dart-define-from-file had the ability to get access to provided key-value pairs in gradle and plist but it was removed (more info can be found here https://github.com/flutter/flutter/issues/138793). 

This feature was particular handy for CI/CD configuration when third-party plugins require some public keys to be provided or configure env specific values for native such as iOS trusted website domain, define bundle ID or app name suffix etc.

For Android cli tool has `android-project-arg` where you can provide key-value, but there is no such key for any other platform. And also it doesn't allow to specify json file or .env with multiple key-values

### Proposal

Add keys to cli tool like `native-defines-from-file` that will provide key-value pairs for Android gradle and xcconfig file.

Alternatively it can be separate keys like `android-defines-from-file` `ios-defines-from-file` `windows-defines-from-file` etc.