Good afternoon. It was only two short years ago that they introduced the iPhone SDK, and developers like you have downloaded it more than 2 million times. You guys have created more than 225,000 apps for the App Store. And users of iPhones, iPods, and now, iPads, have downloaded them more than 5 billion times. The fact is, there are now almost 100 million devices out there that are running the iOS, with customers that are ready to buy your apps.

The App Store we created has turned into huge advantage. It is a global market space that is available on every one of those almost 100 million devices making it very easy for your customers to find and purchase your apps. And of course, behind this vibrant market space, they are the Xcode Tools that you use everyday to create these apps. And in this session, we want to talk about what's new in the Xcode Tools.

Let's start with the iPhone SDK 4 that is available for you today and contains the latest version of Xcode 3.2. Since we last met here in this room about a year ago, the iPhone tools have advanced a lot. Everything related to packaging, testing, and distribution of apps is now easier and faster. Let me just give you one example. Uploading applications from Xcode to a device is now done incrementally, which means that it very quick for you to launch your applications on your devices and test them natively.

Even games that tend to have very large amounts of resources now have very quick added debug interfaces. But I think the future you might like best in the latest iPhone tools is that now, you can simply take your devices, plug them into your computer, enter your IP developer ID and password, and you immediately get a fully provisioned device. It's ready for development.

It's instant setup.

And the instant setup works across multiple devices and multiple members of the team, so that you can immediately share and test your applications with all your coworkers. So to show you how simple it is to set up a device now, I'd like to ask Todd Fernandez to come up on stage and give you the first demo.

Thank you, Andreas. Getting started developing on a device is now as simple as connecting it to your Mac and telling Xcode you want to use it for development. You enter your developer program log in information, submit the request, and there's no step 3.

I simply end up with a device that's ready for development. It's that simple.

But it also works great for teams. As new engineers and new devices join your team, Xcode always maintains a single provisioning profile containing all team members, all their devices which will work to develop any app. Now that our device is ready, let's open our project and build our app.

This project builds a universal app called Picture Viewer, and you'll see it throughout this session. I'm going to build and run it on the device, and of course, I'm using LLVM to compile it which is now available in the new SDK. So take advantage of its faster build times and much more precise diagnostics. That will be very helpful for those of you with errors in your code.

Because Picture Viewer includes many megabytes of photos, it takes a few seconds to upload to the device. I think I'm going to have to ask all of you to turn off your Wi-Fi.

Picture Viewer is a very simple app, it loads a series of photos on to a virtual table and allows me to tap on each one to show at full screen. Now, that's a great photo.

It's reminding me of the vacation I'm finally going to take later this summer. Alright, you get the idea. But I want to improve that launch experience by adding a launch image. I conveniently have a launch image in my project. I just need to add a reference to it in the apps Info.plist.

Now, when I build and run again, you'll see that the upload is instantaneous because the only thing that needs to be uploaded is that single file. And there's my launch screen.

This small change saves huge amounts of time for those of you with large resources in your app.

We've also simplified how you choose the destination where you want to build and run your app. We've been building on the device, and now, I want to see how my app looks in the simulator. So simply choose simulator and build and run again. And as you may have seen briefly, the iPhone Simulator in the new SDK now allows you to simulate the new iPhone 4.

And now, in the new SDK that same build can be run in the Simulator against older versions of the OS, just like you're used to on devices, so that I can see how my app looks on iPad as well. I simply choose iPad Simulator 3.2 and build and run again. And there it is on iPad.

Well, now that we've built our app, it's time to think about distributing it. And the way you get started in that process is to use the new Build and Archive command. Xcode will build your app if it's not up-to-date, and then create the archive. Archive preserve your ability to symbolicate the crash reports form this specific build of your application.

And more importantly, since it will help prevent those crash reports in the first place, allows you to continue testing your application until you're ready to distribute those exact bits without rebuilding. This is really important, because as Steve mentioned this morning, your app crashing is actually one of the most common reasons why your app is not approved during those first seven days. And we have now made it really easy for you to avoid that fate.

Now, in order to show you the distribution features with this archive that I built, I need a distribution provisioning profile. Developer profiles are another great feature that allows you to export all of your provisioning information into a single file which you can then import on a new development system to get you-- your devices ready for development immediately.

And I'm going to take advantage of it to import the distribution provisioning profile I need to show you the sharing features.

Xcode now provides a number of ways to share your app. But before we get there, Validate Application actually runs many of the same tests that will be run on your app once you submit it for App Store review.

Again, Xcode leads me through the entire process. I enter my iTunes connect log in information, I choose the distribution provisioning profile and application I want to validate, Xcode resigns the app, packages it up, uploads its iTunes Connect with a test or run, and then reports the results back to me right here in Xcode.

And it appears that I've forgotten to include an iPad size version of my icon. And Xcode even tells me how to fix it. This is really great because it allows you to find and fix common problems like this very early in your development process well before your ready to submit to App Store.

Now once your app passes validation, there are a number of ways that you can distribute your app more widely. Xcode can package up your app and simply save it to disk to distribute however you choose, or you can have it attached to an email to send out to your beta testers.

Alternatively, you can take advantage of one of the new enterprise features that Steve mentioned this morning to distribute your enterprise app. Again, Xcode will create the files that you need in order to post your app on your corporate internet so that your employees can download it wirelessly to all of their devices.

So once you're done, all this testing, your sure your app is ready to go, you can use the last button to submit it to iTunes Connect. All of the same test that were run when you did validate application will be run again. And if they all pass, your app will be forwarded for review for the App Store where it can begin making its contribution to those next billion downloads. Back to you, Andreas.

So that was a quick tour of the latest iPhone Tools and the instant setup process for your devices. As you can see a lot has been accomplished in the Tools over the last year. And Xcode 3 is ready for you to get to start. To start working on your next iPhone and iPad projects.

And I can't wait to see with what kind of great new stuff you are going to come up with. But you know, we also have something new to share with you today. And I would like to use the remainder of this session to give you a sneak peek at the next big thing we've been working on which is Xcode 4.

This is Xcode 4.

Xcode 4 is built upon the proven foundation of our fast source editor, our robust build system, and our powerful compilers. But the user interface and workflow are completely new. There's so much new stuff in Xcode 4 that I could probably be up here on stage all day long to talk to you about it. But of course I won't get quite that much time. So we're going to focus on eight of the top features that make Xcode 4 amazing. [Laughter] It's only going to be eight.

[Laughter] So to explain the first one, I'm going to go back to Xcode 3 one more time. The Xcode 3 user interface has served us very well over the last several years. But when we started working on Xcode 4, we had a very specific problem in mind that we wanted to solve.

In the project windows, of course, you get most of your work done. But while you proceed through your development process, you have to branch out in traditional windows. For example to perform Find, or to interact with the Debugger, or to edit base settings. So you're going to edit them and you find yourself juggling multiple windows on the screen. So, the first key feature of Xcode 4 is that all core development tasks are handed within one single window.

The vast majority of space in this window is given to the editor. So it stays focused on your content.

And on the left side of the editor, you find the new Xcode navigators which organize your project information. There are several navigators that support the entire-- that support all the different phases of your development process. You can mange projects and files, you can browse classes and methods, you can perform searches, you can work through bid errors, you can track debugging information, and you can view things like bid logs. And all of that is presented to you in one consistent way in the navigator area. In fact, Xcode 4 allows you to manage multiple projects within the same window. So can you-- you can make changes across all your frameworks, libraries, plug-ins, and application at the same time.

You could match up the functionality to perform the most common development task into the new streamline Toolbar which is cleaner but still does more, and right underneath the Toolbar, you find a new Jump bar which shows you where you currently are in your project, but also allows you to click and navigate to other parts in your project. Feature number two, as you might have already guessed from the screenshot I showed you a few moments ago, is Interface Builder fully integrated into the Xcode IDE.

There's no more standalone Interface Builder application anymore. Everything you'd be able to do with the standalone application is now part of the Xcode design and editing experience. But since it's now one application, the interface editor has access to all the class information in your project index, which makes it much easier for you to keep your interface files and your source code in sync. The edit-- the Inspectors and the Library at the right side of the window, and with that all of IB is now part of Xcode.

Feature number three, is the Xcode Assistant. When you're making changes to your source or to your interfaces, these changes never have an isolation. Often, changes affect many different files at the same time. And so, there are a lot of things that you need to know or research before you can complete making a change. For example, you might have to know how subclasses are affected by a change you're making the super class, or you might have to check the definition of a category. And of course, you always have to keep your header and implementation files perfectly in sync.

And that's why we created the Assistant. The Assistant organizes the information on your project index and brings it to you in the editor in a context-sensitive manner. Xcode basically hands you the information you're looking for without you even asking for it. And to related content, simply shows up as a split editor taking advantage of the additional space that we now have available in the single builder layout.

The Assistant really shines with Interface Builder. But now, you can work on your GUI and your source code side by side. It also works really well for things like data models. But now, you can easily access the classes that are back in your models. So the Assistant brings you a ton of information from the project index. And to show you how it works in practice, I'm going to ask Matt Firlik to come up on stage and give you our first demo of Xcode 4.

Thank you, Andreas.

I'm really excited to be the first to show you some of the new features of Xcode 4. So let's jump right in. What you see here is the picture of your application, Todd showed you just a moment ago, now open in Xcode 4. You can see immediately the dramatically refined and streamline UI of Xcode 4. We've simplified the Toolbar to provide you just the controls you need right at your finger tips.

On the left hand side of the Toolbar, we provide you all the controls for running and debugging your application. And we've taken all those settings, all the context, around running and bug-- debugging your application, and brought it down into a pop up, where picking the thing you want is just one click.

The center of the Toolbar is host to the activity view. This is where we show you the current status of your project, as well as activities that are going on in the project like finding, building, and such. You'll see here, as I start to build my project, it shows me the dynamic display of what's going on, it shows me the state when it's done, and shows me the results. It's built successfully and with no issues, which is exactly how your projects are all the time.

The right hand side of the Toolbar is host to the controls to allow me to configure the user interface to bring in different elements, to allow me to adjust my workflow based on what I'm doing. We'll see those in a little bit. Most of the window's dedicated to navigation and to editing, two primary tasks that you guys have experience with a lot. The left hand side is host to the navigators. Here, we're seeing the project navigator showing me the structure of my projects.

Now, the navigators provide you different axis of information depending on what you want to look at. I can easily use the chooser at the top of the navigator to select the symbol navigator. And now, I'm looking at my project with a symbolic representation, allowing me to select anything I want. So whether you're looking at issues, find results, build information, the navigators are your source of information to get those and allows you to change your point of view without changing your context.

Now, we feel that navigation is such a critical element, we've integrated it directly into all the editors in the form of the Jump bar. Now, the Jump bar is across the top of my editor here and provides me access to all kinds of navigation options. If I want to navigate inside the file I'm in, I can grab the right hand most item and select a different piece.

In this case, it's a different method within this file and I can jump right to it. But say, what I wanted was not something in this file, but it's a related header file or another file in the group that this file is in. I can select the note previous to that and select any other file and move directly to it.

In fact the Jump bar provides me the entire structure of my project, such that I can grab any note here and navigate to any file I want with just a single click. And it's that easy to move about in your project. The Jump bar actually goes a step further and provides a list of related files, both based on the context I'm in and the file that's currently being presented.

So I have access to the recent files, unsaved files, but I also have access to counter parts of this file, in this case, the header, but also, super classes, siblings, and include files. This kind of navigation right at your fingertips is so critical, but so powerful, that I can actually decide to use the control here in the Toolbar and collapse the Navigator completely.

And now, I have access to all the navigation I want to get to and have the editor taking out the full window for my particular use. And this is actually great for all of you people who think differently about line-wrapping and turn it off. This is great for you. Yeah, I know you're out there. This is a great view for you.

Now, we've brought together-- we brought together-- we brought forward all of the great editors from Xcode 3. This is the powerful source code editor with all the features like code completion, code folding, all the syntax coloring. Well, we also made improvements to a number of editors and added some new ones that I'd like to show you.

I'll use the Jump bar and select a data model. And here, you see the diagram representation of my data model with the source list here that allows me to click through and select each item. And while this view is great for kind of the high level view, I can also switch to an integrated form view that gives me access to all the properties of my core data model, so that it's really easy to modify it and configure it.

Now, many of the assets that you work with in your development process require editing. But some don't. For example, resources like images and movies, or PDFs or other documents that you have in your project. Xcode 4 integrates technologies like PDF Kit and the Quick Look technologies to provide viewers now for all the standard data types you guys work with. So, whether you are for example looking at the startup movie that your graphic designer presented to you, it will run when you're application runs.

Or, you're looking at the PDF document that your manager sent you to describe all the different features that your application needs to support. Or if you're just actually looking at the keynote presentation that defines all the different features about the application you need to demo next, those are all integrated directly in the Xcode as primary workflow.

Now as the picture in picture describes here a little bit, one of the greatest advancements of Xcode 4 is the integration of Interface Builder. So, let's take a look at the Preferences NIB file for this application.

I will select it from the Jump bar and here it is. Here's the Interface Builder canvas with my interface. I can move it around on the canvas here. Along the left side of the editor is the Dock which provides me access to the top level objects. I can click in the Dock and bring in other views and I can select as many as I want so I can bring in 2 or 3 and pick the items I want to use or I can just focus on any number of items.

Now the Dock also gives me access to the structure of my document. By clicking the button down here at the bottom of the Dock it will expand and it now shows me the outline view. That I can expand this and now see all the different items within my interface and select them directly.

Now, you may have noticed that the Jump bar across the top has been updating too. It provides the same kind of navigational affordance. So now if I wanted to select any view within my NIB file I can instantly pick it from the Jump bar and have it selected. So, it's that easy to continue navigating.

Now, as we're working with our interface files we know we need two utilities, we need the inspectors to modify attributes of our interface and we need the library to add new items. So, I'll click on the upper right here of the toolbar and I'll bring those utilities in. So, now we see the inspectors across the top and the library across the bottom.

Now the inspectors and the library work as you would expect them to from Interface Builder 3. I can select for example, the view that's on the left hand side here and let's change its background color to something well, not too offensive. And it's just like that. I can also select for example all the text labels here and let's choose to align them to the other side. So the inspectors are very natural and very fluid.

Now, you'll also use the library down here switching to the Object's tab to add elements to your interface. Let's drag another slider up into my interface. Just like that, we'll drop it in. It's exactly where we want it to go. And you can also use the library to change other parameters.

For example, I'll switch the library to its media group which shows me all the images that are within my project and I'll scroll down here and let's find that wood grain and just drop it on my interface and there we go. So the library and the inspectors are still very, very fluid right here in Interface Builder.

Now being an integrated editor, the Interface Builder content also has access to related information. If I pop open the related pop up here, we'll see that in addition to the recent files we had before we now also have top level objects. These are the classes that correspond to all the objects in my interface.

So I can instantly switch to them and get access to them as I want to start refining my interface, making it really easy to move between source code and my interface. But we wanted to take this a step further, and this is where the Xcode Assistant comes in. I'm going to close this view and I'm going to turn on the Xcode Assistant by clicking this button in the upper toolbar here.

Now, you'll see that I have my interface and the source code right here. Now this is more than just a secondary editor, this is the editor that brought me the content that was most relevant to what I was working on. In this case it's the file's owner class, it's the class of the control I'm going to be using most often. So here I can start adding outlets and add in actions right as I refine my interface, bringing these two together so they feel as one. But we wanted to take this a step further.

As I'm making connections in my interface normally, you would do that by control dragging from let's say this picker view to one of the objects in the interface here. But to make this truly feel like one, I'm proud to announce to you now that instead of dragging two objects you can now drag directly to--

Yup. Directly to source code.

And this truly allows you to design in the way that you think. I know you guys all want to see that again so let's take the slider [laughter] that I just added in and let's connect this up. But to really show you exactly how fluid this is, you'll note that this time when I'm dragging there is no outlet there. But as I pop in, here's the insertion point.

And, of course, this works for actions too. So, while the assistant change to the implementation file for this, let's scroll down to where I want this to go, and I'll control-drag right into the source, let it drop. We'll call this the adjust load-rate method, hit return and there it is. So, now, we're bound up with our action and we're bound up with our outlets.

Now, we wanted to bring some of the elements of Interface Builder into the rest of the IDE.

So, you'll actually note down here in the Library, there's a code snippet section. This is where we'll provide you some great snippets, but you can also add your own. I've added a method for working with sliders that tells me when I hit the min and max value, so I can just grab that, drag it right into my source code here, and drop it, and there's my method. [Background Applause] So, now the different items where dragging and dropping work for your interfaces and for your source code.

Now, the Xcode 4 Assistant shines, its genius actually comes out more when we start to see the different content it can provide. Here, I've been looking at the file's owner streaming my controller class. But there are other content we can look at. I'm going to change the group here from showing me the top level objects to automatic. And you'll note in doing so, it's not going to adjust based on my selection. So, now, we're saying it selected the adjust load-rate method.

If I click one of the other sliders, it's going to jump to its method and therein. So, it makes it really, really easy, really, really fluid to start working with these editors as pairs in exactly what you think. If you want to modify the action, click on the button. You want to modify the view, click on the view, and the Xcode Assistant will bring you exactly what you want.

And the Xcode Assistant actually works great for all kinds of editors. I'm going to switch back to the data model I was looking at before. And now you see that there's going to be the data model on the left and the corresponding runtime class on the right. As I pick a different entity, the editor updates to show me exactly what I need. And the collaborative editing works exactly as you'd expect here.

I can go and select, for example, two properties in the list and just copy them, and I just go right over my source code, no trick up my sleeve, and I'll just paste interfaces, and there's the interfaces that we had. I can even have the Assistant switch to the implementation file, and we can now paste the attribute implementations right there. So, the editors truly take you to where you need to be.

The Assistant is also very fluid and allows you to move between content very seamlessly. Here, I'm looking at the data model and the source code, but if I decide to shift my attention to this file on the right, I can simply say Navigate and Promote, and it's going to move that file-- the left hand editor, and now I can look at its counterparts. In this case, the implementation file.

Or I could decide to look at siblings and move through all of the other entities from my model here if I wanted to refine their interfaces. So, as you can see, it's the combination of the integrated Interface Builder and the Xcode 4 Assistant that makes editing truly amazing in Xcode 4. Thank you.

So, as you can see, Xcode 4 is all new. The interface has been completely redesigned to keep you focused on your code and interface files, and the Assistant really helps you understand your projects, and just keeping all the different parts of your projects perfectly in sync. And with that, let's move to on our feature number 4, which is the LLVM Compiler 2.0. I've been talking to you about LLVM for a number of years now, but in case you're not yet familiar with it, it's our next generation compiler technology which is replacing GCC.

LLVM is an open source project. It's hosted at LLVM.org and has contributors from all across the industry that is led by the engineers in Apple's compiler team. Let me just list a few of the highlights of LLVM. First of all, it's fast. The typical Objective-C application on the Mac compiles more than twice as fast with LLVM than it did with GCC. So that alone is a great reason to make the switch to LLVM because it saves you a lot of time doing a long day of engineering.

But not only is LLVM is very fast, it also produces better and faster code. Defined very consistently that LLVM generated code easily outperforms GCC generated code. Let me show you a few numbers. This chart shows how much faster LLVM generated code runs and compares them to GCC, in this case, when running a number of benchmarks from the OpenSSL test suite. OpenSLL contains numbers where it performs critical pieces of code. And what you can see here is that LLVM runs that code up to 25% faster.

Now, this year, we're also making LLVM available for the iPhone. And so, I thought I'd share the same set of data with you that we found for the iOS. As you can see here, LLVM produces even better results. LLVM generated code runs up to 60% faster than GCC code. And so with a very simple change in your project just by switching to the new compiler. You have the potential to gain a lot of performance for your applications, and I recommend that you give it a try.

Our third area the LLVM, its real value over GCC is when it comes to diagnostic messages. LLVM error messages are a lot more precise and they contain exact range information instead so that Xcode can pinpoint the exact location of the piece of code that caused an error or warning.

And we can show it to you, the nice highlight as you can see here in the screenshot. But the real big news on the LLVM for this year is that in addition to Objective-C and C, we're adding support for C++.

So LLVM is now a complete replacement for GCC compiling C, Objective-C and C++.

But LLVM is much more than a static compiler. And starting with Xcode 4, LLVM is now fully integrated with the Xcode IDE to provide the source editor and other parts of Xcode with a complete understanding of your code. LLVM is now the engine behind things like syntax coloring, the Xcode assistant, and also code completion.

With LLVM, code completion is now syntax-- I'm sorry, is now context aware. So, it allows the IDE to present much more precisely how it can complete your code. And that of course works for all the languages that LLVM supports. So that means that our support for C++ in the source editor has just taken it huge leap forward.

Now integrating LLVM into Xcode has allowed us to create another very profound feature. So feature number 5, Fix-it.

All of us take it for granted that when we enter something in the word processor, the computer immediately checks our spelling and alerts us that we are making a mistake. With Fix-it, you're getting that exact behavior now in Xcode when you're entering your source code. Xcode immediately checks your code and alerts you if you're introducing an error or warning.

And you can do even better than that. Since now we have such a complete understanding of your code, it can even suggest fixes for you, so with just a click of a button, you can correct your source code.

Fix-it can correct dozens of common coding mistakes, for example, misspelled symbol names or mismatched parenthesis, or simple things like missing semicolons.

And while Fix-it works right while you type, I also wanted to remind you that last year, we did another feature that's based on LLVM technologies, and that's the static analyzer. The static analyzer goes far beyond the regular compiler analysis. It runs a deep check of many of your code pass and it can find errors like memory management issues over hundreds of lines of code.

And when it finds a bug, it shows it to you with a nice set of arrows that guide you step by step through your program to show you how you introduced your bug. And now to show you our C++ code completion, Fix-it, and the static analyzer, I'm going ask Mike Ferris to come up on stage for our next demo.

Thank you, Andreas.

I want to show you how great C++ code completion is in Xcode 4. Xcode 4 lets you jack hammer through even complex C++ to make sure that we are always offering you exactly the right completions. I'm going to dereference this pointer that I'm grabbing out of the vector, and at this point Xcode has traversed through several instantiations of several different templates using operator overloads and every step of the way, it has offered me the appropriate completions.

Xcode also pays attention to little details. So as I add to the switch, Xcode knows the possible completions and it offers them to me. And as I add a second case, notice that Xcode has narrowed the list down to offer me only the completions that aren't already covered in the switch.

I really love the little details like that.

Because Xcode's indexing engine is based on the LLVM compiler, we get amazing accuracy. And that's not the only editor feature that's based on this stuff. This accuracy also applies to stuff like jump to definition. Here I have two calls to a function called myMin. If I jump to the definition of the first one, it goes to the general template function definition. But watch as I jump to the definition of the second one. Xcode knows that there is a template specialization that's being used in that case and so it will take me to that correctly.

Now let's talk about something that's brand new in Xcode 4. Andreas told you about Fix-it. I'm going to show it to you. I'm a terrible typist but Xcode knows when I get something wrong and it alerts me to that. I can click on the error icon to find out exactly what the problem is and I can even have Xcode just correct it for me.

Misspellings are just the beginning though. Here's another common C pitfall. We're seeing is the code completion again here and as I type the rest of this conditional, again Xcode thinks that there may be something a little fishy going on and so I'll click on the icon.

This time Xcode is giving me multiple choices because I might have meant to make a comparison instead of an assignment here or maybe I really did mean to do the assignment but I should just be more clear about it. In this case I meant to do the comparison so again I'll have Xcode fix that for me.

Finally, let's look at a C++ example. Here I'm adding a copy constructor to this class and as I finish, once again Xcode has flagged the problem. Now this time I actually know exactly what's going on here and so I'm just going to use a keyboard command which will fix the last mistake that I made while letting me continue to work.

Fix-it finds areas immediately and helps you to fix them. Static analysis on the other hand can help you to find bugs in your application. I'm going to analyze this project and see if they can come up with any errors and it switched me to the issue navigator to show me the problem that it found. I can click on that to go to the source of the problem and it's telling me that I am using a reference counted object after it's released.

This is a subtle bug in this case but I can explore by clicking on the message bubble and it will take me into this and I can walk through it step by step. The arrows show me the path that the code is taking and each step it explains what's happening. So in the first step I am returning an object that has a refcount, that sounds right, and then I'm releasing it and then I go back up to the top of this loop.

Now step 4 is where the problem occurs and if I look at the arrows I can see that I never go inside the first conditional where I'm allocating the string and yet somehow I'm releasing this thing. Well, what am I releasing? It turns out that what I'm releasing is the string from the first pass of the loop which I already released the first time through the loop, and so I could fix that if I just cleaned up after myself after releasing the string and made sure that it wasn't around for me to talk to again after I'm done with it. I think I fixed this bug. Let's see if Xcode agrees.

Yeah. So, that's one less bug waiting for my customers to find. [Applause] Andreas?

So as you can see LLVM now aids you throughout the entire development process. It helps you write code with Code Completion. It presents Fix-it if you're making a mistake. It compiles your code and it even runs a static analysis to find deep coding errors, deep logic errors that are very hard to find without the static analyzer. So, let's move on to our feature number 6, the Version Editor.

One of the most common requests from our community is better support for source control. And the most widely used source control system out there in our community is Subversion. So, Xcode 4 has a great improved support for Subversion. But over the last several years we've also seen developers very quickly moving to distributed source control management systems. And the most popular one out there is Git.

So in Xcode 4, you're adding support for Git alongside with our support for Subversion. And all the operations of this support for Subversion, biggest support equally weighed for Git. It ranges from the normal checkout, commit, and update workflows to somewhat advanced operations that they're introducing the Xcode 4, like support for branching and merging.

But Xcode 4 goes far beyond the standard SCM operations. We wanted to make it really easy for you to understand how a code has changed over time, and that's why we're introducing the Version Editor. It allows you to view multiple iterations of your files side by side in comparison view. And you can even go back in time that the head of a simple timeline that shows up in the middle of the editor.

So simply by dragging a slide in this timeline, you can see how it will changed and you can go back more and more iterations in time. The easiest way to explain it a bit better to you is to show you another demo. So I'm going to ask Max Drukman to come up on stage to show you the Version Editor.

Thank you, Andreas. Good afternoon everybody. Let's demo.

Alright. So here we have the two projects that we're demoing with in this session today. One checked out of Subversion and one from Git. I have some local changes here which you can tell by the M annotations they're modified files. Now, I have modified files sort of sprinkled throughout these two projects, but I want to concentrate on just the ones that are modified.

I can filter in the navigator to see just those. So at the bottom of the navigator is a filter bar which allows me to click on a button to just see the files with source control status. So it's that quick to narrow down and see exactly what I want to work on.

So let's select one. And now I'm going to go to the Version Editor. Now, the Version Editor shows me a comparison view, so on the left is my file as it exists on disk on my machine, and on the right is the latest version from the repository, whether, it be Git or Subversion. Now I can look at other source control aspects of my file as well.

For instance the log, which is the source control life of my file, or blame, which shows me line by line who the authors of this file are just in case I need to know that information.

I can go through and look at this aspect of each file, of course, and if I see a revision that has in particular interest to me, I can click on the arrow button to go directly to a comparison against that version.

Now, at the bottom of the Version Editor is another jump bar. Instead of showing the structure of my projects, it's showing me the structure of the SCM system, so I can see branches and revisions. Again, I can get right to exactly what I'm after. And as Andreas showed you, there's a timeline, which allows me to scrub through and see all the revisions, along with it the commit information.

I can slide the version on the left or even slide it on the right so I can compare any two versions of my file, not just now to then but then to then as well. And of course, because it's an editor, well, it's a live editor. I can edit and make new differences and see them show up as I'm making my edits.

Okay.

Alright, well, how about this one?

I can reach back in time and grab some code that I never should have deleted in the first place and bring it forward and edit my current file with it, so I can go back and correct any mistakes that might have come into play.

That's the Version Editor.

I think you're going to love it. Now, there's one more edit I need to make before I'm through. It has been pointed out to me that some deprecated API made its way into both of these projects, and let's not dwell on who put it there. Let's just say that it's up to me to fix the mess I made. Now, what I want to do now is use the search navigator to find where the problems are.

I'm going to switch the search navigator and I'm going to look for the API, which is NSString, string, we'll see string, and you'll see that the navigator is presenting me with some search options. So there are different strategies that I can use to search with. I'll go ahead and accept the default one.

Now, I have a few changes here, and so let me go through and not just find them but replace them. So, I'm going to go for something more 21st century. Let's go NSString stringWithUTF8String, because sometimes it's not cool to be old school. So now I've got my replace loaded up.

I can select a single occurrence and click Replace and replace just that occurrence, or I can select the whole file and click Replace and replace all the occurrences in that file. Since I'm done with this file, I can click Delete and remove it from the navigator so that I can concentrate on what I have left to do. This is great for working incrementally.

And of course, I can click Replace All to replace all of the occurrences. Now, since this is a navigator, I can use it to navigate, right? Pretty simple. But think of it as a navigator that you get to make for yourself using search and it gets really cool when you do that.

So now I've made edits to some files. I can filter the navigator on that as well. If I turn off the source control filter and turn on the unsaved files filter, I can see just the files that needs saving. And so I can use that to navigate around as well, but I think I did a pretty good job here, if I do say so myself.

So, I'm going to go ahead and save these. I'll do Save All. And now the navigator clears out because nothing meets the filter criteria, all my files are successfully saved. But they're all still there, don't worry. Now, I'm done with my edits, so it's time to commit. Let's go to Source Control, Commit.

And now, here is where I can see, again, all of the files that are modified. On the left I have a navigator that shows me those files, and I can look at those files in the project structure, as you see here. In the on-disk structure as they show up in the finder, or as a flat list if you don't care about structure at all. And on the right is a comparison view. Now, just like with the Version Editor, this is live, so I can actually delete that bit of garbage that you thought I was going to check in.

Now, not only that, but I now have a new unsaved change to that file. Because I just deleted that bit of garbage, I can just hit Save right here. I don't have to back out, get out of my workflow in order to do last minute changes.

So now, all I need is a commit message. Commit to get and subversion at the same time! And now, when I click the Commit button, Xcode will save my changes to both Git and Subversion at the same time, which is very cool. Back to you, Andreas.

So all the features Max showed you are going to support it for Git and Subversion. And I could tell you from our own experience that the Version Editor is a great help into trying to track down regressions that happened several iterations ago in your code. Feature number 7 is a brand new Debugger.

This is a screenshot of the new debugging experience in Xcode 4. There are 2 navigators that are dedicated to debugging, and there's also an additional area that comes up from the bottom of the window to give you access to critical debug information. Now integrated in Xcode 4 in a very fundamental way is the ability to debug multiple threads. So Xcode will show you the stack traces of all threads in the navigator. And then even though it's about dispatch queues, so it makes it very easy for you to debug GCD applications.

Now, with more threads come many, many more stack frames. So we built a great new way into Xcode 4 to compress stack traces by simply hiding uninteresting symbols. For example, you can typically assume that the bug you are tracking is not in the system log which you are running against. So you can simply-- [Laughter] So with a very simple gesture in Xcode 4, you can hide those symbols and focus only on your own code without losing any relevant information.

The debug area at the bottom of the window gives you control over your program execution. You can now step by line, by instruction and also by thread, and all of that with a much more precise variable display. The new Xcode 4 Debugger is context-aware so it even has an automatic filter to only show you the variables that are currently in the scope of your debug state and all of that works on top of our low-level debug engine which as you know is GDB.

Now, a few moments ago, I used the term brand new debugger and I'm very pleased to tell you that it didn't just mean a new user interface. Today, we're introducing a new low-level debugger which we're naming LLDB.

LLDB has a lot in common with LLVM. Among other things, it's designed for performance right from the start. For example, LLDB can load symbols up to three times faster than GDB.

And this chart shows you the amount of memory used by the debugger itself and we're stopping at breakpoint for very, very large corporate application. As you can see here, LLDB is almost 3 times as memory efficient as GDB and what these numbers mean is that LLDB will give you much faster debugger startup time and much more stepping speed. Now, I'm also very pleased to tell you that later today, we are going to hand over the code of LLDB to LLVM.org. So we're going to contribute our debugger to the LLVM community alongside with our compiler.

And to show you our new debugging experience, I'm going to ask Dave Payne to come up on stage for our next demo.

So I'd like to show you some of the cool new features that we have in the Xcode 4 debugging environment and I'm very proud to tell you that throughout this entire demo that I'm going to do, I'll be using our new debugging engine LLDB that we've been working very hard on. So, let's get started.

So, I'm going to launch the picture of your application again and note at this point that we are showing the project navigator in the navigator area. Let me go ahead and launch, come up in the simulator. Now, I've got a breakpoint set at handling the tap action in my application. Watch what happens in the navigator area when I tap on a photo.

So we hit my breakpoint and the debug navigator automatically switches over just showing me all the threads in my application and the backtrace of the currently active thread. Now, I can twiddle open any of the other threads here and we see that many of them are actually threads that the system has added for us for things like handling GCD and idle work queue threads. So, on both Mac OS X and in iOS 4, as GCD comes into it, there can be a lot more threads in your application.

But a lot of times I'm not interested in all that detail so by clicking on the Hide Thread button down at the bottom here, I can focus onto just those threads that are interesting to me, so those that have my debug symbols in them or any threads that I've crashed in.

But, still, there's a lot of deep layering in Mac OS X and iPhone software, so backtraces of a single thread can still be very complex. So, scrub through with this stack compression slider. Note again what happens in the debug navigator here. Hide all the symbols within a single library or even all those symbols across libraries or go even deeper than that. So I'm going to the default level here which is to show the symbols that I have source code for. So my debug symbols as well as those system symbols that I'm directly interacting with. So focus on just the things that I care about here.

So let's move down to the debug area down at the bottom here. In addition to the standard debugging controls: Pause, Continue, Step, we have a Jump bar here as well that lets me move between the individual stack frames or between all the threads and symbols there. We have a Variables View. We have a console area on the right side where we're showing a log message that I had on the breakpoint or I can directly interact with the low-level debugger to do more detailed things that I'd like.

But let's focus on the Variables View. So, we note that we have a long list of variables that are relevant in this function, but that's a pretty complicated list. What I'd really like to do is switch over to the auto variables mode so that I see only those variables that are relevant to the lines of source code that I'm currently executing. So, as I step through the code. It automatically updates what variables are being shown based on what code we're currently at. So, this is taking advantage of the power of the Xcode indexer to do this.

Now, let me go over to the breakpoint navigator and I have another breakpoint I'm going to enable. So, what this does is such a breakpoint on drawing each frame of my graphics. So let me go ahead and continue through my app and continue a couple times. Aren't those graphics cool? Well, it would be cool if I could actually see them. So, if I go to the Window Behavior menu, I can bring my target application to the front while I'm still indexing [applause] or still working with Xcode in the background.

So now, as I step through, we can actually see the graphics changing on the screen step by step. So, this is great. Lets you see what you're doing in your target application while you're also interacting with the full screen Xcode. We've packed so many features in here that really likes having full-sized windows. So, let's move to a somewhat more complicated example. We have another application that scales graphics for us, so we have a number of images being shown once I start showing them.

Let's process the images. Shows a number of images and scales them. Now, I happen to know that this application uses GCD. So, I have another breakpoint that I can enable that is on my scale image routine. So, let's go ahead and process the images again and we hit the breakpoint, great.

So, let's continue a couple of times and now, let's take a look at some things here. So, we have over on the PC annotation, we see a little badge here. Thread 7, hit a breakpoint but we see a 3 that indicates that on this multiprocessor system, we've actually simultaneously hit three breakpoints in a single line of code. So, Xcode is coming right out and showing me this.

If I move back to take a look at the Debug navigator again, we again see that we're seeing all the threads that are relevant to me at this point but now, it's more interesting with my multithreaded application but because this is using GCD, I can switch the sort order to be by queue. So now, all of those threads that are associated with the mipmap queue are sorted together so I can concentrate on those. So, I can see that I've got several threads in that area.

So, one of the other things about debugging through multithreaded code, typically, when you do a step over in multithreaded code, actually any code, the Debugger lets all the threads continue. It's implicitly set a breakpoint on the next line of code and it's often kind of confusing when you get thrown completely out of context because it hits another breakpoint in a completely different thread but we've created a solution for that which is that I can hold down the Control Shift keys as I hit the Step Over button and I'll be stepping through just a single thread at one time. So, that lets me focus--

Let's me focus on just what I care about at that particular point in time. Okay, that's the debugging experience all working with LLDB. Thanks, Andreas.

Alright.

So, that's some cool stuff in our new debugging experience. And of course after debugging, you want to tune the applications and that brings me to our eighth and final feature of today which is the new version of Instruments. Instruments is a partner application to Xcode. It's focused on performance analysis and profiling.

The next version of Instruments is going to adopt the number of the features you've already seen in the Xcode 4 IDE. For example, it's going to use the Jump bar to quickly move around a user interface, that's going to use stack compression in looking at code trees. But we're also adding a number of new-based Instruments to your applications so that you can learn even more about them.

First of all, we're going to add a new, a brand new instrument focused on OpenGL ES. It's very good at making very precise recommendations for how to tune your OpenGL code. Second, we are extending our Memory Allocations instrument. It has always been very good at finding memory leaks but in the next version, you're also going to be able to find unattended memory growth that is strictly speaking on a leak but still represents unattended memory growth for example, in filling up large caches.

Third, the Time Profiler instrument that so far has only been available for the Mac is now also available for the iPhone. Time Profiler is the best way for you to collect time samples of your applications. It has very, very low overhead and gets you very precise measurements. And fourth, we're adding support for full system trace into Instruments.

That way, you can not just look at one single application but learn about your entire system and see how applications interact with each other and with the kernel of the OS you are running on. And to show you these new features in Instruments, I'm going to ask Steve Lewallen to come up for our last demo of the day.

Good afternoon.

So, as Andreas mentioned, Instruments has a new feature called Heap Shot and Heap Shot allows you to look for abandoned memory and let me show you what I mean. I'm going to go to my demo machine here and in my Xcode 4 workspace, I have the picture viewer app you've been seeing. I'm going to launch that from Xcode 4 while simultaneously having Instruments analyze it to demonstrate Heap Shot.

Now, while this is setting up and Instruments is gathering some data on our picture application, let me explain what abandoned memory is because this isn't leaked memory. You still have a reference to it but you may not need it anymore and as the chart that's developing in the screen suggests, it may be building up overtime. So, we have enough data here.

Let me stop this trace and let's use Heap Shot to find out why it's growing like that. Well to use Heap Shot, the first thing I need to do is establish a baseline of where my heap is because I want to compare it later to other Heap Shots. So, I move my inspection head and mark the heap there. We've got a baseline. Now, I'll go to the next place where heap has grown some. My memory growth has occurred at a steady state and I'll take another Heap Shot and then one more for good measure.

Alright, what do we have here? Well, our Heap Shots represent about a meg of heap growth each and if I twist one of these open, they contain all of the data that was allocated since the previous Heap Shot, in this case, when Heap Shot 1 was taken. That's still alive when I quit my app. So, I allocated and just stayed around until the app quit. We look at the previous Heap Shot, we can see about the same kind of data. And in each of these seems like it has a lot to do with images. This is an image processing app.

So, let's see what it can tell me about how I'm using CGImage. I'll focus in on that and I'll open the extended detail view up and thanks to stack compression, a pretty long backtrace has compressed just my own code. I mean I have four frames in my own code right in front of me. It's great. So, I see that I come in to draw view and it goes through a rendering step and asks for a texture and maybe goes out and gets it from the file.

Let me double click on Texture For Index. Well, this has a texture cache in it. I remember this. I put this in here so that this API would return images faster but I think I suffer from a case of premature optimization here because I forgot about the memory growth that this would incur. So, what I should really do is go back, maybe at a heuristic or think about how I'm caching this to avoid the problem that Heap Shot and Instruments is showing me quite clearly.

So, that's Heap Shot and it's very useful, very simple to use though. I recommend you take advantage of it for your Mac and iOS 4 development. So Andreas also mentioned that we have a new instrument in Xcode 4 called the OpenGL ES Analyzer. And the picture of your app just happens to be an OpenGL app. So, let's see what that instrument can tell us about our app.

As you might expect, it can give us basic data of all sorts, all the raw numbers our number of geo calls, the number of redundant state changes, a number of triangles rendered, et cetera. But this instrument can go further. It can actually recommend to me how I can improve my app. Let me show you that.

So I click on one of these and I'll see a recommendation. In this case, what it's telling me is that, you know, by providing the app with very large images and making it scale them down to size, that's using a lot of resources, it'd be better to provide mipmaps, or a series of intermediate sized images.

That would make it perform better and a plus would actually be that the images will look better on screen too. So that's the OpenGL ES analyzer. Any OpenGL programmers out there, I really recommend you take advantage of this. This is truly an awesome instrument. So let me close that.

But this does beg the question, how would one create these mipmaps? Well, I have a mipmap app for that, and I'm going to show it to you now but unfortunately it's not running very fast. And whenever you have a piece of software that isn't running very fast, use the Time Profiler on it. That is as Andreas mentioned available for Mac OS X and the iOS 4 now.

Somebody process these images again and wait for it to finish and then I'll quit the app and we'll see what data we have. When we filter down, adjust my own code we're spending 80% of our time at scale image. Let me double click on that. Well, we're doing various things but most of the time, is spent on CGContextDrawImage. Well, there's nothing I can really do about that. That's a CoreGraphics call and I'm sure those guys have already totally optimized that. So Xcode 3, this is as far as it would take, I could go with my analysis.

I couldn't go any further, I'd be stuck. But as Andreas mentioned, now in Xcode 4 we have system trace. So let's see what system trace can tell us about this app from its perspective. Now when I run system trace, I'm going to run it in what we call deferred mode, new to Instruments. So if it looks a little bit darker and different, that's why. So let's have it start up and we'll put our little app through its paces again.

Great, now the instrument is going to analyze a ton of data it has just collected and it's going to summarize it all for me in these great charts. This represents a ton of data in the back-end and you can you can feel free to explore it all. But it's giving me clues as to what I should look at and right away this chart VM Fault Durations catches my eye. It seems very much out of proportion that ZeroFill should be that much of all my VM operations here. So, let me cook on this chart which will take me to the next layer of data. What it's showing me actually is call treesassociated with VM operations.

And to me, a performance guy, that's just really amazing. I have never seen a tool do that for 'em. So, let's open up ZeroFill and our old friend Scale Imagine again. Let me double click on that and we'll wait for it to collect all the data. And now it's saying in the context of VM operations, it's also finding a lot of ZeroFills on CGContextDrawImage.

Well, this is really cool because what Instruments has done is correlated for me a time profile which clearly as identify them, spending all my time in this call with VM operations data where it's clearly identified that quite a few ZeroFilters going on behind the scenes when I make this call.

So, if I restructured my code, I think I could optimize that some and then I go through Instruments and do the next round of optimization. So, that is Instruments. Thank you very much. Andreas?

So that was the new version of Instruments. There's some great new ways to learn even more about your applications.

And that completes our sneak peek of the Xcode 4 release.

I probably don't have to tell you how excited we are about this new release. We've been working at it for a while. We've designed a complete new set of tools, made the entire tool chain simpler and at the same time more powerful so that you can write even better applications.

So, please keep using Xcode 3 with the new instant set up process for your devices to develop the new iPhone and iPad applications but also take a look at Xcode 4 and let us know what you think about it for the future. Thank you very much.