Good afternoon and welcome to the Developer Tools State of Union. Over the last year, the Apple Developer Community has grown tremendously and that's of course because we now have two major development platforms, the Mac, and iPhone. As you heard earlier this morning, the iPhone SDK has been downloaded more than 1 million times. It has been truly fantastic to welcome so many new developers to the Apple community.

And it's great to see so many new faces here at WWDC. So in this session, we're going to take a look at what's new in tools. And what's new is that along with Snow Leopard, we are shipping the 3.2 release of our Xcode Tools Suite. 3.2 contains updates to all our applications. Starting with Xcode, our primary IDE for developing native Mac, and iPhone applications. Interface Builder, our graphic user interface design tool. Instruments, our powerful performance analysis tool. Dashcode, our IDE for developing web applications.

And of course the iPhone simulator. Now today we are actually making two distinct releases available to you. Snow Leopard preview and the iPhone SDK 3.0. And both of these work very great together. If you want to try that out, you install Snow Leopard along with it, the tools from the DVD we handed out. And you download the iPhone SDK from the WWDC Attendee portal. Make sure that you're downloading the iPhone SDK for Snow Leopard only package.

So 3.2 is a great release. It has a lot of new, powerful features and to get us started, I'd like to ask Matt Firlik to come on stage and give you a demo of some of the new features in Xcode and Interface Builder while building an iPhone application.

Matt?

Thank you Andreas. So everyone enjoying the conference so far?

OK, this is actually a check to make sure you're awake. Is everyone enjoying the conference so far?

Thank you. It's only going to get better with tools.

You don't believe me?

All right, show of hands.

How many of you have built an application using one of the iPhone SDK 2.0 releases? That's awesome. How many of you have played with the 3.X SDK beta releases? All right, you don't need me to be up here at all. So I'm going to take a little brief journey through some of the new features of the iPhone SDK 3.0 and some of the tools to show you exactly what you're going to be able to get.

So if we're going to look up here on screen here, we'll see a device that's running an application. I like to view it in application. It's called World Jam. And it's a Garage Band like application. And it's built using the iPhone SDK 2.2.1. This application allows you to pick tracks and layer them to create music.

But unlike picking tracks by instrument, we pick them by geography. So on the device here, I'm going to select the guitar instrument, and we'll see it goes to a table view of geographies. I can pick Japan and we can hit the play button.

Play a little bit for us. Let's pick a rhythm track something like South Africa.

And see what happens.

Just like demo with a soundtrack.

You can feel free to dance in the isles if you want.

All right, so let's take an experiment and see what it takes to take this from the 2.2.1 SDK to the 3.0 SDK. So to do that, we'll switch to the demo machine. And you'll see the project I have for this application.

Now the project is just a standard Xcode project. Here is the, we're looking at a source file. This is the TableView controller, you're just seeing a list of geographies. So let's take this and move it to the 3.0 SDK. To that, I'm going to stop the application that's running on the device currently.

And I'll go into the project menu and select edit project settings. That's going to bring up the project inspector and I'll just use the base SDK down here pop up and change that from the 2.2.1 to 3.0 SDK. That's it, we're done. Now, actually, while I'm here, I'm going to edit the project settings and edit the target. What I want to do is take advantage of some of the new functionality of the iPhone 3 SDK, specifically the map view framework.

So I'll keep a plus sign here. And just select MapKit and add that to my project. We'll get to that in a little bit. So now that I've switched to the 3.0 SDK, we have our choice between running on the simulator or on the device. We'll pick running on the simulator first. And let's hit build and run and see what happens. So we build and well we see we actually didn't build. We failed to build. I actually have my project pedantically configured to treat warnings as errors.

In this case, you're seeing the new warning bubbles in Xcode 3.2, which is, they're very streamlined on the right hand side. You can see they show you very, very precise, but terse information. If I hover over them, they show you a tool tip which you know that they don't reflow your code and they stay out of your way.

I told you you're going to like it. You'll also start to see that there's user experience that goes along with them as I start working with my code. So pay attention. Now in this case, it's telling me I have some deprecations. Happens sometimes when we move from 2.0 to 3.0 SDKs and other releases. In this case, I know that the table view cell had some modifications. But I don't quite remember what they were.

I'm going to show you another new feature of the Xcode release. I'm going to hold down the option key with this hand and double click on selected text color. And up pops, what we call Quick Help. And Quick Help is contextually based on demand assistance for APIs. In this case, it's showing me an abstract, but it's also helpfully showing me that this API is deprecated and tells me what I'm supposed to be using.

In this case, I should be using the label attributes on this cell. So let's go ahead and fix that. I'll just delete that API and start typing. You'll see that code completion pops up and I can select the text label. And I'll start typing selected, no that's not the right one.

I think they've renamed it. But that's OK, I can just back up here, the code completion gives me a list of all the available APIs and I see that they've actually renamed it to highlighted text color. So I'll select that one. We'll make the same modifications for the other ones, we need to use the text label, and in this case, we're supposed to be using the image view instead of the image itself. So you'll note when I save, the message bubbles went away. It's giving me contextual information to tell me I made changes to my code, to allow me to see what I still may need to work on.

So, I realize one of the things that would've helped me was if my API was a little more expressive. In this case, my, my variable here is cell. If it had been TableView cell, it would've been much more helpful. What I'm going to do is take advantage of another great Xcode features with this, which is integrated find much like Safari. I'll just hit command-F and you'll see up pops an integrated find bar at the top. I'll start typing in cell and it immediately highlights all the instances of cell right here.

I could also use the find and replace.

And I could replace them if I wanted to. However, I note here there's too many cells. You'll see that it's in comments and it's in the middle of API. I want something a little more fine grained. So I'm going to cancel that and you'll see that if I hover over my instance variable here, there's a little pop up that comes up and I could select all and scope. By selecting this, the editor is going to allow me to change all of the instances.

All right at once.

So, impressed yet? Let's see, let's see if we can build and run now. So it build and run, up comes my application in the simulator. We could go ahead and interact with it too. We can select all of our tracks. Now I'm sure I'm like every single one of you in this room. I write perfect code. My code works every single time, no problems whatsoever.

So I literally do not have a problem to debug in front of you here. What I want to do though is use the debugger to be more playful with my code. The integrated debugger is a really great experience. It allows you to be more playful or especially a little more investigative with code you haven't seen before.

So let's pretend for a moment I've never seen this before and I want to debug what happens when I select a geography here. I'll go back to my code and I'll just scroll down a little bit. You'll see here this implementation of a delegate method which handles selection.

What happens when I select a role in the table view? If you watch, I'll click in the gutter here and set a break point. Now I just started running my application. I wasn't debugging before. But Xcode handles that seamlessly. We've now connected with the debugger. And we'll see that when I go back to my application and select a different item, we now break right in the editor where we're supposed to be.

At the top of the editor, you'll see some streamlined debugger controls. I can start clicking and stepping over to get to where I want. But we've made some other improvements in the editor in the debugging experience in the new tools to allow you to just be very, very focused. In this particular case, I want to be at the bottom of this method.

I want to be at the place where we get the index for the current geography. I could step all the way down, but if you watch the cursor as I go across the gutter here, you'll see that I get a very contextually sensitive continue button that when I click that, so we'll go down right to where I want to be and click that, the debugger jumps right to where I want to be. In fact, it's even better. It will give a step control to step over.

So I don't even need to go back to the top of the editor. I can stay very, very focused. Now in this case, we just got the selected row. And I would like to see what that value is. So if I hover over the instance variable, we see that the index is 3 by the data tips that we're seeing. If I step over again, we'll see that it's going to get the corresponding geography.

And I can use the fact that the data tips will allow me to drill down and see more information. So you can see here, we're going to select the geography of France and the music is French Industrial, if we were to play this. Now, while my code is perfect, maybe my fingers are not. You guys might make me nervous. So maybe I picked the wrong one.

Maybe I really wanted the one above it. The debugger and the integrated assistance here allows us to just grab the program counter and just move it back up. And let's see, I'm still on the selected row of 3, but if I wanted Chile, I could just come over here and just, let's just change the value. We'll go back and now step over. And take a look at the geography again. And you'll see that now we're on Chile. So I just go ahead and start modifying my application as I'm working with it.

Without a problem.

Now, I think it's really important to point out that all the stuff you've seen recently, all the new features in the Xcode 3 tools, I haven't left the editor at all. No extra windows, no nothing going on. We wanted, really wanted to make sure that you stay focused on what's important to you. And we'd like to bring all these features to the editor. So I hope you like those. What I want to do is to actually change my focus for a second and show you some modifications to Interface Builder and take advantage of the 3.0 SDK features.

I'm going to stop my running application for a second here and I'm going to open up the geography do. This is the list of the all the geographies you saw before. You see it's implemented here with a TableView. I want to change this to a MapView. So I'm just going to delete it out of my interface here. And I'll drag the MapView which is now in the library over here on the left, I'll just drag that out and drop it right in my interface. That's it. OK, I may have cheated before. There is some code that I need to make work with this.

There's a delegate class that's already in my project and I want to put that now in my interface file. To do that I'm going to take advantage of one of the new features of Interface Builder, which is showing classes in the library. So now, you can see here a list of all my classes up on the left.

I'm going to filter down to Map and here's my controller that's already in my project. I'll just drag that in and we'll just connect it up in standard Interface Builder fashion, connect the controller up to the MapView so I can place the annotations, connect the map to the controller as a delegate. And we'll just connect up the controller in my interface here.

And that's it, we're done. Now when we run, we should see a map. Now before I quit here, there's actually one other thing I want to show you. Which is this morning you guys heard about the new VoiceOver technology that's available on the iPhone SDK. This is a tremendous revolution for bringing such level of accessibility to a handheld touch device.

So what I would like to do is edit the root view, which is the top view of my application here, with all the instruments. And I'd like to add some accessibility to some of these buttons. They have some default accessibility, but I want to make them a little more specific. So I'm going to select the button in the lower right by my guitar here.

And if I change the inspector, which is on the right side of your screen, to the identity inspector, you'll see that there's a new accessibility section. And I'm going to give this a label. We'll call this melody. And for the saxophone, I'm going to give it something a little more interesting. Let's do.

If I can spell.

And we'll see what that sounds like. So we'll save this. Now we can quit and let's run our application but let's now run it on the device. So we'll click build and debug. Now if we can switch to the device view, you'll see that our application is now going to build for the 3.0 SDK, it's going to be installed on the device, and in just a second, here comes the application, just as we knew it before. Now when I pick an instrument, and see that now we have a map. It's the standard MapView that I can interact with. We can zoom in and drill in. We see we have some flags placed.

There's a flag in Texas. Any Kelly Clarkson fans in the audience?

It is very lonely up here. OK, so we're going to.

We're going to scroll over, something maybe a little more appropriate. We could pick Germany. I think Andreas will appreciate that.

So we could pick that and get a little bit of music for us here.

OK, so we're going to go back to the top level view and what I'm going to do is enable VoiceOver so we can see what this looks like. I'm going to enable this through iTunes for a second so I don't have to switch out of the application.

But in a second, you'll hear.

VoiceOver on.

VoiceOver is on.

Jam session.

It starts speaking to me. I can actually select one of the buttons and the ones I haven't configured will just have a default label.

Button. Button.

If I pick the guitar, you'll start to hear the configuration.

Melody button.

And of course if I pick the saxophone.

Let's get this party started button.

So you see, just like that, it's very, very easy to configure your applications both with MapKit, with VoiceOver and other functionality and take advantage of a lot of the great features in the SDK and the new tools. So I hope you have as much fun as we do and rock the house.

Thank you.

Thank you Matt. So the two applications you saw most in this demo were Xcode and Interface Builder. And the new versions of both of these applications contain a ton of improvements. We've really tried to listen to your feedback and implement the most commonly requested enhancements. To give you just some examples, Project, project by define time in Xcode is now up to 2 1/2 times faster. And we've editor command to rename entire projects.

Interface Builder.

Interface Builder can now copy and paste connections and bindings and of course as you saw, it supports all the new iPhone SDK 3.0 features like MapKit and accessibility. And there's a ton of features just like that in both of these applications. There's just one area I want to touch on explicitly and that is the source editor in Xcode because that's of course where you spend most of your time during development. In the Xcode Source Editor has really come a long way. It offers everything that you would expect from a great IDE. And in Snow Leopard, we've even added a new font that is specifically tuned for the purposes of coding.

It's called Menlo and it makes your source look great. Now one thing I feel very strong about is that the source editor needs to be the focus point of your work. And so we designed a number of workflows that make sure that you never have to leave the context of your editor while performing most of your development tasks.

You saw an example of that in the demo when Matt was able to do all of his debugging right in the editor just with the aid of the small debugger bar that comes down from the top of the editor. And the data tips that show you variable use just by hovering with your mouse pointer over your source code. So in Xcode 3.2, we've added find and replace in a similar fashion.

So the new find works just like Safari's. It shows you all occurrences of the search string at once and it calls of course in Xcode we went a step further in the editor case and the define bar as well. New message bubbles are also a vast improvement over the earlier releases. They are now much more compact and less intrusive. They don't reflow your code anymore if they can avoid it. And they even dim out if you edit a line of code to indicate that you've already addressed the problem that was reported.

The new Quick Help pops up right in the editor with answers to the most common API questions. And if you want to know more, you can use of the many links the Quick Help window to jump right to the new documentation window, which has also been completely reworked.

It's now much cleaner, it's faster and it's easier to use.

So those were just some of the improvements in Xcode and Interface Builder, our tools for developing Native, Mac and iPhone applications. Let's now take a quick look at developing web applications for which you of course use Dashcode. Dashcode started out as a tool to develop dashboard widgets. And last year, we added support to develop iPhone web applications as well.

This year, we are taking it a huge step further by expanding Dashcode in multiple directions. First of all, you're now going to be able to not only develop applications running in Safari and the iPhone, but also applications that run in Safari on the Mac and PC. Secondly, Dashcode now supports the new HTML5 and CSS3 standards. Which means that the Dashcode JavaScript parts can make views of CSS animations and effects, media texts and offline storage APIs. Third, and this is a big one, we are adding support for automated data sources and data bindings.

Similar to the Cocoa bindings mechanism that some of you Mac developers might be familiar with So far, what you had to do if you wanted to get data from a data source into the user interface of your application, you had to write a bunch of JavaScript glue code.

By going forward with Dashcode, developing programming user interfaces is going to be a lot easier because we will be able to replace all this JavaScript glue code with the use of automated controllers and data bindings that manage the content of your UI for you. So here's how that works.

You just enter the URL of a data source in Dashcode. Dashcode will then go and parse the data source and show you the structure of the data so that you can graphically wire it up, right to the elements you use in interface. So using data bindings is very quick, makes it very quick to pull together a user interface in Dashcode. And it's especially useful in another new feature which is that applications in Dashcode going forward can contain multiple versions of their user interface.

So you can develop out of a single application that runs on Safari in the iPhone and Safari on the Mac and PC, just one application for all target platforms. And to show you all of this I'd like to ask Max Drukman to come up on stage and give you the second demo.

Thank you Andreas. Good afternoon developers, developers, developers, developers.

Now, some of you may be wondering why you should build a web app in the first place. Well, it's pretty simple. Web apps are a great choice if you have constantly updating content that you want to deliver to your users in a way that's quick and easy to build, easy to maintain and can be updated at a moment's notice. That's where Dashcode comes in.

Let's have a look. Now before we have a look at Dashcode, I just want to show you my content. It's a RSS feed of recent Mac hardware. Each item in the feed is one piece of hardware and each item has an image. Pretty simple stuff, but that's exactly what I want to deliver to my users.

Now, that's my content, but this look isn't what I'm going for. That's why I designed a custom interface. Now this is what I want my users to see when they come looking for my content. So the question is how do I get this content into this interface? There's an app for that.

It's Dashcode. Let's have a look. So here is that very same interface in Dashcode where I designed it. It took me just a few minutes. I built it out of Dashcode parts. It was very easy to do. The only thing missing now is my content.

And I'm going to show you just how easy it is to get your content into your interface in Dashcode. I'm going to bring up the data sources view. And select the data source that's already there. There's nothing in this data source right now because I haven't pointed it at my feed yet.

All I need is a URL, have one right here. And go ahead, thank you. Now what just happened? Well, Dashcode went out, it fetched my feed, validated it, parsed it and now it's showing it to me. Both the structure and the content. Let's look a little closer. The channel that's RSS speak for the feed, contains items, each item is one piece of hardware and each item has an enclosure that includes URL of the image for that item.

So because Dashcode presents me both structure and content together, I can actually cycle through the items and look at every single bit of data in this feed so I know exactly what I have a hold of before I ever start binding. But let's go ahead and start binding. And this couldn't be easier. First thing I want to do is I want to bind the title of my feed to the title of my web app.

And that's as simple as drag and drop. Now Dashcode is presenting me a number of choices for which attribute I want to bind. In this case, the text attribute, that's it. I've made my binding. The UI is updated to show me that the binding has been created. So that was kind of fun, let's do some more.

I want to take the title of each item and I want to bind it into the list. So that each row of the list represents one piece of hardware in my feed. And again, I drag and drop. Now this time, as I make the binding, I want you to keep your eye on the data sources view. What just happened? Dashcode created a new data source for me, but why? Well the reason is that lists in Dashcode manage their own content and most importantly, they manage a selection within that content.

So that means that the list itself can act as a data source so that when the user makes a selection in that list, that selection can be used to drive content into other parts of my UI. And that's exactly what I want to do. So if I go to the list data source now and start binding from it, that means that a selection in the list is going to drive that content into the detail area to the right of my list.

So again, I'm going to bind the title. Easy enough. I'm going to bind the image, this time to the image source attribute. And now all I need to do is bind the description. Now because Dashcode is showing me content along with the structure, I can see that there are HTML tags in there. So that tells me that I want to bind instead of to the text attribute, to the HTML attribute so those tags get honored as formatting and don't show up as plain text.

So now what else do I need to do? Nothing. There's no step three. I hit run and here comes my interface with its content. All in place just because of Dashcode bindings. Now I make a selection in my list and you can see the detail view updates. Everything's working beautifully, it's all in a split view.

Thank you.

And I even get a nice sexy CSS3 reflection on my images thanks to Dashcode. But of course, there's one more thing. Sorry Steve.

As Andreas mentioned, Dashcode also supports the ability to have interfaces for Mobile Safari. And I went ahead and I created an interface for this web app for Mobile Safari as well. Now it started the same way that the Safari version did, with a list.

But I, I'm making this one a little bit different. Inside the list is a part called a stack layout. Now stack layout is a really cool part from Dashcode that manages multiple subviews and flips between them with nice animated transitions. That's exactly what I'm going to set up right now in the Dashcode Inspector. So Dashcode allows me to have both 2D and 3D transitions and in fact, I'm going to choice the flip transition. Now the flip transition is the exact same transition that Dashboard Widgets use to flip from front to back.

So I'm going to have that style now in my web app. So just as before, we need to do a little bit of binding. Now you've already seen me do this. So let's see how quick it is to do if I don't have to stop and talk about it. So let's do that. Get my enclosure. I guess I am talking about it. Now I'm going to flip to the other view.

And bind here. Now once again, is there a step three? Nope. Hit run and this time, the simulator is going to launch. Mobile Safari, here comes my content. All thanks to Dashcode bindings. Here's my list. If I click on an item, it flips over now to show me the detail view.

Flip it back. There it is.

Pretty cool.

So there you have it, two interfaces, one for each platform inside one project all, both linking to one data source. So you saw in just minutes I created a web app that works for both Safari and Mobile Safari in Dashcode. You should give it a try yourself, you'd be amazed at how easy it is to make beautiful, powerful web apps in Dashcode.

Thanks, enjoy the rest of the show.

Thank you Max. So now that we are familiar with the basic workflows for creating both Native and web applications for Mac and iPhone, we're going to use the remainder of the session today to look at how to get the most of our tools and how to build really optimized applications. And we're going to start by just taking a look at processor architectures.

One of the things that is unique about our tool chain is that it makes it really easy to create single application that runs on multiple different processor architectures. What you see here on the slide is a simplified file system layout of a typical Mac application. The executable in there contains the machine code of the processor architecture that you choose to support. If there's more than one, Xcode will simply build them independently but then merge them together into the same executable.

So of course, this makes your application a little bit larger. But notice that none of the resources had to be duplicated. So in practice we find that most applications only grow by about 25%. That makes it ideal to make sure that end users have the best possible experience because you as application developers can distribute one single package, not multiple packages, one for each processor architecture, and end users don't have to worry about where to install which package.

The same application runs on all their systems. So if you've been a Mac developer for the last several years, you're of course already familiar with this technology. Because we've been using it for years now to support universal applications that run on all Intel and PowerPC Macs. But going forward with Snow Leopard, which we often run in 64 bit mode to make the best use of the modern processor capabilities, you will want to include an Intel 64 bit binary as well so that your application too can make the best use of the modern hardware capabilities. And the same technology is now going to become important for iPhone developers as well.

We are now shipping the third generation of the iPhone. And while the first two generations used a processor that was built on the RD6 instruction set, the new iPhone 3G S has a processor that supports both the RD6 and the RD7 instruction set. So why applications that are build for the RD6 instruction set which should be run on all iPhones and all iPod Touches out there.

If you have an application that is performance sensitive, you will want to start including an RD7 version of it as well so that it runs most optimal on the iPhone 3G S. So to build your applications, you need a compiler. And the new default compiler for both Snow Leopard and the iPhone OS 3.0 is GCC 4.2. 4.2 supports all the new features that the new OS has introduced.

So on the Macintosh side, GCC 4.2 has support for the new blocks technology. And on the iPhone side GCC 4.2 supports code generation for ARM v7. And generally GCC 4.2 creates better optimized code than its predecessor GCC 4.0. And GCC is the very mature compiler, everyday it's used to build millions of lines of code for both Mac and iPhone.

But we've also been working on a much, much more exciting compiler technology. Of course I believe I know what you think if I use the term exciting new compiler technology. You probably think we are crazy. But I think today I can change that perception. Because we have some fantastic announcements around LLVM.

LLVM stands for Low Level Virtual Machine and it's a new compiler technology that we've been working on for several years now. Here's what we've been doing with it. If you look at the architectural volume of a compiler it's typically distinguished between the so called front end, which is essentially the parse of the compiler and the so called back end, which is essentially the code generator.

What we've done last year is that we've given you an alternative back end for the Mac in the form of LLVM. And this year we're taking the next step and we're introducing our new front end as well. It's called Clang and at this point in time it supports Objective-C and plain C. And we've seen some stunning results with this new compiler. And to tell you more about why it is such a promising technology, I'm going to hand over the stage for a moment to Chris Lattner who is the principal architect of this technology.

Thank you everyone. I'm thrilled to be here. Compilers are really exciting despite what some people say and you know it is a very exciting time for compilers here at Apple. So I want to tell you a little bit about what LLVM is, why we're so excited about it, and what we're doing with it.

So you may be wondering why do we need new compiler technology? And in particular, why are we investing in compilers? Well compilers are really interesting for two reasons. Alright? They're often unappreciated, right? The thing that gets in between you writing your code and you running your code, but they're also really important. A compiler sees all the code going through the system.

That means that if we can make an improvement to the compiler, if the compiler can get better and produce faster running code, that means that all the applications that go through it can potentially be faster running. This is great. The compiler also has a huge amount of information about your program. This is information like data flow information, control flow information.

It means the compiler has a really good idea of what your program is doing and this is really powerful if we can use this information to make our tools better. So as many of you know we've been using GCC for many years now. Well GCC is a great compiler.

I mean, we've shipped many applications using code compiled with GCC. However GCC really isn't able to accomplish the things that we need to do. We can get nice evolutionary improvements, you know 5 percent here, 10 percent there. But we're at the point in our tool story where we're ready for something really revolutionary and time to start pushing for it.

And that's really what LLVM is all about. So LLVM like GCC is an open source project. In fact it's been a very popular open source project with a lot of contributors and we're really excited to see it grow. You can go to the LLVM.org website and read all about it if you're interested.

But more than just picking up an open source project and contributing to it, I'm happy to say that at Apple we've picked up an open source project and started driving it. We're really setting the stage for an amazing new set of compiler technologies here. This is not just the boring, you know, compilers they've been using for 30 years now, this is some really great stuff.

So why is it different than these previous compilers or really any other compiler out there? Because there are many other compilers, more than just GCC. Well LLVM is all about performance. So performance is really crucial both for code generation but also for things like parsing code because compilers really do get in the way between you writing your code and you running the code.

And if it takes a long time to compile your application, that sucks. We want fast compilers, we don't want slow compilers, right? So beyond that. Thank you. Woo! Beyond that we also want really great performance coming out of your applications, right? We all want really fast apps. And fast apps can be helped and can be made possible through a compiler technology.

Well LLVM is very different than a lot of compilers that have existed for decades, right? There's no baggage. That means we can use the best algorithms, we can use the best design, we can take the best technology that's been developed over the last, you know, one or two years much less 5, 10, 15, 20 years and apply it to the problem.

Beyond just building it well and using the right techniques and tools and all that geeky compiler stuff in there, the one thing that makes LLVM really different than any other compiler that I'm aware of is that it's built as a set of libraries. Well what does this mean? I mean, you know what library based design is, right? The entire Apple framework stack is built as a set of libraries.

This is not something new. Well for some reason, compiler people throughout the world seem to think that a compiler is your application as one executable. It's not something that you can take and reuse and do different things with, right? The compiler is something that you put code in and you get machine code out. Right? I think that's garbage.

We want to be able to use compilers to do great things. That means we want the compilers to be modular, we want to be low memory profile, we want it to work just like the Apple framework so that we have, that do everything else on the system. Because as compilers we want them to be language independent.

We love C and Objective-C and C++ but who knows what language might come down the pike in 5, 10 years. Also Apple supports many architectures. We support, you know, PowerPC and Intel and all kinds of different things and there's more architectures that are becoming interesting over time. So we need to support all these different things. Well I'm very happy to say that all the pieces are coming together. LLVM has really matured over the last year and we have some exciting things to tell you about.

So what can we do with raw technology? Well the first perhaps the best example is OpenCL. You've heard a lot about OpenCL today and maybe in the past. OpenCL is a great new way to compile and run your code. But it's more than just that of course. OpenCL is really about building kernels of computation that run both on CPUs and GPUs. These kernels are then load balanced and executed on all the compute cores you have at your disposal. This is ground breaking stuff, right? This means I can write one piece of code and have it be executed on many different compute devices.

Well there's lots of processors out there, right? Some have SC2, SSC3, there's many different GPUs out there. And these all have different capabilities, how are we going to take advantage of that? The answer is LLVM. LLVM works at runtime, it works on CPUs and GPUs, it supports fully general languages like OpenCL which is basically C with enhancements. Not some watered down graphics language that you might be familiar with in the past.

And beyond everything else, OpenCL is all about performance. If the code coming out of the compiler isn't as fast as possible, then it's not going to work. Because you're using OpenCL to get performance. Alright? So LLVM is really the thing that makes OpenCL possible and it's really exciting to bring this to the world because we think it's going to have a groundbreaking affect on the whole rest of the OS. Now you may also know that OpenCL is not the first place that Apple's been using LLVM. OpenGL is an API, it's a very popular API for doing graphics programming. OpenGL has been using LLVM for many years now.

And this is not something that you yourself can use like OpenCL, its hidden implementation detail, right? But the OpenGL library stack uses LLVM in ways that accelerated its own internal processing. So when you go to upload a texture to the GPU, it uses LLVM to runtime generate code that handles the conversion of that to, the texture that you give the GPU to a format that GPU recognizes. Alright, so JITs, Just in Time compiles a little bit of code that handles that conversion to make it execute as fast as possible. Well it does more than just that, it handles pixel shaders and vortex shaders and vortex submission and all kinds of different things in OpenGL.

And the great thing about it is that LLVM makes it really fast. So OpenGL, our implementation has existed for many years that had a previous Just In Time compiler that LLVM replaced. Well, by switching to LLVM the OpenGL stack was faster, better performance, the architecture was more flexible because they had a better design they could build and use in different ways, and they got support for new architectures.

One in particular was Intel 64. I hear its popular today. So LLVM is a great set of compiler technologies and as a set of pure technology there's a lot of things that we're doing internally at Apple with it. But the things, potentially the most interesting to you as developers is its use in compilers. And so to talk about compilers in Xcode I'd like Andreas to come back up and tell you a little bit about what we're doing.

Thank you.

So LLVM and Clang are going to allow us to innovate in a lot of technology areas. And the way it's going to affect you the most directly is by building your own projects with them in Xcode. So let's see what they bring to the table. The three things that make a compiler great are first of all that they generate fast code, secondly that they build projects very quickly and third that they give good diagnostic messages.

Let's take a look at how LLVM and Clang hold out. This chart shows a comparison of code generated with LLVM and code generated with GCC and running a number of performance benchmarks. What you can see here is that LLVM generated code runs between 5 and 25 % faster than GCC generated code. 25 % is huge. Keep in mind that many of these benchmarks have been hand tuned for years, so getting 25 % simply by switching the compiler is simply fantastic. So we're very happy with the speed of generated code from LLVM.

Let's take a look at build times. This is a chart that shows the last year. It shows how project build time decreased over the last several years through a combination, through improvements in both hardware and in software. What you can see from this graph is first of all that they really care a lot about build times because we know that build times have an immediate impact on your productivity.

The other thing is, that we have, what you can see from this graph is that is has become increasingly hard for us to have breaks of improvements in build times, something like a 10 % improvement per year has become a hard step for us to take on top of GCC. So let's take a look at what 10 % do to the build time of a project like Xcode. Xcode is a fairly large Objective-C code core application and our latest and greatest hardware is built in a little less than seven minutes.

If you would only get the normal 10 % building Xcode would still take more than 6 minutes. Well if you built the same project now with Clang, this is what happens to build time. Building Xcode with Clang is more than twice as fast than building it with GCC and this holds up for pretty much every project we try it on. Here's just a sample of several projects in Snow Leopard. Very consistently we see that Clang is more than twice as fast than GCC. So we have fast code.

So we have fast code and we have fast builds. Let's take a look at help and diagnostic messages. Here's an admittedly very senseless piece of code, but conveniently it contains two errors. If we run this code through GCC, it will correctly find these two errors and this is how it would be reported to you in Xcode. Well these error messages are certainly correct.

But I think in this case they are also remarkably unhelpful. I don't know about you, but I can never remember whether I have to start counting at zero or at 1 to get to the argument that caused me a problem. And the other case, just by glancing at this line, I see at least four plus signs.

So I can still design all day long, this error message does not tell me where I have to start fixing my problem. So this has been bugging us for years and we've tried to greatly improve on this with Clang by integrating it much more closely with the Xcode ID. So when you build the same piece of code with Clang and Xcode, this is how error messages are reported to you.

Let me zoom this up for you. Xcode and Clang point you right to the expression that caused the problem. There's no more guessing around and no more counting when you build with Clang.

So you have fast builds, you have fast code, and we have better error messages.

Quite an attractive package for you to switch your compiler from GCC. And if you want to try it out, we've made it really easy for you. All you have to do is go to Xcode, find the Build Settings Inspector, and the Compiler Version Base Setting. And then switch the popup to the compiler of your choice. The first thing you should know about all our compilers is they're fully binary compatible so you can now return, you mix and match code with the GCC and code with LLVM and Clang.

The first thing you should do if you have an Objective-C or C project, should switch to the Clang LLVM base setting. Now one thing to know is that Clang is still a fairly new front end. So it does not yet implement all the little features that GCC has piled up over the many years of its existence. There's a chance that Clang might not build your code. But if it does, this is really the best choice because it gives you the fastest page times and the best code because it uses LLVM as the back end.

Now if you run any of these edge cases I just described or you have a C++ project, you command that you still switch to the LLVM GCC Compiler which gives you full source code compatibility with GCC but it gives you a better code generator in the form of LLVM. So this is all the story on LLVM and Clang and I used the term new compiler technologies several times now, so I'm sure you're wondering is this technology really ready for you. Well I wouldn't ask you to do anything that I wouldn't do myself.

And so let's take a look at which applications in Snow Leopard on the DVD that you hold in your hands are already built with LLVM and Clang. We started out switching projects internally just a few months ago. And we started with a fairly small project, Property List Editor. It went very smoothly and so we took more and more aggressive steps and picked larger and larger applications, AppleScript Editor, Automator, Dashcode, and Interface Builder.

And I'm pleased to tell you that we didn't stop there. Even the Xcode that you hold in your hands is built with LLVM and Clang. So if we can build all these applications, I bet you, you can build yours as well. And I think you should give it a good try if you have a quiet moment.

So once you've compiled your application you typically want to debug it. Let's take a look at our debugger. With a powerful debugger integrated right into the Xcode IBE, you saw the Editor Center Workflow in the demo earlier today, and from advanced cases, there's specific debugger and console windows which can bring up.

One of the best things about our debugger is it can work as a remote debugger. And that's of course what all you iPhone developers use on a daily basis to debug your applications natively on an iPhone or an iPod. Now we also added the feature to support on demand processes, debugging on demand processes. They're more and more types of processes that go through different kind of code paths when they launch, depending on the type of signal that caused the launch. iPhone push notifications are a great example for that.

Depending on the type of notification that arrived, there are different kind of code paths that executed when your application launches. Xcode can now launch your application in a special suspended state which allows the debugger to attach early on before any code is executed. You can set break points, and then cause the right signal to go through the code path of your choice.

If you want to try it out, just go to the Executable Inspector and click on the Wait for next launch checkbox, it's that easy. Next performance tools. The flagship application of our performance tools is instruments. Instruments is a very powerful performance tool that allows you to collect data from multiple different kind of data sources at the same time and to display the status side by side, in a GarageBand-like timeline view.

So seeing it there side by side allows you to spot interactions between different subsystems in your application. They will be hidden if you would just look at the data in isolation. And best of all, there is no need to prepare your application in any special way to use it with instruments.

You can run instruments against any application in your system. So we support a number of different kind of data collectors ranging from CPU usage to graphics, memory, network and file system activities. Even proofed on many of the instruments that you're already familiar with from the last releases, we've added a few new ones specifically for Snow Leopard so that you can work with Grand Central Dispatch, and so that you can monitor threads, the instant off state, and zombies in your applications.

Now there's another performance tool that many of you like to use and that is Shark. Shark is a very powerful low level performance tool. It's a CPU profiling tool that has very low overhead and so it's ideal for very fine grade sampling. For the last year we've been working very hard to bring these two technologies closer together.

And we're doing that in the context of the Instruments application. So in the new world of Instruments, you will find a number of advanced analysis features that you might already know from Shark. For example, annotated source code viewing or call tree charging, or best of all, we've taken the core of Shark and refactored it so that it could be used with Instruments as well. And in that process we made it even better so that the new time profiler instrument gives you the lowest overhead ever. To show you, here's Steve Lewallen.

Thank you Andreas.

Good afternoon. Just let me get this straight, Matthew was happy to be here because apparently he writes perfect code and Max was happy to be here with Dashcode because he didn't have to write any code, I think that means I just got stuck with the buggy, whooped, bad performing demo code.

Shoot. Well luckily I have Instruments, and Instruments in Snow Leopard has a lot of great new features that are going to help us diagnose the issues in this demo code and have them running just as good as the other apps. Let's go ahead and look at the demo application now and I open it up in Xcode and I'm going to build and run it.

Now what this app should do is, when I hit the enhance button at the bottom of the window, begin to enhance or brighten up the images you see before you now. This is happening excruciatingly slowly. This application has a severe performance problem. Well here I am, I've run the app from Xcode, I'm face to face with my performance issue. And I'd like to know what's going on inside of that app.

Well I can do that using that time profiling technology that Andreas mentioned earlier. Now pay attention to the center of the screen. I'm going to point my mouse cursor at my app and hit the global hot keys control option tilde. Now what just happened? And equally as importantly what didn't just happen? Well because I have instruments on my doc, not running, just in my doc, I'm afforded a minimal UI, a set of global hot keys and a few menu items to trigger that time profiler in the kernel.

When it's done the data's extracted from the kernel and saved to disk. So put another way, I just used the next generation of what was already a low overhead time profiler, and then we took it the next step by not even requiring you to have a performance application running while you use it. Now the Shark Instruments was running before, during or after that time profile? You asked for low overhead time profiling and you got it.

So let's go back to the application and let's stop it. And now let me direct your attention to Instruments running inside of the doc. It's not running, but it does have a red attention bubble. Let me click on that and I can see that I have a recent time profile.

So I'm going to select that now, now Onstruments finally starts and what is Instruments telling us? Well it's saying that we're spending about 27.4 percent of our time in OBJC message send. Now that's part of the Objective-C runtime that's responsible for dispatching the method calls that you make.

And the only way to get that kind of a number in that API is to dispatch a heck of a lot of method calls. Well let's keep that in mind, put it in the back of our head for a second and in the meantime let's go ahead and use another new feature of Instruments in Snow Leopard, library data mining, in order to remove this noise from what will be the problem in our own code.

So I'm going to right click on our, or control click on that and say charge symbol to color. So what's happened? Well I've taken the time I was spending in OBJC message send and I've attributed it to all the colors and then I've removed it from the call tree itself.

But I want to accelerate this process, so I'm going to click on hide system libraries, and now I'm getting the right to my own code. And I can see of my own code that was executing at the time, 98 and a half percent of the time was spent in enhance image rep using histogram mend value. Well this is basically where instruments before Snow Leopard, instruments and before, would've left us. We'd know what the hot call frame was but we wouldn't know why it's the hot call frame.

What exactly could be going on inside of that API to make it take up so much time? Well that's no longer a problem in Snow Leopard. Now we can go right to the source of the issue literally. So let me just make some more room here, double click on my symbol, and great. Now I see line by line where I'm spending my time in this function call.

And we can see for example that we're spending almost 8 % of our time creating a new color and doing some other miscellaneous things but we can see that almost 50 % of our time is spent fetching NSColors pixel by pixel out of these images. Well I have hundreds of megabytes of image data in my demo. So this explains why we're sending such a large number for OBJC message send. Well I have a better way to write this.

So I'm going to go to Xcode and I'm going to replace the API we saw along with its sibling API that operate on this image data at a high level, I'm going to delete that, and I'm going to bring in a more efficient version. Now this new version of the code still goes over the data pixel by pixel but it gets at the raw bitmap data and then use low level operations to modify it. So I'm going to save and build that.

Now let's go back to instruments for a moment and let's look at the threads user. Well this shows that we only encountered one thread during our time profile. We already know that this is a compute bound task, we optimized it but it's still going to be compute bound. And we know we have these discreet units of work images to process.

Well I have this powerful Mac Pro on stage that has 8 cores, 1, 2, 3, 4, 5, 6, 7, 8, 8 cores on it. And I'd love to be able to distribute my work concurrently across all of those cores. Well this case screams for using Grand Central Dispatch. So let's go back to Xcode and do that now.

I'm going to close that file and open up my enhanced controller. Now at the bottom of that, I have this little API called Enhance. And this is what's called obviously when I hit that enhance button on the screen. So I'm going to go and delete that. And I'm going to bring in a new version that uses Grand Central Dispatch.

Now, what's this new API going to do? Well it's still going to go over the images one by one, but it's going to dispatch asynchronously to the concurrent queue an operation to enhance my image on a thread of the kernel's choosing. And then it's going to asynchronously dispatch to the main queue which will be the main thread a small bit of code to update the UI. Great, let me save and build that.

So whenever you take some code and you're trying to break it up into concurrent operations, you should do as they say and trust but verify. Because it may be the case that you're using a framework for example that has a global lock or maybe your operations are somewhat I/O bound or there's some other condition that's precluding you from achieving the concurrency that you were seeking.

Well another thing that's great about Instruments in Snow Leopard is that simultaneously with this great technology such as Grand Central Dispatch we released Instrumental to help you analyze how you're going to use that technology. In this case we call it the multicore instrumentation and we can use it now to see if we've achieved concurrency with these changes. So what I'm going to do is go up to the run menu and say run the performance tool multicore. So all the instrumentation is starting up and my app is going to start up here in a second.

And now let me hit the enhance button again. Wow. Those things really moved a lot more quickly. And they were enhanced out of order. I don't know if you noticed that, but that enhance that we've achieved some bit of concurrency, but let's go back to instruments now and verify.

So I'm going to find the detail view in Instruments just for a moment. And I'm going to explain to you what we're seeing. This is the first instrument thread states, and it shows many threads were created approximately simultaneously and what I want to do is see several things running at the same time. Well, great.

We saw that and that says that we did have things running concurrently. Now let me go to the dispatch instrument and go to the blocks view, this third view. I'm going to search for enhance which will be part of my block name. Great, so I see two groups of 20 blocks each, 20 images, 20 bl ocks.

The first group was processing the image, enhancing it on some other thread and the second group was updating the UI. Super, so we did achieve concurrency and all of our blocks are processed. Excellent. So, let's go back to the app and let's look at the third and final issue I want to diagnose with Instruments.

The problem is that if I click on an image and I try to put it back, it crashes. Well if we look at the crash report, I have this somewhat unhelpful message saying that I sent something to a read object. Well, what this is saying is that I have messaged an over released object.

And the jargon we use for that is zombies. In this case, we have sort of a half live, half dead state. Our objects have been deallocated, but we have a live pointer to it. We use it, we crash. Well the vital data to track down with this is the pointer and that retain release auto release history so we can see where that imbalance was that caused it to be over released.

Now I could diagnose this pre Snow Leopard, but it was a very tedious process. I had to go back and set an environment variable, run it in a debugger, look for a little hex number to get spit out and basically go through a process that was similar to looking for a needle in a haystack. Tedious. It was doable, but it was tedious. Now it's about as easy in Snow Leopard as pushing a few buttons.

So let's take a look at that. I'm going to go back to Xcode again. And I'm going to say run, run with performance tool Zombies.

Our App will start up again and it'll put it through its paces. And now I'll go through the workflow that generates the crash. Well, what's instruments tell us? Well it's saying, bam! Right here our zombie was messaged and here's the pointer at this time. And it has a little pointer history button. And if I click it, I get that entire vital pointer history that I needed.

Now.

Now I'm going to assume that the problem is in my own code, so I'm going to search on events in it. And I see two events. A malloc event, now that was responsible for creating the memory of the image, that can't possibly be responsible for over releasing it. And then I have a second event. An auto release event.

Well, let's look at that. I'll double click on it. And then the source instruments is saying bam! Here's our over released right at this line. Well, I know how to fix this, let me go back to Xcode. What I had done in this get error for selected images was try to follow Apple's guidelines of returning and retained auto released object to keep it valid in the calling scope, but I forgot to retain.

So I'm going to save that and rerun once again. Put the app through its paces. And look at an image. Put it back, look at another image, put it back. Great. So there you have it. The lowest overhead, the lowest overhead time profiler ever. Performance annotations right in your own source code, library data mining and push button zombie detection.

This is Instruments in Snow Leopard. Thank you.

Thank you Steve. Instruments is a really powerful tool and it's invaluable for finding memory issues and performance bottlenecks, performance bottlenecks in your applications. But wouldn't it be nice if Xcode could actually find your bugs before you ever saw them? Well in Snow Leopard, we are adding a technology that does exactly that.

It's called the Static Analyzer. The Static Analyzer is another huge innovation on top of our new compiler technology. It's based on Clang. Clang is not only able to pass your source code and hand it off to the editor on the backend, it's also able to really understand your code and to dive deep into all the different possible code pass.

And sniff for common coding errors. This slide is just some of many check the Static Analyzer is performing. As you can see, it's ranging from memory leaks to unused code, uninitialized variables, can even check that you're using the calling conventions defined by our system frameworks like foundation correctly.

I want to point out that tools like this are often out of reach for most developers because usually they cost thousands of dollars. With Xcode 3.2, it's included for free. And it works great all your Mac and iPhone applications. And so we designed a new workflow around this new technology and I'd like to ask Todd Fernandez to come up on stage and give you another demo.

Thank you Andreas and good afternoon developers. Now, there's been a lot of loose talk up here about buggy code, no code, perfect code. So I'd like to start with a show of hands. How many of you write perfect code?

Put your hand down Matthew.

Well, for the rest of us, Xcode includes a number of different tools to help you find, diagnose and fix problems in your code. Specifically compiler errors and warnings, unit tests and now the Static Analyzer. Each tool finds different types of problems and we made them all much easier to use in Xcode 3.2.

So I'd like to start introducing them to you using a simple Mac OS X application which I'll open using the new Xcode 3.2 Welcome Screen. My application consists of a framework as well as an application and unit test which use it. I'll bring up the new build results window. And the first thing you'll notice is by golly that was a fast build. I must be building with Clang. Well, in fact I am building with Clang, but that's not why that was fast. Xcode 3.2 persists your build results and reloads them when you reopen the project.

So you can get right back to work where you left off.

The second thing you'll notice is there's some new controls underneath the toolbar to control the information that the new build results window presents to me. And I'll be using those throughout this demo. The first thing I'd like to show you is the enhanced support for unit tests in the new build results new.

We've made it really easy for you to see not only each individual test case result, oops. But also helpful summaries at each level of your test sweep hierarchy. I'm also extremely pleased to announce that with iPhone SDK 3.0 you can now run unit tests against your application running on a device.

Now as some of you sharp eyed audience members noticed, I have some errors and a warning here and I really want to clean those up. It's kind of embarrassing. So let's start with my unit test failure which is epic. That's easy enough to fix.

Shh, don't tell my boss. Oh, he's over there. The next thing I see is I've got a compilation error. And well sure enough, sometimes I forget a semicolon. But I'm really glad I did. Because this is another example of those more precise Clang diagnostics.

No more of that indicating the missing semicolon in the next line business.

Now, I believe and I'm sure you're with me here, that I fixed both of my errors. But as Steve pointed out, trust but verify, especially don't trust yourself. So I want to go ahead and rebuild to make sure that I fixed both of those errors.

But before I do, I'm going to switch my display to just see the latest results. And I don't have any yet because I have not yet rebuilt my project since I opened it. But when I do, I should see just recompiling the source file that I fixed that missing semicolon as well as running all my unit tests.

And whew, it looks like I fixed all my issues. However I seem to remember something about a warning. And in the old Xcode, this is all the information I would have at this point. I would have lost that information about my warning. But in Xcode 3.2, I can simply switch back to all results, which shows me not only my warning, but the latest output from each build command in my project. I don't lose information by building.

So it's easy to build, fix, build.

So let's make this a little bit easier to look at and let's just look at the issues in my project, not all the successful build command. And I can see that this warning is just as hard to fix as the unit test and the missing semicolon.

So that's a really quick introduction to the enhancements in the build results window to help you with your compiler errors and warnings and your unit tests.

But I know you're anxious to see what the Static Analyzer can do. Well we've made it really easy to use. We've added a new command to the build menu called build and analyze. And it will go ahead and analyze my project, which has yet another issue. It looks like the Analyzer believes I have a leak in my project.

So let's take a closer look.

Now just as compiler errors and warnings are presented in message bubbles, so are Analyzer results. But the great thing about the Static Analyzer is it knows a lot more about each issue and the great thing about how we've integrated it at Xcode is we brought that information right into the editor. I access all that additional information simply by clicking the message bubble.

Now the first thing you've no doubt noticed are those arrows. And they indicate the control flow from the previous significant event in this issue to the next. Each issue, each event gets its own message bubble. I also get a new navigator bar at the top of the editor which lists all of the significant events in this issue as well as provides controls for stepping through them to understand the issue and what might be going wrong in my code. So let's, let's look at this particular issue.

I'm allocating an NSMutable array and the Analyzer is telling me that returns an object with a plus 1 retain count. Straightforward enough. Let's take a look at the next step and you can see that the control flow arrows highlight to show that I'm on the next one. I see control flowing from the beginning of my method, my allocation down to the end of my method where the Static Analyzer tells me that I will no longer have a reference to that array but it still has a retain count of plus 1. This is a classic leak.

Fortunately, it's very easy to fix. I simply need to release the object to decrement the retain count. But again, trust but verify. We'll rebuild and analyze. And verify that I've cleaned up my project. So, that's a great start. But this is a sample application. I'm sure you're wondering what does this really do for a real world application? So to show you, I'm going to switch gears to a shifting, Open Source iPhone application for accessing the Word Press Blogging software.

Now, in gratitude to the Word Press community for being good sports about this, I'll be sure to file bug reports for each issue I'm about to show you.

I'm sure they would also really appreciate new volunteers to help fix them.

I'd also suggest that all of you build and analyze your own projects before you feel too smug.

So this is the Word Press project. I simply checked it out from their Open Source repository. The only change I made was to make it build against the iPhone SDK 3.0. Just as I did earlier with my sample project, I'll build and analyze.

And now I'll filter down what I see in my build results window to just look at the Analyzer results. As you can see, there are a number of warnings and 20 Analyzer results. In the old Xcode, this is the only way that you could look at this information, organized by each individual build command, typically each file being compiled But in Xcode 3.2, we've added a new by issue view which groups them in categories.

This is, yes please! Don't, don't hold your applause!

The team has been working really hard on these features and they're not above flattery.

Oh thank you sir.

Well, let me regather myself.

So this is really great for the Static Analyzer which returns in a number of different categories as you saw on the slide that Andreas presented earlier.

It allows you to triage the issues you might want to deal with in your code and perhaps work through all of your memory usage issues at once. And in fact, I'd like to start by showing you a leak in Word Press. And those of you who may have thought my earlier example was a bit contrived, this is exactly the same problem where the UI or alert view is allocated at the beginning of the method, but is not released before the end of the method. And it's fixed in the same way.

Alright the next, the next issue I'd like to show you is the logic error. We'll reenter the mode and we'll see that control flow proceeds from the beginning of the method, down to the declaration of this bool variable named result. And there, the Analyzer tells me that I haven't given it an initial value.

OK. Let's see what happens next. Control flow proceeds through a set of IFTHENELSE statements and then the Analyzer tells me that if in fact all of those if statement evaluate to false, I will then try to read that variable's value and it still hasn't been initialized. Now, I know what you perfect coders are thinking out there. This isn't a bug. There are only four buttons in that alert view. So alert view tag will never return anything outside the range of 1 to 4. And moreover you would never, ever forget to adjust this logic if you added a fifth button.

At the end of a release cycle, while you're frantically fixing bugs, or if say an intern were helping you out or even worse your manager. Yikes.

While we've seen a number of examples where the Static Analyzer points out a clear bug in your code, this is a really good example of where the Analyzer indicates where your code is making an undocumented assumption and really should be written more defensively.

This is also something testing can't find. There are a number of ways we could address this issue. We could of course initialize this variable when we declare it. We could rewrite this code to use a switch statement with a default case that initializes the variable. Or we could make that undocumented assumption explicit by converting this final IF statement into an assertion. Let's not forget that semicolon.

Alright, now the final issue I'd like to show you today is another leak.

Now as you'll see, the control flow here is a bit more complicated. But this is where the Static Analyzer really shines. With unit testing, you need to write a specific unit test for each particular code path. Where the, the Static Analyzer can look at every path through your code and find problems like this.

So again, let's take a closer look. As we saw with the earlier leak examples, we first allocate an object which gives it a plus one retain count. And then we start cycling through this loop. And you know it'd be a lot easier to find out what's going on here if we could take advantage of Xcode's new Safari style find to indicate every usage of this variable in my method.

So again we start off by allocating the object. In the four loop, we're adding a series of dictionaries which means that if this array is leaked, it's going to be a significant leak because we're going to leak all of those dictionaries as well. Then we pass the array into this other method, postrec.

And finally, well we release it before we leave the method. Doesn't look like a leak, but let's see what else the Static Analyzer has to tell us.

Let's step to the next event. We exit the four loop, we, if that IF statement is true we enter that block of code.

We get to another IF statement. And if that is true, that's where the Analyzer is telling me that I will no longer have a reference to that object, but it still has a retain count of plus 1. So let's have a little audience participation. Who can spot the bug? Not you Matthew.

You, right in the back. That's right. We're, we're actually returning from this method. So this is again a good example that only in this particular code path is the object leaked. And we can fix it by adding an auto release up here. If I can manage to type it and take advantage of a great new Xcode feature, if you saw it entering the open embrace for me.

And of course I also need to remove that release, otherwise we'll over release the object for certain code paths and get one of those scary zombies Steve was talking about.

So again, let's trust but verify. Now, again you see that we started off with 20 Analyzer results. And I believe I fixed three of them, so let's see, another pop quiz. How many should I have?

22.

So hard to find good help these days. Alright, 17, that's right. And we have 17.

I don't mind applause either.

So this is just scratching the surface of what the Static Analyzer can do. And we think that making it this easy to use and even fun in Xcode makes it a clear win for every developer. We've been working really hard to make great tools to help you make the best possible Mac OS X and iPhone applications and we can't wait to see what you come up with next.

Thank you very much.

Thank you Todd. So the Static Analyzer is really fantastic. And it's already had a profound impact on the Apple internal development process. We just wrapped up our work on this a few months ago. And then we started running it over several projects in Snow Leopard, iLife and the iPhone OS. And within just a couple of months, we found and fixed more than 1000 bugs. It's very quickly turning the tool that we are going to use on a daily basis to ensure high code quality.

And I'm convinced that if you try it in your own project, it's going to have the same profound impact. So with that, we are at the end of the session. Xcode 3.2 contains updates to all our major applications. And I especially encourage you to try out our new compiler technologies, LAVM, Clang and the Static Analyzer.