For iOS development using Objective C, you will be familiar with #import which are a better version of #include, basically, skipping the need for include guards, which prevent including the same header file recursively.

#import and #include work the same, simple way – the preprocessor inserts the contents of the imported header files into the files at the point of the #import statements. This can lead to longer compile times as multiple headers are imported by many other files (and hence duplicated). Pre-compiled headers is a way to address this problem, basically, by caching commonly included header files. However, you need to manually maintain your pre-compiled header configuration, and if there’s only one group of people in the world who shouldn’t like to do things manually, that’s programmers.

Hence we have @import and modules.

You #import header files like this:

#import <UIKit/UIKit.h>

Using @import, you would do it like:

@import UIKit;

The one downside of modules is it only works for frameworks provided by Apple¹. But there are several advantages over #import-ing Apple frameworks:

1. Syntactically, it’s fewer characters to type.
2. @imports also automatically include the framework when linked so you don’t have to manually add the framework to your project target’s Build Phases, “Link Binary With Libraries” section.
3. Building projects become faster.
4. Lastly, once modules are enabled in your Xcode settings – under Build Settings, search for modules – #import statements for Apple frameworks are transparently treated as @imports.

Newer Xcode projects are created with modules enabled. For older Xcode projects, you’ll need to go into your project settings to enable module support.

[1] Actually that’s not true, if you manually write Module maps, they’ll work too.↩

Your feedback is valuable: Do you want more nuggets like this?   Yes   or   No