what is used for android, desktop (jvm) and iOS f...

# multiplatform

[bryankeltonadams]

what is used for android, desktop (jvm) and iOS for something similar to BuildConfig.Debug and gradle.properties. I have an API access ID that I want to be different for debug and production builds. Also not sure if there's a concept of productFlavors for KMP or other platforms outside of Android. I'm trying to store a google ad mobs banner ad unit ID which I want to be the generic ad banner test for debug but the actual ad unit ID for production.

TLDR: best way to store private (kept out of version control but easily applied via automation script) tokens, and how to have a single variable for different build types, (prod, debug).

I know in iOS I can use Platform.isDebugBinary

[Pablichjenkov]

The exact functionality of flavors or targets doesn't seem to be supported just yet. However, gradle is really good at switching modules and with proper abstraction you can leverage that to conditionally include modules in your build.
So you can have 2 modules that offer the same functionality and select one of them to a specific build base on some build properties.
That's basically what flavors are or even better.

[Pablichjenkov]

Check this line as an example: https://github.com/pablichjenkov/macao-marketplace/blob/dev/composeApp%2Fbuild.gradle.kts#L91

[Blaž Vantur]

@Pablichjenkov how are you changing the flavor with such approach while running the app from IDE? By changing value inside gradle.properties file?

[Pablichjenkov]

In a real life project your pipeline will provide these Gradle properties, or you can get them from the environment.
Or fetch a build-config file that brings these properties using a Gradle task which does a request to your company app builds management system

[Blaž Vantur]

Thank you for your answer. I was just curious if you have managed to do this in some other way…maybe it can be done with additionally creating buildTypes/flavors for Android and schemes for iOS, for easier switch while developing.

Nice to see that there is also this approach possible…I just need to think it through what benefits you get comparing to using libraries like BuildKonfig and gradle-buildconfig-plugin.

[Pablichjenkov]

They are similar somehow since at the end, they are all ways to select what code to include in your build.
The biggest pain with flavors that I see, it generates many folders in AS. When the dimension number starts growing, it is hard to manage.
Simple example with only 3 dimensions:
1- location: USA/Global/China
2- app-cost: free/paid
3- environment: debug/qa/prod
You get 3*2*3 folders in the same repo plus other inconvenients. Slowness to switch from flavors and hard to navigate. It forces all the flavor folder code to be in the repo.
Another big pain is when you have libraries in other projects. All flavors have to match and publish them accordingly. You cannot consume just a general version from your library but has to be the right flavor combination version.
So basically the next approach, split the App by pluggable features.
You don't focus on dimension but rather in the specific functionality. You can have many implementations living separately in other repos. No need to release specific flavors of the plugin library, no need to switch flavors and so on.
Implementation wise you might end up with the same number of plug-in implementations as flavor permutations but the distribution/consumption is easier.

[Pablichjenkov]

From the architecture point of view, it helps to split your App into more granular features rather than a wide split as flavor is.
In fact this was the purpose of flavors initially, to divide the App by big and wide different features like style or so but we started to exploit it for small features too and don't scale well.

[Blaž Vantur]

Interesting way of doing this. It does resolve folders and flavor combinations problems as you said yes. Since you are already using this approach for some time, did you observed any other downsides besides that it doesn’t scale well for small features?

[Pablichjenkov]

Sorry if I express myself wrong. I meant to say that the flavor approach doesn't scale well when you have many small features.
Flavors are good for 1 or 2 dimensions that represent a wide difference between the 2 produced Apps. Like the case of style.
For more granular features, it is better to use the plug-in modular approach.