I am currently working on a new project using Comp...

# multiplatform

[Sarthak Sharma]

I am currently working on a new project using Compose Multi Platform targeting for both Android and iOS platforms. One of the core requirements is to support multiple app variants (approximately 40) from a single codebase.

In my previous Android projects, I achieved this by using the flavor approach, where I created separate .env files for each flavor to dynamically configure elements such as manifest placeholders and application IDs. This method worked well, and I've successfully replicated this setup for the Android part of my current CMP project.

However, I'm facing challenges implementing a similar dynamic configuration for the iOS part. Specifically, I would like to read the respective .env files at build time and use their values to programmatically change the app's display name, bundle identifier, and possibly other iOS-specific configurations.

Could anybody please advise on the recommended approach to achieve this in a CMP/iOS setup? I'm looking for a way to automate these changes reliably for each app variant during the build process.

https://stackoverflow.com/questions/79638217/build-multiple-apps-from-single-codebase-in-kmm-cmp-for-ios

[François]

This is not a kotlin issue, mastering Xcode is hard but possible!.
A single advise, use tool like tuist, it will save your life (and time)

[Sarthak Sharma]

Thanks @François

[Anonymike]

For what its worth, we use a gradle submodule next to our app that has configurations in the form of implementations of a common base class called AppConfiguration and asset folders for different versions of our app. It allows us to swap out lottie animations, images, build names, etc. and uniquely configure different common screens. Using a kotlin class gives us a lot more flexibility to configure the app at runtime compared to env files.

We switch configurations with a configuration:switch -Dapp={appNameHere} gradle task under the hood which does two things:
1. Replaces the configuration file in our app shared code with the app specific one.
2. Swaps out asset folders.
We do have a target for each app in XCode mainly for certificate and team configuration for testing and release builds.

Like @François said, use something like Truist if it makes sense for you. We went this route because we're not a fan of depending on third-party servers for basic needs like builds so we host the tools we can internally, but that leaves us limited in options for some things.

[Sarthak Sharma]

Thanks for the help @Anonymike