hi, we have android project which we are slowly c...

# multiplatform

[Krystian Kaniowski]

hi,

we have android project which we are slowly converting to multiplatform (android and ios for now). We were used to have flavors approach for additional development-only utils like extra network calls. I was thinking about extract development part to standalone gradle module. It's possible to add dependency for selected build types in android app, but it's not possible to expose two xcframework umbrellas (one regular modules and second with additional development modules) as they will be treated as isolated libraries.

What do you recommend to keep this availability for including development functions only in development builds?

[Krystian Kaniowski]

i heard about compilation flags and dead code elimination on compilation stage, but it sounds like a fragile approach in every day use (as it will be quite easy to leak development functions to production code)

[Pablichjenkov]

The umbrella will depend on the extra module. The extra network module will split in two, API, which is an empty module just containing interfaces and abstract classes and the implementation, which will have actual implementations of the API module. Then you could swap many implementation modules, all you wanted, QA, qa2, qa3, prod etc ...
This is an example of how you could swap them.
https://github.com/pablichjenkov/macao-marketplace/blob/dev/composeApp%2Fbuild.gradle.kts#L93
In this example I don't use an API module I just copy paste the same abstraction in each module under the same package name for simplicity. But the proper way is to have a light abstraction API module

[Krystian Kaniowski]

hmm, so I will build two different xcframework with exactly the same public api, but with using different implementation. API will expose posibility to perform development action, but implemntation for it will be empty for production build. Am I understand it correctly?

[Pablichjenkov]

Just like that right.
If you don't want to deal with many API modules for multiple features, you can place all APIs interfaces+abstract classes from all features, in one single core or common-abstraction module. Although I don't see a problem with importing 2 modules. Libraries like flipper from Facebook use this approach.
But yes, the idea is around that module swapping principle

[Krystian Kaniowski]

thank you for advice I like this idea, I'm not scare of modules as we have near 200 modules in android app right now