I know it is proper practice to put a forward class declaration (@class ClassA) in the .h and #import "ClassA.h" in the .m. And also I know doing that can make compiler compile it later on(until #import it in the .m).
Usually we use @class ClassA in A.h meanwhile add #import ClassA.h in A.m, though the compiler would not compile ClassA in A.h, still compiler have to compile it in the A.m. So why not use #import in A.h directly?
You almost never use @Class A in A.h. The common practice is to use @Class B in A.h and @Class A in B.h. The reason for this is to avoid circular dependencies in the .h files. If A.h imported B.h and B.h imported A.h, the compiler would explode from the circular dependency.
Your last sentence seems to be asking why we never import A.h in A.h. I think it's pretty obvious why that isn't done.
Remember, the header file (.h) is meant to tell the world the minimum possible about your declarations. It's there to tell the compiler - "Hey, we have a class (@interface) with some methods and properties. And those methods use these other classes. We use @class for those other classes because at this point in time we only need to know that there will be such classes eventually. It's just enough to make the compiler happy so it can do its job. Ultimately, the linker makes the final decision about whether those classes really exist somewhere.
The source file (.m) needs to do the actual importing because the compiler needs to verify that there really are the methods and properties you are trying to use. But the header file doesn't call methods and it doesn't call properties. It simply states - "This stuff exists".
I use @class instead of #import in .h for two reasons:
Makes circular dependencies possible.
Reduces compile time.
I commonly find it useful to have mutual links, A->B and B->A, which is impossible without forward declarations.
