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:
Using @import, you would do it like:
The one downside of modules is it only works for frameworks provided by Apple1. But there are several advantages over #import-ing Apple frameworks:
- Syntactically, it’s fewer characters to type.
- @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.
- Building projects become faster.
- 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.