What are the best practices and guidelines for organizing Xcode solutions?

Question

Are there any recommendations for organizing one solution in xcode

This is mine currently from the root:

• A folder for each third-party structure, for example. KissXML
• Folder for my unit tests
• Folder for frameworks, products and resources
• A folder for MyApp that has auxiliary folders for the model, view, controller, database, supporting files and domain.

Answer 1

My:

Main application Model Singletons Helper+managers Controllers // I keep nibs with their respective class files View Resources images plists // ... groups from other types of resources if needed Supporting files Unit tests Frameworks 

For reusable code in iOS, I use static libraries and add them as separate projects to the Xcode workspace. Even for third-party code, if there is no target static library, I create one. Thus, I relate to third-party code in the same way as to my own library code. In addition, I do not need to worry about versioning third-party code.

I find it important that Xcode reflect the structure of the code file system, at least to some level. I accepted this practice after reading this blog post . I do not do this below the levels listed above. This helps, for example, when sharing code on github. Instead of loaders or contributors having to dig your entire source, dumped into one directory, it is organized into functional buckets. I saw some projects where the Xcode organization is fine, but every single file in the file system is dumped into one directory.

Answer 2

Although no specific method can be without flaws, this is what we use.

• Folder for the core of the application or model. This includes subfolders for any used third-party libraries and folders for specialized model classes. For example, there will be a folder for processing web services.

• A folder for one main module, which will include subfolders for each screen containing class files, tips and resources (this may include more subfolders as needed).

• Folder for the second main module, etc.

This model serves us as one of the main goals. There are things in our application core such as logging, data encryption / decryption, etc. Therefore, this is very unlikely for many of the applications we are developing. Similarly, there would be some applications that needed the functionality of the main module and add some other things. Therefore, these three groups of folders are stored as separate repositories in disruptive activities.

Now, when we start a new project, we create a new repository for the project and associate it with the repository of the main application box and other main module repositories according to the needs. Thus, any changes made in the application core by one project team are reflected in other projects. The same with other core modules. It also helps us achieve full modularity.

Of course, there would be flaws for this scheme, but this scheme has been well suited for us for many years :)