At first, hopefully following terms project and product won't be confused.

Traditionally, we used to have a code base, which usually was a main project. For our products, we created one project for each product, and these projects surly depended on main project (code base). When product was released, we created release branch for archive and maintenance.

Now I'm developing iOS applications, and I noticed there were specific terms for Xcode, project and target, which were similar to project and product. At first look, it's more easier to share configuration between products, to simplify product releases by taking advantage of target and target dependencies. Compared with traditional way, on the other hand, it's more difficult to manage source code, to branch, etc, if number of products goes really large.

In practice, is anyone efficiently using this Xcode built-in structure to manage code and products?
I'm quite new at iOS & Xcode and looking for good advice, thanks.

2 Answers 2


It sounds like you're talking about using Xcode to build a Software Product Line kind of a configuration. I've done something like this before with respect to white-labelling a product - so there were no code changes between products, just different resources.

My approach would be to define a different target for each product - whether they're in the same project or not is up to you. Xcode handles dependencies across different projects quite well, so you could easily define multiple projects that state their dependencies, and use xcconfig files[*] to maintain configuration details that must be the same across all targets. It's easiest to do that from a version control perspective, to reduce the chance that people working on different products will need to edit the same project file.

Put the code that goes into all products into its own (static library) target, and include that target as a dependency of the other targets. Similarly if there are resources that are shared across all projects, create a "bundle" target that includes those shared resources.

[*] An xcconfig file is a plain text file containing Xcode build settings. If more than one of your projects contains targets that should use the same build settings, you can base those targets all on the same .xcconfig file so the settings are defined in the same place.

  • With structure of one project and several targets, if I had some common targets (static libs), and one of my product depended on just part of those libs, I would have to branch entire project even if I want to only branch this single product. That's what I'm doubted.
    – fifth
    Jul 24, 2012 at 8:29

The targets within a single project file are usually strongly related. For example, if you have a product that collects data and which has several related components, DataCollector, DataCollectorAdministrator, and DataCollectorLibrary, those components might all be targets in the same project. Furthermore, you might also have targets in that project for things like unit tests and even documentation.

You probably wouldn't have a target for a mostly unrelated product, BaseballStatsGuru, in your DataCollector project. You'd use a different project file for that, because it's really a whole different product, even though it uses DataCollectorLib as one of it's components. Even though it's a different project, you still want BaseballStatsGuru to be rebuilt whenever DataCollectorLib changes, so it always uses the latest code. That's fine -- you can add the DataCollector project to the BaseballStatsGuru project as a dependency.

There's even a special type of target called 'Aggregate':

Aggregate target

Aggregate takes this a step further: an aggregate target doesn't have a product of it's own -- it only exists so that it can be dependent on other build targets. When you build an aggregate target, it causes all the targets that it depends on to be built (if they're not already up to date). So, you could create a single uber-project that includes all your other projects as sub projects and depends on them. The target of that project would simply be an aggregate target that depends on the targets of all its sub projects. Using a system like this gives you the ability to build a whole series of products with a single command.

Note that this isn't exactly novel -- you can do the same thing with makefiles if you want to.

In practice, is anyone efficiently using this Xcode built-in structure to manage code and products?

Sure. Both the ability to have different targets and to create dependencies between targets are very important. I'm not sure how to characterize the level of "efficiency," but you can bet that having Xcode manage the dependencies is a lot easier and more reliable than trying to do it by hand.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.