4

For one of our company's products we need to generate iOS apps with slight changes (different logos, slightly different settings in the 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 slightly annoying to have like 20-30 different schemes and targets in the main Xcode project - plus it's a pain to have colleagues modify it, because it tends to break things now and then.

Unfortunately I'm not very familiar with Xcode's inner guts; but I'm pretty sure someone else already has solved this before.

Some ideas that came to my mind:

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

Not sure what the best practice is here; ideally there would be a clear separation of the project code and configuration of customer app targets. More ideally this would be a maintainable by co-workers without the risk of breaking the base code accidently.

Any ideas/thoughts/suggestions?

BastiBen
  • 19,679
  • 11
  • 56
  • 86

1 Answers1

0

It depends on the use case. Do you need to release (Archive) the targets for a synchronized deployment? Or are these client customizations that get released independently? How big is the development team?

There are really only a few options either way.

Option 1

Manage the products as separate targets. This is basically what you are doing now. You can set it up so that building one target builds them all to save yourself some agony. The major drawback here is that you are managing images/plist data separately.

This is the way I usually handle it. The customizations are usually one off and you can specify a different precompiled header to alter some functional differences.

Option 2

Manage the products as separate branches in CVS. This can be a bit of a headache to handle but works better if there is a larger team working in the codebase. Keep the functional code on one branch. Maintain an independent branch for each product. Merge changes from the functional branch into the product branches as needed.

Option 3

Mange the products as separate sub-projects. This is very similar to option 1 as you still need to maintain the settings separately but the advantage is that you are less likely to mess up other products when making changes to the underlying xml for the project files.

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

brewp
  • 172
  • 3