Good morning, everybody. Welcome to day two of Apple's 2006 Worldwide Developer Conference. I'm Chris Espinosa. I'm the head of the user experience group in the Xcode development tools team, and I'm here to welcome you to Xcode, Apple's IDE. Our objective this morning is to orient you to the Xcode suite of tools to highlight some of the similarities and differences between Xcode and other tools you may be experienced with, and to answer some of the common questions you're going to encounter as first-time users of Xcode. If you are not a first-time user of Xcode, now would be an excellent time to deplane.

If you are experienced with using Xcode, I suggest going to the Cocoa session in the next room, or please, please, please, downstairs to How to File a Good Bug Report. That will help us much more than you're sitting in here learning the rudiments of Xcode. So if you're still with me, that means that you probably have not used the Xcode tools extensively before. You may not be familiar with the Xcode tools at all. You may be a newcomer to the Mac OS X development environment altogether. So I want to do a little show of hands.

Hands of where you're coming from. Which of these do you recognize? How many people are more experienced in the Visual Studio, Visual C++ development environment? Okay, good number. The mug in the middle is the Emacs cheat sheet. How many of you are primarily Emacs terminal make file developers? Great, that's where I figured it. And how many people have experience in the Eclipse development environment? Good, good mix. How many are Code Warrior refugees? Figured.

So many of you, it looks like, from either Visual Studio or from Emacs or Code Warrior know what an IDE is and what the benefits of having an integrated development environment are. If you've only used the GNU tools or command line tools to develop, an IDE may seem new to you.

What we give you with the Xcode IDE is actually the best of both worlds. It's the graphic user interface that you're familiar with as a user plus the full power of the back end tools that you get using the command line. The IDE integrates, and that's what the I in IDE is. It integrates a lot of different functions, not just the editing and building. But it's editing, building, debugging, source code management, visual modeling, documentation reference.

A lot of things are packed into one application, and there are bridges to other applications that allow you to do four. For example, interface design as well. And Apple's IDE is different in that it guides you specifically to developing Mac OS X applications. While in many respects it's a generic build, link, debug development environment, there are a lot of things all over Xcode which guide you to developing Mac OS X specific applications.

The first questions you probably have if you're approaching the Mac OS X platform as a developer is, well, where are my tools? Well, you know, if you're a Microsoft developer, you go and buy Visual Studio. If you are an Eclipse developer, you download Eclipse. If you're a Mac OS X developer, what do you do? Well, the good news is, out of the box, with every single Macintosh we've ever sold with Mac OS X on it, and with every copy of Mac OS X at retail, the developer tools are included.

With every copy, there's nothing to buy, there's nothing to download. You boot up your machine, or you put in your installation disk, and there is a disk image of the developer tools right there on the hard disk or right there on the DVD. You double-click that disk image, and you get the installer for the developer tools.

If you want to upgrade, you go to Apple Developer Connection, ADC, and you can download the latest tools. The current tools up there is Xcode 2.3. We just introduced 2.4 yesterday. It's not up on the website yet, but it can be downloaded from the servers here at the show. We're going to be using Xcode 2.3 for the demonstration today.

When you install developer tools, something subtle happens to the top level of your hard disk. You get a folder called developer. Most of the developer tools are there. And if you want to start with the Xcode IDE or any of the other tools, you just double click that.

Some of the applications are at the top level. Others are buried within it. But most of the things that you want to use as a developer will be found inside the top level developer folder on your hard disk after installation. But there's a lot that goes other places too. Let's take a look.

In the developer folder, you see a top-level about document, a PDF that you can read. The reference library, which is all of the documentation, will show you how to get to it. The applications, which is where Xcode is. Then there's documentation and a lot of examples, a ton of sample code in examples, some headers, some bundles. Notice the SDKs folder here. That's the software development kits for Mac OS X. That is where the headers and link libraries are that you'll be using in the projects you create. We'll talk a little bit more about those later.

But there's more in other places. If you're a traditional Unix developer, you understand that slash user is where most of your developer stuff goes. When you install Mac OS X, a large number of Unix utilities and tools are included, but not all of the development utilities. When you install Xcode tools, all of the development utilities are added in, including the Unix header files in user include, the link libraries and runtime libraries in user lib, and all of the tools, including the compilers in user bin.

These are the typical places they are in a Unix or Linux development environment, and you'll find them there. The third place in the Mac OS X idiom is in the library folder, and the library folder is your machine configuration. It's where you put machine-specific stuff, and when you install the Xcode tools, your machine-specific plugins and configuration go in slash library.

They're buried in a folder called application support slash apple slash developer tools, and there are a bunch of templates, a bunch of plugins, a bunch of configuration scripts. When you get to be an advanced Xcode user, you will find your configuration information, you will find your customization goes on in that folder. So let's take a quick tour of the Xcode IDE.

Xcode has three different layouts, and you pick one in the preferences. And the different layouts are designed for different development styles and for, in many respects, for different origins of where you might come from. The default layout gives you the product, the project view, Laser. The project view on the left, and then a detail view on the right, and then an editor window slides up to show your edit text. It gives you most of the tools you want in one window, but you will often open other windows for specific tasks such as editing and debugging.

There's a condensed layout, which is more familiar to those of you who use Code Warrior, where your project is in one window, and then editing, building, and debugging, and finding all happen in separate windows. But if you come from a more all-in-one environment, where you expect everything to be in one window all the time, there's the all-in-one layout, where your project and your detail and your editor are all in the same window, and then you switch pages with the page button up here to go to debugging or to... ...to building. Pick the layout you want. We will be using the default layout in the demo, but most of the things that we're showing today work equally well in all layouts.

So when you start putting together a project in Xcode, you do it in what's called the groups and files view. This is where your headers and source files go, and you can group them together in these folder-like groups to organize them. There are really two things here. One is the project membership up here, and two is a bunch of smart groups down there.

The smart groups are much like smart groups in iTunes or iMovie or another i application. They give you a quick reference to certain kinds of things. For example, a smart group at the bottom called project symbols shows you a list of all of the classes and methods and macros defined in your program. It's essentially a flattened version of the project index.

It's very useful to use these smart groups for navigation. You'll spend most of your time in the editor. Whether the editor is in a separate window or whether it's embedded in your default or all-in-one view, the editor works the same. It's a source code editor. It does automatic indentation. It does syntax coloring. You'll see more advanced features of the Leopard Xcode editor in this afternoon's session. We're just going to show you the basic one that's currently in 2.3 and 2.4.

If you're doing an application with a graphic user interface, you'll be using Interface Builder. Most of your projects will come with default interface files called nib files. You double-click those, and you launch a separate application called Interface Builder. And you use it to design your project. You design your graphic user interface and then wire it up to your source code.

If you're doing object-oriented programming, which most of you probably are, you'll want a class browser. Under the Windows menu, there is a Tools item, and under the Tools item are most of the windows you're about to see. The class browser is one of them. You can also put a toolbar tool in to pop up a class browser at any time, and it lets you inspect classes and see what the members are and go straight to the header file for any particular class in your application. You can also look at the classes in your application in a graphic way using the class modeling tools from the Design menu.

There's plenty of documentation. From the Help menu, there is Xcode Help, which takes you directly to the Xcode user guide, and a general documentation item, which takes you to all of Apple's documentation on the Macintosh product line, from hardware on up. And it's 15 years worth of documentation. It's a huge amount.

The installation of the documentation is as large as the installation is the developer tools themselves. It's a huge amount of information, so huge that some of it is even indexed on your local disk, but it goes to the network to get the actual content. This way you get the freshest content, and we can provide you all the information that you really need.

When you've got your source code written and you want to build it, there's a build results window that gives you the controls for building your application and shows you the build steps and will show you errors and warnings as they occur. You select an error and warning and it brings it up in the source code. This is called the build results window.

A crucial part of the build results window, especially if you're coming from a makefile terminal-like environment, is what's called the build transcript. If you look right here, there's a little widget, tiny, obscure, mysterious, that if you click it, it discloses the secret underlife of Xcode. This is the actual transcript of the build commands being issued to the shell to execute the compiler, linker, and other commands that build your product.

If you open that all the way, you will see hundreds of K of terminal commands, and you can look at them and see them step by step. If you select a build step in the top pane, it will select the corresponding build steps in the transcript so you can see exactly what's going on with your build.

And finally, debugging. When you launch your program in the debugger, you can set breakpoints, step through it, step into, step over. You see the stack trace. You can select different threads. You can inspect the value of variables. Much of this is familiar to you for anybody who's used an IDE with a debugger in it.

When your application is up and running and you've made all the changes you want, you may want to commit it to a source code management repository. Source code management is integrated into the Xcode editor. When you enable your project for source code management, you get an extra column in your detail view that shows the status of any file. M for modified, C for conflict, for example. And you can use the SCM menu in Xcode to commit or check out or inspect differences between two versions of a file. This is an integrated development environment. All of these tools are in one application.

So let's talk about your workflow, what you do as a user of Xcode. You edit your code, you build it, you get errors and warnings, you build it, it succeeds. You debug it, you step through, you inspect what your program is doing, you get it working, then you deliver it to customers. We're going to walk you through that workflow with Xcode. Rick Ballard is going to come up to talk you through it, Chris Hanson is going to be on mouse and keyboards, and I hope you enjoy the demo.

Thank you. I'm Rick Ballard. This is Chris Hanson. We're going to step you through some demonstrations of common tasks in Xcode. We're going to start out with a demo of creating a new project, probably the first thing you'll do in Xcode. Let's go ahead and get Xcode going.

And we're going to go up to the file menu. I don't think we're showing the correct machine. If we could switch, please. One moment, please. Well, what we're about to show you is we're going to bring up and create a new project. Xcode gives you a bunch of assistants, which let you start with different templates for different types of projects. Here we go. All right. So you can see here we have the assistant window up. You get that by going to the file menu and selecting new project. And here we have a bunch of different categorized types of projects that we can create.

Let's go down to the command line tool category, and we're going to start out with a standard tool. That's just a simple C command line application. We click the next button. Here, Xcode lets us name our project and decide where we want to put it. Unlike some other IDEs, in Xcode, your projects can live wherever you want.

And generally, you may put all your source files in a project directory, but you can locate things wherever you want, really. So let's go ahead and click Finish. This will cause Xcode to create our project for us. And you see the project window, which is where you're going to spend most of your time in Xcode.

So you see, as Chris Espinosa showed you earlier, there's a Groups and Files pane on the left. That top icon that has the name of the project, "Hello World," and a little project icon, that's the root group. That icon represents the project itself, and it contains everything in the hierarchy, source files, resource files in the project.

Next to the Groups and Files pane, you can see the Detail pane. And you see there are a few files listed there. Well, the Detail pane will show you everything in the hierarchy under what you have selected in the Groups and Files pane. So since we have the project icon selected, you can see all the file references in the project.

If we click on the products group, we can filter down and see just the file references in the products group. You see there's one reference there. It's got the name of the project, and it's red. If we click on the products group, we can filter down and see just the file references in the products group.

You see there's one reference there. It's got the name of the project, and it's red. If we click on the products group, we can filter down and see just the file references in the products group. You see there's one reference there. It's got the name of the project, and it's red.

If we click on the products group, we can filter down and see just the file references in the products group. You see there's one reference there. It's got the name of the project, and it's red. after it's finished. So we're gonna turn that on. And now we can go ahead and click the little build hammer in the toolbar, and it'll build our project.

You can see the steps that it's done there, and our build has succeeded. Now, if we want to see a little more detail, you can click that little text widget, one of those little boxes, and we'll see the actual commands that Xcode has sent to GCC, which is our C compiler. We go ahead and click the Run button. It'll go ahead and run our project, and it prints Hello World. No big surprise. Let's go back to our slides.

So you may have noticed that there was a little bull's eye icon in the Groups and Files pane called Targets. What's a target, and what's the difference between your projects and your targets? Well, a project contains references to all the files related to your deliverable. So my deliverable might be an application that I'm linking against a couple frameworks. I have to build my frameworks. I have to build my application.

We generally recommend that you put all the source files, if your frameworks are really just for that one application, in one project. You have all the files there that you can refer to, and your project can contain other ancillary files that you're not necessarily going to compile, like notes. It'll contain your resource files, everything related to your project.

Now, the target is what actually processes your source files. It compiles them. It'll take your resource files and copy them to the correct place. So your target just contains the files that it processes, and it produces one build product. So I'd have a target for a framework, a different target for my application. Every different build product has its own target, and the target just contains, references to the files which are relevant, which it will process for that target.

Your project also contains general settings that you're going to use for all of your development, for everything for this deliverable. A target contains the settings that are specific to that one target. And the project contains all the targets that you're going to use with that project. Likewise, a target contains a series of build phases which process your files. If this sounds a little confusing, let's go to a demo and show you what I mean.

So we're going to open up our temperature converter project. This is an application which will convert from Fahrenheit to Celsius for us, but we need an actual converter in a framework that it will link against to provide it with the actual conversion routine. You see if we disclose that, we've disclosed that targets group, you can see there's one target.

Represented by the little application icon, that represents the application we have in our project. What we're going to want to do here is add a second target, which will build our framework. So this project will have two targets in it. It's also possible to put each of your targets in a separate project and use cross-project references between them.

If all your targets are related to one deliverable, we recommend you put them in the same project. So let's go ahead and add a new target. We're going to go up to the project menu, and we're going to say new target. And we'll get an assistant that's very similar to what we had earlier with the new project assistant. Here we can select what type of target we're going to build.

Unlike the project assistants, these don't come with template files to get you started, but they do come, it does create a target with the right settings initially for the type of product that that target is going to build. Here we're going to create a Cocoa framework. So let's select the Cocoa framework.

And we'll go ahead and click finish. We'll name our target first. This is going to be the converter framework, so we name it converter. You see there's a pop-up which will let you choose which project to add this target to, but we only have one open project. Let's go ahead and finish. And we're going to close the info panel that's open for us. And you can see it's added a second target. This target has a different icon because it's of a different type. This is not an application target. It's a framework target.

Let's go ahead and finish. And we're going to close the info panel that's open for us. And you can see it's added a second target. This target has a different icon because it's of a different type. Those phases process the files that the target needs to process to build its product.

There's also the compile sources phase. That's pretty self-explanatory. If we click on that, we can see the source files that we will compile when we build this target. Finally, this target has a link binaries with libraries phase. You can see we have one framework, the Cocoa framework, that it's going to link against when we build this target.

Well, we need to link this application target against our converter framework. And we need to make sure that our converter framework actually builds some source files that we're going to use. So let's start out by adding the source files that we need for our converter target to the project. We're going to go to the finder.

And we have a couple source files here already that we've written. You remember how I said the project contains all the files that are related to your deliverable for all the targets in the project? We can just add these files to the same classes group that the other target source files are in.

It'll give us a couple options, none of which we need to change right now, but there is one we do need to pay attention to, which is the target membership. We want the converter target to process these files, and we don't want our application target to process these files.

So we'll make sure just the converter is checked. Go ahead and finish. And it adds these files to the project for us. Chris is going to quickly fix up the header role for our header, and you can learn more about what that means in one of our later sessions.

Now we need to make sure that we link against this converter framework when we build our application. Well, if you click on the Products group, you'll see that it's added the build product that this converter target is going to build, the converter.framework. We can just take that and drag it into the link binaries with libraries build phase of our application target, and that will tell our application to link against the built converter dot framework when you build the application.

But we haven't actually built that framework yet. If I was to hit Build right now, well, there are two different targets. Which one is it going to build? There's the notion of an active target. If you go to the project menu, you'll see set active target, and we can choose which target is currently active. The active target is the target that will be built when you click build.

We're trying to build our application here, so let's leave the application as the active target. But we also want to build our framework when we build our application. And in fact, if we ever change the framework and go over to build the application, we want to make sure that the latest version of the framework is built along with it. So let's set up a target dependency. That'll make the framework target automatically build whenever we build our application target.

To do that, we're going to open an info panel on the application target. You can do that by selecting the application target in the Groups and Files pane, and clicking on the Info button in the toolbar, or the keyboard shortcut is Command-I. And it'll open up a panel with several tabs here. Here we want to go to the General tab. And you see that there's a large box for dependencies, with a plus and minus button at the bottom.

Let's click the plus button, and it'll give us a list of all the available targets that we could make this application target depend on. We'll choose the converter target. Go ahead and create that dependency. We can close our info panel. And let's see what happens when we build. Let's open up the build results window.

And let's go ahead and click build. And you can see it builds-- if we scroll up a little bit, you can see it builds the converter framework first, and then it builds our application target. Let's try and run it and see if it worked. Here's our converter. It's supposed to be 69 degrees in San Francisco today, so we can type that in, and we can see what that is in Celsius. So there's a two-target project with a dependency. One's linking against the other, but we have the source files for both targets in the same project. Let's go back to our slides. There's going to be time for questions at the end. We'll get to that, though.

So there's some settings which control how your targets are built when you click build. Things like, what do I want to name the built product? Do I want to generate debug symbols? What architectures do I want to build for? These are called build settings. And since you generally have different sets of build settings that you want to use at different times, For example, when I'm building day to day, I may just want to build for whatever architecture I'm currently on.

So I can quickly edit, build, debug, edit, build, debug. But then when I release, I need to make sure that I'm building universal. So I need different settings for releasing my project and for building day to day. These sets of build settings that we give you are called build configurations.

Each build setting in a build configuration, these build settings are kind of akin to makefile variables in a makefile. Each build setting has a makefile variable-like name, all caps with underscores instead of spaces, and also a more verbose, readable name that tells you what the setting actually is.

And each project has a set of build configurations with these settings. Whereas where each configuration will set the settings for the same project, same source files you're going to build, but each configuration will let you build it in a different way. Let's go to our demo, and I'll show you what I mean. We're going to go ahead and open up our next demo project. Here we go.

And here, I told you before that the root group, that project icon with the name of the project and the groups and files tree, that that represented the project. Well, in fact, if we open an info panel on that, it'll give us the settings for the project. One of those tabs is the Configurations tab. We can go ahead and click on the Configurations tab.

And you can see the different build configurations we have in this project. Debug, release. Pretty simple. These are the configurations you'll get by default when you create a new project. But you can add new ones by duplicating an existing configuration. You can remove them, and so forth. Let's go over to the Build Settings tab. So each of those configurations has a set of build settings. You can see the human readable friendly name on the left, and you can see the value on the right.

And you notice some of these are bold, some of them aren't bold. What's that mean? Well, the ones that aren't bold, they have the base value that you get if you haven't explicitly set your own value. The ones that are bold, those settings have been customized in the project. A new value has been set there that's different than the base value.

We can go up to the collections pop-up, and there's a customized settings option. And that'll show you all the settings that we have customized in this project. And when you create a new project, it'll come with some customized settings. So this is a quick way to find the settings that you've changed.

Now, say in this application, we want to, when we build day-to-day for debugging purposes, have some debugging log statement. But when we release it to our customers, we don't want that debugging information logged. It's a pretty common thing to do, right? So one way people do that often is by using a preprocessor directive to turn on and off debug logging. If we go back to our project window and open up our source file and scroll down, you can see that we have a preprocessor directive that makes the debugging log statement conditional on whether or not the debug preprocessor macro has been defined.

So how do we control whether that macro is defined? We want it defined when we're debugging, not defined when we're releasing. So let's use the debug and release configurations. Let's go ahead and close this source file, go back and open an info panel on the project. And let's show all our settings again.

Well, we want to set a preprocessor macro. What's the easiest way to figure out how to do that? There's a little filter box in the info panel here. And if we just try typing in preprocessor, it'll filter down the available build settings. We can find what we want.

Well, look there near the bottom. It says preprocessor macros. If we click on that, you notice in the bottom, it describes our build setting for us. The end of the description, there's also that all caps with underscores name. That's the make file variable like name of this build setting.

Let's go ahead and edit that build setting. Let's actually close that quickly. Let's take a look at-- you can see there's a little pop-up that shows which configuration we're editing. We're currently editing the debug configuration. It's important to know which one we're looking at. Let's go ahead and edit that again. And let's set debug equals 1 as a preprocessor macro for the debug configuration.

And you can see that that's turned bold if we deselect it. So you can see, indicating that we've customized that setting. If we select the release configuration, you'll see it turns unbold and no longer has a value, because we haven't set one for that configuration. Now, you remember I told you around the last demo that the project contains the settings that are general for all your development, but the targets contain the settings specific to one build product? There are settings at the target level, too. And if we click on our project window and click on our target, open an info panel, you can see it's a parallel set of build settings. It's the same list of build settings.

Anything you've set at the project level is going to be inherited at the target level. This is something that confuses a lot of people new to Xcode. So it's something I really want to stress. It's a good takeaway. When you're trying to set a setting to control something about your product, if you set it at the project level, all your targets in your project will inherit that value.

If you set it at the target level, only that one target will use the setting. And anything set at the target level overrides the value set at the project level. So when you go to set some setting, when you're working with Xcode, you maybe double-click on that project and set the setting and hit build, and it doesn't do what you expect. Make sure to check the target and see if you've overridden that build setting.

Now here, we set that preprocessor macros setting at the project level. What if we filter on the target for preprocessor again and see what value it has now? You can see we're looking at the debug configuration, and there it says debug equals one. But it's not bold. It's because we customized it at the project level, and it's inheriting it at the target level.

If we were to set a value at the target level, it would be bold there. It would no longer inherit. And if we select the release configuration for the target, you can see that setting is no longer there. Let's close both info panels, and let's try building and running.

You can see we printed out our debug statement. Pretty simple. One other thing you may want to be especially aware of-- let's open up our project info panel. When you're building an Xcode, you really want to make sure that you're going to be building universal when you release.

So that architecture setting happens to be the top setting when you open up an info panel. That's how you're going to build Universal. If we double click on this setting to edit it, we'll get a couple check boxes. Let's go ahead and click, make sure both are checked. So we're going to turn on the Intel check box. Click OK. This will make us build for both architectures, so we build Universal. Let's go back to our slides.

So you've been editing for a while, debugging. You think you've got your project ready to deliver to your customers. But there are a whole bunch of symbols here you may need to worry about. You may want to make sure that your product is ready to give to your customers. That's where stripping comes in. There are three types of stripping, conceptually, that you'll want to worry about.

First, there's dead code stripping. If you have any code in your application that never actually gets called, you don't actually want that in the product you ship to your customers, because it'll make the resulting binary larger, reduce performance. So you want to strip out all that dead code.

Then you may have debug symbols that you were generating, and you don't want to ship those to your customers. Those will also make your binary a lot larger, and they may reveal things about your product that you don't want to reveal. So you want to strip out debug symbols.

And finally, the third type, privacy stripping. Well, you may not want your customers to reverse engineer your application. So you may want to strip out all symbols that don't actually need to be in the resulting binary. Anything that's not a public entry point to a framework of yours, or almost anything in an application, that's called privacy stripping. Unfortunately, this can be sort of confusing to set up in Xcode. So we're going to step through and show you all the different settings that you're going to need to manage to correctly set up stripping for your product. So let's go back to the demo.

And we've got a project here. Let's open up an info panel on the project. There are a myriad of settings that you're going to have to deal with here. If we type in "strip" into the filter box, we'll find a whole bunch of them to start out with. So first you'll see at the top it says "Dead Code Stripping." Well, we want to turn that on. And we're currently editing our release configuration. You can see from that pop-up. So let's go ahead and turn that on.

Those of you coming from Code Warrior may be used to dead code stripping, stripping out your dead code before any linker errors could have occurred. Well, in Xcode, it will link and then dead code strip. So if you have any linker errors that would be caused by your dead code, you need to fix those or remove that code, or it won't compile, or it won't link, rather.

Chris Espinosa, Chris Hanson, Rick Ballard To do our dead code stripping, we need to make sure that we build with a bunch of debug symbols, because the linker needs those debug symbols to strip out the dead code. So let's filter on debug, and we'll see the settings for debug settings. First of all, we need to make sure generate debug symbols is on.

But we also need to make sure that the level of debug symbols is set correctly to let dead code stripping work. It needs full debug symbols. All symbols are dash G full. So we're going to set that. That's all the settings we needed to set to make dead code stripping work.

If we were to build in link, it would strip out dead code now. But we just turned on debug symbols, and we turned on all the debug symbols. We don't want to ship that in a release, so how do we strip the debug symbols back out? Well, let's type strip back into our filter box again.

And you can see there's a strip link product setting. It's currently on. That'll strip things back out of the product, like debug symbols, if deployment post-processing is on. Deployment post-processing means you want to go ahead and strip your product and install it. Well, there's a separate setting for that, but do all these things that are conditional on deployment post-processing. So in your release, you probably want to have that on.

We also want to check the strip style. Strip style will tell it what we want to strip out when we strip the linked product. Well, do we just want to strip out debug symbols? No, we probably want to do privacy stripping, too. We want to strip out all those entry points and symbols that we don't need to ship in our finished application.

So let's make sure that the strip style is set to all symbols. That's what it's set to by default. Or maybe, maybe we're shipping a framework and we need some public symbols, or even an application that has a plugin API, but we don't want all our symbols public. Well, then we can choose non-global symbols from the strip style.

And that'll strip out anything that's not global. How do we control that? Well, there are a couple different ways. First of all, there's an inline compiler directive you can use in writing your code. Second-- There's a set of, or two settings, an exports file setting, which we can see if we type export into the filter box, and an unexported symbols file setting. We can set these build settings to an exported symbols file or an unexported symbols file that respectively specify the symbols we wish to export and or the symbols we don't want to export.

Finally, if we type in private into that filter box, there's a setting, use private extern by default, or symbols hidden by default is the actual name. If we turn that on, it'll make everything non-global by default. So that's a whole bunch of build settings I've just thrown at you. Don't expect you to remember that. What you really need to take away is three types of stripping.

Dead code stripping, stripping debug symbols, stripping privacy stripping, and how to find those settings. You can type in strip into the filter box, make sure stripping is on, deployment post-processing, type in debug, make sure your debug symbols are being generated properly, export to set your exports file, and private if you want to turn on private extern by default. Let's go back to our slides. and Chris Espinosa is now going to take you out with some tips on better Xcode usage.

Second thing is that a lot of the Unix files are hidden from end users. Well, how do you get to them if you want to add a header file or a library from /usr/lib? Well, you just do the open window, and then you either type Command-Shift-G or just the slash key, and the standard navigation panel will let you get directly to that folder by path name.

It's a universal way to get to hidden folders that we want to hide the Unix things from the Mac OS X users, but make them available to the developer. So that's a very common trick to use, is just open, type slash or Command-Shift-G, type in the path, and you can get directly to that header file or that library to include.

This one comes up about every month on the Xcode users list. When you create a new file using the new file template, it comes up with a placeholder for your organization name. You set that placeholder with a hidden preference. You set it from the terminal with defaults right.

This is one of the more poorly documented parts of Xcode. There's one simple line you cut and paste into your terminal. You do it once and it works forever. But this is something you need to go to Google or go to the expert preferences document to put in. You do this once and every new file you create will have your organization name in it instead of my company name with double underscores around it.

This is one that people keep asking us, why don't you put this into Xcode? And we say, well, it's here in Xcode. It's called Find Sets. You go to the Project Find, you click the Options button, there's a checkbox for search in files and folders, and you can add any folder, add any path to that, and then you can either make a default find set or a custom find set search in arbitrary files and folders on your disk.

So if you want to search user include, if you want to search the boost sources, if you want to search your own set of sources, you can just add them to this list, and they'll be searched. Similarly, in Xcode Preferences, there's something to add your own list of source files for the open quickly mechanism if you want open quickly to navigate to things in your sources in other places.

Finally, there is a favorites bar in Xcode. We don't have tabbed editing or tabbed navigation, but we do have a favorites bar you can add, and you can put selected source files, header files, documentation, even files from outside the project, like your to-do list of things you want to do frequently, and you can just drag and drop them into that favorites bar and then navigate to them quickly. It's a very easy way to jump around to places that you have to go to constantly without having to just have a finder window open on your desktop.

So I want to give you a summary of what we've talked about today. We've talked about what an IDE does and why integration is good in your development environment. We've talked a little bit about some differences between the Xcode IDE and the IDEs you may be coming from or familiar with. We've taken you on a quick tour through creating projects, editing, and building. We didn't touch debugging, but there are a couple of debugging sessions later on in the week that I highly recommend you go to. We've given you some quick tips and tricks for working in Xcode.