Support for SDKs for Other Platforms
The most significant addition to Xcode 3.1 is support for Software Development Kits (SDKs) for platforms other than Mac OS X. In addition to supporting SDKs for other versions of Mac OS X, Xcode 3.1 now supports SDKs that contain headers, libraries, plugins, and tools for developing for the iPhone and iPod Touch.
SDKs for other platforms are installed in the /Platforms directory in the Developer folder, and contain a directory tree that resembles the root directory of Mac OS, but populated with tools and plugins for the other platform. For example, the/Developer/Platforms/iPhoneOS.platform contains compilers and linkers in iPhoneOS.platform/usr/bin, Xcode plugins iniPhoneOS.platform/Developer/Plug-Ins, and individual SDKs for iPhone and iPod Touch development iniPhoneOS.platform/Developer/SDKs.
Apart from installing them, you will generally not see platform distinctions in Xcode. When you create a new project or target, you will see project types categorized by platform; when you edit and build projects, you will set the SDK that supports the frameworks and APIs that your code uses, and the SDK will determine what platform tools it needs.
New gcc-4.2 and llvm-gcc-4.2 Compilers
Xcode 3.1 includes the gcc 4.2 compiler as an alternative system C / C++ / Objective-C compiler.
In addition, the llvm-gcc-4.2 compiler is also included with Xcode 3.1. This compiler uses the LLVM backend and code generator with the gcc 4.2 parser, and supports C, C++, Objective-C, and Objective-C++. More information is available in the LLVM-GCC 4.2 Release Notes.
To use either of these new compilers in a project, you can use the new Compiler Version build setting and choose the compiler you want from the popup menu. By changing this setting in different targets and configurations and using the per-architecture and per-SDK popups, you have fine-grained control over which compiler is used in different circumstances. Note that neither gcc-4.2 nor llvm-gcc-4.2 will compile code against the 10.4u or earlier SDK, or deploy for Mac OS X 10.4 or earlier.
Updated New Project, New Target, New File assistants
The New Project, New Target, and New File assistants have been updated to a more modern user experience and up-to-date templates.
New projects created from the templates use several conventions different from previous versions of Xcode. You should be aware of these differences when working with the projects or sharing them with Xcode 3.0 or 2.5 users.
Projects are created with Xcode 3.1 compatibility and need to be set to a different compatibility level to be used on other versions of Xcode. Xcode 3.0 project templates were created with Xcode 2.4.1 backwards compatibility already set.
The initial Project Configuration is set to Debug. The “default configuration” for building from the command line withxcodebuild is still Release.
The Architectures build setting is set to “Standard 32-Bit” for all configurations at the project level. The “Only Active Architectures” build setting is set for the Debug configuration. This means that in general Release builds are 2-way fat and Debug builds are one-way thin for the build machine.
Source files created without a matching header file do not have the #include line for the nonexistent header.
The ORGANIZATIONNAME substitution value in templates is now replaced with the Company Name from the current user’s Address Book card if present, rather than __MyCompanyName__. If the PBXCustomTemplateMacroDefinitions user default has already been set, it will be honored.
ALWAYS_SEARCH_USER_PATHS is not set in any templates.
Updated Factory Settings for Preferences, Toolbars, and Window Geometry
To simplify the Xcode experience for new users, the initial Project Window (in Default layout only) is now larger and shows the Editor pane by default. The default Toolbars on all modules have been simplified and made more consistent. Defaults in the General, Building, Debugging, Text Editing, and Indentation preference panes have been changed to reflect the expectations of new users.
Users who have set their own preferences, window size, or toolbars will generally not see these changes; they will be seen only by users who have not customized the factory settings. Opening any project in Xcode 3.0 may reset your global Toolbar settings to Xcode 3.0 factory settings, removing the new Xcode 3.1 default configuration.
New Integrated Property List Editor
Selecting a Property List file in the Groups and Files or Detail view now opens the file in a tabular outline instead of text form, regardless of whether the property list is in old-style text, XML, or binary format. You can expand and collapse the arrays and dictionaries in the property list as in any outlining tool, and edit the keys and values. Option-click the disclosure arrows to Expand All or Collapse All.
To see the property list in text form, control-click and choose Open As... ▶ Source Code File or Plain Text File.
The editor will edit any property list file as a generic property list. In addition, provided Property List Definitions allow you to view and edit the property list in a structured way. Definitions are provided for Info.plist, .scriptSuite, and .scriptTerminology files in the Mac OS X platform. To apply a definition to the property list in the editor, choose View ▶ Property List Type.
To create a new entry in the property list, simply select a row and press Return. If the row is a containter (array or dictionary) and is disclosed, a child item will be created; otherwise, a peer item is created. Option-Return toggles the expansion state of the item before adding a row. The + button at the end of a row has the same effect as Return, including following the option key behavior.
If the Property List Type is None, you’ll get a generic item and have to set the key name and the value type manually (with the context menu obtained by Control- or right-click) . If the property list is of a defined type, a default key and value will be assigned automatically; pick from the popup in the Key column to change the key (and therefore the type).
You can drag and drop to reorder items in arrays (and, in fact, dictionaries, though you cannot rely on the order of keys in dictionaries). You can print property lists at their current disclosure triangle expansions state.
All of the features of the embedded Property List editor are available in the stand-alone Property List Editor application.
Comments are not supported and are deleted from the plist document when saved. This includes preprocessor #defines in files meant to be preprocessed. The Property List Editor will not open an XML property list error if the #define comments appear before the XML header block.
Updated FileMerge application
The standalone File Merge application has been updated with the inner workings of Xcode’s built-in file comparison utility. This results in faster and more accurate diffing of files, and has addressed a number of longstanding bugs and shortcomings. Specifically, the new File Merge can handle files of differing line endings properly, as well as ignoring leading white space on lines.
Updated Open Quickly panel
The Open Quickly panel has been updated in both function and appearance. The previous Open Quickly search paths in the Xcode Preferences are ignored and have been removed; Open Quickly searches known locations in the project, including the index, the SDKs in use, and the Header and Framework Search Paths, to find symbols and files.
Open Quickly now does autocompletion for known terms, and shows multiple results in a list for selection with the arrow keys. The magnifying glass icon in the search bubble holds recent searches for reference.
The behavior of the Jump to Definition function now mirrors the Open Quickly feature, essentially jumping directly to the first result that the Open Quickly panel would have shown.
Previous implementations of Open Quickly would jump directly to a file if the insertion point were set in its file name. This was confusing to people who wanted the Open Quickly panel but had the insertion point inadvertently set in a valid file name. The behavior is still available with Option-Open Quickly. You can also change your Key Bindings to associate Command-Shift-D with the Open This Quickly action, which makes the old behavior the default. In addition, you can set defaults write com.apple.Xcode XCOQSkipPanelBehavior to any of these values:
0 | Default behavior |
1 | Always show the Open Quickly panel |
2 | Skip the panel if the insertion point is in a valid file name in an #include or #import statement |
3 | Always skip the panel if a good match is found |