Project Modernization

When you open a project, Xcode 4 evaluates it to see whether there are any settings that should be updated. This feature provides an easy way to make sure your projects conform to the latest SDKs and best practices.

Open the Issue navigator to see whether anything in your project needs to be updated. You can also select the project in the project navigator and choose Editor > Validate Settings.

If the Issue navigator lists modernization issues, click the issue to see a dialog that explains the updates that should be made and lets you perform any or all of them.

After you have clicked Perform Changes, whether you choose to make all the changes or not, Xcode does not show the warning again. To rerun the check, select your project in the Project navigator and choose Validate Settings from the Editor menu.

Default Compiler

The default compiler for iOS development in Xcode 4.1 is LLVM-GCC 4.2. Compared with the GCC compiler that was the default in Xcode 4.0, LLVM-GCC provides better code generation and optimization than GCC, while being exactly source compatible with GCC 4.2.

Custom Behaviors

The Behaviors preferences pane lets you specify what should happen when a variety of events occur. Xcode 4.1 introduces new Behavior options, such as running a script, collapsing and expanding the navigator and utilities panes and the toolbar, or switching to Full Screen mode. This feature greatly expands the power of Xcode behaviors, enabling Xcode to run a script or perform a variety of actions in response to a large number of triggers.

You can also can design custom behaviors by defining behaviors that are triggered by menu items or their key equivalents. This feature allows you to create behaviors that you can invoke at any time. Once you’ve created a behavior, it appears in the Xcode > Behaviors menu.

To assign key equivalents to custom behaviors, in the Key Bindings preferences pane, select the Customized tab to find the behavior for which you want to assign a key equivalent.

Preprocessor or Assembly Output

Xcode 4.1 introduces commands in the Product > Generate Output menu to process source files and generate the preprocessed output or assembly output.

The preprocessor evaluates directives in your source code (instructions starting with the pound sign (#) such as includes, defines, and conditional logic) and converts them into C code to be sent to the compiler. You can examine the preprocessed output to make sure that the logic in your source code is being interpreted by the preprocessor as you expect in order to debug compilation problems.

The assembly output is the set of instructions that the compiler generated from the preprocessed output. You can study the assembly output to see how the instructions were formed or ordered, to seek out better optimization patterns, or to look for compiler bugs.

The output type is also a new category in the assistant editor for a selected primary file.

Autolayout

Interface Builder in Xcode 4.1 adds support for the new AppKit Autolayout feature. Autolayout, available starting with OS X v10.7 Lion, uses relationships called constraints to govern the layout of objects in the user interface. This feature is a complete replacement for the autoresizing mask. As you make changes to any view or control in Interface Builder (move it around, resize it, change an attribute, add a subview, and so forth), Interface Builder automatically adds and removes constraints based on the new layout. When you enable this feature, Interface Builder shows the constraints as you work.

Autolayout is enabled per nib. To start using Autolayout, select the Use Autolayout checkbox in the File inspector for each nib. When you enable Autolayout, Xcode updates your build settings, if necessary, to ensure your deployment target is OS X v10.7 or greater. For nib files in projects that had been targeted for OS X v10.6 or earlier, Interface Builder adds constraints to your nib files automatically when you enable Autolayout.

You can edit an automatic constraint or add your own. To add a constraint, select the view or views for which you want to add the constraint and choose a constraint from the Editor > Add Constraint menu.

You can delete a user constraint, but not an automatic constraint. Rather than trying to delete automatic constraints, create the constraints you want.

Build Setting Values in Scheme Pre- and Post-Action Scripts

There is often a need to access values from the target build settings in pre- and post-action scripts (similar to the way shell script build phases work). This enhancement allows a pre- or post-action script to define the target build settings to use via a pop-up menu in the scheme editor’s pre- and post-action panes.

OS X Application Sandbox

An application sandbox enforces restrictions, known as entitlements, on how an application can interact with the rest of the system. A sandboxed application is harder to compromise and therefore enhances security for users. For example, if your application has no need to have access to the network, you can specify that the application’s sandbox should prohibit network access. Then if a hostile hacker manages to take over control of your application on a user’s computer, the hacker won’t be able to use the application to send email or connect to the internet.

The iOS platform has supported entitlements for a while, and with Lion, OS X does as well. With Xcode 4.1, the project editor provides a UI for setting up entitlements for OS X applications. You can set entitlements for each target in the project editor. There is also a default code-signing entitlements file available in the file templates in the utilities pane.

When you enable application sandboxing, you can select an entitlements file if you already have one. If you do not, Xcode creates one with the name of your project and the extension entitlements. You can view and edit this file with the property list editor in Xcode.

Debugger Disassembly

The debugger disassembly feature provides you the ability to select what kind of content you view when debugging: source only (when available), disassembly only, or source and disassembly. The disassembly is the set of assembly-language instructions seen by the debugger while your program is running. Viewing the disassembly can give you more insight into what your code is doing when it’s stopped at a breakpoint. By viewing the disassembly and source code together, you can more easily relate the instruction being executed with the code you wrote.

Choose Product > Debug Workflow to enable the disassembly-only display. The source and disassembly display is implemented as an Assistant category.

Git Remote Management

Support has been added in Xcode 4.1 for managing GIT remote repositories. You can select remote repositories from appropriate SCM workflows (such as push or pull). This feature enhances the ability of Xcode to be used for source control management.

In-Place Snapshot Restoration

With the Xcode 4.0 release, snapshots could not be restored on top of the current project content. The workflow for replacing the current version of your application with the version preserved in a snapshot involved restoring the snapshot, and then using the Finder to delete the current version and move the snapshot version into the appropriate folder. With Xcode 4.1, snapshots are automatically restored on top of the current version, unless you specify otherwise.

In Xcode 4.1, when you choose Restore Snapshot from the File menu and select the snapshot to restore, Xcode displays a preview dialog in which you can review the differences between the current version of the project and the snapshot version. When you click Restore, Xcode replaces the current version of the project with the version in the snapshot. Xcode makes a snapshot of the current version before replacing it.

To restore a snapshot in a new location instead of restoring on top of the current project, select the snapshot in the Projects pane of the Organizer window, choose the project you want to restore, and click the Export Snapshot button at the bottom of the window.

Internal Project Files in Repositories

This feature provides visibility into internal project files (schemes, user interface settings, and so forth) when looking at SCM details in the SCM commit and update workflows. You can use this facility to save and keep track of versions of project files in the same way as you save and keep track of source files.

Scheme and Run-Destination Selection

The popup menu for selecting schemes and run destinations has been changed to a path control, in order to provide you the ability to select either the scheme or run destination independently. You can still select both in a single gesture (using the submenus of the schemes). For projects or workspaces having a large number of schemes and several run destinations, this path control makes the menu much shorter and easier to deal with.

Key Bindings for Closing a Project or a Workspace

In Xcode 4.0, there was no default key binding to close a project or workspace. If you held the Option key when clicking the close box in the upper-left corner of the workspace window, all tabs, windows, and the project were closed, so that when you reopened the project, your previous set of windows and tabs did not reopen. In Xcode 4.1, the Command-Option-W key combination closes the project or workspace. Also, when you hold the Option key and click the close box, the project or workspace closes without first closing all windows and tabs. In this way, your window configuration is restored the next time you open the project.

Interface Builder Plug-in Support

If you used Interface Builder plug-ins in Xcode 3, you can continue to build and run your project in Xcode 4, and you can update your project to make your nib files editable in Xcode 4.

Xcode 4 provides limited support for Interface Builder 3 plug-ins. Specifically, you can build a project with Interface Builder plug-in dependencies, but you can’t edit the nib files. When you try to open a nib file with plug-in dependencies, Xcode 4 displays a dialog suggesting that you update the file. If you agree, Xcode converts the class of custom objects built with plug-ins to the nearest AppKit class. If the conversion isn’t possible, Xcode 4 provides a detailed error message. In that case, you must remove the plug-in dependency using Interface Builder 3 before you can edit the nib file in Xcode 4.