Splitting a project into multiple Xcode project files

Question

The iPad project I was working on became bloated with a huge amount of files. The application is a prototype, and we are considering ways to prevent this from happening when we rewrite it.

One of our team members suggests dividing all the components into separate Xcode projects, which will be included in the main Xcode project.

Is that a good idea? What are the reasons, if any, to avoid splitting functions / components / controls into separate Xcode projects?

Answer 1

Now with Xcode4 you can create a workspace and add all your projects there. For documentation purposes only :)

Answer 2

You can add an additional project file to the main project file in Xcode. Just select "Add File" and add it. When Xcode creates a wizard, it will also create a child structure, if necessary.

I use a similar system. I often break up a project into subprojects so that I can focus and provide encapsulation. I write the data model first, then add the application delegate, and then the specific user interface elements. I add each project to the next one in turn. It also allows me to come back and change things without the risk of hacking.

Indeed, a properly designed objective-c application should be easy to decompose into multiple projects. Ideally, all components are so encapsulated that they do not need other than a data model.

Answer 3

We added some of the code to our own project, creating the structure we are referring to in some other projects. Sometimes it’s annoying that you don’t immediately see the implementation code for the frame code in another project (using cmd + click or cmd + shift + D or what you usually do for navigation). Xcode will show you only the title, you will have to open another project and find the file there manually. It doesn’t matter, but if you often look at the code, it bothers you.

The real problem is that you are changing the scope of some operations. Things like “Find in Project” will work with a different set of files, which sometimes may not be the same as you want (an attempt to find where this method is called / the key is used in all code or something else); well, Finder / find remains, so that everything may be in order. Refactoring is not - all the renaming of things just breaks down, since this will change only the code of the current project, but not the projects that reference this one. If you change interfaces frequently, it is better to avoid splitting the project.

It’s good that you will encounter less conflicts in your .xcodeproj files (if they are stored in a shared repository), because someone deleting a file from project X will not create a conflict with someone else by adding a target to project Y, where earlier was the same .xcodeproj (not quite sure if this is a conflicting case, but there are definitely some).

Answer 4

To view and modify subproject implementation files, you must add subprojects directly to the main project.

1 step - drag and drop the .xcode project files into the main project.

Step 2 - Go to the main project TARGETS → Build Phases. Add subproject goal in target dependencies. You can also add binaries to Link Binary With Libraries.

Step 3 - Add the path to the source project to the path to the main project. Go to the main project → Build Settings → Header Search Paths (e.g. $ (SRCROOT) /../ CoconutKit-master / CoconutKit / Sources)

Answer 5

An Xcode project can contain any number of build goals, and you can arbitrarily group the source files into folders. Why do you think several projects are needed?