Workspace with multiple projects or one project with multiple targets?

Question

I have 4 iOS apps that are all similar. They're flash card apps, with each app having a different topic. They share a lot of classes and images. Right now I have all 4 of them as separate projects, but I'm looking to simplify maintenance and share resources. Would it be better to have all 4 projects in the same workspace, or have 4 targets in one project? What are some pros/cons of each method? They seem very similar.

Answer 1

This is an excerpt of the PDF that Marty posted. It is an excellent document, but 4.4MB and will probably be taken offline after a lot of people download it ;)

Trade-Offs of Putting Many Targets in One Project

You can help determine whether to put many or all your targets in one project by considering some of the trade-offs involved. Here are some of the advantages of combining multiple targets in one project:

• Indexing works across all targets. Indexing information is required to access classes in the class browser, view symbols in the Project Symbols smart group, and to take full advantage of code completion. It is also necessary to use Command–double-click to jump to a definition and to use symbolic counterparts.

• You can easily set up dependencies between targets in the project.

• Anyone using the project has access to all its files.

• If your computer has multiple CPUs or you have access to additional computers on your network, you can use parallel builds or distributed builds to improve the build time of a large project. See Building in Parallel” in Xcode Project Management Guide and Reducing Build Times for details.

Here are some of the disadvantages of putting all your targets in one project:

• All of the code is visible to any individuals or teams using the project, even if they’re working on only one target or a small subset of the overall project.

• The project size may become unwieldy; this can cause Xcode to take a long time to perform operations such as indexing.

• All targets must use the same SCM system.

• All targets must build using the same SDK.

• You can’t use the Xcode debugger to debug two executables in one project at the same time.

Trade-Offs of Using Multiple Projects

There are also trade-offs in breaking up a software product into multiple projects and targets. Here are some of the advantages of using multiple projects:

• You can use the project as a unit for dividing work among different individuals or teams. The separate projects allow you to segregate the code (for example, to limit access to confidential information).

• Each project can be of a more manageable size, and Xcode can perform indexing, building, and other operations more quickly.

• If projects need to share outputs, they can build into a common directory, as described in "Build Locations" in Xcode Project Management Guide.

• You can use cross-project references to build other projects needed by the current project.

• Each project can use source code stored in a different SCM system. However, if individuals have physical access to other projects, it is still possible to look at SCM information from multiple projects that use the same SCM system.

• Each project can use different SDKs.

• Each project can define a separate list of build configurations.

• You can use the debugger to debug two or more executables at the same time, one in each project. This is useful when products communicate directly or otherwise interact.

Here are some of the disadvantages of having multiple projects and targets:

• You don’t have cross-project indexing, and thus you have access only to symbols that are specifically exposed by other projects. This means, for example, that you can’t automatically look up definitions in other projects unless you have physical access to them (not just to their end products). Similarly, you cannot take full advantage of other features that depend on indexing. That includes using code completion, using Command–double-click to jump to a definition, refactoring, and using symbolic counterparts.

• Management of many smaller projects is likely to incur additional overhead. For example, to set up a target that depends on other targets in multiple projects, you must first set up cross-project references.

  Similarly, use of multiple projects may require additional communication between teams.

• For an individual working on multiple projects, it may become unwieldy to switch between many open projects. This problem, however, may be alleviated by using the Organizer (see Using the Organizer for details).

• Individual projects are smaller and are less likely to be able to take advantage of distributed builds.