• Choose a category
• All
• Classic-Fiction

#lse

#define DebugLog(...) do { } while(0)

#endif

An excellent place for such a macro is your precompiled header file, usually named ProjectNamePrefix.pch and found in the Supporting Files group. This file is essentially included by every file in your project. Because modifying the precompiled header file (or any file it includes) triggers rebuilding the entire project, we usually include only files that will change very rarely, such as framework headers.

Creating a Release Build

Now that you know about build configurations—enough to know that when you’re distributing your app, you will want a release build—how do you create one? The simplest way to do this in Xcode is by archiving your target. Note that in the Scheme Editor the Release build configuration is selected for the Archive action. Select Archive in the Product menu. Your target will rebuild.

Xcode’s archiving feature is intended to assist with cataloging an application’s various release builds, as well as with maintaining its debug symbols for use later on with any crash logs you might gather in the future.

Once your target is archived, it will appear in the Organizer on the Archives tab (Figure 37.3).

Figure 37.3. Archives in the Organizer

You can then extract the app bundle from the archive by using the Share button. You will be prompted for the format to share it in. Choose Application to share only the app bundle (Figure 37.4).

Figure 37.4. Sharing Your Application

Once Xcode has exported the app bundle, you can compress it in a ZIP archive and post it on your Web site, or send it to your beta testing team.

A Few Words on Installers

If you are new to Mac, you may be wondering how you are going to create an installer for your application. Our advice is: Don’t. Application installation on a Mac is different from other platforms, and in most cases an installer adds unneeded complexity, and also hides its actions from the user. Most applications are installed by simply having the user drag them from their downloads folder into /Applications. This has the advantage of a very clear uninstallation: Drag the application to the trash.

There are two common approaches for packaging an application for download. Many app bundles are simply compressed in a ZIP archive. By default, Safari unarchives ZIP archives containing app bundles, making drag installation very easy for the user.

The second approach is to create a DMG (disk image), which has the advantage of displaying a Finder window with the contents of the image when it is opened (mounted). This allows for the inclusion of files in addition to the app bundle itself, such as a readme, a symbolic link to /Applications (to make drag installation even more convenient), and an optional custom background. Configuring such a DMG is complicated enough that there are third-party tools to help with the process.

Both approaches are not without their pitfalls. For example, users sometimes forget to drag the application to their /Applications folder, leaving it in their downloads folder or, worse, running it from the DMG. One solution some developers have implemented is to detect the app bundle’s location on startup and offer to move it for the user.

Note that Mac App Store apps cannot use an installer.

Application Sandboxing

In the old days, an application had all the same rights of the user running it. If you trust all your applications, this sounds fine. However, most users don’t have the luxury of running only apps they trust, and, more important, no user can run only bug-free applications. The unpleasant truth is that even a trustworthy application can have an innocent bug that causes damage to a system or allows an attacker access to the user’s system. Sandboxing is a big step toward mitigating this problem.

Sandboxing is a security method that constrains the means by which an application can interact with the system (filesystem, network). Applications on iOS have been sandboxed for years now. With Mac OS X Lion, Apple is bringing sandboxing