Home > Bash scripting, Mac administration, Mac OS X, Packaging, Xcode > Building a Grand Unified Xcode 4.4 installer for both Lion and Mountain Lion

Building a Grand Unified Xcode 4.4 installer for both Lion and Mountain Lion

Apple has released Xcode 4.4 through the Mac App Store for all Macs running 10.7.4 and higher, including Mountain Lion. This application, on first launch, then installs the other Xcode tools. The command line tools can be installed separately through the Xcode preferences, in the Downloads section.

Screen Shot 2012-07-26 at 11.41.12 AM

For my users who are developers, I wanted to include Xcode 4.4 in their new machine builds and also install the command line tools automatically. I also wanted to build one Xcode 4.4 installer that worked for both 10.7.x and 10.8.x. The Xcode 4.4 application itself runs fine on both Lion and Mountain Lion, but the command line tools are OS-specific.

To do this, I used a modified form of the methodology referenced in this post to repackage Xcode 4.4 for distribution without needing an Apple ID. See below the jump for the procedure.

Building the package

Install Xcode 4.4 from the Mac App Store onto your build machine.

Update – 7-31-2012: I’ve seen Apple ID-related issues with updating the Mac App Store’s Xcode since posting this, where I was signed into the App Store using a different Apple ID than the one used to install Xcode. To avoid this problem, download and use Xcode 4.4 from the Apple Developer site.

Download the latest Lion and Mountain Lion Command Line Tools for Xcode disk images from the Apple Developer site

Verify that the permissions on the Xcode application in /Applications are correct by running the following command:

sudo chown -R root:wheel /Applications/Xcode.app

Screen Shot 2012-07-26 at 11.26.22 AM

Set up a new Iceberg project. Since we’ll need to run this installer with root privileges, I recommend setting the project type to Darwin: Package. That will open the project with the installation privileges automatically set to root.

Screen Shot 2012-07-26 at 10.52.05 AM

In this case, I’m naming the project Xcode 4.4.

Screen Shot 2012-07-26 at 10.52.23 AM

In the Files section, click on the Applications folder in the listing.

Screen Shot 2012-07-26 at 11.48.36 AM
Go to the Archive menu and select Add Files…


Select the Xcode application in /Applications

Screen Shot 2012-07-26 at 11.50.10 AM

Verify that it’s now showing up under Applications in your Iceberg project

Screen Shot 2012-07-26 at 10.53.25 AM

Select the Lion and Mountain Lion Command Line Tools for Xcode disk images and drag them into the Additional Resources section of your Iceberg project.

Screen Shot 2012-07-26 at 11.24.09 AM

The last pieces are removing any previous Xcode.app from /Applications and telling the correct Command Line Tools for Xcode installer to run.

To remove any previous Xcode.app from /Applications, I’m using the following preflight script:


# Remove existing /Applications/Xcode.app from machine

if [ -d /Applications/Xcode.app ]; then
  rm -rf /Applications/Xcode.app

To install the command line tools, I’m using the following postflight script:


# Determine OS version
osvers=$(sw_vers -productVersion | awk -F. '{print $2}')

if [[ ${osvers} -eq 7 ]]; then

# Installing the Xcode 4.4 10.7 Command Line Tools

# Create /tmp/Command Line Tools (Lion) mountpoint in /tmp

  /bin/mkdir "/tmp/Command Line Tools (Lion)"

# Mount the latest command line tools disk image as /tmp/Command Line Tools (Lion)

  /usr/bin/hdiutil attach "$1/Contents/Resources/xcode44cltools_10_76938107a.dmg" -mountpoint "/tmp/Command Line Tools (Lion)" -nobrowse -noverify -noautoopen

# Install the Xcode command line tools

  /usr/sbin/installer -dumplog -verbose -pkg "/tmp/Command Line Tools (Lion)/Command Line Tools (Lion).mpkg" -target /

# Clean-up

# Unmount the command line tools disk image from /tmp/Command Line Tools (Lion)

  /usr/bin/hdiutil eject "/tmp/Command Line Tools (Lion)"

# Remove /tmp/Command Line Tools (Lion) from /tmp

  /bin/rm -rf "/tmp/Command Line Tools (Lion)"


if [[ ${osvers} -eq 8 ]]; then

# Installing the Xcode 4.4 10.8 Command Line Tools

# Create /tmp/Command Line Tools (Mountain Lion) mountpoint in /tmp

  /bin/mkdir "/tmp/Command Line Tools (Mountain Lion)"

# Mount the latest command line tools disk image as /tmp/Command Line Tools (Mountain Lion)

  /usr/bin/hdiutil attach "$1/Contents/Resources/xcode44cltools_10_86938106a.dmg" -mountpoint "/tmp/Command Line Tools (Mountain Lion)" -nobrowse -noverify -noautoopen

# Install the Xcode command line tools

  /usr/sbin/installer -dumplog -verbose -pkg "/tmp/Command Line Tools (Mountain Lion)/Command Line Tools (Mountain Lion).mpkg" -target /

# Clean-up

# Unmount the command line tools disk image from /tmp/Command Line Tools (Mountain Lion)

  /usr/bin/hdiutil eject "/tmp/Command Line Tools (Mountain Lion)"

# Remove /tmp/Command Line Tools (Mountain Lion) from /tmp

  /bin/rm -rf "/tmp/Command Line Tools (Mountain Lion)"


Once you’ve got the preflight and postflight script built, run the following commands to make the scripts executable:

sudo chmod a+x /path/to/preflight

sudo chmod a+x /path/to/postflight

Last step, go ahead and build the package. (If you don’t know to build, check the Help menu for the Iceberg User Guide. The information you need is in Chapter 3 – Creating a package.)


Once the package has been built, test it by taking it to a test machine running 10.7.4 or higher that doesn’t have Xcode 4.4 and install it. The end result should be that Xcode 4.4 installs along with the correct command line tools for the host without requiring an Apple ID.

  1. nbalonso
    July 27, 2012 at 7:47 pm

    Aren’t you going to face problems by re-packing the App Store version? specially now that 10.8 will open the App Store automatically when an update is available

    I usually use the version from developer.apple.com

    • July 27, 2012 at 8:09 pm

      I haven’t seen issues so far with the Mac App Store version. That said, getting it from the developer site also works.

    • July 31, 2012 at 11:50 pm

      I’ve now seen issues, so I’m updating the post to recommend using Xcode from the Apple developer site.

  2. Michael Crispin
    August 5, 2012 at 11:25 pm

    It is not clear to me whether an Xcode user must have admin rights or not in order for Xcode to be useful. Nevertheless, in using this process, and after deployment, the end user is asked to install Device tools which requires admin rights. Is this expected behavior in 4.4; should I also include the Device tools, or should Xcode only be deployed to admin users?

    • August 6, 2012 at 12:29 am

      You can update the postflight script to include installing the Mobile Device tools if desired. The path to the package is “/Applications/Xcode.app/Contents/Resources/Packages/MobileDevice.pkg” (no quotes).

      For non-admin users, they should be able to work with Xcode once they’ve been added to the “_developer” group. They can be added individually with the following command:

      sudo dscl . append /Groups/_developer GroupMembership “username”

      If you want to add a group (like “staff” or “everyone”) to the “_developer” group, you can run the following command:

      sudo dseditgroup -o edit -a “group name” -t group _developer

  3. Not this either...
    August 16, 2012 at 2:04 am

    You will still need to turn on developer security mode; (DevToolsSecurity -enable) or you will continue to be prompted for admin access.

    • April 19, 2013 at 8:53 pm

      From the DevToolsSecurity manpage:

      “When the Xcode developer tools are installed, the post-install script automatically runs this DevToolsSecurity tool to change the authorization policies, such that a user who is a member of either the admin group or the _developer group does not need to enter an additional password to use the Apple-code-signed debugger or performance analysis tools.”

      Sounds like the postinstall, paired with Rich’s tip above, should cover it, right

  4. David
    October 18, 2012 at 1:06 pm

    Great Blog!

    1) I found that when you first start xcode you are prompted to install a Device package

    To get around that I added these two lines at the end of your postflight script:

    /usr/sbin/installer -dumplog -verbose -pkg “/Applications/Xcode.app/Contents/Resources/Packages/MobileDeviceDevelopment.pkg” -tgt /

    /usr/sbin/installer -dumplog -verbose -pkg “/Applications/Xcode.app/Contents/Resources/Packages/MobileDevice.pkg” -tgt /

    although probably only the 2nd line is needed.

    2) I see that when installed and you look in Xcode > Preferences > Downloads tab

    there are several simulators that can be installed. Any idea if it’s possible to install them from the command line and where the packages are located for them?

  5. David
    October 22, 2012 at 7:44 am

    Ok – seems like the simulators live in the following location:


    Seems that all that is necessary is for you to copy the iPhoneSimulatorxx.sdk folder from one installation to another. I guess that could be either downloaded already and in that case it would be part of the Xcode.app. Otherwise they could be used in another installer for people who needed it later.

    • February 18, 2013 at 7:18 pm

      David, that’s correct – although Apple has occasionally provided patches for the Simulators after they’ve been released, and checks for these when Xcode launches.

      The Simulators are also available as standard packages to install, although they require some modifications to install to the correct location, and they don’t actually use receipt version numbers to check whether they’re installed. Some more info is here in a blog post:


  6. Pete
    January 9, 2013 at 11:09 pm

    Why are we not able to install the command line tools from the mpkg file? That would be easier than mounting/unmounting the dmg, but I can’t get it to work. When I drag the mpkg out of the dmg, the file size is way too small.

    Also, are both MobileDevice.pkg and MobileDeviceDevelopment.pkg required to eliminate the prompt to install them when you run Xcode for the first time?

    I love this site and have found lots of useful information so far.

    • January 10, 2013 at 5:41 pm


      There’s two ways you can set up a metapackage. The first is with all of the installer packages stored inside the metapackage, so that everything you need is copied over when you copy the metapackage to a new location.

      The second way is to have the installer packages stored outside the metapackage, and that’s the situation here. The metapackage is actually referencing installer packages stored in an invisible directory on the disk image named Packages. By mounting the disk image and running the metapackage from the disk image, the install can run because the metapackage can access the installers in that hidden directory.

      • applicatorz
        August 2, 2013 at 1:25 am

        But how can one convert a metapackage of the second kind (with pkgs located outside the mpkg) into a metapackage of the first kind (with all the pkgs stored inside the mpkg)?

        I’ve tried running pkgutil –expand on the mpkg, editing the Distribution file (specifically the file URL in the pkg-ref), and rebuilding the mpkg with pkgutil –flatten. I can never get the resulting mpkg to show a file listing of all the incorporated pkgs.


  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 143 other followers

%d bloggers like this: