How to use this solution with google-services.json and GoogleService-info.plist

[toeydevelopment]

This solution is very useful and easy for apply flutter multiple environment.

But i'm not found solution how to apply this with google-services.json and GoogleService-info.plist

[CodingAleCR]

What I did was set up a couple of sh scripts that replace files according to the environment. There probably is a more elegant way but that is what has worked for me.

[Minituff]

Looking for a solution for this as well. Based off the Firebase docs, it seems this can only be done with Flavors, not --dart-define. This might mean that I need to run flutter run --dart-define ENV:dev --flavor DEV, but I am looking for a solution that only uses --dart-define

[TatsuUkraine]

@Minituff not necessarily, all depends on your env config and the CI/CD implementation. For instance Codemagic has a few articles how to configure a build for multiple environments with the Firebase. Another way is to tweak Gradle and and iOS build to generate needed files based on dart defines.

One more option could be - simple Dart command that will do needed actions (like file creation)

Third option might be even simpler - you can use FlutterFire package that already has dart command. You just need to invoke it during your build workflow in Codemagic or bitrise for example

[TatsuUkraine]

One more option could be somewhere in between, when you can create dart cli command that will generate some RC file, which can be used in the Gradle and iOS build actions

[Minituff]

@TatsuUkraine I like these ideas. What I'm going for is I could issue flutter run --dart-define ENV:dev either on my workstation PC or in a CI/CD build and I can switch between dev and production firebase projects as well as have the flutter code know which environment I am in (because some of the firebase emulators are setup in actual dart code.

Can you points me to some docs/examples of your 2nd, 3rd, and 4th ideas? Just seeing a little more detail will help me understand. Much appreciated.

[erf]

You can now use flutterfire cli to create two separate Firebase config dart files which you will initialize in two separate main dart files, e.g. main_prod.dart and main_dev.dart using the --target option.

This seem like a nice solution in addition to using --dart-define instead of multiple build targets.

[CodingAleCR]

I personally still prefer using dart define since it allows me to just do configuration through the IDE in a similar way as .env files. Although it is pretty handy to have it as part of the cli too, at least as a starting point. Nice!

[TatsuUkraine]

Yes, with FlutterFire cli tool you can generate needed files with just one command. And locally and in CI/CD tool so you basically no need any dart defines

[erf]

But if you need API KEYS other than Firebase (google maps, stripe, etc.), you'd still need to pass these on, and i think here maybe --dart-define is better than flavors. You'd just need to create a couple of bash script or run configurations in vscode per environment.

[TatsuUkraine]

Yes) for packages that doesn't have cli tools to generate files for themselves, you will need to do this for them, or pass them data)

[erf]

As the author of the article on --dart-define and this example, would you recommend using --dart-define for other API KEYS or are there still reasons to use multiple environments?

[TatsuUkraine]

are there still reasons to use multiple environments @erf What approach you mean by this?

[erf]

I mean are there still reasons to have multiple flavors / environments / build schemes, with multiple xcconfig files or local.properties to avoid adding API keys to the git repo, or would you prefer to pass the the arguments using --dart-define perhaps using two bash scripts for PROD/DEV calling run with the various API KEYS args?

• Sorry for hijacking the thread and being a bit off topic ..

[TatsuUkraine]

I was successfully replacing flavors and multiple envs with some small scripting or existing packages alongside with dart-defines. For instance - before FlutterFire cli tool I was adding needed files with CI/CD during the build and some step by step doc for local env like - go here, copy it here. Some stuff, like square reader SDK integration, was solved with simple sh script and a few lines of code in gradle. So I would say it heavily depends on the project, and I can imagine that there might be cases when you won't be able to avoid using flavors, but for now, I was successfully avoiding using multiple entry points and different flavors for a project that has at least 4 different environments)

[erf]

Sounds great! I have a solution now which uses dart-defines (as per your article) to use API KEYS outside source control. We use the Firebase CLI's functions:config:get to fetch API keys in addition to the FlutterFire CLI to fetch the Firebase app config. Will try to add some additional scripts to fetch the API keys and prepare them for dart-defines. Thank you so much for the article!