Hi, I've a quick question about the `*/app` produ...

# kotlin-toolchain

[Fernando]

Hi,
I've a quick question about the */app products on mobile (Android/iOS).
Is there a way to have build types/flavours? Or is there a plugin that can help with that?
If not yet, Is that a planned feature?

[joffrey]

Currently, we only support debug/release (as -v/--variant CLI option when building or running). @Anton Prokhorov might share a bit more details here about the current state and the plan.

[Fernando]

Wow, that was fast 😅 I'll keep an eye on this 😄

[Anton Prokhorov]

@Fernando thanks for the question, may I ask about your use case if you don't mind?

[Fernando]

Hi @Anton Prokhorov I think like a paid/free version of an app, an android build for QA that is optimized but has specific AndroidManifest entries (like network options to allow network debugging)

[Anton Prokhorov]

I see, thanks for the explaination

In short, we don't have the workaround for you right now (besides of having 2-4 android/app with different manifests)
What we definitely should do, is to add support of user-provided manifests to kmp/lib which would unlock expressing the QA/non-QA builds as different apps (which they are, actually, if we are being honest)
I'm not completely convinced that we should start supporting debug/release sourcesets, I'd rather prefer to express free/paid axis with something else, like runtime feature flags or Android dynamic features (which we don't support yet)

[Anton Prokhorov]

But I'm still curious if expressing paid/free with flavors help you to not to incorporate this knowledge on the backend app? If not, then I would be curious to learn what stops you from doing it by feature flags which depends on whether user paid or not
If the integration with Google Play payment system is the culprit then I still would like to learn the details if possible (not an NDA or secret)

[louiscad]

In my company, we use product flavors to support the users that are not using Google Play Services.

[Anton Prokhorov]

In my company, we use product flavors to support the users that are not using Google Play Services.

I'm curious, what makes it nessesary to use exactly product flavors for it? how many dimensions do you have?

is it only cartesian, like:

gms/non-gms x debug/release

or something more complicated?

[louiscad]

Only "cartesian". I believe we would resort to another technique if needed more kinds of variants.

Another use-case we have is to swap some urls so the app targets a given staging backend. Currently, we either set a third build type, named staging or preprod, which is debug + some config, but it'd be nice to have the ability to set build tasks or app variants that are essentially the debug one, but with some parameters injected (as opposed to having a whole compilation unit for them)

[joffrey]

Yeah that last use case seems more about injecting values into the build than building different things

[louiscad]

And having a good dev ex for it, i.e. being able to just have a button (run configuration) for it, ease of configuring it, and ability to set it up so the app is installed next to the other variants (applicationIdSuffix for Android)

[louiscad]

This need is very common for Android apps, and I think for iOS apps too.

[joffrey]

I think eventually we want to cover this in KTC-3854 Possibility to define different configs for different environments

[joffrey]

Once we have a proper design to declare "injectable" values (read: some sort of list of available "properties"), we could consider exposing them through the run configuration UI