Organize #import Statements for Objective-C/XCode

Question

After several months of coding in Objective-C, I completely understand when I need an #import, how import statements cascade (ripple?), and when to use forwarding classes. I do not know how to aggregate imports to get them inside of <> instead of in quotes (although maybe that's just for frameworks)...

The problem is that I'm making a huge mess. I come from Java (and the heavy-handed IDE), so I just add imports as I see fit. Sometimes I add them to the interface, but since that's usually not necessary, I just add them to the top of the .m in question.

Today I started thinking: there must be some rules of thumb on how to organize this stuff. In fact, since Objective-C is a C superset, there are rules of thumb for everything, but I don't know them. How should I organize my imports? Particularly:

• When should I import in the .m?
• When should I import in the .h?
• Should I create .h files just for the sake of importing them (i.e., header files that just have imports in them)? If so, any hints on organizing that?

This is just a general idea of what I'm trying to figure out.

Answer 1

The <....> syntax is indeed just for frameworks. That doesn't mean you shouldn't create a framework to contain the core logic of your application though. Often this is a useful thing to do if you:

a) Need to provide support for loadable bundles that want to invoke aspects of your application logic (the bundle links to the framework, so does your application) b) Write multiple apps that share the same core logic

Your question is somewhat subjective and you will get developers who argues both ways, but a convention I follow is:

1. Never import class definitions in the .h file, unless you are subclassing it. Use forward @class directives for everything in the .h.
2. Only import class definitions into a .m as you find you need to use that class in the implementation.

Generally speaking, the .h does not need access to the class definition of its ivars, method arguments or return values. It only needs to know that they are classes, which is what @class allows you to do. It does need access to the class definition of anything you're subclassing, adding a category to, or (obviously) implementing a protocol for.