Centralizing configuration parameters across multiple iOS targets is a valuable approach, especially in larger or modularized projects. Maintaining separate settings for each target often leads to duplication, inconsistency, and errors. Developers frequently struggle to keep build settings, API endpoints, feature flags, and environment variables in sync across targets such as staging, production, or app extensions.
By demonstrating how to structure and manage these settings in a clean, scalable way—using tools like xcconfig files or centralized Swift structs—you can enhance maintainability, reduce bugs, and promote best practices in professional iOS development.
In this post, we’ll walk through an example of centralizing the project and build version across multiple targets.
Note: The goal here is not to convince you to centralize all configurations, but to show you how to do it effectively if your project requires it.
Multiple version values
One common problem when having more than one target app is managing multiple version values across different targets for the same app version.
In this case, MARKETING_VERSION and CURRENT_PROJECT_VERSION are defined in three places: the project build settings and each target’s build settings. We want to define them at the project level, and have each target inherit these values from the project.
To do this, select the CenterXCodeConfigs target:
And replace 1 by $(CURRENT_PROJECT_VERSION), and also
1.0 by $(MARKETING_VERSION). Switch to project build settings:
Now, fill in the current project version and marketing version with the desired values, then switch back to the CenterXCodeConfigs target’s build settings.
Voilà! Values are now inherited from the project settings. Repeat the same operation for the AlternativeApp target.
Conclusions
In this post, I presented how to centralize common settings values across all targets. You can find source code used for writing this post in following repository.