Good morning. Welcome to the introduction to the iPhone Developer Tools. This is session 901. My name is Michael Jurewitz. I'm Apple's Developer Tools evangelist. So my job is to work with developers like yourselves to make sure that you're getting the most out of the tools. And we've really got a great session here for you this morning to do just that, to make sure we speed you along in your development, that you understand exactly what you need to do to write iPhone applications. So, welcome to a new day and a new mobile development platform. We really think that it's the best mobile development experience in the world, bar none. Just for a show of hands, I'm curious, how many of you are experienced Mac developers? Just raise your hand.

Okay, smattering. How many of you are new to Mac development or new to iPhone development as a whole? Raise your hands. Excellent, good. All right, so we've got the right audience. We wrote the description correctly. So today we're going to be trying to take you on a tour through the tools, a journey, to make sure that you understand exactly how they need to be used in the development process as a whole.

And if there's three things that you take out of this session, I want you to understand a few things about our tools at a high level. The first is that our tools are streamlined. They're there to help keep you productive, to keep you moving forward in your development. We always want to make sure that we're staying out of your way and allowing you to do your job as a developer.

Our tools are well integrated. We've got a wide variety of tools on the platform, but they all work seamlessly together so that you can transition from writing code to working on your interface to performance analysis without having to switch your mental model or without having to worry about syncing between these different applications. And finally, our tools are complete. On a lot of other platforms, you end up having to purchase things like performance analysis tools or design tools, and we actually provide everything for you out of the box. Thank you.

The real goal here is that when we're done with this session, I want you guys to be able to walk out of this door and get right down to code. Have enough of a working knowledge with the tools that you're proficient to begin writing that next great iPhone application.

So let's start this journey and go through and take you through all the different knowledge that you're going to need to get started. So we'll be focusing on five tools today. And the real great thing about these tools is that these are the exact same tools that we use for Mac development. So if you've done Mac development, a lot of this is going to be very familiar to you.

And if you haven't done Mac development, as much of you have not, this is great because what you learn for iPhone easily transitions back over to the Mac. So first, we'll talk about Xcode, our integrated IDE. Next, we'll talk about Interface Builder, our design tool for your iPhone and Mac applications. will talk about the iPhone Simulator, which allows you to run your iPhone applications on your desktop.

And we'll talk about Instruments, a powerful analysis tool that helps bring context to your analysis to help you better understand how your application is performing. And finally, we'll finish up with another of our performance tools called Shark, which gives you instruction level accuracy in your profiling with incredibly low overhead.

So the journey we're going to take today is going to be through writing code, through testing in the simulator, designing your interface, analyzing that code with instruments, moving that code over to your iPhone, and then finally testing and analyzing on the iPhone itself. So let's start with Xcode. Now since many of you are new, I just want to give you a grab bag of some of the powerful features that we have at your disposal so you understand all that the IDE is here to do for you.

So when you first open up Xcode, you're greeted with a welcome window. It's got a great jumping off point to tons of resources to help speed you along in your development. So things such as links to documentation for the iPhone, or even links to mailing lists that you can rely on your peers and ask questions, and also talk with Apple engineers.

The real focus on Xcode as the IDE has evolved over the years has been to keep you focused on your source code and not force you to get out of that mode. So we've got a very powerful source editor. Like many IDEs out there, we support code completion. So that as you're writing your methods, we auto-complete for you along with parameters to help speed you along and keep you productive.

We also that you've used several times all in the same scope. So we have this feature we call Edit All in Scope, which simply allows you to engage and begin renaming a set of variables right in line in your source and know that it's going to be accurately making this change for you and only in the scope, in your local scope.

We also come with tons of built-in documentation so that right out of the bat you can read up on all the resources you need for iPhone development and keep these in sync with what's on the developer website to make sure that you are always moving forward and always have the most recent knowledge.

Now, along with this, we also make it easy for you to get the information about your projects and about the classes that you're using. So, for example, you can command-double-click on a symbol and jump directly to where it's declared in a header right from within the interface and get to the media information that you're looking for. Similarly, you can option double click on the same symbol and will jump right to the documentation for it in our documentation viewer. These are some pretty nice power user features that you should use in your development to speed yourself along.

We've got a powerful refactoring engine, which lets you make large-scale structural changes to your application with the confidence that you're not going to be changing the logical flow of how your application works. We integrate directly with Subversion, CVS, and Perforce for source control so that you can browse your repositories and integrate them directly into your projects. You'll notice on the left-hand side of the screen that we even show you when you've modified files relative to your source route, for example. And when you've done that, we even provide you with a convenient way of seeing just what it is that you've changed.

Now, even when you go to build, we try to keep you engaged in your editor. So we give you message bubbles on your build errors so that you know exactly where they're happening and can diagnose and fix them quickly. We also integrate the debugger directly into your editor. You'll notice at the very top of the editor you've got a few debugger controls that you can step in, step out, bring up your console, see your different stack frames, all from right within your editor.

What's more, you can do this whether you're using the simulator or iPhone itself. You can also mouse over symbols as you're debugging them, and we give you live information about them, both on the iPhone simulator and on iPhone. You can even set breakpoints and modify their attributes right in your source with message bubbles. So if you need to do something like set conditions or enable or disable, you can do that quickly and easily.

And if you prefer a more traditional debugger experience, we've even got that for you too. So that's a bit about some of the features that we have in the editor to keep you productive. And now I'd like to bring up Rick Ballard from the Xcode engineering team to walk you a little bit through the project structure of an Xcode project. Rick? Thanks, Mike.

In Xcode, new projects are born in the new project assistant. The new project assistant gives you a set of out-of-the-box templates that you can just create and build and go and have something useful to start working on, nothing needed. You're going to want to start out by choosing the template most similar to the sort of application that you want to design. And once you've created it, you'll be taken to Xcode's new project window, or Xcode's project window. This is your hub in Xcode.

You can see this project comes with all the sources needed to build the type of application that you chose right out of the box. A new project comes with one target, seen on the left-hand side in the Targets group. And your target knows how to take that source code that your project has and turn it into your iPhone application.

If you want to add more targets to your project, you can use the new Target Assistant. And in particular, you may want to add a static library target to your project to enable you to share code at development time between multiple applications that you're developing. When you add a new target to your project, it'll show up in the targets group on the left-hand side. Xcode projects are the container for all your source code and related information. And your projects contain their targets. An Xcode target is a blueprint for taking that source code and turning it into one of your products, like a library or an application.

You'll see in Xcode, in the upper left-hand corner, there's an icon that represents your project. Your project provides you access to all the source code that that project manages, and you can browse it, rearrange it, and organize it as you see fit. The targets in that project operate on the project's source code in build phases that process it. For example, a compile sources build phase, which runs a compiler on all the source code files to produce the output.

You can see these build phases contain the same file references that your project vends. Beyond just files and targets, the project window is also your hub for more detailed configuration. If you choose the project icon in the upper left and double click or use the Get Info button on the toolbar, you'll be taken to Xcode's project settings window. Project Settings gives you access to the high-level core settings that affect your entire project.

Likewise, if you double-click or get info on a target icon, you'll be taken to the core settings that affect just that target. Things like what other targets it depends on at build time, so when you build one, the other will build automatically. Or what libraries that target links.

The Build tab at either the project or target level gives you access to Xcode's advanced build property interface for more detailed customization. You can set these properties on the project level to affect all your targets, or you can set it on an individual target to just affect that target. To give you a taste of this, I'd like to introduce Clark Cox. He's going to build us and run an Xcode project from the template.

I'm going to show you what it takes to get started building your first iPhone application with Xcode. I'm going to launch Xcode. Then I'm going to create a new project by going to the File menu and choosing New Project. This is the familiar New Project Wizard. I'm going to create a utility application. A utility application is a program sort of like weather or stocks on the iPhone where data is displayed on one view, and the user is allowed to switch the view to a settings view on the other side.

So I'm going to choose that, name my project, And there it is. It's been created. To show that this is a complete application directly out of the box, I'm going to build and run it by going to the Build menu and choosing Build and Run. Xcode compiles all of my sources, packages them up, links them, launches the simulator.

Because I do not have a device attached, it knows to do this automatically. So here we have the application running in the simulator. All of the functionality you would expect from such an application is there. Now I'm going to go back to Xcode, filter to find my root view controller.

And then use the symbol pop-up to find the toggle view method. This is the method responsible for actually flipping the view. I'm going to place a breakpoint by clicking in the gutter. Xcode knows by virtue of the fact that I've placed a breakpoint that I'd like to start debugging. I don't have to relaunch the application, I don't have to rebuild it, the debugger attaches if it isn't already, and we're good to go.

This time, when I flip the view, I get dropped back into Xcode, and you see my breakpoint was hit. All of the features that Mike mentioned earlier are available to me. I can mouse over and inspect variables, I can step and continue all the things you would expect from the Xcode debugger. Thank you very much. And now, back to slides. Thanks, Clark.

Later this week, we have some more sessions that will go much more in-depth with Xcode. Later today, if you've used other IDEs like Visual Studio or Eclipse, I highly recommend the Xcode for Visual Studio and Eclipse Developer session at 3:30 in Marina. And tomorrow, we have two more sessions that will go into more of the power user features to help you get the most out of Xcode. Xcode is your hub for the developer tools. It's where you'll start, where you'll probably spend most of your time, and you'll find that it integrates well with all of our other tools, leading you to them as you need them.

So we started out by putting together some code, and Clark has showed us how to take that code and launch it up in iPhone Simulator. Let's go a little more in depth on what exactly iPhone Simulator is and how it works. iPhone Simulator is Apple's newest addition to the Developer Tools, and it's designed to get you up and running with your iPhone application as quickly as possible.

You should know that iPhone Simulator is an API simulator. It is not a hardware simulator. When you build your iPhone application for iPhone Simulator, your iPhone application is an Intel binary, and it gets access to all the powerful hardware in your development Macintosh. It runs, your iPhone app runs as another process on your Mac, just like a Mac app.

You may be used to, if you've done any Mac development, AppKit, Apple's user interface framework for Mac OS X. AppKit sits on top of other frameworks, lower level like Foundation, Core Foundation, and they work together to provide the Cocoa Stack for Mac. iPhone OS is very similar. We have a different higher-level framework called UI Kit.

UIKit sits on top of iPhone OS's versions of the same lower-level frameworks like Foundation. These frameworks are for the most part similar, but built for iPhone OS. When you build for iPhone Simulator, you're actually using a hybrid of the two. iPhone Simulator takes UIKit and layers it on top of Mac OS X's foundation and lower-level frameworks. So when your iPhone app runs in iPhone Simulator, it's using a specially simulator-built version of UIKit, but using the same low-level frameworks that all your Mac OS X apps use.

For the most part, this is transparent because most of iPhone OS's low-level frameworks, like Foundation, offer just about the same APIs as Mac OS X's Foundation. So your iPhone app can go from Simulator to iPhone OS and not notice a difference. In a few cases, like Security Framework, Mac OS X offers a different set of APIs than iPhone OS.

When your iPhone app needs to use a framework like Security, you'll want to write code to both use iPhone OS's API and Mac OS X's API. You can conditionally compile this API using a macro like Target iPhone Simulator. So when your code runs for iPhone Simulator using Mac OS X's Security, you'll use one set of API. and when it runs on iPhone OS, you'll use a different set of API, and you can go back and forth with no problem.

iPhone Simulator's biggest advantage is that it gives you incredibly quick turnaround. You can go from debugging your iPhone Simulator app to making new code changes, building, and right back in the debugger with extremely low overhead. iPhone Simulator also lets you use all the great built-in debugging goodness that you may be used to for Mac OS X or you may be about to discover.

Goodness like DTrace, the lightweight system tracing utility which lets you build probes that give detailed information about your process without affecting performance. And it's Zombies, which let you keep some information behind when your objects are deallocated to help you track over-release problems or problems of touching dead objects.

Or GuardMalloc, which lets you easily track down buffer overruns and other memory corruption issues. All these and more are described in TechNote 2124: Debugging Magic, which contains a host of useful tips and tricks for debugging Mac OS X applications that you can apply directly to your iPhone applications by running them in iPhone Simulator.

Once you're up and running with iPhone Simulator, you're going to want to start building your interface. Apple offers a first-class interface design tool, and we call it Interface Builder. Interface Builder supports Koko's model-view-controller paradigm, and in particular, is designed to let you lay out your views and connect them to your controllers.

Interface Builder gives you both reusability and flexibility. Reusability because it makes it easy to share your custom view and controller subclasses and use them as appropriate. And flexibility because it's a great tool for getting up with rapid prototyping and iterating quickly as needed. This is Interface Builder. Out of the box, it's very easy to use and very addictive. Interface Builder offers a "what you see is what you get" style of interface design, where views automatically grow to fit the space as needed and snap into place with smart guides.

In Interface Builder, you're both going to want to choose your views, lay them out where you want them to be, and then connect your objects together. To establish the relationships between your objects and your interface, you use Interface Builder's connections, like here, where we just connected our view object to its controller.

Interface Builder's main document window is your ZIB file. X-I-B, or ZIB. It contains the top-level objects that make up your interface. Your ZIP file contains a set of instructions for instantiating the objects that make up your interface and setting the properties on them to make them behave as you want.

They don't contain the code to make that interface run. Instead, that code comes from UIKit or your own custom subclasses. When you build, your ZIP file is compiled into a Nib file, which is a compiled representation of the instructions to instantiate those objects and set the properties. What this means is that Interface Builder is not a code gen tool. It lets you specify what you want, and the frameworks do all the heavy lifting.

When you start out in Interface Builder's document window, it'll come up in icon view. But when you're developing for iPhone OS, you may find it useful to switch to list view, because instead of just displaying the top-level objects in your nib, it will display the complete hierarchy that makes up all your instances and lets you drill down and set what you want.

Interface Builder's library offers you all the views that you might want to use to drag right into your interface. You can easily filter if you know exactly what you're looking for, or you can use the library's built-in categorizations to help you quickly browse through the different objects that we offer for your interface.

Once you've got an object in your nib, if you inspect it, you'll get properties at the beginning that allow you to specify how your object should behave and how it should look. An overview of all its connections we call outlets and actions, which are the relationships between the objects in your Nib. A smart sizing inspector, which allows you to fine-tune placement and specify how auto-sizing rules will work for when your interface rotates or sub-superviews expand and contract.

and class management. You probably don't just want to use all of the generic superclass objects that come in Interface Builder. You want to write your own custom subclasses in many cases, your own view subclass, for example. And when you do, you specify what subclass of the interface object you dragged in that you want to use in the class field of this inspector. Interface Builder will take your class name and talk to Xcode for you automatically to pull out of the header file what actions and what outlets your subclass supports.

Interface Builder stays in sync with Xcode all the time. So as you make edits to your subclasses, Interface Builder will know and present the new outlets and actions and behave as you would like. Interface Builder is a great way to design your interface. It's really easy to start using. And frankly, Interface Builder is a lot of fun. It's really a cool tool. To show you exactly how much fun, I'd like to invite Clark back up to demo building us an interface. Thanks, Rick.

Okay, I've got a simple project here. I want to design an interface for it. To get started, I'll use the Groups and Files tree to navigate to my ZIP file. If I double-click on that, it will launch Interface Builder. Here we have my main ZIP file. It's a pretty sparse file at this point, where I'd run this application, it would do nothing but display a blank white window.

So we'll have to add some content. The first thing I need is a view controller to manage my views. I'll go to the library, select an appropriate instance, drag it out, and drop it in my document. That instantiates the object, and as you can see, it opens a window ready to receive my view.

First thing I need to do with this view controller. As Rick mentioned, we don't necessarily want to use the generic class offered by Interface Builder. So I'm going to, with the view controller selected, go to the Identity tab of the Inspector. My project has a class called My View Controller.

I'll start typing. And as you can see, Interface Builder knows about that class by virtue of it being in my Xcode project. That's all it takes to change the class of this instance. Now, to add actual content, I need to find a view to place in the view controller, so I'll go over to the library and start searching.

Again, I grab the appropriate instance, drag it out, and drop it in place. As you can see, Interface Builder sizes it automatically from the space available and snaps it in place as I drop it. Now to add some more visually interesting content. In this application, I'd like to have an Edit field in a bar across the top of the view and a table view in the bottom. So I'll go find the navigation bar that I want to put at the top. Again, grab an instance.

Grab an instance and drop it into place. Now for the Edit field, it's the same process. I search for a text field, grab the instance, drop it into place. Now, Interface Builder knows where views can go in this bar, so it does that automatically for me. But I'd rather not have it. I'd rather not have it here on the side, so I'll do it again.

Do it again and drop it into place. Now that view's in place and there's one issue that you may not be aware of looking directly at this view. What happens when the device is rotated? Well, Interface Builder allows me to simulate that by clicking here. Now, as you can see, that field looks awfully small for the space available.

To remedy that, with the field selected, I'll go to the size tab of the inspector. I want to make sure that the field maintains a constant distance from the left, top, and right sides of the field. I also want to make sure that the text field expands when its parent view expands.

Now, when I simulate the rotation again, you can see it automatically expanded to fill the space. Now, I need to add the actual table view. So again, I'll search in the library, find the instance I want, drag it out, and drop it into place. Interface Builder sizes it appropriately and gives me guidelines as to where I could drop it.

Now the interface is visually complete at this point, and if I wanted to see what it would look like on an actual iPhone, Interface Builder allows me to use the simulator to simulate the interface. This launches a test harness in the simulator with my interface. I can interact with it just as I would any iPhone application.

The keyboard comes up when I click the text field. And so on. Okay, so I'm going to quit the simulator now and return to Interface Builder. Now the objects in my nib, or in my zib, need to know about each other. I need to make sure to tell the app delegate which view controller to load, and so on.

To do that, I'll control drag from the app delegate to the view controller and choose the view controller outlet. Likewise, my view controller needs to know about its views. So I'll control drag from the view controller to the table view and choose the table view outlet. And again, from the view controller to the edit field and choose the text field outlet.

Now the table view itself needs to know where to get its data and whom to ask about certain behavior. This time, I'll Control-drag from the table to the view controller, connect the data source outlet, and again, for the delegate outlet. Now, one final connection that needs to be made, I need to tell my edit field what to do when the user has entered some text. So I'll Control-click on the Edit field and connect the Did End On Exit event to my view controller's Add Row method.

At this point, with all the connections in place, I'll Save, return to Xcode, Build and Go, And there's my application running the simulator. I can, again, interact with it just as I would any other iPhone application. and that's how to use Interface Builder to design your iPhone application's interface. Thank you and back to slides.

All right, thank you, Clark. So as you can see, Interface Builder does a great job at helping you create your interface, lay it out on your canvas, and then connect all the logic together to make sure that it actually works. We've got a couple sessions this week planned on Interface Builder to really help speed you along.

So later on today, we have Designing Applications with Interface Builder, which will focus on iPhone development and help you understand a lot of the core principles behind Interface Builder. It can seem like it's a bit of magic if you're not used to tools like this, but it's actually really powerful and very deterministic, I promise. We also have later in the week, on Thursday, Mastering Interface Builder.

So after you've had a chance in the early part of these first few days to get a good feel for Interface Builder, we'll help you kick that up a notch and really take your knowledge to the next level so that you can be the most productive as possible with Interface Builder.

Okay, so we've talked about designing your interface, but now let's talk about analyzing your application. Now, for the large majority of you who are used to doing development in a mobile environment, this is a very important topic, so I'm sure that you're used to. You really need to focus on squeezing as much speed as possible out of the applications that you're running on. And it's the same story on iPhone. Performance is really, really important on the iPhone.

I can't stress that enough. We make it easy to integrate performance into your workflow, and it's essential that you do so to make sure that you're shipping the best possible application for your customers. When you look at it, if you've got two applications that do the same thing, which one is the customer going to pick? The one that's slow or the one that's fast? So really make sure that you're integrating this in your development cycle from the start.

Now, it's tempting if you're used to desktop development to just kind of fall into this lull of, well, the desktop will take care of it. There's lots of powerful hardware out there that obviate a lot of the problems that I might see otherwise. So, for instance, your users might have more memory on a desktop, and you're not going to notice issues such as thrashing or just poor usage of memory quite as much on the desktop. You might have algorithms that are way too complex and don't scale well with additional data. Again, you'll see these on the desktop, but the hardware will often just chew through it.

And there's also wasteful I/O. It's not a big deal on the desktop a lot of the times, although it does hurt. It's a big deal when you start talking about flash memory in particular. So you need to be very aware of these particular issues as you dive in to do performance analysis. And it's important to remember that the iPhone is not your Mac. It's not your Mac desktop. It's not your Mac laptop. It's incredibly powerful for its size. But remember, it's not a 64-bit Core 2 Duo.

So with performance being so important, it's important that you have a tool to help you along the way to make sure that your analysis is both easy to do and comprehensive. So to help you with that, we have a tool that we call Instruments. As I mentioned before, Instruments helps bring context to your analysis. It helps you understand what your application as a whole is doing.

Now, in traditional performance analysis, you tend to find yourself usually looking at one thing. So, for example, you might be looking at the timing of your application, seeing where you're spending time in your call stack. And often, what you end up with is just a series of data along the way. Things pop up, you notice them, you deal with them.

But oftentimes, it's not the whole story. And what Instruments helps you to do is to take data from multiple sources, record them at the same time in your application, and correlate that data together so that you can be sure that you're honing in on exactly what the problem is in your application.

Now the interface for Instruments is really rather welcoming. First, we start you off with a set of templates. We have Mac OS X templates for doing analysis on Mac OS X, and also an iPhone set of templates. And you'll notice we've got some commonality between the two, things such as Sampler, Activity Monitor, Leaks, Object Alloc.

These are all tools that you can use to analyze things like memory, like where you're spending time in your application. But the iPhone also adds a few instruments for you to do your analysis. You'll notice we have a Core Animation Instrument template, as well as an OpenGL ES template. So you can make sure that you're getting the most out of the graphics hardware on iPhone.

So you simply select an instrument from this template, and we populate what we call your trace document directly with that instrument. Now from there, you have a lot of options in configuring the kind of data that you want to get from that instrument. It varies from instrument to instrument, depending on what data is available to it. You can also, though, control how you want to view that data as well. Now, beyond just these templates, we also have a wide library so that you can pick exactly the right tool for the job.

When you start recording your application, you get a live timeline to show you exactly what's happening in your application from these different sources. And again, they're correlated in time so that you can go back and figure out which events happened together. From here, you can select an instrument and data mine deeply into it to figure out exactly what happened. In the case of ObjectAlloc, we can even see exactly where an instance came from in our call site and when it happened. So we can trace down any memory issues very precisely.

So now the best thing about Instruments is that you can still use it when you're using the iPhone simulator. So as you're rapidly prototyping your application and bringing it up, you can still be doing analysis along the way to make sure that you're delivering the best application possible. So there are a few things that make sense to analyze in the simulator and a few that don't. So let's talk about those.

So the first are memory issues. Your memory performance between iPhone simulator and the iPhone itself shouldn't vary too greatly. You're not going to see some object get over-released on the simulator, but not on the phone. So if you find yourself having memory problems, it's completely valid to use the simulator and instruments to track these down.

You can also use the simulator to get rough ideas of the general algorithmic complexity of your application. So if you want to start feeding in large data sets and understand how well you scale with that, you can use the sampler instrument to gain a really good understanding of it.

You can also use Dtrace with Instruments. Now, some of the functionality in Instruments is actually powered by Dtrace, but you can also write custom scripts to get to precisely the information that you want in your application. Some things that don't make sense to profile in the simulator are things such as wall clock time. Again, you're running on the Core 2 Duo on your desktop. You're not running on the processor on iPhone. So your timings are going to be inherently different.

Other things you don't want to analyze are things that rely on just the general hardware on iPhone itself. Things like the graphics subsystem, for example. You're going to want to analyze those on iPhone. Now we make it easy in your project to get up and running with your performance analysis. You can simply go to the Run menu, select Start with Performance Tool, and select one of the templates to jump right into Instruments. And now, I'd like to bring Clark back on stage to give you a brief demo of Instruments in action. Clark? Thanks, Mike.

Okay, here I have another sample project, and I'd like to analyze it in Instruments. I'm going to be searching for memory leaks. So I'll go to the Run menu, choose Start with Performance Tool. And as you can see, here are a list of instrument templates that I can use. I want to use the Leaks template.

Selecting that will launch Instruments, which will in turn launch my application in the simulator. Instruments starts recording data about my application, including the total amount of memory used. Sometimes it needs administrator access. The total amount of memory used, as well as any leaks it's found so far. It'll scan periodically to find any blocks of memory that are unreferenced and therefore are likely leaks. So while Instruments is recording data, I just interact with my application as I normally would.

Add things, remove things, move things around. And there, you see a spike in the leaks instrument. Okay, I'm going to stop my application and go to inspect what was going on there. I select the leaks instrument, and as you can see, a single object, an NS object of 16 bytes in size, was leaked. If I select that object and then click this button to open the extended detail view, I'll see a stack trace of exactly where that object was allocated. This can be incredibly helpful in tracking down these memory leaks.

If I scroll towards the bottom of the stack trace and find the last stack frame that is in my code that I'm responsible for and double-click on that, it'll take me back to Xcode directly to the leak. There it is. Wonder how that got in there. I'll fix my bug. Start with the Performance Tool again. It's time it launches again. Interact with it as before. Delete, move, add. And as you can see, no leak was registered. I fixed that bug. Thank you, and back to slides.

Thank you, Clark. So you can see, Instruments makes it easy for you to analyze your application. So we've got a ton of sessions on Instruments and its related technologies coming up this week. So on Wednesday, we have a session that's getting started with Instruments to take you through a general acclimation to the application so you understand exactly how to get the most out of it. On Thursday, we'll have Debugging and Profiling Your iPhone Application. In that session, we're going to focus specifically on the tips and techniques that you can employ to make sure that you're writing well-performing iPhone apps.

Now, if you want to start taking a look at the Mac OS X side of things, especially in regards to the simulator, we've got a couple sessions this week that are going to focus specifically on DTrace and on Instruments and how it interacts with DTrace and how you can take advantage of DTrace from within Instruments.

So we have Using DTrace on Mac OS X on Thursday and Advanced Performance Analysis with Instruments and DTrace Friday morning. It will be great sessions. I highly recommend that you attend them. Okay, so we've talked a little bit about performance analysis, but now we need to talk about what you all have been waiting for all this time, which is getting your application on the device itself.

So, chances are you've probably got a team that you work with. It's probably not this team, and they probably don't wear suits, but you probably have a team that you work with. Or at the very least, you've got multiple devices that you like to use in your development.

So, the problem is you need to get your application onto these devices. But iPhone development is a little bit different from Macintosh development. You can't just write a development version of your application and send it out to as many phones as you want and have it run immediately. So why is this the case, though? Why is there this limitation?

Well, it's all about protecting our users. It's important that debug versions of both development versions of applications aren't put out there in the wild to put users' data at risk or to put the cellular network at risk in general. It's important that we allow them to make sure that they're using their phone as a phone.

Now, along with this, though, you still have the need of getting your development done. So in order to move applications to the device, there's two things that we need from you. Only two things. We need to know the devices that you want to develop with, And we need you to sign your applications so that we know that they've come from you. So first, we're going to focus on the devices side of the story.

So every iPhone that rolls off the factory line, an iPod touch, has built into it a unique identifier. We call this a UDID or a UDID. Now, this unique identifier you'll be able to find within Xcode. And all you need to do is gather up the unique identifiers for your development iPhones and send them off to Apple so that we know that these devices are going to be used for development purposes.

You can do this quickly and easily through the iPhone Developer Portal. Simply log in. Add your iPhones by adding in your UDIDs and giving them a name, and you're good to go. That's all we need to know about the devices. But now we need to focus on signing.

So, to talk about signing, we should take a step back for a second and really briefly talk about asymmetric key cryptography. Now, please don't get scared. We don't need to go in any depth on this. But it's important that you understand at least the basic principles here. So in asymmetric key cryptography, you've got a private key and a public key. And you hand this public key out freely to as many people as you want.

And you use this private key to do various things, such as sign data or encrypt data. Now, once you've done that, users can later use your public key to ensure that the data is as you sent it, that it wasn't changed while in transit, or use it to decrypt that data.

So when you're signing your iPhone application, you're essentially taking a snapshot of it in time. And you're saying that, saying that I, Michael Jurewitz, swear that the application looked like this at the time that I signed it. And when you go to put the application on iPhone, the iPhone is going to actually check to make sure that that's the case, and that the application has not been modified, at which point it'll launch your application.

So to create these keys that you need, we start with Keychain Access. You'll find this in your Utilities folder on Mac OS X. We simply need to create a certificate request and fill in the appropriate data. After we've done that, we'll actually generate a file that we send off to the iPhone Developer Program.

And what Apple does-- so the question is here, what just happened here? We just pasted this random data into this website. Well, you made a public and a private key when you created this request. And you sent this public key off to Apple. And what we do is make sure that you are who you say you are, that no one is trying to pretend that they are you. And if so, we hand you back a certificate. And this basically lets us tell the world that if you receive this public key, we at Apple verify that it is truly associated with this person.

So with this certificate, you'll be able to download this from the iPhone program portal once it's been approved. If you have a team that you're working with, they'll also submit certificate requests, and you as a team lead can very quickly and easily approve them so that they can get on with their development.

Now, it's especially important that you safeguard these certificates once you get them back from Apple. In Keychain Access, they're all grouped together, but you need to make sure that you are backing up both your private and your public key, and that you do not give these out to anyone. Someone who has your private key can pretend to be you, and you don't want that. Trust me.

Okay, but we still need to get the application onto the device. So the last step in here is to actually create what we call a provisioning profile. And you do that again through the iPhone program portal. And a provisioning profile is essentially a single file that encapsulates which certificates and which iPhones can be used together for development.

So, for example, if Rick and I were on a team, both of our certificates would be in the profile and both of the devices that we use would be there, too. That way, Rick could build and sign an application and I could run it on my phone. I could build and sign an application and he could run it on his.

Again, now one additional step is you'll create also a bundle identifier for either your suite of applications or your specific application itself. And this just uniquely identifies your app so that we can isolate it from the rest of the world for things like preferences in the keychain. Now you download this provisioning profile to your Mac, you drag it to Xcode, and you're good to go.

But we have all these devices now that we have to interact with and we have to use in some way, but we need a tool to help us to do that. So what are we going to use? Well, I'd like to bring Rick back on stage to tell you just what that is. Thanks, Mike.

In Xcode 3.0, we introduced a tool we called the Organizer. And the Organizer is used to manage some frequently accessed source files and do some inline editing for convenience. But in Xcode 3.1, we've taken it a bit further and made it the hub of your device management. This is the Organizer. It has your devices on the left and detailed information on the right. You can get to the Organizer from any time by going to Xcode, going to its window menu, and choosing Organizer.

When you first plug in your device, Xcode will bring up a window asking if you want to use it for development. If you confirm, your device will be added to the Devices list on the left-hand side of the organizer. So here, we just click the button, Xcode has read in what my iPhone is, and boom, there it is on the left.

If we highlight in on the devices section, you can see I have three phones plugged in here, one of which is grayed out. One has a red dot, one has a green. Well, grayed out devices are those that you've chosen to ignore when you first plug it in. You say you don't want to use it for development. So if you've got a personal phone that you're plugging in that you're not doing any development with, say ignore. And when it's plugged in, Xcode will acknowledge that it's not to be paid attention to.

Red phones are those that you have used for development, but don't currently have plugged in. And when you plug in a device that is used for development, it'll show up with a green dot on the left and allow you to edit all the information you want about it.

If you delete-- oh, sorry about that. If you delete a phone from the left-hand side, you can plug it back in and choose Use for Development again or Ignore if you've changed your mind about how it should work. So here, I've just deleted one. And when I plug it back in, the dialog pops back up and lets me decide that I want to use this phone for development.

In the upper section of the organizer, you see some vital stats on your phone, like the name, its capacity, its serial number, most importantly, that identifier or UDID that Mike Jurewitz mentioned. When you need to know the UDIDs of your phone, you'll want to come to the organizer to read them.

You can also find the software version that you have loaded onto your iPhone. And if you want to upgrade your iPhone to a newer version, you can do it right within Organizer by clicking on the OS version pop-up and choosing Other, finding an iPhone software restore file, an IPSW file, and loading it into the organizer. When you do this, the organizer grabs it, copies it in, and will know about it in the future. So you can choose it from the dropdown and click Restore when you want to upgrade to that OS version.

In the middle, we have provisioning information. So that provisioning profile that you got from Apple that you need to use to let you run your apps on your device, you'll want to configure here. When you get a mobile provision file from Apple, if you just drag it onto Xcode's dock, it'll become available for all your devices to use. And when you decide you want to use a given provisioning profile with a given device, all you need to do is check the box, and the organizer will upload your profile into your device for your use.

At the bottom of the organizer, we have a section that lets you inspect the applications that you currently have that you've uploaded onto your device. You can easily add or remove applications here, or you can inspect the application data that each has. If you click the download icon next to the application data, the organizer will let you actually download the applications data folder from your phone and put it right on your Mac.

So here we click it, we choose where we want to save the data file, and once we've done so, the organizer will even add it to the upper left-hand corner where it manages some frequently accessed files for your convenience. That data folder is your application's home folder on the phone. If you look, it contains both a document subdirectory and a library subdirectory, which contains, among other things, your preferences.

So you've got your apps on your phone. You've maybe been using it around beta testing it, out living on it for a while, and maybe your app has a few crashes. You're going to want to get that information back to your developer's tools somehow so you can find and fix your bugs.

The organizer-- we'll get to that in a second, actually. The organizer is also your equivalent of console. So for Mac apps, console gives all the console logging for all the applications running on your computer. For all the logging running on your device, you want to use the organizer, which will show you everything as it goes by, allow you to filter as needed, and save out log files that you may find interesting later.

So when your applications crash, then you want to use the crash logs. When you go to this section, the organizer will automatically download any crash logs that your phone has accumulated since you last plugged it in. And it will automatically try to symbolicate them for you. So instead of having a stack trace with just unreadable addresses, you'll have your nice method and function names so you can easily tell what went wrong.

In order to let the organizers symbolicate your stack traces, you'll want to keep around the binaries and their associated symbolic information files, or .dsim files, for any application that you'll want to symbolicate later. So long as the built binary and .dsim file that is exactly what was running on your phone is somewhere on your Mac that Spotlight can index, the organizer will find it automatically and symbolicate your crash traces.

If an application crashes that you don't have that information available to spotlight in, you'll find that your application stack frames are not symbolicated, and you'll know why. The organizer provides a useful utility for taking screenshots as well. It's very easy. You just click the Capture button, and it records exactly what's on your phone.

If you want to set a default image, click Capture, it records exactly what's on your phone. If you want to set a default image so that when your phone application launches, it appears responsive and comes up immediately, you can also take a screenshot of the image that you want to come up and click the Save as Default Image button in Xcode.

And Xcode will automatically add it to your project for you, so that when you launch your application, your next build and go, that will be the initial image. This isn't meant to give you the ability to add splash screens to your application. It's just so that your application comes up immediately showing the interface that it will use as soon as it actually starts running.

So once we've finished configuring your application in the organizer, we're going to want to go and actually start building and running on the device instead of in the simulator. To do this, you're going to want to investigate Xcode's new overview pop-up in the upper left-hand corner. The overview pop-up gives you at your fingertips access to controls for exactly what will happen when you press Build and Go.

You can change which target you're going to start to build with, what configuration you're going to build, or for this purpose, you can change the active SDK from your simulator SDK to the device SDK. Once you've done so, the next time you build and go, your iPhone application will rebuild for iPhone OS and automatically upload and run on the device.

What if you have multiple devices plugged in? Well, the overview pop-up lets you choose as well. For each device you have plugged in, provision for development, you'll see an executable in the overview pop-up. And to change which device is running your application, you just change which executable is selected. That's all it takes to get up and running with your devices. Let's see how it looks when you want to dive into analyzing on the phone with Instruments. I'd like to invite Clark back up to show us how to do it.

All right, I've got a project here that, as you can see, is configured to build for the device. I'm going to, like before with the simulator, choose Start with Performance Tool. And since my application is an OpenGL ES application, I want to gather some OpenGL statistics about it. I'll launch that. Instruments will launch and in turn, upload the application to my device and start it running.

Even though you can't see this, it is a pretty fun little game. I'll play around, shoot some things, see how it affects the frame rate. Well, obviously something is going wrong here. So, to track that down, I'll come back into Instruments. Going to stop my application. And to focus on the actual problem, I'll option drag and select the region where I had that abysmal frame rate.

Now, as the OpenGL ES instrument was collecting OpenGL statistics, Sampler was also collecting information about what my code was doing at that time. So if I select the Sampler instrument, bring up the extended detail view as before, I can look through these samples and look for a stack trace that looks like I'm responsible for the problem.

Here we see this missile render function is calling NSLOG. It doesn't seem likely that I should be logging from a render function. So, again, I'll double-click on this, it'll take me directly to the source, and indeed, there's my problem. Now, this is obviously a pretty contrived problem, but you can use the exact same techniques to track down real problems in your application, and hopefully getting it running and performant on the device. Thank you, and back to slides.

All right, thank you, Clark. I promise you, we never have bugs like that in our own software. All right, so we've talked a bit about using instruments on the device. There's one tool we haven't talked about yet, Shark. So now, Shark is another one of our performance tools for getting instruction-level accuracy in your profiling, so that as you're doing time profiling of your application on iPhone to understand where it's spending time, you're doing so with incredibly low overhead and high accuracy.

When we look at the Shark interface, it's pretty simple. If you've seen general backtraces or the sample application, it's pretty familiar. In this trace document, we can see on the left-hand side where we're spending time as a percentage of our execution. On the right-hand side, we see the call stacks. We know exactly where we were when that happened and what had called what. So now using Shark for iPhone development is pretty simple, but there's a little bit of setup we have to do first. So we'll go to Shark's Preferences and bring that up.

And then we need to go to our search paths and make sure that Shark knows where to find our source files and our DSIM files, our symbol information. So we'll select our source files and hit the plus button. It'll bring up a little dialogue for us. We'll tell it where our sample application happens to reside.

In this case, it's our metronome application. And add that to the search paths. Now we'll also go to our symbol-rich files and make sure that Shark knows where to look for our DSIMs. Again, we'll click the plus button, navigate to where our symbol files are, and click open.

Now, you can install the Xcode Developer Tools wherever you want on your system. So, if you haven't installed them at /developer, we need to make sure that Shark is aware of this. So you can go ahead and double-click on the path for the iPhone OS frameworks and change the leading /developer to whatever the name of the developer folder it is that you chose. In this case, Xcode 3.1. In this way, Shark will be able to look at the iPhone OS call stacks and understand which symbols in iPhone were being called at that time.

From there, Shark's pretty easy to use. We simply engage Network iPhone Profiling, and we get an extended interface. When we've got the device plugged in, we'll see it listed here in the window. Now, we can use this then to select what we want to sample. In this case, we'll select our metronome application from the pop-up.

We can then select what kind of profiling we want to do. In this case, we're just going to do a time profile, which is just figuring out where we're spending our time in our application. We click Start, we do what we want to do in our app, and we're done. We simply click Stop. Shark comes up and will tell us exactly where we were spending time, and will do so without affecting the performance of your application.

Now, you can double-click on any port in these call stacks and jump exactly to the line and source that's responsible for that call. You can also dig down and see the assembly view if you want to see exactly which instructions were happening at a given time. There's also some chart facilities in Shark so that you can see your call stacks in time and understand general behavioral issues at a higher level.

So that's Shark. Really a very powerful tool. There's an incredible amount of surface area that we don't have time to get into right now. But we do have a couple sessions later on this week and even today to get into that. So for those of you who are experienced with Mac development, we have advanced profiling techniques, performance profiling techniques with Shark. This will be at 5:00 p.m. today in Marina. It's a great presentation if you're familiar with Shark but want to dig in a bit deeper.

and later on this week, we'll have a more introductory session on Thursday, Performance Tuning Your Application with Shark. And this will be a great introduction if you're curious about more of the tool, how it works, and how you can use it for your application. So we've been through a tour of the developer tools and shown you what you need to do and all the tools that you can use for your iPhone development.

You've seen that they're very similar to Mac development, and that they're there to help speed you along and keep you moving forward. For more information, please feel free to email me at [email protected]. We've also got a rich set of documentation, whether on the iPhone OS, Xcode, Interface Builder, Instruments, or Shark. So please see our developer website as well.