TARGETS | SCHEMES | CONFIGURATIONS

I recently created a new project and had to reevaluate which way I wanted to go in terms of multiple configurations, to lets say communicate with different server endpoints or to show different app icons based on build type.

My approach so far, which by the way worked well, was to have multiple targets and each target had the specific plist files assigned which contained the configuration. This works well, but as your project grows it also comes with a burdon.

Our POS at 9Cookies has around 1k source files and comes with 6 different targets, this actually leads to a massive project file since all entries are in there 6 times, for each target once. We rarely have merge conflicts, but if we have them, you always have to hope that the diff can actually be produced on your Mac, since it immediately starts beachballing.

Hence the lookout for a better solution.

I recently came across another post which described how to deal with multiple configurations and I took that one as a blue print.

The transition was really smooth, I only wasted 2hrs on unit tests which suddenly didn’t run anymore. The reason for that was that the `TEST_HOST` entry didn’t update itself to the configurations I added and it simply used an old entry which didn’t exist anymore. Hard to find in my opinion, since the error message wasn’t clear at all about what the problem actually was.