Xcode files and folders clean structure and organization

Question

After four years in development with Xcode I started to ask myself (well, yes, I know, a little too late but when you are deep in coding you don't see other things) what kind of structure and organization of files and folders can be a good one to follow some sort of guidelines.

I saw Google coding guidelines and I wonder if there's any similar doc around for the subject of this question.

I can see that if you create a new project in Xcode (I'm using the latest version) you have one folder with the same name of the app, then inside "supporting files", then frameworks and product. The last two are fine, but I just wonder if I add some graphics and other classes and static library and so on, how I could name them and where to put them (ex: some standard graphics like icon and default image will go in a folder named "design" or "standard design" inside "supporting files"). Rules like that.

This is because when you start to handle multiple project (and I mean 3-4 per day) you want to have find the same things in the same folder and even because for future updates and references, you will know where to find the right things in the right place.

Answer 1

I think the best strategy is to organize them in groups (groups are the "folders" within XCode, which are not real filesystem folders unless you esplicitely make them such) according to what part of the program functionality they are related to. It is somewhat debatable whether also organizing them in actual folders is a good idea or not (sometimes I do sometimes I don't).

However much before you start organizing the files in groups you should start organizing the structure of your project. And with that I mean systematically follow best practices related to how to modularize the project, where to put your code (where meaning in which classes) etc.

A pretty good starting point on how to organize the project is Matt Gallagher's The design of every Mac application post in his renown blog CocoaWithLove. His ontological analysis also makes almost self-evident how to organize the groups (and in fact he admits to having created the ontology by transcribing the group names of a project).