Xcode Project Resource Organization and Structure

Question

I am relatively new to Xcode and one thing that has bothered me is that when I add a resource it gets added to the top level directory of my project directory. So for exampl

Answer 1

The accepted answer didn't work for me in Xcode 4.3.2. Looks like they removed the "Get info" menu option. Instead I did this:

1. Created the directory on disk where I wanted it.

2. Went to the file menu

3. Right clicked on the group I wanted to add to

4. Selected "Add Files to PROJECTNAME"

5. Added the files from the directory I created in (1)

Answer 2

Life is hard for IDEs. They have to mediate between a filesystem world, where the compiler, with its source files live, and the UI world, where programmers work.

In the old times that formed the contemporary coding culture, everybody, compilers and people, used to live all togheter in the filesystem. So today we still have a tendency to think we want to control where sources and resources reside on the disk. That is good, because we may need to know exactly what compilers eat.

Anyway if you think your IDE just as a the frontend of a funny database system of source code and if you really have full confidence about its capabilities and features (which is seldom the case), you may get to the conclusion that if you just don't care about the filesystem you may have a better life, as a programmer (and as a human being).

You're right wondering, because Xcode is not very good nor friendly about filesystem code organization and people that is (correctly) picky on that will learn how to move files on their right folder on disk, and on their right Xcode group. That, if you use the "Create folder references for any added folders", have a 1:1 relation.

But you will see many people, and many project examples from Apple itsef, that use a simple flat filesystem tree with everything in the same folder.

My advice is that you at least group public headers and resources in different folders, something à la Java/Maven, but there is no universal convention.

Answer 3

It's actually really easy to get from where you are to where you want to be. Create the images/ folder and put all the images in it. Now in the project window in Xcode, the image files have gone red because they aren't in place any more. Get Info on them, and "Choose..." the new location.

Note that just because you've moved the file in the source file system (known as $SRCROOT), there's no change to the way the file is used in the product. If it got copied into Contents/Resources/ before you moved the file, that's where it gets copied to afterwards. No subfolder will be added at the destination.

Answer 4

Here's a little more explanation of Graham's suggestion:

• Create an images directory
• Create an images Group in Xcode
• Right-click the group and Get Info
• "Choose..." to set the group's directory to be your images directory

Now, anything you put in the images group will automatically go into the images directory. That's true if you drag/drop from within Xcode, from other other projects or from Finder, or if you Add New... by right-clicking on the images directory. (This assumes you leave the default setting of "relative to group" in the info pane.)

This will work for anything you put in that group (NIBs, etc).

For imageNamed:, you just give the base name.

My recommendation is to keep a small number of filesystem directories, and mostly organize with groups in Xcode. But I agree, a small number of filesystem directories are very helpful. I put all my source code in a Classes directory (just because Apple used that name; I would have picked "Sources" or something). I also have a Resources directory at the top level and generally create images and audio directories under that. But I don't generally create a lots of real directories beyond that. This keeps things a bit tidier, but makes it easier to grep and wildcard things with the shell.

Beyond shell tools, the big advantage of organizing by groups rather than directories is the impact on version control systems like subversion. When you suddenly realize that your "Views" group is way too big, you can reorganize it without taking the huge impact of moving files around.