Database Reference
In-Depth Information
A quick note about version compatibility of Xcode is worth mentioning here. At one
point, Apple had Xcode 3.2, Xcode 4.0 and a beta of Xcode 4.1 all available for down-
load at the same time from the developer site. It is easy to imagine that you could end
up with situations where developers were using one version of Xcode, while the build
machine was running a different version.
By and large, this is not an issue. While you never want to have your build machine
running a beta version of Xcode (you can't upload apps built with it to the App Store,
for one thing), I've generally found that Xcode has been fairly forgiving of mix and
match Xcode versions dealing with the same project files. The big (and nasty) exception
is that if you use features that are only available in the beta, and then try to open the
project in an older version, anything could happen. But, for example, at the moment I
am developing at home using the latest Xcode beta, checking in my files and having
them work without a hitch in Xcode 4.1 on our build machine. The one big gotcha is
that you may want to start building using the GM version a week or so before the new
version of iOS is released, so you can have a version in the store at launch time. If you
bought your copy of XCode via the Mac App store, rather than downloading it from
the developer portal, you won't be able to update it until the new version of XCode is
formally released.
The other (and unpleasant) things you'll need to keep in sync between development
and build machines are the provisioning profiles and certificates. There are a number
of reasons that these can go out of sync. For one, every time you add someone to your
Ad Hoc profile (which will be discussed in more detail in
Chapter 7
), you end up with
a new profile, which you need to reference in your project file. If your build machine
doesn't have a copy of this profile (or the backing certificate) in the keychain, the build
will fail. We'll discuss this later in this chapter in more detail. If you're doing both an
Enterprise and Ad Hoc/App Store build, things can get very, very complicated, because
of keychain conflicts. This is also discussed in
Chapter 7
.
Installing Hudson
Once you have Xcode installed and running (a good test is to check out your project
as a logged in user on the build machine, and make sure that you can build and run the
app), it's time to install the build automation tool (in this case, Hudson).
Although I haven't said it explicitly, the requirement that you must build iOS apps on
Mac hardware means that your build automation tool must be able to deal with Mac
OS X. In the case of Hudson, this isn't an issue, since it's a pure Java tool. Other
proprietary tools may work with Macs, or may have client plug-ins that let your re-
motely run a build on a Mac. If your tool can't communicate with a Mac in any way,
you're kinda out of luck, and may have to sell your build automation group on letting
you use a tool such as Hudson instead.
