In Compose Multiplatform, are there any recommenda...

# compose

[Jakob Ulbrich]

In Compose Multiplatform, are there any recommendations or best practices on how to build whitelabel apps?

I currently have an Android App using flavors that I want to migrate, but in CMP/KMP the concept of Android Flavors does not exist. I moved the brand specific Compose theme definition and resources from the flavor folders into separate Gradle Modules, where both theme modules have the exact same api. My module dependencies now look like this:

composeApp1 -> ui-feature-a -> ui-components -> ui-theme-brand1
composeApp2 ->                               -> ui-theme-brand2

You can find what I already tried in the thread. Is there anything that I haven't thought about yet or any better approach?

[Jakob Ulbrich]

I now tried different solutions to make it select the the correct theme at the end of the chain depending on the consumer app at the start of the chain
• Expose new brand-specific Gradle configurations in the ui-components module and select them based on Gradle attributes declared in the app modules --> But messing around and duplicating and hiding configurations created by the AGP and KGP seems error prone and fragile
• Using a fixed dependency on ui-theme-brand1 in ui-components, but use a dependency substitution rule in my app modules to enforce the usage of the correct ui-theme-brand module --> This feels a bit hacky
• Using a fixed dependency on ui-theme-brand1 in ui-components. Using the same Gradle capability in my ui-theme-brand modules telling gradle that this is basically the same library, just different implementations. Specifying an explicit dependency on the correct ui-theme-brand module from within the app modules, creating a capability conflict and resolving it with a resolution strategy --> That's what I tend to use now, since both ui-themen-brand modules have in fact the same capability since they share the same api
• Using CompositionLocal to "inject" the correct theme from my app modules, so my ui modules do not need to care about the dependency themselves --> This would work well for compose theme definitions, but creates a lot of overhead since it prevents me from using the Res object directly but instead requires that I write new accessors for my composeResources. Also it prevents me from using android resources in my intermediate ui modules.
• Using a gradle parameter to define which brand to build and select the ui-theme-brand dependency accordingly --> This feels off in terms of Gradle caching and prevents me from building brand1 and brand2 within the same cmd call

[Pablichjenkov]

Conceptually CMP is moving more towards iOS, where, instead of flavors, you have build targets. Each target is basically a collection of configurations. You decide what to put in each target's collection.
This is ideal for an App based on plugins, since you can have a common interface that is implemented by different plugins that you can select at build time. This is impossible with flavor dimensions since the amount of versions grow permutationally. dimA x dimB x dimC...
You are saying it prevents build both targets in one cmd. Why not a script that call the cmd multiple times?

[Jakob Ulbrich]

A script would be possible, but still it would have an impact in Gradle caching, wouldn't it?

[Pablichjenkov]

I don't recall but I believe gradle/build caches are preserved between commands. I gotta recheck

[Jakob Ulbrich]

I now solved it by using separate gradle modules for my theme implementations and separate app modules that run dependency substitution to select the correct theme module