Apple Developer Connection
Advanced Search
Member Login Log In | Not a Member? Contact ADC

Xcode

Xcode 2.4.1 Summary Release Notes

Xcode 2.4.1 is the latest release of Apple Computer's integrated development environment for Mac OS X. This release addresses many known issues and is a recommended upgrade for all Xcode users of versions 2.2.1 or earlier. Please choose Show Older Release Notes from the Help menu to see the release notes for previous releases of Xcode. Additionally, the complete list of Xcode and related tools release notes can be found from within Xcode by choosing Help -> Xcode Help from the menu bar, and selecting the "Release Notes" bookmark item or look in the /Developer/ADC Reference Library/releasenotes folder.

The About Xcode Tools document located in the documentation folder discusses Xcode and its role in development on Mac OS X.

Changes to Xcode 2.4.1

  • Stability and security fixes in the Xcode IDE, cctools, debugger, and compiler
  • CHUD has been updated to version 4.4.3. CHUD also releases independent from the Xcode Tools releases. Current versions of CHUD can be found at: http://developer.apple.com/tools/download/
  • The 10.3.9 and 10.4u SDKs have been updated.
Since the release of Xcode 2.3 both the Stabs and DWARF debugging format have been fully supported by Xcode. By default Xcode uses Stabs for new and existing projects in this release. Apple recommends moving to DWARF when possible due to its superior debugging fidelity and more efficient use of disk and memory space. For information on changing this setting see the DWARF documentation below.

General Issues

  • Supported configurations

    Xcode 2.4.1 will run on Mac OS X 10.4 (Tiger) on a Macintosh with either a PowerPC or an Intel processor. It will not install or run on earlier versions of Mac OS X. Xcode 2.4.1 supports development that targets Mac OS X 10.1, Mac OS X 10.2 (Jaguar), Mac OS X 10.3 (Panther), or Mac OS X 10.4 (Tiger) (both PowerPC and Intel) using the Mac OS X SDK support.

  • Project File Format and Extension Changed for Xcode 2.1 and later

    To support new features in Xcode 2.1, Xcode's project file format was changed. Xcode 2.1 and later will open projects created with earlier versions of Xcode, and allow you to save them in the same directory with a new extension (.xcodeproj). Once upgraded for Xcode 2.1 or later, a project file cannot be opened or built by Xcode 2.0 or earlier.

    Note that you will have to add the new project file to your SCM repository. If the project contains references to other projects, those references are not updated automatically. You must open and upgrade those projects, then change the project reference to the upgraded project.

    If xcodebuild is executed in a directory containing both .xcode and .xcodeproj projects, it will prefer the newer format. If it finds only a .xcode project, it will upgrade it for building only, without saving the upgraded project file. Previous versions of xcodebuild will ignore the new project files.

    Please see the "Installation Notes" section at the bottom of this document for more detailed installation instructions.

Build System

Enhancements

  • Support for DWARF Debugging Format

    The Xcode IDE now includes support for the DWARF format of debugging information. DWARF is an alternative to the Stabs format which was the only format supported in older versions of Xcode. Stabs is still available and is still the default debugging format, but DWARF may be chosen as an alternative format.

    The debugging information format can be set in Xcode via the “Debug Information Format” (DEBUG_INFORMATION_FORMAT) build setting. It supports the following options:

    • Stabs: Xcode will use the Stabs debugging format. This is the default value.
    • DWARF: Xcode will use the DWARF debugging format.
    • DWARF with dSYM File: Xcode will use DWARF and generate a separate symbol file (with the extension .dSYM), rather than relying on the symbol information stored in the individual object files.

    If ZeroLink is enabled, then Xcode will not generate a .dSYM file even if directed to do so, as this combination is not supported. In addition, .dSYM files should not be generated for targets that produce static libraries or object files, only enable DWARF in these cases.

  • Improved support for Nasm

    Xcode now supports the Netwide Assembler (Nasm) for Intel directly as a separate compiler. Support for the -fnasm flag has been removed from GCC, and it is therefore recommended that users move to using the compiler specification, which works as follows:

    • Nasm only applies when building for the Intel architecture.
    • A new file type for Nasm files has been added, which recognizes the .nasm file extension. For Nasm files with a different extension (e.g., simply .asm), it is recommended that you change the file type for the file's reference in the inspector to 'sourcecode.nasm'.
    • A built-in build rule maps the Nasm file type to the Nasm compiler specification.

    See the nasm man page for information on the available command-line arguments for this tool.

  • Improvements to sharing precompiled headers

    A new build setting, Increase Sharing of Precompiled Headers (GCC_INCREASE_PRECOMPILED_HEADER_SHARING), will increase sharing of precompiled headers among targets which share the same prefix header and precompiled header directory. Specifically, search path options to the compiler (e.g., -I, -F) will not be considered when computing the hash value used to identify the PCH to use for a given file.

    Enabling this build setting carries some risk, since targets which use the same prefix header, but include different files (due to different search paths when precompiling that header), will not truly be able to share the same header. In that case, this option must be turned off to ensure correctness and avoid subtle build problems.

  • Better linking support

    When linking against a framework or library, which is referenced via a project reference, Xcode will now properly track changes to and dependencies on the framework or library and re-link if it changes. Moreover, it will pass to the linker the full path to the referenced binary so that search paths are not necessary in order to link against it. In the event that you wish to use a search path to link against it, the recommended solution is to create a standalone reference to the file rather than using a reference which comes from a project reference.

  • Clean improvements

    A checkbox has been added to the clean confirmation sheet labelled “Also Clean Dependencies”. When checked (the default), then the dependencies of the targets to be cleaned will also be cleaned. When unchecked, the dependencies will not be cleaned. A -nodependencies option has been added to xcodebuild to support this behavior (but only for the clean action).

  • Improved support for processing Info.plist files

    Now Xcode correctly preprocesses a target's Info.plist even if it uses build setting macros of the form $(X). Xcode runs the Info.plist through the GCC preprocessor first, and then expands any build setting macros in it. Finally, (if needed) a PkgInfo file is produced from the preprocessed, macro-expanded version of the Info.plist. As before, both the preprocessing and macro expansion steps can be skipped by configuring the corresponding build settings in the target (or project) inspector.

    Note that many Xcode project templates include build settings in their Info.plist files by default, so if you choose to disable build setting expansion in the Info.plist file then you must edit the file to replace those build settings with appropriate concrete values.

  • Build settings inspector now shows setting definitions

    The build settings inspector now shows the evaluated values in the ‘Values’ column. For example, if the value is $(TEMP_DIR)/$(PRODUCT_NAME), then the value column shows the resulting value based on the current definitions of the referenced properties in selected build configurations. In order to see and/or edit the definition, either double-click on the value, or select it and click the Edit button.

Dedicated Network Builds

Enhancements

  • Dedicated Network Builds is a new feature in Xcode 2.4.1 targeted at developers of large projects with dedicated build farms for compilation. The existing distributed builds mechanism (distcc) does not scale past 6 to 12 builders, depending on network speed and host architecture. Dedicated Network Builds is designed to scale well beyond a dozen builders and has been tested with up to 32 builders. Dedicated Network Builds uses an advanced caching mechanism such that bandwidth between the build client (recruiter) and builders (volunteers) is minimized.

    Dedicated Network Builds is not a replacement for distcc builds, which is best used for small- to mid- size projects, and ad-hoc, auto-discovered builders. Volunteer machines participating as Dedicated Network Build builders are not auto-discovered. Instead, each machine must be added to the preferences pane in Xcode. This workflow will be improved in a future release.

    Processes on the builder are run chrooted to a mount point whose underlying filesystem mirrors the filesystem on the build recruiter (the machine running the Xcode build). As such, whatever version of the compiler and headers installed on the build recruiter will always be used for the compilation process on the volunteers. As a result of this, the compiler and system version number in the preferences pane will be shown as the same for all volunteers.

    Dedicated Network Builds also uses more volunteer machine resources, so dual-use build volunteers/developer workstations are not recommended.

Known Bugs & Workarounds

  • "Recruiter daemon isn't listening", "no such file or directory" messages when building using Dedicated Network Builds.

    A bug in the bfobserver daemon, which is responsible for initializing the DNB system on recruiter hosts (developer machines) sometimes causes builds to fail with the message "Recruiter daemon isn't listening". The bfobserver daemon is managed through launchd(8) and can be controlled using the launchctl(1) command. Issue the following commands to restart the bfobserver if any of the above build errors appear:

    sudo launchctl unload /System/Library/LaunchDaemons/com.apple.dnbobserver.plist
    sudo launchctl load /System/Library/LaunchDaemons/com.apple.dnbobserver.plist

    After issuing these commands, toggle the "Distribute via" checkbox in the Distributed Builds preference pane off and on again.

    The bfobserver binary is located at /System/Library/'PrivateFrameworks/DedicatedNetworkBuilds.framework/Resources/bfobserver. Running this binary by hand requires "sudo" access, and it logs debugging messages to standard output. Remote users logging in via ssh who need to restart the daemon can use this method.

    For more information on the launchctl command, see the manual page for launchctl(3).

  • Restarting a crashed volunteer daemon.

    The volunteer daemon should not crash. In the rare case that it does, Xcode reports a message to the build log when a job fails on a remote build volunteer. If one volunteer consistently reports failures, restart the volunteer daemon on that machine with the following commands:

    sudo launchctl unload /System/Library/LaunchDaemons/com.apple.dnbvolunteer.plist
    sudo launchctl load /System/Library/LaunchDaemons/com.apple.dnbvolunteer.plist
  • Enabling the volunteer daemon without opening Xcode

    On a machine with the Xcode development tools installed, the volunteer daemon can be enabled without launching Xcode. Issue the following command:

    sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.dnbvolunteer.plist

    The -w flag to launchctl load writes the property list back out in the enabled state, which will persist across reboots.

  • Enabling debug output.

    The Dedicated Network Build daemons are controlled via launchd. /System/Library/LaunchDaemons contains two property lists named com.apple.dnbobserver.plist and com.apple.dnbvolunteer.plist that control the launching and configuration of the daemons.

    Adding the following lines to the property list files enables debug logging. This can be helpful when reporting bugs:

    <key>StandardOutPath</key>
    <string>/path/to/file</string>
    <key>StandardErrorPath<key>
    <string>/path/to/file</string>

    For more information on launchd property lists, see the manual page for launchd.plist(5).

  • Increasing the number of concurrent distributed tasks.

    The user default XCMaxNumberOfDistributedTasks in the com.apple.Xcode domain controls how many concurrent compile jobs Xcode will send to the DNB system at once (25 by default). This value can be manipulated with the following command:

    defaults write com.apple.Xcode XCMaxNumberOfDistributedTasks <desired-number>

    Setting desired-number to a value higher than 100 is not recommended. Several timing runs at increasing concurrency levels can help in determining the optimal value for your hardware profile and project setup.

  • Compatibility between recruiter and volunteer

    While a mix of volunteers can be configured via the preferences panel, only volunteers of the same CPU architecture as the recruiter will be used.

    It is highly recommended that the recruiter and volunteers all run the same version of Mac OS X, including all of the same system patches. The chrooted environment ensures isolation from the volunteer system down to, but not including, the kernel. As such, the libSystem on the recruiter must be compatible with the kernel running on the volunteer.

Debugging

Enancements

  • Better tracking of breakpoints across projects

    The Breakpoints window now shows all breakpoints that will be used in the current debugging session. Dependent projects are shown as items of the current project and unrelated projects are shown at the same level of the current project. Checkboxes in the outline view allow for the breakpoint from these other projects to be ignored. If you have two completely un-related projects open you can now specify that you don't want to include the breakpoints from the other project when debugging. (It used to be the case that all breakpoints from all open projects would be used for each debugging session.) The location, or module (shlib/executable/ZeroLink file), of a breakpoint is now shown and can be edited. This gives better feedback on where Xcode is attempting to set a breakpoint. Deleting the location of a symbolic breakpoint will cause the breakpoint to be set at the first occurrence of the symbol in the next debugging session.

  • Support for template breakpoints

    Xcode will now set template breakpoints in more than one location. They will only show up as one breakpoint in the Breakpoints window. A tooltip in the ‘Breakpoints’ column for a set template breakpoint will show the gdb breakpoint numbers, address and executable/shlib/bundle the breakpoint is set in. In this release GDB will not re-evaluate template breakpoints for each bundle/shlib load once the initial breakpoint has been set. To specify a bundle/shlib you can edit the ‘Location’ for the breakpoint in the Breakpoints window by double clicking the location and entering a new one. Enter an empty location to return the Breakpoint to Xcode’s control for determining the location.

  • New DWARF debugging format and .dSYM files

    Debugging with DWARF information stores all debug information in the object files and creates a debug map in the final executable or shared library runtime file. Object files must remain present on the build machine in their original location in order to debug.

    dsymutil archives all DWARF debug information found in all object files for an executable by parsing the debug map and linking all of the debug information into a single file. Object files can be deleted after the creation of a .dSYM file. dsymutil was meant to archive debug information (for later use in debugging binaries that have no debugging information) and is not intended for use in fix/compile/debug cycles. Linking the debug information using dsymutil can greatly slow build times and was implemented with a focus on correct archiving, rather than speed.

  • Double-clicking on a stack frame will take you to that function in a separate editor.
  • Pended breakpoints are shown as orange in the editor gutter.
  • Variable format settings, hex/decimal/OSType etc, are remembered across debugging sessions.
  • Registers are split into several items in the Variables View and Expressions window.

Design Tools

Enhancements & Changes

  • Command-. and the ‘Escape’ key now dismiss the predicate builder sheet.

Bug Fixes

  • Initial sort ordering is improved for the “Properties” list in the diagram view.

Documentation

Enhancements & Changes

  • Documentation bookmarks can now be dragged into text files (resulting in the associated URL being pasted into the text).
  • Added a new item to the User Scripts menu to convert the selected method definition to a selector.
  • Option-double-click now works on symbols names in documentation windows.
  • Now Command-. and the ‘Escape’ key cancel the “Open man page…” dialog.
  • Command-E (Find→Use Selection for Find) now works properly in framesets in the documentation window.
  • Now you can miniaturize the documentation window.
  • Now you can remove extended documentation locations with the delete key.
  • Bookmarks in the Documentation window can now display a contextual menu allowing you to rename or delete them.

Project Editing & Navigation

Enhancements & Changes

  • When using an SDK, Xcode now recognizes C++ Standard Library files without file extensions as source code.
  • C++ template files with the extension .tcc are recognized as source code.

Source Code Management

Enhancements & Changes

  • Now when displaying annotations for a file under Subversion, per-line date information is shown.
  • By default, Xcode looks for svn in /usr/local/bin/svn.

Bug Fixes

  • Xcode’s Subversion support now deals properly with non-ASCII characters in paths and filenames.
  • SCM integration now works when run on a system that is set to use Hebrew (or possibly other non-Roman languages).
  • Xcode is now more robust when stopping SCM operations via the activity viewer.
  • Fixed problems attempting to rename a source file that was just added (but not committed) to a Subversion repository.
  • Fixed a problem where renaming files under Subversion would cause the file type information in the inspector to be displayed incorrectly.
  • The SCM smart group is no longer home to file references after they have been deleted.
  • Xcode now correctly handles return characters in commit messages when using Perforce.
  • When renaming a file under Subversion, we properly remove the old file from the repository.

User Interface

Enhancements & Changes

  • Fixed some problems with keyboard navigation when using the list mode of the open panel. The old behavior of being able to select a folder and then open the first project found in the folder is now turned off by default and is hidden behind a default (XCOpenProjectFilesInsideFolders).
  • Key bindings can now be assigned to items in the User Scripts and Window→Tools menus using the Key Bindings Preferences pane.
  • Now you can assign key bindings to the Help→Open man page… menu item.

Bug Fixes

  • Xcode is better about notifying users that a read-only project has been changed when closing it.
  • When quitting Xcode we now show the complete list of files with unsaved changes.
  • Fixed problems where Xcode projects were not showing up properly on secondary displays.
  • Fixed a problem where changes in a text field being edited in a floating inspector could be lost when switching to another application.
  • Fixed a problem where Subversion silently refused to rename files with local modifications.

Unit Testing

Enhancements & Changes

  • The following assertion macros have been deprecated, and are now protected by an #ifdef: fail, fail1, should, should1, shouldnt, shouldnt1, shouldBeEqual,shouldBeEqual1, shouldRaise, shouldRaise1, shouldntRaise, shouldntRaise1, shouldnoraise, should1noraise, shouldntnoraise, shouldnt1noraise. If you need to continue using these macros, you must #define STEnableDeprecatedAssertionMacros before importing any headers from SenTestingKit.framework. One way to do this is to add STEnableDeprecatedAssertionMacros=1 to a “Preprocessor Definitions” build setting.
  • The DYLD_FRAMEWORK_PATH and DYLD_LIBRARY_PATH environment variables will now be properly set before unit tests are injected into an application under test. This means that if the application depends on loading any frameworks from its shared build directory that it will locate them properly.
  • The /Developer/Tools/RunUnitTests script used by the Xcode unit testing infrastructure now returns the result code generated by an application into which tests are injected, bringing application tests in line with framework tests.

GCC Compiler

Apple's GCC 4.0 is now based on version 4.0.1 of the Free Software Foundation's GNU Compiler Collection. For complete notes on Xcode's use of GCC and pointers for transitioning between versions of the compiler, please view the complete GCC release notes here:

/Developer/ADC Reference Library/releasenotes/DeveloperTools/GCC4.html
/Developer/ADC Reference Library/releasenotes/DeveloperTools/GCC3.html

Changes in command-line options

  • -fno-nested-functions is the default for C and Objective-C which disables nested functions by default. -fnested-functions can be used to enable support for nested functions.
  • The -fuse-cxa-atexit flag is now working and on by default, which means that destructor ordering is now correctly the inverse of constructor ordering, and bundles may be unloaded when running on Mac OS 10.4 and higher.
  • -ggdb now produces DWARF, since this gives better debugging than STABS.
  • The -fnasm flag was removed from the compiler; users should use nasm directly if running GCC from the command-line.

Optimization

  • Optimization for code size (-Os) optimizes for size, but not at the expense of speed. -Os enables all -O2 optimizations that do not typically increase size. However, instructions are chosen for best performance, regardless of size.
  • Optimization for code size at any cost (-Oz) optimizes for size, regardless of performance. -Oz enables the same optimization flags that -Os uses, but -Oz enables instructions that encode into fewer bytes.

64-bit

The CALL_ON_UNLOAD pragma, which never worked, has been made an error. Users should use '__attribute__(\ (destructor))' or another alternative.

Support for section attribute on functions

This version of the compiler now supports the section attribute on functions. For example, the following code will assign function foo into section __bar of segment __TEXT: 

   void foo (void) __attribute__((section("__TEXT,__bar")));
   void foo (void) { }

x86

long long is now used as principal type for Vector intrinsic type __m64. This is a C++ ABI change. Now function names, whose signature includes __m64, are mangled differentely.

C++

Now #pragma visibility(default) wrappers are added around to ensure that the exception classes are not hidden.

DWARF

DWARF debugging format is now supported. However, STABS is still used as default debugging format. In subsequent releases, DWARF will be used as default debugging format.

Major bugs fixed in this release of GCC 4.0

  • radar 4053179: gcc-5001: Conditional vector operation is not supported by auto vectorizer.
  • radar 4299630: Xcode linking fails with warnings about relocation overflow
  • radar 4333194: Rotoshape crashes Intel Release builds crash at optimization levels above 1.
  • radar 4334498: var obj created for STL string is 'out of scope'.
  • radar 4343764: Link error after XCode 2.2 update (std::__ioinit, fixed by turning off "Separate PCH Symbols").
  • radar 4375453: -ftree-vectorize results in a misaligned stack (bad codegen).
  • radar 4382844: GCC halts and reports internal error.
  • radar 4458276: gcc bus error while precompiling.
  • radar 4193359: Wrong warning with gcc version 4.0
  • radar 4505813: Definition of MMX/SSE constants not working as expected
  • radar 4493694: GCC crash when precompiling the attached header on x86

How to build the compiler from source

The source code for the Apple GCC 4.0 compiler is now available for download using anonymous svn from svn://gcc.gnu.org/svn/gcc/branches/apple/200605-release

The file README.Apple, in the top level source directory, explains how to build the compiler.


GDB Debugger

This note covers known bugs or usage issues in Apple GDB Version 477, which is based on the FSF GDB sources as of August 15, 2005. It only covers issues which are specific to the Mac OS X parts of GDB.

For complete information about GDB, please refer to the GDB manual in:

/Developer/ADC Reference Library/documentation/DeveloperTools/gdb/gdb/gdb_toc.html

Changes since Xcode 2.2 Developer tools update (gdb-437)

  1. Support for DWARF debug file format

    GDB now supports the use of the DWARF debug file format. It can work with DWARF in one of two ways: The debug information is stored primarily in the .o object files with a little bit in the executable, and with all of the debug information collected into a dSYM file and no debug information in the executable.

    For normal change-compile-debug, change-compile-debug workflow, leaving the debug information in the .o files is the intended usage. A dSYM file should be created when you are distributing your binary to another person who will need to debug it, or archiving the debug information of a release binary so you can debug crash reports/bugs that are reported to you later.

    In the case of debug information in .o files, the .o files must remain in their original location for gdb to find them. They may be copied to another system, but the pathname must remain the same -- or soft symbolic links (cf ln(1)) must be put in place.

    In the case of a dSYM file, dsymutil(1), is run on the executable file before stripping to create the dSYM. After that has been done, the binary may be stripped and released - you will be able to use the dSYM file along with the stripped binary to debug it later. The dSYM file must be next to the binary you are debugging for GDB to find it. For instance if your application is /path/to/my/Fun.app, the dSYM file should be named /path/to/my/Fun.app.dSYM or GDB will not read in the dSYM file. There is currently no way to specify the location of a dSYM file to gdb -- again, soft links are one workaround if copying the file into place is not feasible.

Changes since August 2004 Devtools update (gdb-330.1)

  1. Lazy symbol and on-demand symbol loading under Xcode

    When gdb is used under Xcode, and the Load symbols lazily Debugging preference is checked, gdb will postpone symbol reading until the symbols are needed. This optimization will yield faster start-up times, particularly on larger applications.

    For developers with command line proclivities, some caution is needed when using Xcode and lazy symbol loading. When the application, dylib, bundle, or framework hasn't had a breakpoint set in it, or you haven't stopped execution while the PC was contained in that app/dylib/bundle/framework, gdb won't know anything about the symbols in that file so breakpoints in that file can't be set as you normally would. For instance, you run your application under Xcode, then pause it and open the Console window. In the Console window you type "break MyFile.c:85". If the symbols for the executable file containing MyFile.c haven't been loaded yet, gdb won't know where to set this breakpoint. In the case of a ZeroLink application where every source file is in its own bundle, this can happen often.

    Breakpoints set from the Xcode UI will be handled correctly because Xcode knows which executable file contains that source file and communicates this information to gdb. You can force the symbols to be read for a file by either disabling lazy symbol loading (Xcode's Debugging Preferences), or once the app is running, Pause execution, open the Debug > Tools > Shared Libraries, and raise the load level of the executable file you're working in to "ALL".

    From the debugger Console window in Xcode, if you are setting a breakpoint with the break command and want to inform gdb which executable file contains that breakpoint (so the symbols for that file are read in), you can use the -shlib argument to the break command. e.g. for the Sketch sample application, built in ZeroLink mode, you would do this to tell gdb that it should read in the symbols for the SKTGraphic ZeroLink bundle:

    break -shlib SKTGraphic.ob SKTGraphic.m:19

    Lazy symbol loading is only in effect when using gdb under Xcode. None of these caveats are required when using gdb from the command line.

  2. Cached symfiles are no longer enabled

    The cached symfile feature has been superseded by the lazy and on-demaned symbol loading.

  3. Support for 64-bit executables

    GDB now has support for debugging 64-bit executables.

  4. No longer necessary to set osabi when working with 64 bits

    In previous gdb releases, it was necessary to use set osabi Darwin64 to examine the full contents of registers in a 32-bit app on a processor with 64-bit registers. This is no longer necessary.

  5. gdb's .app app bundle support works for more bundle layouts

    gdb will now look at the CFBundleExecutable key in the application bundle's Info.plist and look for the executable under that name. So the shortcut gdb /My/Workdir/MyProg.app will work for more applications.

  6. gdb can step through a longjmp call

    If your application has a setjmp()/longjmp() call, stepping will work correctly through the longjmp.

  7. Performance improvements for single stepping with data formatters

    The stepping speed in Xcode when there are custom data formatters that require function calls has been improved. For instance, in an Objective-C application, if you have a number of NSString local variables in a function, gdb must call one function per object after stepping to see if the contents have changed.

  8. Calling Dead Code Stripping-elided functions in Fix and Continue won't work

    If you are developing with Dead Code Stripping, and you add a call to a function that has been stripped by DCS in the process of Fixing a source file at debug-time, that call will not work. You must do a re-link of your program, at which point the Dead Code Stripping feature will recognize the new call to the stripped function and keep the function in your executable.

WebObjects

The WebObjects Current Patch List (http://docs.info.apple.com/article.html?artnum=70037) contains information on all available patches and updates for all versions of WebObjects. Read this document if you're not sure which update you need on your system. Please see the knowledge base article at http://docs.info.apple.com/article.html?artnum=302797 for the most recent updates.

Troubleshooting

1. My application is throwing the exception "com.webobjects.foundation.NSForwardException for java.lang.NoClassDefFoundError: javax/servlet/ServletContext"

For some reason, the necessary packages are not in your classpath. Debug your classpath to make sure the javax.servlet.* classes are there. If the classes are not found, the resolution is to download the servlet.jar and put it into /Library/Java/Extensions or in your classpath. The servlet.jar can be found with many open source distributions (e.g tomcat).

2. How do I convert my legacy WebObjects application to build as a true war bundle?

  1. In Xcode, configure your build settings to the following:
    SERVLET_SINGLE_DIR_DEPLOY = NO
    SERVLET_STUB_WAR = NO
    SERVLET_TRUE_WAR = YES
    SERVLET_DEPLOY_LICENSE = {your deployment license}
    SERVLET_WEBAPPS_DIR = /Library/JBoss/3.2/deploy
  2. Add the JavaWOJSPServlet.framework to your project 3. You should also verify that all of your custom frameworks are being built as jar files and are installed or linked into /Library/WebObjects/lib.

3. Interface Builder and the WebObjects Assistant in Xcode is complaining about the 'Enterprise Objects' palette not being installed


The 'Enterprise Objects' palette is not loaded by default in the Xcode 2.4.1 release and has been moved from an auto-loaded location in /Developer/Palettes to /Developer/Extras/Palettes. This mainly effects people building Java Client nib based applications.
To load the palette from the new location:
  1. Launch Interface Builder
  2. Go to the menu item Tools --> Palettes --> Palette Preferences
  3. Delete the 'Missing' Enterprise Objects palette reference
  4. Add a new reference to the Palette in /Developer/Extras/Palettes

Interface Builder 2.5.4

Interface Builder 2.5.4 is an update that fixes some known problems in Interface Builder 2.5.3. General

  • Popup buttons now stay open while editing.

    To fix a previous bug, popup buttons closed after an item was edited. Now popup buttons remain open for editing until the mouse is clicked outside of the popup button.

Cocoa Specific

  • Fixed a crasher bug related to bindings.

    Previously, this behavior was triggered by editing a key path field and toggling the Bind checkbox. This is now fixed.

  • The inspector for NSManagedObjectContext is limited to valid outlets.

    The inspector for NSManagedObjectContext no longer shows the PersistentStoreCoordinator as an outlet.

Carbon Specific

  • Fixed a crasher bug related to editing Bevel Button menus.

    Previously, editing the menu of a bevel button and then tabbing to the next item caused a crash. Now bevel buttons with menus work the same way as other popup menus.

Nibtool

  • Added functionality for exporting and importing properties as a plist

    Nibtool can extract properties into a plist format that can be edited and then reimported into the nib using the new --export (-e) and --import (-i) flags.

Xcode 2.4.1 Expert Preferences Notes

Below is a partial list of expert preferences supported by Xcode not accessible through the user interface. To set any of these preferences, go to a Terminal window and type:

defaults write com.apple.Xcode defaultName defaultValue

General

  • PBXCustomTemplateMacroDefinitions

    A dictionary that provides extra macros for use in file and project templates. One, ORGANIZATIONNAME, which defaults to __CompanyName__, is used in several of the standard templates and can be set in this dictionary to provide a default expansion. You can define and use your own macro names as well.

  • PBXExtraPlugInFolders

    A string or an array of strings, specifying extra paths to look for Xcode plug-ins beyond the standard /Library/Application Support/Apple/Developer Tools/Plug-ins folders. This is mainly to aid plug-in debugging. There is no default setting.

  • PBXDontWarnIfProjectSaveFails

    Setting this to YES will suppress the display of a warning sheet when Xcode tries and fails to save the project file, which is useful for those living in an environment where projects are checked out from their source code repository as non-writable by default. By default this is set to NO.

  • XCAutoClearRunDebugStdIOLogs

    When this default is set to YES, logs shown in the Run, Debug, and Standard I/O windows will be cleared out after each session. By default this is set to NO.

  • XCOpenProjectFilesInsideFolders

    When this default is set to YES, open panels in Xcode allow selection of folders and "opening" a folder will attempt to open the first Xcode project found inside the folder. By default this is set to NO since it causes problems with keyboard navigation in open panels.

  • NSRecentDocumentsLimit

    The maximum number of items to show in the File→Recent Projects sub-menu. By default this is set to 10 items.

  • NSDragAndDropTextDelay

    The delay (in milliseconds) during which Xcode performs a drag-and-drop operation, rather than a selection. Setting this default to a non-positive value will disable drag-and-drop editing.

File Editing

  • PBXIndentOnPaste

    By default, Xcode will try to re-indent code that is pasted when “Syntax-aware indenting” is checked in the Indentation pane of Xcode’s Preference window. This can be disabled by setting this to NO.

  • PBXBeepOnNoMatchingBrace

    Setting this to YES will cause Xcode to beep when typing a closing brace that does not match an opening brace or when double-clicking a brace that cannot be matched. By default this is set to YES.

  • PBXEmacsPath

    The path to the emacs command line editor. It is set to /usr/bin/emacs by default. You should only need to set this if you want to use a custom built emacs editor.

  • PBXXEmacsPath

    The path to the xemacs editor. It is set to /usr/bin/xemacs by default.

  • PBXPipeShellPath

    The path to the shell to use for Worksheet (control-R) functionality in the Editor. It is set to /bin/sh by default.

  • PBXPreservePosixPermissionsOnSave

    Whether to try to preserve POSIX file permissions when saving a document. By default this is set to YES.

  • XCShowUndoPastSaveWarning

    Setting this to NO will cause Xcode to turn off the warning sheet that is shown when you try to do an undo past the last save of a file.

  • XCColorUnknownLanguages

    Setting this to YES will cause Xcode to do syntax coloring for files containing unknown languages. These rules treat lines beginning with # and text inside /* and */ as comments. Text inside double quotes is treated as a string. URLs inside comments are highlighted as links.

  • XCSelectToInsideMatchingQuotes

    Setting this to YES will cause Xcode to select text inside quotes (if the “Select to inside matching braces” preference is checked) when double clicking on single or double quotes. By default, this value is set to YES.

  • XCScrollToEndOfMatchingBrace

    If this setting is YES, double clicking a quote, brace, or parenthesis scrolls the window to the opposite end of the new selection. By default this is set to YES.

  • XCMatchIndentWithLineAbove

    Setting this to YES will cause Xcode to align new lines with the line above when “Syntax-aware indenting” is turned off in the Indentation pane of Xcode’s Preferences window (when hitting return). This setting also affects file types that don’t support syntax-aware indenting. By default this is set to YES.

  • XCSmartInsertDeleteEnabled

    Setting this to YES will cause Xcode to try to be smart about inserting and deleting spaces around words when inserting and deleting text in source files. By default this is set to NO.

  • XCShowNonBreakingSpace

    Setting this to YES will cause Xcode to show non-breaking space characters (Unicode 0xA0) as a middle dot (‘·’) in text files. By default this is set to YES.

  • XCShowControlCharacters

    Setting this to YES will cause Xcode to show control characters as an inverted question mark (‘¿’) in text files. By default this is set to YES.

  • Encodings

    This is a list of NSStringEncoding values used to populate the Encodings menu found in various places in Xcode. This list uses that same format as the list in TextEdit’s user defaults. It can be copied from com.apple.TextEdit.plist to com.apple.Xcode.plist in ~/Library/Preferences using a text editor.

  • PBXMethodPopupIncludeMarksDefault
    PBXMethodPopupIncludeClassDeclarationsDefault
    PBXMethodPopupIncludeClassDefinitionsDefault
    PBXMethodPopupIncludeMethodDeclarationsDefault
    PBXMethodPopupIncludeMethodDefinitionsDefault
    PBXMethodPopupIncludeFunctionDeclarationsDefault
    PBXMethodPopupIncludeFunctionDefinitionsDefault
    PBXMethodPopupIncludeTypesDefault
    PBXMethodPopupIncludeDefinesDefault
    PBXMethodPopupIncludeWarningsDefault

    These defaults control what is displayed in the text editor’s function popup. The Code Sense preferences pane of Xcode’s Preferences window contains a checkbox to “Show Declarations”. This preference controls only the inclusion of function and method definitions. To control other types, set one of the above defaults to YES or NO. All but PBXMethodPopupIncludeWarningsDefault have a default value of YES.

Building

  • BuildSystemCacheSizeInMegabytes

    The desired size of the shared precompiled-header file cache in megabytes. Xcode checks the total size of the cache every time it is launched, and at the end of the next build after a dependency analysis is performed, if it is more than the size specified by this default, Xcode tries to prune the cache back to the desired size by removing the oldest precompiled-header files first (though it will never remove a cache entry that is younger than the number of hours specified by the BuildSystemCacheMinimumRemovalAgeInHours default). A value of 0 indicates an unlimited cache size. By default the shared PCH file cache size is set to 1024 megabytes.

  • BuildSystemCacheMinimumRemovalAgeInHours

    The minimum age (in hours) for candidates for removal while the build system cache is pruned. The default value is 24, meaning that no cache file that has been used within the last twenty four hours will ever be removed. See the description of the BuildSystemCacheSizeInMegabytes default for more information.

  • PBXBuildFailureSound

    Path to a sound file to play when a build fails. There is no default setting.

  • PBXBuildSuccessSound

    Path to a sound file to play when a build succeeds. There is no default setting.

  • PBXJamPath

    The path to the jam build tool, which is used for targets upgraded from Project Builder. If you want to run a custom version of jam without replacing the one internal to Xcode, this can be used. This is mainly a debugging aid for the Xcode team. If this default is not set, the Xcode version of jam will be used.

  • PBXSaveJamfiles

    If set to YES, causes the dynamically generated jamfiles to be saved to disk during builds of Project Builder (aka “jambase”) targets. This is mainly a debugging aid for the Xcode team.

  • PBXNumberOfParallelBuildSubtasks

    The desired number of parallel tasks used by the build system when building a project. Unset (or set to 0), the build system will default to using the “best” number of parallel tasks, equal to the number of processors on the machine. There is no default setting.

  • PBXBuildDebugLevel

    When using targets imported from Project Builder that use jam to build, the build debug level can be used to vary the output in raw build logs. Level 0 shows only errors, level 1 shows abstract build actions and errors, level 2 shows abstract build actions, executed build commands, and errors. Higher levels are not typically useful in part because of the very large amount of text that is generated, though levels as high as 9 are defined and level 6 may be useful if display of all settings and time stamp comparisons are desired.

  • PredictiveCompilationDelay

    Indicate the idle time (in seconds) to wait before starting a predictive compile. This is only in effect if predictive compilation is enabled. By default this is set to 30 seconds and a minimum value of 10 seconds is enforced (setting this default to less than 10, results in 10 seconds being used).

  • UsePerConfigurationBuildLocations

    If set to YES, the built products and intermediates build files locations are segregated by configuration. If NO, the built products and intermediates build files locations are not segregated by configuration. Turning off this feature is not recommended. By default this is set to YES.

Distributed Builds

  • XCMaxNumberOfDistributedTasks

    The maximum number of concurrent distributed build tasks to allow when building. By default this is set to 25 concurrent distributed build tasks.

  • XCDistributedBuildsVerboseLogging

    If YES we run distcc in verbose mode. This is sometimes useful when looking at distributed build failures. By default this is set to NO.

  • DistributedBuildsLogLevel

    If set to 1 or 2 we enable additional logging for Xcode’s distributed builds manager. This is useful when looking at distributed build problems with the Distributed Builds pane of Xcode’s Preferences window. By default this is set to 0.

Debugging

  • PBXGDBDebuggerLogToFile

    Setting this to YES will cause Xcode to log the communication between Xcode and gdb in a file in /var/tmp/folders.uid/Temporary Items. (See the PBXGDBDebuggerLogFileName default for the file naming convention.) The log file can be included in bug reports sent to Apple for problems with the Xcode GDB debugger. (Note that sending data to the log file will reduce the stepping performance.) By default this is set to NO.

  • PBXGDBDebuggerLogFileName

    The full path to a file for the Xcode↔GDB communication logging. Specifying a value will cause the same file to be overwritten for new debugging sessions. When not specified, the file name defaults to the format XCGDB-name-pid where name is the name of the executable being debugged and pid is the process id of Xcode.

  • PBXGDBPath

    The full path to a gdb to use in place of the installed version. Defaults to /usr/bin/gdb (or /usr/bin/ssh if using remote debugging).

Code Sense

  • XCCodeSenseIndexBasePath

    The optional path to save the Code Sense index information at. When empty, Xcode will store the index information in a folder named <project name>.pbxindex inside the intermediates folder for each project. If the path specified for this default is not an absolute path, it is assumed to be a relative path off of the project directory. For example, if the value specified is Index and a project MyProject is opened from /tmp, the index information will be stored at /tmp/MyProject/Index/MyProject.pbxindex. There is no default setting.

  • XCCodeSenseAllowAutoCompletionInPlainFiles

    If set to NO, automatic code completion is disabled in files other than C, Objective-C, C++ and Java source files. Code completion in these files is limited to the set of words used in the files along with any language keywords and text macros defined for the file type.

Source Code Management

  • PBXCVSToolPath

    The path to the cvs command line tool. By default this is set to /usr/bin/ocvs.

  • PBXPerforceToolPath

    The path to the p4 command line tool. By default this is set to /usr/local/bin/p4

  • XCSubversionToolPath

    The path to the svn command line tool. By default this is set to /usr/local/bin/svn

  • XCSCMLogSize

    The maximum size allowed for the SCM log (in kilobytes). If this size is exceeded the oldest log content will be dropped to bring the log below the limit. By default this is set to 500 kilobytes.

Documentation

  • DVDefaultAPISearchResultsBatchSize

    Sets the number of matching records retrieved at a time for a Quick API search. Setting to a small number (less than 10,000) reduces the batch size (filling the results table in smaller increments and causing the counter in the user interface to update more rapidly), but also increases the processing overhead for retrieving large numbers of records. By default this is set to 10000.

  • XCDocWindowSharesGlobalFindString

    Sets whether the search field in the documentation window shares the global find string. If set to YES, changing the find string in the Project Find panel (or even in Find panels in applications like Mail or Safari) will also change the find string in the documentation window, and vice versa. If set to NO, the find string in the documentation window does not update to (nor is updated by) the find strings in other Find panels. By default this is set to YES.

Known Issues and Workarounds

Here are some commonly-reported issues that are known with this release of Xcode.

  • Spaces in project path items

    Any build setting that contains a path (or includes another build setting that resolves to a path) must be enclosed in double quotes if the path is likely to contain a space character. Xcode will handle the quoted value correctly, but will fail if an unquoted value resolves to a path that includes a space.

  • Accessing Subproject Build Products in a Copy Files build phase

    If you are using the default per-configuration build folders, a project may not be able to refer to the build products of a subproject in its Copy Files build phase. We recommend you use a shared build folder for projects that require access to each others’ build products.

  • Issues When Using SDKs

    When defining the “SDK Path” (SDKROOT) build setting for a project or target, consider explicitly defining the “Mac OS X Deployment Target” (MACOSX_DEPLOYMENT_TARGET) build setting to an appropriate value (usually, to the earliest release of Mac OS X on which the software should run). This can avoid certain compile-time or run-time errors by ensuring that the Xcode will generate code and use libraries appropriate for the release of Mac OS X you are targeting. If you use different SDKs per-architecture (e.g., SDK_ROOT_ppc), use the corresponding per-architecture deployment target setting (e.g., MACOSX_DEPLOYMENT_TARGET_ppc).

    For other build settings which do not have explicit per-architecture versions, you can define the explicitly-supported build setting in terms of another, per-architecture setting which you define manually. For example, to define the Other Linker Flags setting using a mix of architecture-independent and architecture-dependent settings, you can configure your build settings with the following definitions:

    OTHER_LDFLAGS = -flag1 -flag2 $(OTHER_LDFLAGS_$(CURRENT_ARCH))
    OTHER_LDFLAGS_ppc = -ppc_specific_flag
    OTHER_LDFLAGS_i386 = -intel_specific_flag
  • Problems referencing files and folders when a symlink is in the path

    Xcode tracks symlinks (like /usr/lib/libz.a). However, this has led to a regression with references to files and folders where a symlink exists anywhere but the last path component. Note that symlinks like /tmp/ (which points to /private/tmp/) are handled properly. Currently the biggest impact is to files and folders on statically mounted network volumes (dynamically mounted network volumes are not affected). The only workarounds at this point is to either only use absolute paths for references that are affected or to move such files to locally mounted or dynamically mounted network volumes.

  • Preprocessing Info.plist adds whitespace that causes XML parse failure

    Using the Preprocess Info.plist feature may produce an invalid XML file. Adding the -traditional flag to “Info.plist Other Preprocessor Flags” may help.

  • Limitations When Importing CodeWarrior 10 projects

    Xcode 2.4.1 doesn't recognize the new optional text based project format available in CodeWarrior Development Studio for Mac OS v10.

  • Shared Libraries window bugs

    Currently, you are unable to change the load level of libraries shown in the Shared Libraries window.

  • Setting breakpoints in #included files that aren't members of a target

    If Xcode is choosing the wrong location for your breakpoint, you can either edit the location column in the breakpoint window with the correct executable/dylib/framework/ZeroLink file or add the file to the target with a 'Copy Headers' build phase.

  • Setting breakpoints in dylib C++ Templates using DWARF

    There is a bug in gdb that will cause all the C++ template breakpoints in a dylib to be collapsed into the first one when the library slides. If you are trying to set breakpoints on a template #included in a dylib, you will need to ensure the library doesn't slide when it gets loaded. To do this, add a -seg1addr argument to the "Other Linker Flags" field in your shared library target.

  • Remote debugging to 10.3

    When remote debugging to a 10.3 machine you get the error mi_cmd_break_insert: Unknown option ``l'' because GDB on 10.3 doesn't understand the '-l' option being used by Xcode 2.3 and later. You can workaround this by doing the following in Terminal.
    On the 10.3 machine backup /usr/bin/gdb.

    # sudo cp /usr/bin/gdb /usr/bin/gdb.orig

    Edit /usr/bin/gdb with your favorite command line editor.
    # sudo pico /usr/bin/gdb

    Change the last line from

    exec "$gdb" "$@"

    to

    exec perl -e 'while($len = sysread(STDIN, $buf, 1024)){$buf =~ s /-break-insert -l -1/- break-insert/g; syswrite(STDOUT, $buf, $len);}' | "$gdb" "$@"

  • Remote debugging to 10.2

    When remote debugging to a 10.2 machine you need to make the changes mentioned above for 10.3 and disable 'Load symbols lazily' in the Debugging section of Xcode's Preferences.

  • Xcode 2.4.1 bug fixes may make projects incompatible with Xcode 2.1.

    The Xcode 2.4.1 file format and build system are backwards compatible with Xcode 2.1, but this does not extend to new features in Xcode 2.4.1 or Xcode features that have problems in Xcode 2.1. If you exploit a new feature or bug fix in Xcode 2.4.1 in your project, it may not work on Xcode 2.1. This includes (but is not limited to):
    o Using .xcconfig files in project-level build settings
    o Compiler features like symbol separation, Essential Symbols, and per-architecture build settings
    o Using macros in Run Script build phase input and output paths
    o Includes and comments in .xcconfig files
    o Projects and targets based on .xcconfig files that are missing at project load time
    o Use of User Header Search Paths, Rez Prefix Files, GCC_VERSION_IDENTIFIER, or other new build settings
    o Reliance on the updated 10.4u SDK included with earlier versions of Xcode 2.X

  • Accessing subproject build products in a copy files build phase.

    If you are using the default per-configuration build folders, a project may not be able to refer to the build products of a subproject in its Copy Files build phase. We recommend you use a shared build folder for projects that require access to each others’ build products.

  • Preprocessing Info.plist adds whitespace that causes XML parse failure.

    Using the Preprocess Info.plist feature may produce an invalid XML file. Add the -traditional flag to “Info.plist Other Preprocessor Flags” may help.

  • Project find, debugger, or other views are partially obscured.

    Changing screen geometry (due to adding/removing an external monitor or waking from sleep) may cause parts of the Xcode user interface to redraw wrong. Resizing the windows corrects this.

  • SDKs:

    When defining the “SDK Path” (SDKROOT) build setting for a project or target, consider explicitly defining the “Mac OS X Deployment Target” (MACOSX_DEPLOYMENT_TARGET) build setting to an appropriate value (usually, to the earliest release of Mac OS X on which the software should run). This can avoid certain compile-time or run-time errors by ensuring Xcode will generate code and use libraries appropriate for the release of Mac OS X you are targeting. If you use different SDKs per- architecture (e.g., SDK_ROOT_ppc), use the corresponding per-architecture deployment target setting (e.g., MACOSX_DEPLOYMENT_TARGET_ppc).

Installation Notes

The XcodeTools.mpkg package contains several separate sub-packages in the Packages folder that allow flexibility in installation and updating:

  • Developer Tools (DeveloperTools.pkg): This package contains Xcode, gdb, and the other tools necessary for Macintosh development.
  • GCC 4.0 (gcc4.0.pkg): This is the latest version of gcc. This compiler is necessary for 64-bit development.
  • GCC 3.3 (gcc3.3.pkg): This package contains the gcc 3.3 compiler.
  • Software Development Kits: These packages provide the header files and link libraries necessary for Macintosh development. All Macintosh development requires the Mac OS X SDK, that provides the API for basic Macintosh technology such as Carbon, Cocoa, and command-line tools. The other SDK packages provide API for extended Macintosh technologies, such as QuickTime or OpenGL, etc.
  • Java 1.4 Developer Tools: These packages are used when developing Java 1.4 applications for Macintosh.
  • Developer Documentation (DevDocumentation.pkg): This package contains the core Macintosh developer documentation for technologies such as Carbon, Cocoa, QuickTime, WebKit, etc.
  • Developer Example Software (DevExamples.pkg): The package contains example code for a wide variety of Macintosh technologies. Note that these examples may require any of the above Software Development Kits to be installed before they will compile.
  • WebObjects (WebObjects.mpkg): The packages necessary for WebObjects 5.3 development.
  • Cross Development Packages for Mac OS X v10.2 (Jaguar), Mac OS X v10.3 (Panther), and Mac OS X v10.4 (Tiger) to allow cross development. (MacOSX10.2.8.pkg, MacOSX10.3.9.pkg, and MacOSX10.4u.pkg). These can be installed together or independently, and can be installed separately from the installation of the rest of Xcode. You must install the MacOSX10.4u.pkg to build univeral binaries. (CrossDevelopment.mpkg)
  • CHUD (CHUD.pkg): The Computer Hardware Understanding Developer Tools.

Downloading and installation:

  • Download the disk image from the ADC Member Site
  • Double click on the disk image to mount
  • Double click on the XcodeTools.mkpg file to install. This will require an administrator password.
  • Follow the instructions in the installer. If you need to install CHUD, WebObjects packages, additional SDKs, or the Java 1.4 Reference Documentation, you must select "Custom Install", and check those packages.
  • Authenticate as the administrative user. The first user you create when setting up Mac OS X has administrator privileges by default.
  • NOTE: Xcode Tools MUST be installed on the same hard drive partition from which you booted Mac OS X. The Installer prevents installation on any other partition.
  • If you encounter any problems in installation, including not having enough disk space to do the installation, please refer to the "Troubleshooting" section below.
  • Once you have installed the Xcode Tools package, you can access the documentation by launching Xcode and choosing any of the items in the Help menu, or by launching Help Viewer and clicking on the Developer Center link at the bottom of the Help Center welcome page. Developer applications, such as Xcode and Interface Builder, are installed in /Developer/Applications.
  • It is highly recommended that you copy any of the examples in /Developer/Examples to another directory before opening them and modifying them. If a particular example is modified such that it no longer works, you must remove the example, and reinstall the entire examples package by double-clicking on Packages/DevExamples.pkg on the Xcode Tools installation disk.

Troubleshooting

If you have a small amount of disk space on your boot volume, you can set up a symbolic link for any part of the /Developer hierarchy. The installer will respect the symbolic link and install the files correctly. For more information on symbolic links, see "man ln".

In some configurations upgraded from Jaguar to Tiger, the Project Builder IDE and Xcode IDE will both be available in the /Developer/Applications folder. The Project Builder IDE is not supported for use on Tiger.

Uninstalling Xcode Tools

  • To uninstall from the CD or disk image that contains Xcode Tools, type in a Terminal window:
    $ sudo perl /Volumes/Xcode\ Tools/Utilities/uninstall-devtools.pl
  • To uninstall Xcode Tools on your system, type in a Terminal window:
    $ sudo perl /Developer/Tools/uninstall-devtools.pl
  • NOTE: Running the uninstall script from Xcode will uninstall any previous installations of Mac OS X Developer Tools or Xcode releases.
  • NOTE: After running the uninstall script, you should restart your system before installing Xcode again.

Additional Resources

Web Sites

Developer Mailing Lists

There are a number of mailing lists that are great for Mac OS X and Xcode developers. For more information please go to http://lists.apple.com. There are lists on the following topics and many more:

  • xcode-users: This list is great for asking (and answering) questions about Xcode.
  • java-dev: A place for Mac Java developers to hang out.
  • cocoa-dev: Keep in touch with the Cocoa community.
  • carbon-dev: Keep in touch with the Carbon community.
  • fortran-dev: For Fortran development issues.
  • unix-porting: For developers porting standard Unix software packages.
  • webobjects-dev: For WebObjects development issues.

Reporting Bugs and Issues

All members of the Apple Developer Connection can use the online bug reporting tool at http://developer.apple.com/bugreporter to communicate issues with Apple. Please include detailed information of the issue, including the system and developer tools version information, and any relevant crash logs or console messages.