What’s New in Objective-C and Foundation in iOS 7

Note from Ray: This is an abbreviated version of a chapter from iOS 7 by Tutorials that we are releasing as part of the iOS 7 Feast. We hope you enjoy!

Objective-C is the most common language for developing iOS and OS X apps. Sure, you can use third party frameworks that allow you to develop apps using other languages such HTML & Javascript or C#, but if you want to write blazingly fast, super efficient native apps then you need to use Objective-C.

Foundation is one of the core frameworks that you’ll use when developing Objective-C applications.

As an iOS developer, it’s critical to keep up-to-date with the latest advances in Objective-C and Foundation – and in iOS 7, there are some important changes you need to know about.

In this article, you’ll take a quick tour of some of the new features in Objective-C and Foundation.

Note that this is an article instead of a tutorial – you’ll get a quick crash course of what’s new (with some code snippets along the way), so you can get up-to-speed as quickly as possible.

Let’s dive in!

Modules

Chances are good that you’ve written the #import statement a thousand times or more:

#import <UIKit/UIKit.h>
#import <MapKit/MapKit.h>
#import <iAd/iAd.h>

This syntax harkens back to the roots of Objective-C: vanilla C. The #import statement is a pre-processor directive that works in a similar fashion to #include. The only difference is that #import doesn’t re-import headers that have already been imported; it’s a one-shot deal.

When the pre-processor meets an #import directive, it literally replaces that single line with the entire contents of the header file being imported. It does this recursively, through a potentially large number of header files.

The UIKit umbrella header, UIKit.h, imports all of the other headers included in the UIKit framework. This means that you don’t have to manually import each header file in the framework, such as UIViewController.h, UIView.h or UIButton.h.

Curious about the size of the UIKit framework? Go through and count all the lines in the entirety of UIKit’s headers, you’ll find it amounts to over 11,000 lines of code!

In a standard iOS app, you’ll import UIKit in most of your files, meaning every single file ends up being 11,000 lines longer. That’s less than ideal; more lines of code means longer compile times.

Original solution: Pre-compiled Headers

Pre-compiled header files, or PCH files, attempt to address this problem by providing a mechanism for pre-computing and caching much of the work required during the pre-processing phase of compilation. You’ve probably seen the stock PCH file that’s generated by the templates bundled with Xcode; it looks like this:

#import <Availability.h>

#ifndef __IPHONE_5_0
#warning "This project uses features only available in iOS SDK 5.0 and later."
#endif

#ifdef __OBJC__
    #import <UIKit/UIKit.h>
    #import <Foundation/Foundation.h>
#endif

The #warning in there notifies the developer if the app they’re building targets an SDK prior to iOS 5. The UIKit and Foundation umbrella header files are part of this stock PCH, since every file in your app will use Foundation and most will use UIKit. Therefore these are generally good additions to the PCH file so that the pre-computation and caching will benefit the compilation of every file in your app.

“So what’s wrong with that?” you might ask. There’s nothing technically wrong with the PCH as-is — if it isn’t broke, don’t fix it. However, you may be missing out on a host of performance benefits that result from a well-maintained, highly tuned PCH file. For instance, if several areas of your app use the Map Kit framework, you may see an improvement in compilation time by simply adding either the Map Kit umbrella header file or the individual header files of the Map Kit classes you use to the PCH file.

We’re all guilty of being lazy developers though, and nobody has time to tune their PCH file for each project they work on. That’s why modules were developed as a feature of LLVM.

Note: LLVM is a collection of modular and reusable compiler and toolchain technologies bundled with Xcode. LLVM has several components; the most important ones for Objective-C developers are Clang, the native C, C++ and Objective-C compiler; and LLDB, the native debugger ¬¬— which is the developer’s best friend.

New solution: Modules

The first public appearance of modules in Objective-C was in a talk given by Apple’s Doug Gregor at the 2012 LLVM developers’ meeting. It’s a fascinating talk, and it’s highly recommended for anyone interested in the workings of their compilers. You can find the video of the session online at http://llvm.org/devmtg/2012-11/#talk6.

Modules encapsulate frameworks in much cleaner ways than ever before. No longer does the pre-processor need to replace an #import directive with the entire contents of the file verbatim. Instead, a module wraps a framework into a self-contained block, which is pre-compiled in the same manner as a PCH file and delivers the same improvements in compilation speed. However, you no longer have to state which frameworks you’re using in a PCH file; you get the speed boost simply by using modules.

But there’s more to modules than just that. I’m sure you recall the numerous steps you go though the first time you use a new framework in an app; it tends to go something like this:

1. Add #import line to the file using the framework.
2. Write code that uses the framework.
3. Compile.
4. Watch as errors are spat out during linking.
5. Remember that you forgot to link the framework.
6. Add the linking of the framework to the project build phase.
7. Compile again.

It’s incredibly common to forget to link the framework, but modules solve this issue neatly as well. (Is there anything that modules can’t do?)

A module tells the compiler not only which header files make up the module, but also what needs to be linked. This saves you from having to manually link the framework yourself. It’s only a small thing, but anything that makes developing code easier is a good thing!

How to use modules

Modules are extremely easy to use in your projects. For existing projects, the first thing to do is enable them. You can find this option by searching for modules in the project’s Build Settings (making sure to select All, not Basic) and then changing the Enable Modules options to Yes, like so:

All new projects created with Xcode 5 have this enabled by default, but you should definitely enable it on all your existing projects.

The Link Frameworks Automatically option can be used to enable or disable the automatic linking of frameworks as described earlier. There’s little reason why you’d want to disable this though.

Once modules are turned on, you can start using them in your code. To do that, it’s simply one small change to the syntax you’re used to. Instead of the usual #import syntax, you simply use @import:

@import UIKit;
@import MapKit;
@import iAd;

It’s still possible to import the parts of a framework that you need. As an example, if you wanted to import just UIView, you would write this:

@import UIKit.UIView;

Yup — it really is that simple! Well, sorry, that’s not exactly the truth. It’s even simpler than that. Technically, you don’t need to convert all your #import lines to @import lines, as the compiler will implicitly convert them for you under the hood. However, it’s always good practice to start using new syntax as often as you can.

Before you start getting too excited about modules, there is one little caveat, unfortunately. As of Xcode 5.0, it’s not possible to use modules with your own frameworks or third-party frameworks. This will probably come in time — but for now it’s an unfortunate downside. Nothing’s perfect – not even Objective-C!