Most efficient way to do 22 different builds

Question

I'm getting close to finishing my first relatively simple Xcode project (a custom installer) and I need to do 22 builds. Yes that wasn't a typo! What's different on each build is the PRODUCT_NAME, a source file in the bundle Resources folder and a variable that says whether the software is a trial version or not.

From what I've read so far, duplicating the existing target seems to be the way to do it when there are only a couple of builds but is that still true for 22? It seems like an awful lot of work. What I had in mind was a way to change the PRODUCT_NAME, source files that are copied into the Resources folder and the trial mode boolean. But I'm stuck.

thanks

Answer 1

I'd probably write a script that used a .xcodeproj template and sed to generate all the necessary combinations.

Answer 2

You might want to check out CMake for maintaining this large number of builds.

Scripting can certainly get the job done, but once the project grows to a significant number of files, or if you find yourself changing the number of builds, changing the script could get hairy. CMake will let you organize those scripts, so it's at least a bit easier to do the modifications in the future.

Answer 3

My gut response is that 22 different builds that only differ by a single source file is wrong...

Can't the problem be turned around? Include all 22 different versions of your applicaiton in one build and supply 22 different key/license files in the .app folder each unlocking one of the 22 versions.

Answer 4

One way that I've accomplished this in the past is to use Localization. When you use the NSLocalizedString flavored macros, some of them have the ability to specify a tableName (ie, a different strings file than the default). Then whenever I need a differently branded build, I just create a new .strings file with the appropriate key-value pairs.

I then have a build target that builds the code with the default values, and a second target that takes the built code and copies the appropriate .strings file into its proper location. This works pretty well and has allowed us to manage many different build flavors.