Transcript
>> Chris Espinosa: Good afternoon
everybody, I'm Chris Espinosa.
I'm the Manager of the Xcode Core Tools team and welcome to
Flight 314, Building and Distributing Your App with Xcode 4.
Please place your luggage under the seat in front of you
and during this short 1-hour flight,
we are going to talk about 3 things.
First, I want to let you know that in Xcode 4, you
can load and build and run the same projects you have
in Xcode 3 and then take them back to Xcode 3.
So even with this developer preview that
you have today, you can try Xcode 4 now.
It installs right next to Xcode 3.
You can open up your Xcode 3 projects and
you can take them back to Xcode 3 safely.
So we haven't changed the project file
format, we haven't changed the build system,
so you can try the new workflow
out and new systems out safely.
[ Applause ]
The first thing we've tried to do with Xcode
is to make the simple things more obvious,
things like setting build settings or setting the deployment
target of your application we're trying to put right
up front so that things that you do commonly
and you need to do regularly are right up there.
But we know projects get complex, so we've tried to
make sure that complex things are now manageable,
and you'll see through this presentation today how
we've taken the complexity that is grown in Xcode
and the complexity that grows in your projects and
given you some great tools to manage that complexity.
The 2 most important ones that we're going to be going
through today, you saw little of these in the State
of the Union on Monday, you saw some of them in the
introduction to Xcode 4 session yesterday, are schemes.
Schemes help you simplify and cut through the matrix
of your targets times your configurations
times your executables times your architectures
and just designated this is what I do, this is what
I want to do all the time and have a one-click access
to a small number of things that you
do regularly, very powerful construct.
Second thing is workspaces: workspaces let you organize
work in multiple projects and associate projects together
on an ad hoc basis or on a team basis
without having to change the project itself
so you can have an archive project, you can throw
it into a workspace, do all sorts of things,
do it in the workspace and then
it doesn't change the project.
That lets you experiment safely.
It lets you share work among people and it lets you
combine projects together in ways you couldn't do before.
So what you are going to learn today is how to use the Xcode
4 user interface to construct and edit projects and targets.
There are some new things we got for
project management and target management
in Xcode 4 we're going to take you through.
We're going to learn how to construct schemes,
to build, launch, and archive your applications,
and how to build workspaces that relate
multiple projects together and share schemes
that you create in them with other people on your team.
So, let's get started.
Before I go into what's new in Xcode 4, I have to give you
some common grounding on what I'm talking about in Xcode 3,
some of the core words and concepts, mainly projects.
A project is simply a bag.
It's a bag of references to source files and header
files, some groups that are artificial constructs
that organize the files in the user interface for you.
And then these things called targets, you
never build a project, you build a target, OK?
The target is the thing that contains the instruction
for turning your sources into your application,
and they are the heart of Xcode, and we're going to
give you more and better access to targets in Xcode 4.
In a target, there are references to the source files
in the project and the target contains build phases,
and the build phases say first compile my
code, second link it, third copy my nib files,
fourth package it all together and then copy it on to disks.
Targets are the same in Xcode 4 as they are in Xcode 3.
They may seem to you to be buried a level deeper,
but that's because some more powerful
constructs are being layered on top of them.
Now, one of the things that goes across
targets are things called build settings.
Build settings control how each build phase operates,
how code files are compiled, how resources are copied,
and build settings are combined into
these chunks called configurations.
You have one configuration of build settings to debug
and you have a different clump of build settings,
a different configuration, for releasing your code.
And managing all of these, juggling all
the acts, it is really difficult sometimes
because you have your debug configuration, your
release configuration, your application target,
your framework target, your build all aggregate target.
You have architectures for the Mac, you have
architectures for the iPhone and the iPad and iOS.
It gets really complicated, there are 2 big changes
in the Xcode 4 user interface that let you manage
that complexity, and we're going to show them to you.
First is that what used to be the groups and
files tree has been split into several navigators
and the main navigator is the project navigator, and
that's the one where you get at dragging and dropping
and moving all of your files among groups.
The second one is that instead of having all
these smart groups in that group in file tree,
we've given project management and target management its
own full-sized editor, a tabbed editor that shows you all
of the expanse of all of your options in your project in
the target in the full real estate of the editor instead
of trying to cram it into a tiny little inspector.
Or rather than talking about that, I think
the best way to do it is show it to you,
so here is Rick Ballard to take you through the first demo.
[ Applause ]
>> Rick Ballard: Hi, I'm Rick Ballard.
I'm an engineer on the Xcode team.
Today, I'm going to demonstrate how easy it is to take your
existing projects that you have been working with in Xcode 3
and dive right into working with them in Xcode 4.
Today, I'm going to start with the popular open source
project called Colloquy, which is an IRC client for the Mac.
And this is the same project that they
used to maintain their projects in Xcode 3.
I'm going to go ahead and just open it right up in Xcode 4,
it will load and you can see the Colloquy project is
represented in the upper left-hand corner with its groups
and files underneath, just like in Xcode 3.
Now you notice that this project
has some cross-project references.
I can zoom in on this.
In Xcode 3, cross-project references
would let you set up target dependencies
between the targets across multiple projects.
But to do anything beyond that, you would have to
open up each project separately in its own window,
work with it pretty separately, and you couldn't search
across them or really do much with them at the same time.
In Xcode 4, that's all changed.
In Xcode 4, a cross-project reference gives you full
access to the contents of every project you can reach
and you can edit, build, and work with all of the
contents of all your projects together just as easily
as you can with the project that you will open.
That includes searching across all your projects.
It includes filtering across all
of your projects, very easy.
Now in Xcode 3, if you want to work with the
settings of your project or one of your targets,
you'd open up an inspector on that
project and work with its settings there.
But in Xcode 4, we've got all the space.
It's really easy, you just select your project and you get
a full-sized editor for that project in all the targets
that it contains, just like any other kind of editor.
[ Applause ]
This is the Project Info tab, and this is where you'll find
some of the most common central settings for your project.
You'll notice that we've added a slider here
for the deployment target of your product
that lets you easily set the minimum operating
system version that your products will run on.
We've also got a configuration section here.
Now, if you've ever worked with Xcode configuration
settings files, you know that they can be incredibly useful
for organizing and unifying build settings across
multiple targets, configurations, projects, et cetera.
But sometimes, managing which target or project
has which configuration settings file set
and which configuration can be a bit cumbersome and
you can make a mistake and leave one off somewhere.
So, we decided we should make this a lot easier
in Xcode 4 and we give you central access
to the configuration settings files of all the
targets in your project for this project right
in one place across all your configurations.
The Project Info tab is also where you'll
find localizations now so you can easily see
which localizations your project is set up to support,
how many localized files you have for each localization,
and you can easily add and remove new
localizations that you want to support.
So we think that you'll find that centralizing everything
in a project editor gives us a lot
more space and a lot more room to work.
What about build settings?
Well, let's take a look.
If you've worked with build settings
much in Xcode 3 in the inspector,
I think you'll find that our new build
settings editor gives you a lot more power
and makes it a lot easier to work with your settings.
Having all this space makes a big difference.
So you normally start out in basic mode up here.
You can see that there's a basic in all toggles.
Basic shows you just the most commonly needed
frequently accessed settings for your project.
You can easily navigate by category
just like you could in Xcode 3,
and you can switch to see all build
settings if you need to, or you can filter.
And if you want to know more about a setting,
you can select it, bring up Quick Help.
Or if you want to work with a bunch of settings
quickly, you need to find out what everything is.
You can open up the Inspectors and there's a
Quick Help inspector that will also tell you
about the setting that you're looking at.
So in this case, we're looking at the
compiler version, and it tells us what it is
and what the underlying build setting reference,
which shows up as an environment variable
in your Run Script phases, is to refer to the setting.
Now you notice that just like in Xcode
3, we have build setting conditions.
Here you can set a different value for
this build setting for each architecture
that this project supports, if you so choose.
But you may also notice that in Xcode 3, we have
this configuration pop-up for searching back
and forth between release and debug,
and that's nowhere to be seen here.
Well, sometimes it was a pain when you had to switch
back and forth to compare your build setting values
and we decided, hey, configuration is just another
type of conditional, so let's make it a conditional.
If I click the Plus button, I can see the
values for both my configurations side
by side at the same time without any switching.
[ Applause ]
And you notice if I change the value for one of these
conditionals, it will go ahead and show me the value
that will be used for each combination
of conditions in my project.
So it makes it really easy to just glance over and
see what's going to be used under what circumstances.
Now we've got a lot of space here, in
fact I can make it give me even more space
by turning off the inspector navigator.
What else could we do with that kind of space?
Well, one thing that people like to do a lot is
compare the settings across through different targets,
try and keep things in sync, make sure they
have the right things in the right places.
So, you'll notice that if I just select multiple
targets here, I actually get a column for each target
and I can easily compare setting
values right across all my targets.
[ Applause ]
I can make this even easier if I want.
You probably are used to switching back and
forth between your project level settings
and your target level settings and
making sure you know what set where.
We've got this new levels mode, you
can toggle between combined and levels
and we've been looking at combined so far.
But if I switched to levels, it will show me the build
setting values for all levels in my project side by side.
So in the right, I have the default settings that
are inherited, then the project level settings,
and then the settings for both of
the targets that I have selected.
You'll notice that there are these little
green boxes or instance setting values.
The green box tells you at what level the actual
value that's going to be used for that setting came
from so you can easily glance over and see
where your setting values are currently set,
where they should be updated, et cetera.
We think you'll find this much,
much easier and a real big help
when you're managing complex projects
and lots of those settings.
The project editor is also where you'll
find your build rules and your build phases.
So build phases are the ordered set of steps
that will be executed when you build the target.
In Xcode 4, we moved your target dependencies
into the build phases, so these are the targets
that will be built first whenever you build this target,
and then there are other phases like compiling the sources
of this target, linking with the libraries
that it links against, and in this case,
a bunch of Copy Resources phases and Run Script phases.
In Xcode 4, we've added the ability to
filter across all your build phases.
This can be really, really helpful.
If you search for something, it will show you
everywhere in a build phase that it finds a match.
You'll notice too that whenever I go to add something
like say I go to add a new library, I get a really handy--
give it one moment-- really handy sheet showing me all
of my available frameworks and libraries in this case,
and I can filter and easily find what I'm looking for
and add it with a quick little button, very, very easy.
Perhaps the most useful demonstration of why it's nice to
have all these extra space now comes with Run Script phases.
In Xcode 3, you had to edit your
scripts in a little inspector,
but in Xcode 4 we give you a full-size
source editor with syntax coloring
and line numbers for editing your Run Script phases.
[ Applause ]
So we think you'll find this is all a big help when
you're configuring your projects and we hope you like it.
Back to you, Chris.
[ Applause ]
>> Chris Espinosa: Thank you, Rick.
We've taken great pains to try to improve some of the
things that were suboptimal about working with Xcode 3
with multiple projects, with multiple targets, with multiple
build configurations, and the matrix that those provide
without really changing the underlying conceptual
model, and we've got pretty far with that.
But there is something else we need to
do, because working with a single project
or dependent projects was just far too cumbersome.
You had to go too many places and what people want is to
make an overall program that declares what they want to do
with all these projects rather than going in fiddling
with all the projects themselves,
and that's why we created schemes.
The fundamental problem is that when you start a project,
it seems so easy because you have one
target that builds your application.
And then over time, you might add
a library that that project uses.
And then maybe you have a helper application or some
other targets in your project, but it's still manageable.
And of course, you usually just build the debug
configuration, and then of course you have
to build a release configuration that's optimized and
has some special post processing in order to deploy it,
and you're getting to get this proliferation and
this is why you have so many different windows
to go through in so many different modes.
Then of course, Apple invents another architecture
to port to and then another architecture to port to
and another architecture to port to, and all of a
sudden we've got this unmanageable matrix of all
of these combinations and then we go and give
you a completely different platform that you have
to port the whole mess to, and this is beyond control.
This was actually my feature slide
last year, now it's my bug slide.
[ Laughter ]
The feature we introduced last year was this thing called
the overview pop-up that let you pick your overriding SDK,
your architecture, your target, your executable,
and your configuration all in the same pop-up.
We thought that was a great idea.
But what happened was that when you get so
many of these things, it just goes off the end.
And frankly, the times when you're going to use
any particular configuration, it approaches zero.
There are 2 or 3 of those combinations
that you're going to use all the time
and the rest are either completely
nonfunctional or dangerous to use.
So we wanted to give you the control to just pick
the things you need to do and put them in that menu.
What happens with schemes is that you pick a combination
of targets and configurations and places you're going
to run things, and you designate them
as scheme to put in the Schemes menu.
So for example, if my build and debug cycle means I need
to build all of my targets for the i386 architecture
in the debug configuration, I'll make one scheme for that.
And then when I need to ship it, if I just need to
build my application target in my release configuration
for all architectures, I'll make a second scheme for that.
And then there are some variations on where I'm
actually going to run it, but that's all I need.
I don't need a separate entry in the matrix for every access
and I don't need a separate entry for every combination.
And even better, your first scheme
is free, we make it for you.
When you open up an Xcode 3 project in Xcode 4,
Xcode 4 scans your project and looks for targets
that have executables associated with them or
are not dependent, dependencies of other targets
and they're therefore are top-level
entities that need to be built themselves.
And we looked at all the combinations and
create schemes in the scheme menu for you.
So we take each combination of a target and
executable or a top-level standalone target,
and we put them into the Scheme menu
when you open the project in Xcode 4.
Then, we look at the base SDK, the deployment
target, and the executables associated with it,
and we create things called destinations.
Destinations are the places that you build your product
for and the places where you're going to launch to.
So for Mac OS X applications for example,
if you have i386 and x86 64 architectures,
then we'll create separate destinations for
all of your schemes for each one of those,
and then you can just switch back and forth between
Intel, Intel 64-bit and it will build and launch
for that combination when you pick
that scheme from the Scheme menu.
Similarly, if you're building iOS applications, we look
not only at the SDK and the architecture but we also look
at whether you're building for the simulator
or for which particular device that happens
to be plugged in that you're building for.
So, in your Scheme menu, when you have devices configured,
you may see some destinations for your scheme that are
for the simulator, and you may see some destinations
that are for a particular device that happens
to be configured, provisioned, and connected.
So the Scheme menu gives you all of the choices that all
those 5 axis of base-- the override SDK, the architecture,
the target, the configuration and the executable down to
which device you're going to launch
on, all in one short menu.
Now, as Anders went through yesterday there are
three parts of every scheme: build, test, and launch.
These are the three steps the scheme goes
through when you pick it from the Run menu
or the Build menu or the Test menu or the Archive menu.
For the Archive menu, there's a special
scheme called the Distribution Scheme,
which instead of running your application,
copies it of somewhere so that you can upload it,
store, or save it off for future reference.
Now, in each part of the scheme, each part
of the scheme does something different.
The build part does what happens when you build a
target in Xcode 3, it just goes through and performs all
of the build phases of the targets
associated with that scheme.
There's a new test action, which
will perform tests on your target.
It's not fully fleshed out right now, but the intent
is that you can have build, built-in test or build,
test and run, or test and run as separate action.
So, if you want to just build all the time during
your build cycle and periodically decide the tests,
you can do that by preconfiguring it in your scheme and
then just picking what you want to do from the menu.
And then finally, the launch action
determines how you launch the executable,
whether you launch it under the debugger, whether
you want break points turned on or off, et cetera.
For distribution scheme, it's basically the same thing.
Except instead of launching, what you get to do is to
determine which build products to copy, how to copy them,
and where to copy them to, to save
them off for future reference.
Now, if you want to create your own scheme,
you get a lot of control over what goes in it.
You get to look at all of those axes and pick individually.
So for example, if I got these configurations
by those targets and I'm building a new scheme,
first thing I need to do is figure out what I want to build.
So I pick my configuration, and then I pick which
targets I want to build and it'll build those targets
and they'll build all the dependencies that
need to be built first before it builds those.
And then I can designate for each of these whether I
want to make it build when I click Build or make it build
when I click Build and Run, so I get my choice.
Similarly for test actions, I designate which
configuration I want to build for my test--
my test product, which targets I want to build for my test
product which usually involve like my unit test bundle
for example, and then whether I want to build it all
the time or just build it for building and testing.
Launch actions take the place of the
Executables inspector in Xcode 3.
They let you set what your executable is, whether it's
a build product or some other application on your disk,
which debugger you use, GDB or LLDB, whether
or not you want to launch it using instruments,
whether you want to have breakpoints on
when you launch, what environment variables
and command line arguments you
want to use to launch it with,
but a couple of extra things, and these are very powerful.
I strongly suggest you go in and look at these.
It lets you, with checkboxes, turn on
certain memory management diagnostics
like Guard Malloc to run automatically.
You don't have to put in special environment
variables anymore, you just check the boxes.
Second, it gives you--
[ Applause ]
Second, it gives you some advanced logging options
for automatically logging things
from AppKit or UIKit as they occur.
Now for distribution schemes, instead of a
launch action, you have an archive action.
The archive action simply lets you designate what
you're going to archive and choose whether you want
to archive simply your application build product
or a disk image with all of your build products
from the build directory in the flat list.
Now, when each action runs, you get
another chance to customize what goes
on in the scheme by pre- and post-actions.
Pre- and post-actions are basically two things.
One, you can send an email message
or two, you can execute a script.
And these let you do things when you build, when
you build and run, when you test, when you archive.
Some things you might want to do is before you build,
you may have some frameworks that are in the ZIP file
that you need to unzip before you build the first time.
So, you might want to write a script for that.
Or after you finish building, you may want to
go through and script out your private headers
and do that in a post-action on your build.
Before you launch, you may want to copy sample data into
some arena for your application to use and then clean
up afterwards so you can do repetitive test runs.
These are the kinds of things you may
want to do with pre- and post-actions.
And to show you the power of schemes
is Chris Hanson.
[ Applause ]
>> Chris Hanson: Thank you, Chris.
[ Applause ]
I'm Chris Hanson and I'm also a
developer tools engineer working at Xcode
and so aim to go over to our demo machine here.
And let's take a look at schemes in Xcode 4.
Now the very first thing I'm going to do
is edit my active scheme and make sure
that when I'm building, I'm building for development.
[ Pause ]
I think I'll also open up the navigator
again and let's just select some code here.
Now schemes let you build for a given purpose,
but we first get just our top-level targets.
As Chris explained, turned into schemes
when we open an Xcode 3 project in Xcode 4.
I'm just going to select the Colloquy
application here from our project and build.
As you can see, I switched over to the log navigator
already-- or to the issue navigator immediately--
and that's because in the preferences, we actually have a
new alerts panel but lets you set some actions to take place
when different events occur like a build starts.
So here, I just have it set to show the issue navigator.
Because usually, when I build something, I want to
see immediately if I get any errors or warnings.
Well, if I show the issues by file here
in the navigator, you can see that--
even though my build succeeded I
have a few issues in this code.
Now if I select one, of course the editor
will take me right to that line of code
and we get a message bubble here,
describing exactly what goes on.
We can also click add-on-- icon in the gutter,
just like in Xcode 3, to hide the message bubble.
But of course, that doesn't actually
remove the issue it just hides it.
Now, we can also explore issues by type so if you want
to handle all of the issues in your code of the same type
at once, you can simply change how the navigator
is filtered and go one issue after the other
through your code even across multiple files.
But we don't have to use the navigator for that.
Let's say we want to see just all of our code and
not worry about this list of things in the navigator.
I can hide the navigator and instead use
this control up here, you zoom in on that,
that we like to think of this a mini-navigator.
We just click on it.
We got a pop-up menu that shows the
two warnings that are in this file.
I zoom out.
We can switch between those warnings just by selecting them.
But we also have a bunch of warnings in other files.
Well, I can use these arrows here, to iterate through
the warnings and then when I finished the warnings
on one file it'll take me to the next file.
You can see I've gone already from AGRegex.m
to AsyncSocket.m. We can also bring back the
navigator here and used its filtered field.
Just like in other navigators, there's a
filter filled and you can filter on the text
of the warning, the file names and so on.
If I zoom out and I just want to see all of the warnings
involving semicolons, I can just start typing semicolon
and I can see that there are a few semicolon
warnings so I could go through and just fixed these
if the other warnings might be a
little bit more complex to handle.
But really, if you just want to see you
code, Xcode won't get in between you anymore.
I'm going to show the navigator again and we
don't just show issues in the issue navigator.
We also have a log navigator that
lets you see all of the steps
that have gone through-- that your build has gone through.
Like the build window in Xcode 3.
So this should be pretty familiar
to people who have used Xcode 3.
And you can see if we show the assistant, if
we select a warning we're taken right there
in the assistant editor in the bottom of the window.
But what happens if we highlight something that doesn't
have-- oops, that doesn't have a file associated with it.
Well, obviously, we don't have any assistant results but
we can still see a transcript of the command that generated
that warning so we can see what might have been happening.
We can also of course still filter using the buttons up here
to see only errors, you know, in case we don't really care
about warnings or if we really want to see all of the things
that happened during the build, we can show all messages.
And let me go back to the basic mode
here so we can really see everything.
And you can see that Colloquy is
built it goes through a lot of steps.
But we only have one entry in this log, if I hit command B
to build again, well, we switch back to the issue navigator
because that's what I ask Xcode to do and then if I go back
to the log navigator we have two entries for how we built.
You can see that this is the build that I did first and
now if I go to the second build I'm still showing all
of the steps that Xcode went through and that's
because I have All selected in the filter bar here.
If I just click Recent though, it will show that
this particular build went through a lot fewer steps
and those steps generated a lot fewer warnings, too.
So we preserved these logs across multiple builds so
you can see how your project is changing over time,
not just in your own modifications to it but
what Xcode is actually deciding to build.
As Chris was describing, you can customize Scheme menu to
only show the schemes that you really want to use regularly.
Now, Xcode has gone through and created some
schemes for us based on top-level targets.
But I don't necessarily want to see all of these.
For example, I may not want to build
the Ruby support plug-in directly.
I may never really want to work with that.
So, I can just open up the Managed Schemes sheet,
click Show, and now it's no longer showing in the menu.
It hasn't-- the lead of the scheme
know, I can still show that scheme
and it also hasn't hidden it for
all of the users of this project.
That's only gone in my user data.
So different users can show different set of
schemes based on what they do with the project.
[ Pause ]
I'd also like to make sure that things are in the
order that I care about, so I can just reorder these.
Let's see.
I'm probably going to the regex testing
first, so I'm going to, of course,
keep the Colloquy application at the top of the menu.
But the regex tests up above it
and then show the Colloquy tests.
And you can see the Scheme menu
reflects the changes that I made there.
[ Pause ]
>> Now, if I actually want to make changes to the Colloquy
applications scheme, I can just choose Edit Active Scheme
from the scheme pop-up and I can see the stages
that the scheme goes through and also I can switch
between the various schemes that this project knows
about and pick a destination for them that makes sense.
So here, in the build stage, we can see that we're building
the development configuration and I've used the Plus button.
Actually, if I just remove this, I can use the Plus
button to add any of the targets that my project knows
about whether in project itself or in projects
that have references within it to the list
of additional targets to build by the scheme.
Now the launch target would be built by the scheme
and this is actually the target whose
result is selected in the launch stage.
But this other target here, well, I
just want to build it for testing.
So I have that choice now.
So what I'm going to build with command B, this target isn't
ever actually going to build, it's only when I chose test
from the product menu that this
target is going to build as well.
[ Pause ]
Now if I choose Test, my build succeeded
pretty quickly, and if I look at the new build
since I'm only showing recent changes, you
see that it also built the regex test target.
[ Pause ]
If I go back to the Edit Active Scheme sheet, I can
select the launch stage and here we have a choice
of which debugger I want to use or
which performance tool I want to use.
We can off course set the arguments to pass on launch
and the environment variables to pass on launch.
And we can use the diagnostics pane to turn on some
memory and other logging and debugging diagnostics.
For example, I've got Log dyld libraries turned on here,
so I can see what libraries get loaded
at launch time by MyApplication.
If I just choose Run Without Building,
you can see that we have the debugger here
and my product-- my-- don't send, MyProject comes up.
And if I show the debug area again,
there is a bunch of logging information
from dyld saying exactly what libraries were reloaded.
That means I didn't have to remember a cryptic dyld
environment variable, and the syntax for putting
that in my launch scheme, all I
had to do was click a checkbox.
But we're still in the log navigator and you can see
that debugging actually got us a new entry in the log.
If I select it and zoom out, we can see all of the
log data that was generated by that application.
So not only do you get transient log data
in the debugger area as your debugging,
but it's also preserved right alongside your build
results so you can go back and take a look at it later.
Now in addition to the launch schemes,
we also have distribution schemes.
So let's say I actually want to build this
application, which is a Mac OS X application,
package it up and post it on the web server.
I would do that by creating a new scheme,
selecting the primary target that I want to build,
which in this case will be Colloquy application again.
I'm just going to name this scheme, build, and post,
and then I'm going to make it a distribution
scheme instead of a launch scheme.
I click OK and go to Edit Active scheme and now you can
see that the build stage is just like the build stage
of my other scheme, although I think I
want to build for release not development,
because I'm going to send this out to people.
My test target is still only Colloquy.
And now instead of a launch stage, we have an archive stage.
And it's preset to generated a disk image.
And you can select for a Mac OS X application
which kind of archive you want to create,
whether it's a disk image or just an application archive.
And you can see that we have a couple of checkboxes here for
other options like including the dSYM files in your archive.
That's if you want to save this out for symbolication later.
One other thing that you might want
to do with your archive scheme,
your distribution scheme, is actually add a post-action.
Let's say once you've built your
application and had an archive generated,
you want to actually copy that
up using a CP to your web server.
Well, you can just use the new Run Script action button
here, and you get an editor that has the full power
of Xcode's text editor, including syntax coloring,
for shell scripts and any other form of script.
And after I post to MyWebServer-- let's just
actually see what we're going to do here.
Let's say I want to send email to my testers, and
you can add as many run script stages as you want.
You can reorder them and you can delete them.
[ Applause ]
And when you actually build an archive to your application,
they'll show up in the organizer's Archives tab.
Now, of course you don't have to do all
of these through the Xcode user interface.
You can set this up through the Xcode
user interface and then we still support
and have actually freely enhanced
the Xcode Build command line tool
so you can run your configure--
your continuous integration machine.
Actually, I need to run the one that's in Xcode 4 user bin.
We install in Xcode 4 so as to not step
on your currently installed dev tools.
If I just show Help here, you can see that we've
added workspace and scheme arguments to Xcode Build
so you can tell Xcode Build to build a particular scheme
and let it take all of its configuration from that scheme.
And that workspace argument is something
that Chris is going to tell you about next.
[ Applause ]
>> Chris Espinosa: Thank you, Chris.
Boy, that was a ton of stuff to cover.
You've saw some powerful stuff there.
But there were two really important things that
you didn't emphasize that I want you to understand.
I want to thank the Colloquy people for building a
relatively robust, fairly complex Xcode 3 project
that it didn't open and run the first time in Xcode 4.
All we had to do is upgrade it 3 generations of
compiler to build with LLVM 2.0 and it was great.
But that's basically all we did to the open source
Colloquy project in order to get it opening,
editing, building, and launching in Xcode 4.
All we did was change the SDK in the compiler.
A second thing is all of those changes Chris made
to customize his working environment to narrow
down the combinations to make pre- and post-actions
on his launches to set up a special jig for testing.
None of that touched that project.
Those were all his changes and if he wants to, he can
just check the little shared box and share those changes
with other people using Xcode 4 who have
access to his workspace or that project.
Those are two really, really powerful things.
One is that we work with large, complex
existing projects without changing and second is
when you put Xcode 4 features in, that
doesn't affect the Xcode 3 projects.
Those-- that's really going to help
adapt Xcode 4 in your organizations.
Now notice I said workspace.
You saw a little of this before.
Workspace are perhaps long term the most powerful thing
we're adding to Xcode 4 and you're not going to see them
by default because you just opened up a
project and all you see is that project.
But really, it opens in a window that we call the workspace.
The workspace can be very simple or very complex.
So workspace is just the container.
It can contain one file, multiple
files, a project, or multiple projects.
Workspaces have certain attributes.
It imposes consistent cross-project
standards on everything that's in it.
For example, when you throw things into a
workspace, the workspace is indexed as one.
So all of your navigation can happen fluidly between things
in that workspace and if multiple things that build there
in that workspace they all build to the same location
and that location is independent of other workspaces,
even other workspaces that contain the same project.
And we've emphasized this a couple of times because a
lot of people here use the trunk and branch methodology
of development where you have an SVN
repository or a repository for your trunk
and then you fork off a branch and
then load the project from that.
In Xcode 3, if you're set up for a common build
location, when you build trunk and then build branch,
they're typically building into the same build folder and
they step on each other and that's awkward and difficult.
With workspaces in Xcode 4, if you open each project
in its own workspace, they have their own independent,
self-contained build folders and they will not conflict with
each other when you build the trunk and branch alternately.
[ Applause ]
Now what do you do to assemble the workspace?
Like I said, the way you're going to build
workspaces and you won't even know it is just
by double-clicking your Xcode project, so it'll just open.
You can do it deliberately with a new menu and create
a new workspace and you get a blank empty window
and you can just drag and drop files right into it.
You can use it as a standalone text editor if you want.
Just close both sides, collapse the toolbar, drag a text
file into it, there's your Xcode Text Editor right there.
But if you want to drag and drop multiple project
files, it's going to ask you the normal kinds of things
that Xcode asks you for the reference
style and whether to copy or not,
and you can add new projects to
it with the New Project button.
Once you get the workspace, the things you do in
that workspace can be private or can be shared.
And the sharing depends on whether you make
your workspace available to other people either
in a source code system or just by email or exporting it.
So for example, if I've got a project
in my workspace and that workspace is
in a common repository, and Chris checks it out.
All of my schemes are private to me and
all of his schemes are private to him
but I can go and designate some as being shared.
And then he can see them.
And then he can take some of his schemes and
designate them in shared and I can see them.
So that's a powerful way to share things
among people but keeping your own workflow.
For those of you who always wanted to take for example
custom executables from Xcode projects and be able
to export them and share them with other
users, this is what you can do that with.
You create a scheme, a launch scheme that tailors how you
launch, and you click the Shared button and everybody else
who uses that workspace can see that executable:
similar for debugging, similar for testing.
And to show you workspaces is, again, Rick Ballard.
[ Applause ]
>> Rick Ballard: So I'm going to start out
here and take you through a little bit of stuff
that you've seen very briefly at
first but then off to something new.
So we've got an existing application project here.
And if I opened it, as Chris said, you'd automatically get
its own workspace for that project without even knowing it.
But sometimes I want to be able to create a
manually managed workspace for several reasons.
One of them is sharing, another one is this feature
called implicit dependencies which I'm going to show you.
So I'm going to go ahead and start out creating a new
workspace and I can just do that from the new menu.
Say new workspace and I choose why I
want to save it and give it a name.
And I've got a new workspace.
It's not very interesting yet, so
let's go ahead and add my application.
Now I've got my application in here.
You will notice the first time you open
the project or add it to a workspace.
We automatically create a launch scheme for it.
And I can go ahead and build and
my application should build clean.
Oh, it's got a warning, but it builds.
So one reason I might want to create this external
workspace is I've got a couple of things that I want to work
on together and they're not directly related so
the projects don't actually reference each other.
But when I'm working on one, I usually want to-- I at
least look at and maybe work on the other one, too.
So in this case I've got my application,
but I also want to work on this new tool,
so I can just say from the Plus button down
here or from the new menu, New Project.
And create my new command line tool project.
Choose where I want to save it on disk.
I'll say this to my desktop and where in
the workspace structure I want it to put it.
So I'll put it at the top level.
Now, I've got both my projects
at the top level of my workspace
and I can easily search across them and work with them both.
Now if my coworkers want to work on the same 2 projects,
I might give them my workspace file or I might check it
into STM or if it's just me that wants to work on these
together then I might have my own personal workspace
and maybe sometimes use another
workspace that my team is sharing.
Now you'll notice that my application here
links this framework called MyFramework.
It's going to reference to it here and if I want to see the
actual linkage, I can select the project, select the target,
go to the build phases and look at that link binaries
with libraries and yes, it links MyFramework.
Well, MyFramework is this framework
I've got installed on disk
and most of the time I just want
to use the installed version.
But occasionally, I have a problem with it and I have the
source code to this framework so maybe I actually want
to build it from source and run against my
debug version of that framework now and then.
Well, you notice right now I have no dependencies on
this and in Xcode 3, the way I do this is add a reference
to the MyFramework project and then
set up a manual target dependency.
And then every time I build my
application, MyFramework would also build.
But then when I want to go back to just building against the
installed version, I'd have to remove the target dependency,
and every time I'm doing that, I'm editing the project.
You know, I have to be careful not to check in that
dependency if other people don't want to work with it.
So we decided, hey, wouldn't it be great if you
could take a workspace and instead of having to set
up manual target dependencies for
things like this, just if MyFramework,
the project is available, use it, and if not, don't use it.
So that's what we did.
If I go ahead and just drag in the MyFramework
project and build my application again,
you can see that it actually built the MyFramework target
without any explicit dependency
at all just because it was there.
So that's implicit dependencies.
When I'm done with MyFramework project then
I want to go back to using it from disk,
I can just delete it from the workspace
and nobody will be any the wiser.
So you may be thinking to yourself that's great, it builds
it automatically but surely when I go to run I'm going
to have a problem because each project
builds into its build directory
and the linker won't find the framework
at runtime; not in Xcode 4.
In Xcode 4, every workspace automatically has its own
per workspace shared among itself build directory.
So the build products from all MyProjects and
targets in this workspace go in one common location.
This is really useful because each copy of the workspace
gets its own unique build directory and that means that say,
I check at another copy of this workspace from
a different source control branch and go back
and forth building this one, now building that one
maybe because I'm trying to track down a regression.
Since each automatically gets its own build directory,
their build results won't conflict with each other
and I don't have to clean and rebuild
every time I go back and forth.
I just build in one, build in the other, and it just works.
[ Applause ]
If you want control over exactly where your build
products are going now, we definitely give that to you.
If you go to the File Menu, there's
a Workspace Settings option
or if you've open a project, it's called Project Settings.
And when I bring this out, this brings me to a panel
that tells me all about where my stuff is going to go.
The first thing you see here is the derived data location.
Well your derived data from your workspace is the build
products and intermediates you produced and any logs
from your builds and debug sessions and your index.
And by default, we store all the stuff
in a folder underneath your home folder.
But if you needed to go somewhere special you can do
that, say because you need to have everything good
with secure source image for security reasons.
Beyond that, by default, every workspace
gets its own unique build folder
so that it doesn't conflict with another workspace.
But if you want, you can set a
custom subfolder to use instead.
If you set 2 workspaces to use the same custom
subfolder, they'll share their build products
because they'll be building into the same place.
Finally, if you do need to build into the classic
locations set by your build settings as in Xcode 3,
you can choose builds going to locations
specified by projects and instead
of getting the new derived data directory location builds,
your build settings will dictate
exactly where your build products go.
Now, if I click the arrow here, I can actually
go take a look at my derived data directory.
And inside you'll notice that each of my
copies of my workspaces got their own folder.
Inside that you'll see there's a build folder, an
index folder for my index, a folder for my logs.
This file here called Info.text, which just gives the
path to the workspace that this folder corresponds to,
which can be useful if you're trying to work backwards.
And inside the build folder, you'll notice
that we now separate your build intermediates
from your precompiled headers from your products cleanly.
So this should make it easier to work with your
build products when you actually have to do that.
Now as Chris mentioned, there is another kind of sharing
that we support in Xcode 4, and that's scheme sharing.
And I want to show you just a little bit about that.
If I go to the Managed Scheme sheet,
I'm given several options.
First of all, I see all the schemes in my
workspace and I have a Shared checkbox.
Well, by default, every scheme I create belongs just
to me and nobody else can see it so I'm not cluttering
up their workspace and when I change
settings, I'm not affecting anyone else.
But when I set up a scheme that everyone on my team wants
to use or I've got some setting that other people are going
to want to use, I can just click the Shared checkbox and
now it will show up for everybody, everybody will co-own it,
they can all edit it, it's just
a shared scheme at that point.
Well what happens if my team adds a whole bunch
of shared shames and they're cluttering up my menu
and I don't really care about these things
that most of my team members care about.
Well, the Show checkbox that Chris
showed earlier let me easily say, hey,
I want to leave the scheme alone
at shared but don't show it to me.
And that Show checkbox is per user so I'm not
affecting anyone else when I say not to show it.
[ Applause ]
The last thing you'll notice here is the container column
and that lets me control exactly where each scheme is saved.
These schemes are saved off in their own files.
So changing your executable settings no longer affects
some big file that you're managing at resource control.
Instead, each scheme gets its own file easy to manage in
source control and I can control whether I want a scheme
to be saved in, say, the project that
it's associated with or the workspace.
When I do that, that controls whether well, if I share
the workspace with somebody else, do they get my schemes?
If I share just the projects but I'm keeping the
workspace for myself, do they get those schemes?
I have full control over that with the Container pop-up.
There is one more way to share
this which is very useful which is
in the Gear menu there is Import and Export options.
I can go ahead and export one of this and
just save the scheme file directly to disk.
I'll save this one to my desktop.
I could email that to a colleague and
he could turn around and say Import.
Choose the scheme, import it, and
it shows right up in his project.
[ Applause ]
So we think that sharing is a lot easier in Xcode 4
and we hope that you find this stuff very, very useful.
[ Applause ]
>> Chris Espinosa: That's terrific.
Thank you very much, Rick.
Well, we are now approaching our destination.
Thank you for attending.
I want to sum up a couple of things for you.
You saw a lot today.
Come down to the lab tomorrow morning if
you need a recap of what this all means
or to see some of these things in real life.
Download the product from the hardwire connections
in the labs or in any of the public areas.
I hope that when you download Xcode 4
and install it and open up your projects,
you're going to start seeing 3 or 4 things.
First is that your Xcode projects that
you have already open up in Xcode 4
and you can edit and build them just like in Xcode 3.
And then take those projects back
to Xcode 3 if you needed to.
That you have a lot more room and clarity to edit those
projects in their build settings because we show you all
of the configurations at once and all of the targets
and project at once instead of making you go to a lot
of modal little inspectors to figure
out what's happening where.
I'm hoping that what I personally get out of this
is that I never have to ask people are you looking
at the target settings inspector or are you
looking at the project settings inspector,
and then explain what I mean by that question.
[ Applause ]
And its sister question is, do you have all
configurations chosen or just one configuration chosen?
Both of those problems go away.
Third thing is that schemes are a really powerful way to
organize your work personally and to organize the work
in your organization and share it in your organization.
And you can control how you build with schemes without
having to make all of these edits in your project file
that create trash in source code system
and create angst because I don't want
to see those new aggregate targets you created
for your test jig and they make my menu too long.
Those problems go away with Xcode 4.
And finally, the free form association of product projects,
the way that projects will implicitly
build implicitly depend on each other.
The ability to search across multiple projects all the
time and get to the right answer in the right project.
The ability to index and jump and navigate across projects.
The ability to edit the build settings or the targets of all
of your projects you're working with in one window instead
of having to open 7 project windows on your desktop.
You'll find that those tremendously improve your
productivity when you're working with Xcode 4.
For more information, Michael Jurewitz is our evangelist.
He's here the rest of the week, which is not very long.
Apple Developer Forums, there is a specific
developer forum for the Xcode 4 developer preview.
It's all already quite active, get on
it, ask questions, read the questions
and answers other people have answered,
read the release notes.
There are 11 pages of release notes for this release.
Go ahead. There's a lot of stuff
there and there's great documentation.
There are only a couple of sessions
left talking about Xcode 4.
Using Interface Builder with Xcode 4, in this
room immediately after, stay in your seats,
it's going to be great, tons of great stuff.
Tomorrow morning, Debugging with Xcode 4 and
LLDB, the great new things in our LLDB debugger.
Thank you all very much for coming.
[ Applause ]