When Objective-C was new, the system did not ship with many classes. Eventually, however, there were enough classes that it become necessary to organize them into frameworks. In your source code, you would typically #import the master header file for a framework:

#​i​m​p​o​r​t​ ​<​F​o​u​n​d​a​t​i​o​n​/​F​o​u​n​d​a​t​i​o​n​.​h​>​

And that file would #import all the headers in that framework, like this:

#​i​m​p​o​r​t​ ​<​F​o​u​n​d​a​t​i​o​n​/​N​S​A​r​r​a​y​.​h​>​
#​i​m​p​o​r​t​ ​<​F​o​u​n​d​a​t​i​o​n​/​N​S​A​u​t​o​r​e​l​e​a​s​e​P​o​o​l​.​h​>​
#​i​m​p​o​r​t​ ​<​F​o​u​n​d​a​t​i​o​n​/​N​S​B​u​n​d​l​e​.​h​>​
#​i​m​p​o​r​t​ ​<​F​o​u​n​d​a​t​i​o​n​/​N​S​B​y​t​e​O​r​d​e​r​.​h​>​
#​i​m​p​o​r​t​ ​<​F​o​u​n​d​a​t​i​o​n​/​N​S​C​a​l​e​n​d​a​r​.​h​>​
#​i​m​p​o​r​t​ ​<​F​o​u​n​d​a​t​i​o​n​/​N​S​C​h​a​r​a​c​t​e​r​S​e​t​.​h​>​
.​.​.​

And then you would explicitly link that framework into your program at compile time.

This was easy to implement; it was using the existing C preprocessor to copy all these headers into the file that was about to be compiled.

This approach worked pretty well for about a decade. Then, as more classes were added to the frameworks and more frameworks went into each project, we noticed that the compiler was spending most of its time parsing and processing those same standard headers again and again. So, the precompiled header file was added to every project. The first time you compiled your project, the headers listed in the that file would be compiled once and the result would be cached away. Having this pre-digested clump of headers made compiling all the other files much, much faster. The project you just created has the file RandomItems-Prefix.pch and it forces the build system to precompile the headers for the Foundation framework:

#​i​f​d​e​f​ ​_​_​O​B​J​C​_​_​
 ​ ​ ​ ​#​i​m​p​o​r​t​ ​<​F​o​u​n​d​a​t​i​o​n​/​F​o​u​n​d​a​t​i​o​n​.​h​>​
#​e​n​d​i​f​

You still had to explicitly link that framework into your program at compile time.

That worked pretty well for another decade, but recently Apple realized that developers were not maintaining their .pch files effectively. So, they made the compiler smarter and the @import directive was introduced:

@​i​m​p​o​r​t​ ​F​o​u​n​d​a​t​i​o​n​;​

This tells the compiler, “Hey, I’m using the Foundation module. You figure out how to make that work.” The compiler is given a lot of freedom to optimize the preprocessing and caching of header files. (This also eliminates the need to explicitly link the module into the program – when the compiler sees the @import, it makes a note to link in the appropriate module.)

As we write this, only Apple can create modules that can be used with @import. To use classes and frameworks that you create, you will still need to use #import.

We are writing this book on Xcode 5.0, and #import still appears in the template projects and files, but we are certain that in the near future @import will be ubiquitous.