Xcode: how to handle many slightly different goals / applications based on the same source code

Question

For one of our company products, we need to create iOS applications with minor changes (different logos, slightly different settings in Info.plist, etc.); but basically they are all based on the same source code.

Now that we are starting to get some traction, it becomes a little annoying to have 20-30 different schemes and goals in the main Xcode project - plus it is a pain for colleagues to change it because it tends to break things now and then.

Unfortunately, I am not very familiar with the internal guts of Xcode; but I'm sure someone else has already decided this before.

Some ideas that came to my mind:

• You have a separate Xcode project and ...
  • ... import the "base code" using Framework / Library.
  • ... add "base code" as a project (dependencies?)

Not sure what is best here; Ideally, there would be a clear separation of project code and configuration of application goals for clients. Ideally, this could be useful to employees without the risk of accidentally breaking the underlying code.

Any ideas / thoughts / suggestions?

Answer 1

It depends on the use case. Do you need to free (archive) targets for synchronous deployment? Or are these client settings freed up independently? How big is the development team?

In reality, there are only a few options.

Option 1

Manage products as separate entities. This is basically what you are doing now. You can configure it so that building one goal creates them all in order to save yourself from agony. The main disadvantage here is that you manage the image / plist data separately.

So I usually handle this. Typically, settings are configured separately, and you can specify a different precompiled header to change some of the functional differences.

Option 2

Manage products as separate branches in CVS. This may be a bit of a headache, but it works better if there is a large command in the codebase. Store functional code in one branch. Keep an independent branch for each product. If necessary, merge the changes from the functional branch into the product branches.

Option 3

Change the products as separate subprojects. This is very similar to option 1, since you still need to maintain the settings separately, but the advantage is that you are less likely to spoil other products when making changes to the base xml for the project files.

Factors to consider are the size of your development team, as well as the existing team workflow.