Good afternoon, and welcome to the Developer Tools Kickoff. Thank you. Thank you very much. Just over a year ago, we released Xcode 4.0, a brand-new release of Apple's Developer Tools. And with this release, we took Apple's Developer Tools to a whole new level. We reimagined the user interface. We implemented some streamlined workflows that scaled really well to large and small screens. We focused on integrating really great design and editing tools, and then harmonizing them together through Apple's new Xcode Assistant Editor.

We built in tools for source code management to allow you to review and refine your changes as a natural part of your developer workflow. And we built the LLVM technologies right into the IDE so you could use the power throughout the UI. Now, we built on this momentum and brought you a number of great Xcode releases over the last year. This past summer, alongside OS X Lion, we shipped Xcode 4.1. And in Xcode 4.1, we included a great new technology, Auto Layout for OS X, which is a great way for you to define and refine the layout for your UIs.

Last fall, alongside iOS 5, we shipped Xcode 4.2. Xcode 4.2 had some brilliant technologies in it, storyboards for iOS, and also the new OpenGL ES Debugger, a great way for you to improve and optimize the graphics in your applications. This spring we shipped you Xcode 4.3, which brought support for Developer ID for OS X, but it also introduced some significant improvements in the packaging and distribution of the Xcode tools.

With Xcode 4.3, we kind of turned the tools on their head a bit. Instead of shipping you a large Developer folder full of disparate tools, we instead are now going to ship you a single Xcode.app with everything you need embedded directly inside. And this has really been a great improvement for the installation and update experience for the tools.

In addition to repackaging Xcode, we also broke out some of the related tools for the development process into smaller incremental packages. And these packages are focused around kind of domain-specific areas, things like graphics applications, audio tools, and hardware utilities. Now, these packages are available from Apple's Developer website to download directly, or you can download them through Xcode, making it really easy for you to get these tools wherever you want to use them. And as separate packages, we gained the ability to update these outside of our normal release process, so we can make sure to get you the latest and greatest fixes quickly and easily.

In addition to these packages, we also broke out some other content. For those of you who may prefer to bask in the warm glow of a terminal window most days, we also shipped the Command Line Tools package. This package gives you all the tools necessary to work with your open source and community projects directly from the command line. So whether you'd like to use a graphical IDE or you'd like to stay in terminal, you now have the ability to access all of Apple's Developer Tools to work with these projects.

Last year we stood up on stage here at WWDC and said we were going to improve the installation and update experience with the tools. At the time we were shipping an installer app in the App Store, which meant getting the tools was a multi-step process. You had to download the installer, you had to find the installer, you had to run the installer, and then you could get access to the tools.

I'm really happy to say that getting the tools now is a completely hassle-free process. You can download Xcode right from the App Store, just as you would any of the other thousands of applications. And you can be notified when updates are available. So this is a really big improvement to the installation process.

But we also wanted to make sure to update the update process, and for that we needed to address the download size. Last year when we shipped Xcode 4.1, our download size was a little bit over 4 gigabytes. And I don't think there's anything more to be said about that.

When we shipped Xcode 4.2, we were able to shrink the package size down to about 1.5 gigabytes by making some of the legacy content, like the older iOS simulators, downloadable on demand. Now, this is a huge improvement, but even at this size, we know that getting the tools can take a little while over slower connections. And we wanted to improve still. I'm happy to announce that yesterday we shipped Xcode 4.3.3 in the App Store as a 97-megabyte update.

Yeah, we are actually really happy, and apparently so are you, that we're able to deliver these kinds of updates to you. In fact, the model of the App Store makes it really easy for us to focus on small targeted bug fix releases as well as larger more complete releases with the iOS and OS X SDK updates all using the same mechanism.

And this is really important to us because we feel very strongly you guys should always have the latest and greatest tools as easily as possible so you can get the latest fixes, adopt the latest APIs and leverage the latest features in order for you to leverage those during your development process.

So we have two great new versions of Xcode to talk to you about this week. That's Xcode 4.4 and Xcode 4.5. Now, the core of these tools is the same. Xcode 4.4 delivers the OS X Mountain Lion SDK, and Xcode 4.5 adds in the iOS 6 SDK. I'm happy to announce the first feature, which is that we are for the first time going to be supporting these tools running on multiple OS releases from a single binary. So what does that mean? It means for the previews and for the full releases, you'll be able to run Xcode 4.4 and 5 both on OS X Lion and OS X Mountain Lion. So now getting access to the latest tools is really simple.

Now for these releases, we've been focusing on the core functionality of the tools. We've really been focused on the robustness, the stability, and the performance, and focusing on some key features. And I'd like to talk about some of those key features today, starting with language. And by language, I mean the Objective-C language, of course.

Objective C is the foundation and cornerstone of both the iOS and OS X platforms. As an object-oriented extension to C, it's gained many modern conveniences and enhancements over the last few years, as we want to make the development process easier. A few years ago, we added declared properties, and this is a really simple and intuitive way for you to manipulate and manage the accessor methods for your objects. When we provided this syntax, we also included some directives, like @synthesize and @dynamic, to allow you to control how your properties would be provided.

We wanted to make properties even simpler. So this year, with the latest tools, you will now find that the compiler will automatically synthesize your properties. What does that mean? It means you no longer need to type @synthesize ever again. And implementing properties is now a single line of code.

Last year, we also added to the memory management models of Objective-C and removed the need to write these methods ever again when we introduced Automatic Reference Counting, or ARC for short. Pretty much true to its name, Arc gives you the ability to use simple and automatic memory management from the runtime and never have to write retain and release again. And it's a really simple way to manage your objects.

Now, we've been focusing on some other great new features for you. And in keeping with the theme of less is more, we have a great new technology to introduce to you, which is in the form of object literals. Now, object literals are a succinct way to write common code. You're undoubtedly familiar with the pattern we have today for strings.

This being quoted text prefixed with the at sign as a shorthand for creating string objects. We have four new versions of the object literals for you to use in your code. for numbers, dictionaries, arrays, and expressions. And I think the best way to experience these is through a demonstration, so I'd like to bring up Mike Ferris to show you how they work.

Mike? Good afternoon, everybody. You know, hundreds of millions of people really love the apps that you create. Let me show you how the new Xcode makes it even easier to create these great applications. LLVM has a great new syntax for creating literal numbers, arrays, and dictionaries. Here we can see some code that's creating these objects in the traditional way.

Now the new way to create an NSNumber is very simple. It's just an @ sign followed by the number. If you want a numeric expression or an enum constant, you can just wrap it in parentheses. For arrays, we use square brackets. And the best thing of all is there's no longer any need to nil terminate. Dictionaries use curly braces containing comma-separated key-value pairs where the key comes first.

and the rest of the team. We've always had NSString literal objects too, so let's just round out the full set of literals here. And as I do, notice another new feature in Xcode. We have code completion showing us documentation right here. We're bringing the documentation right into the code completion window. And NSString is selected as the default completion.

Because now Xcode remembers my most common completions and will actually use those to prioritize its results. Okay, so this is the full set of object literals, and as you can see, we have a bunch more code down here that could be improved with these. So let's get started with that as well. I can just go to the refactor menu and choose convert to modern Objective-C syntax. I'll confirm what target I want to convert, and then Xcode will actually look at all my code and figure out where it can improve things with this new syntax.

We see the new code on the left, and as you can see, it's really a lot more compact and more readable. So we'll accept that. Let Xcode make those changes. Now, another great new feature is automatic property synthesis. So with @synthesize being the default, adding a property is now just a single step.

I see that I have some @synthesize statements here in my class, and I know that I probably have some elsewhere in this project as well, and I'd really like to remove them. I don't want to actually change parts of this project, though, that belong to other people on my team. So let's use another new feature in Xcode to help out with that.

To search just part of a project, use the context menu in the search navigator, in the project navigator rather, to choose search and select a group. We'll be taken to the search navigator where now all the searching that we do is going to be scoped to just that group. So I can find all the synthesize statements, and yeah, there are a number of them in my code here.

I'd like to use replace to get rid of these, but of course if I do that now, it's just going to remove the @synthesize and not the rest of the line. I could use regular expressions to try to match the rest of the line, but I can never really remember how those work. So instead, let's use another new feature in Xcode, simple pattern searches.

I can use insert pattern to put in a token that will match any sequence of characters, followed by a semicolon. and then a line break. And now we can do the search. And now you can see that Xcode is matching the entire synthesized statement, the whole line. And when we replace, I can get rid of all of them.

Now I'm done searching. Let's focus back in on the code. I can see that this is starting to look pretty good. All that extra synthesis is gone, and my literals are looking a lot nicer. But what's kind of standing out to me now is that I have all these forward declarations of private internal API that, you know, keep me from immediately seeing the good stuff in my class. And it turns out that I don't really need these anymore either. It's no longer necessary to forward declare methods that are only used in the implementation block of your class. So let's delete those as well.

Now this is looking great. When I look at this file, I immediately start to see the interesting content. And by removing all that synthesis and forward declarations, my code is actually less error-prone because that was just duplicated information that I had to keep in sync. It's amazing how little stuff like this can be such a huge help when it comes to readability and maintainability of your code. Now, as you're typing all this nice, clean code, Xcode is paying attention. And it's figuring out a lot of interesting stuff about your project. and it uses that information to enable some great workflows.

For example, I have here a category on UI Bezier Path that implements a method that implements a behavior that I know is now provided by the iOS 6 SDK as built-in API. I want to remove this since there's no point in replicating functionality the SDK is giving me for free.

In order to get rid of this safely, though, let me use another new feature of Xcode to help out with that. Here in the Assistant Editor, I'm going to choose the new Callers Assistant category. Xcode immediately shows me code that calls the method that I have focused in my primary editor. And as I move my selection around, it continuously updates to always be showing me things that call the code that I'm currently focused on.

This gives us a great new way to explore the way control flows through our code. Going back to the method that I want to remove, the assistant is telling me that I have two calls to this method in my class, or in my project. As I change the first one, it's no longer a caller of my category method, and Xcode automatically notices this and updates the caller category to show me that I now have only one call remaining to this API. As I change the last one, again, Xcode will notice, and now the assistant is telling me that I'm done. And so is my demo. Thanks very much.

So as you can see, the new object literal syntax really improves the readability and writeability of your code. And the new auto synthesis of properties reduces the amount of synchronization necessary when working with properties. And we think that these and the rest of the Objective-C features are really going to improve your experience when working with Objective-C.

Now, in as much as we talk about the future, we also need to address a little bit of the past. As you heard yesterday, the memory management model garbage collection has been deprecated starting with OS X Mountain Lion. The latest release of Xcode now includes support in our Arc migration utility, which will automatically convert your application to Arc.

It includes support now for converting garbage-collected applications. So now it is really easy for everyone to be able to move their applications over to Arc and take advantage of the features it has to offer. So those were just a few of the language improvements. Mike gave you a sneak peek into some of the editing improvements in the IDE, and I'd like to dive into those in a little bit more detail.

The first feature is Code Completion with Quick Help. Mike gave you a demo of this, but now in the Code Completion UI, in addition to seeing the available API, you now also see an abstract, excuse me, for the method that you have selected. And this is a really great way for you to learn about and adopt new APIs in your code. If you find that you want to learn more about this API, there's an associated More link in this window that'll jump right into the documentation to give you all the information that you need.

Now sticking with the idea of learning more about your APIs, we've also improved the Quick Help experience in the editor. And Quick Help is a great way for you to learn more about the APIs that are already in your code. To use Quick Help, you simply take the cursor and move it over a particular piece of API and hold down the Option key. This will bring up the Quick Help cursor, and clicking on the API will bring up the Quick Help popover.

You can see here that we've enhanced the Quick Help experience to include even more information about the APIs, including breakdowns of the parameters for your particular method. So it's even easier now to get help. I'm a little excited here, so I went on to the next feature, which is trailing whitespace removal.

Trailing whitespace is kind of like the pollen of the source code editing experience. Bear with me a second. It's invisible. It builds up over time, and for some of us, it's really, really irritating. The Xcode Source Code Editor now includes a feature to automatically remove trailing white space. So whether it's at the end of a line-- It's okay, you can clap for that.

and Chris Lester. Whether it's at the end of a line or it's on an entirely what looks to be an empty line, the editor will automatically remove this for you. So now your editor can be white, trailing white space, worry free. Another great feature of the Xcode Source Editor is replace in selection.

Now when you are in the find and replace workflow in the Source Editor, you can make a selection, and if you hold down the option key, you will see that the replace all button at the top of the view now converts to an in selection button, giving you much finer-grain control over your find and replace actions.

Mike showed you some of the improvements to the search functionality, searching by groups and the new pattern matching. The Search Navigator now also includes a great new feature in symbolic searches. So now you can search for definitions and references of symbols throughout your project, making it that much easier to hone in on the source code you're looking for. Now, we know that searching is an integral part of the development experience, and we wanted to make sure we had the best searching possible. And that really starts with search performance.

We've really focused in this release on improving our textual search performance, and I'm pretty sure you guys are going to like what you see. As an example, we took the open source WebKit project, which has about 10,000 source code files, and we searched for a string that appears about 50 times. We used the industry standard grep and looked for those matches, and it came in at about 19 seconds. The previous Xcode was a little bit slower than this. I'm happy to say that the new Xcode is now a quarter of the time it takes to search grep.

and this is a really great improvement. And the larger your project is, the more you're going to love this feature. Now, we also wanted to take the power of searches and bring them directly into the source code editing experience, which is what we've done with the caller and callee assistants.

You can think of these as super-fast searches that the IDE performs on your behalf just by watching your selection. So now, if you want to navigate and edit your source code symbolically, you can do so by staying in the editor and letting the IDE do all the work for you.

Once you've made all these changes to your source code, we have some great new improvements to the source code management functions. And the first is selective commit. When you're in the comparison view, that's the side-by-side view when looking at two versions of your project, you'll notice that there's a new control in the middle of the editor. This control provides some really great functions to it with an associated context menu.

And the context menu on the right provides one option I really want to highlight, which is the don't commit option. This option allows you to cherry-pick changes that are in your source code to not commit during this operation. By selecting this, the changes stay in your source code, but you've told Xcode to do all the heavy lifting underneath to make sure those changes do not get committed.

And this really frees you up to make all the changes you feel are necessary while you're working, and then at the time you're going to review your commit, you can individually select the changes that you want to commit. And this allows you to create a new control that allows you to check in your changes. So this is a really great improvement.

Now, once you're ready to commit your changes, we also have a new option at the bottom of the commit sheet. You'll see in the lower left that there's a new control, commit to branch. And this button allows you to create a brand-new branch for your checkout and check in your changes, allowing you to easily pick where your changes get checked in. So this, in combination with the previous feature, gives you a lot of control over what and where you're checking in.

So those are just some of a few of the great new editing features we have in the latest Xcode. But we also have some great design features to talk about. We take the I and IDE very seriously. We want to make sure that your development experience includes design aspects that are really core to the development process. When we built Xcode 4, we integrated Interface Builder directly into the IDE to make sure you had the best possible experience for visual design.

Like with source code, you can focus wholly on your interface to dive in really deep, but you can also marry the two together, working side by side with your visual interface and your source code. and in fact, this model of working with the Assistant Editor even allows you to drag and drop connections between your source code and your interface, making new connections, making new actions, and it's a really natural way to connect up the elements of your interface.

Now we've continued to bring more and more design improvements to the development process to give you guys more of a chance to create the amazing things that you can think of. One that we added last year was Storyboards for iOS. And Storyboards give you the ability to visualize and design your applications in a very fluid manner. You can set up the individual screens for your project, and then connect them all together with segues and transitions. And you can really see and visualize the flow of your application from a high level, which is a really kind of natural way to design your apps.

We also added Auto Layout for OS X, which is a way for you to manage the sizing and positioning of your controls in your interface. With Auto Layout, many of the challenges of interface design were removed with the introduction of constraints. And constraints are the rules with which the interface is defined, and you'll see those as these blue crossbeams in the Interface Builder Canvas.

The constraints give you the ability to design your UI not with just how you want it laid out, but what your intent is behind the interface. Being able to articulate things like these two views should be the same size, or these buttons should always move together. And this is a really powerful way to design the UIs because it reacts in the way you expect. I'm happy to say with Xcode 4.5 and iOS 6, we are bringing Auto Layout to iOS. So now you have all of this power when designing your iOS applications.

It turns out that Auto Layout and iOS are a perfect fit for each other. Kind of by nature, you know that iOS applications need to respond to changes. Something as simple as running an application and rotating a device, you inherently know that the application is going to need to adjust to that new size and to make sure that it continues to give the best user experience in this new layout. And this is exactly what Auto Layout was designed to do, to handle these kinds of changes and give you the power to articulate exactly what you expect to have happen.

Now there's another way that applications on iOS and OS X need to respond to changes, and that's when you localize the content. And now the combination of the power of Auto Layout and some brand new localization workflows make creating localized apps even easier. Before, when you had to localize apps, you would start with your user interface in a ZIP or a storyboard, and you would create a copy, one for each localization that you intended.

Now, besides the obvious scalability problem, there's the synchronization problem. When you decided you wanted to change your interface in one of these, you needed to go and update it throughout all of the different interfaces. Now with the power of Auto Layout, you can focus on designing a single base user interface, one that knows how to respond to changes in the content and to do the right thing. So now creating a localized application is as simple as working on your base user interface, localizing your content, and effectively just hitting run. And to prove how easy this is, I'm going to bring up Jon Hess to give you a demonstration.

Jon? Thanks, Matt. I'd like to demonstrate the precision and intuition of Auto Layout and Interface Builder. Let's go over to the demo machine. Here I have an early copy of our Site Seer application, but the design isn't quite complete. This title area, for example, needs to be moved into the center. I'm going to drop it right here where the centering guide and interface builder suggests. And you can see that automatically this blue line has been added to the interface.

That's a constraint. Constraints in the Auto Layout System specify things like the sizing of a view or the spacing between two views or how views align. This constraint is going to make it so that our title always stays centered in our screen. In addition to the title, I'm going to add a couple of buttons to our interface. I'll have one here on the left and two more on the right.

Now, there's a second constraint that I'd like to draw your attention to. And it's right here between these two buttons. It's a spacing constraint, and it's going to ensure they're always that small distance apart from each other. As I make edits in Interface Builder, for example, changing this button to say "near" to show a list of nearby locations we can see, Interface Builder is going to maintain those constraints, and it's going to resize the surrounding user interface elements. So, the button shrinks, and this button here on the left gets pulled into the right. I'm going to press undo and redo so that you can see that happen again. Watch right here.

This saves me lots of time not cleaning up after myself after I make edits to my content. This button here is going to show a schedule of things that we have planned for the day. And over on the left, we'll have a list of locations that we can visit in the Bay Area.

Now we've got all the major user interface elements in place, let's see how this looks in portrait. All right, things look great. The button that we added to the left stayed in the upper left-hand corner. The buttons that we added to the right stayed in the right corner. And our title stayed centered.

Back in landscape, one thing that's catching my eye here is this Near button. It's really small compared to the Schedule button. In fact, it looks kind of lopsided and awkward. I think it would look a lot better if all three of these buttons were the same width. And you'll often see that in applications where you have a row of buttons that will be equally sized. Setting this up in Auto Layout is easy. I can just select all three buttons.

And down here in the bottom of the canvas, we have a menu to manipulate constraints in Interface Builder. I'm going to choose to pin the width of all three of these buttons equally. So now each button is just the same size as the others. In fact, they're all as big as the largest of the three buttons. If I were to change the title of one of these buttons, for example, to "Today's Schedule," they grow together.

Now, this button is getting a little too close to my title in the center of the screen. And I know we're going to visit some places in this app with really long names. So I'm going to back off that big title. But I want to -- I need to think about how my application should respond when there's not enough room to display the full name in this area that we have here.

One opportunity that I see is the left-hand side of the screen over here has more space available than the right-hand side of the screen. When things start to get really tight for my title, I'd actually like it to push over into that available space on the left. I'd also like to make sure that my title never starts to occlude these buttons on the sides. This is easy. I'm going to just select my title and the button and add a new constraint between them.

This is a horizontal spacing constraint. And right now it's specifying that the title should always be this fixed distance from the button. In fact, though, I'd like the title to be able to grow to fill that area, but not get too close to the button. So rather than saying that this is a fixed distance, I want to say that this is a distance that's always greater than or equal to a small value, like 20 points. And now the title will not be able to grow closer than 20 points to the button. I'm going to specify a matching constraint on the opposite side.

Horizontal spacing, always greater than or equal to 20 points. Now our title can never occlude our buttons. It's always going to stop just short. But our title is also always going to be centered because of the centering constraint. When things get tight and the title grows all the way up against the button on the right-hand side, I want it to push left. I need to tell the centering constraint that it can yield to the other constraints in the system. This is also easy. Constraints have a built-in priority system. And in the inspector, I can simply lower the priority of the centering constraint.

and it will yield as things get tight. For example, if I type a large title here, The title moves to the left. You can see that here with this. The centering constraint is still running right through the middle of the text. It used to be right in the middle of the scene here next to my image.

If I hit undo and redo, you can see how it moved when the spacing got tight over here. Okay, I'm making great use of my space. Let's see how things look in portrait. Oh, ouch. My title just absolutely crushed those buttons on the two sides. I need to make my application smarter than this. Let's go back to landscape.

What I'd like to have happen here is for the title to shrink before the buttons, because the buttons should always stay a fixed size in my application. Just like constraints have a built-in priority system, so do the intrinsic sizes of our user interface elements. I can select my title, and in the size inspector, lower the priority of the horizontal sizing.

Now, when my application shrinks, the title will shrink first, and the buttons won't shrink. When the title shrinks, though, there still won't be enough space to actually hold that text, and so it will get truncated. I'd like instead for the font to become smaller, and UILabel has a great feature for this. In the attributes inspector, I can choose to have the font automatically shrink to a smaller size. For example, let's have it scale to one quarter of its current size if there's not enough room.

Now, if I select the scene and move to portrait, you can see that things fit great. My title is right in the center between those buttons. It's the biggest font that it could possibly be to show all of that text and still leave the padding that we specified on either side. If I was to specify this with the old layout system, springs and struts, I would have had to stop. This layout is actually not expressible with springs and struts. I would have had to write manual layout code instead. Manual layout code is a drag.

Our application responds great to new string changes. I could change this title, I could change the button labels, and everything would resize great because of Auto Layout. And we saw that we could build a great new feature on top of this, and that's the new localization workflow that you heard Matt mention earlier.

Let me show you how you can get started with that. I'm going to select the project, and in the project's editor, I can see a list of all of the languages that our application currently supports. Right now, it just supports English. We have a new checkbox under the table here, "Use base internationalization." When I check this, Xcode is going to offer to take my iPad storyboard and move it out of the English localization and instead into the base. And then for each language that I add to my project, I'm going to be able to add a simple strings file to translate that base storyboard into a specific language.

I can check the box, and Xcode is going to move my storyboard from English to the base, and I can add a new language, German. All of my strings files will be copied from English to German, and a set of default strings will be extracted from my base storyboard. I can see the new strings from my base storyboard here in the project navigator.

Now, almost all of the string content is going to be replaced dynamically at runtime with things like facts about the Golden Gate Bridge, but the three buttons that I added earlier are static, and their strings are displayed here. I know just enough German to translate these, so let me replace those couple of strings.

and Matt Fischer are all here. Now, I've already configured the iPhone simulator to launch in German. Here it's running, here's our application, and here's all of our content translated into German. The buttons look great, the title looks great, and all my content specified with Auto Layout looks great. We think you're going to love this new localization workflow. Back to you, Matt.

Thanks, Jon. As you can see, creating a localized application is now just as simple as working with Auto Layout and your localized content. We think you and your users are going to enjoy this feature. Now, in addition to great editing and design tools, the Xcode suite of tools also includes great optimization tools, ways for you to improve your applications.

The Xcode IDE includes a number of live editing features to help you sort out problems that you might be having. Undoubtedly, you've seen the error and warning icons that appear in the editor, pointing out points of problems. The editor will point out the exact line and character at which the problem exists, and in many cases, will give you helpful suggestions on how to fix the problem.

These and other features, like code completion and syntax coloring, are made possible because the Xcode IDE has a deep understanding of the semantics of your project. And that's all made possible because we have the LLVM technologies built directly inside of the IDE. And to give you an overview of all the amazing things possible with these technologies, I'd love to bring up Chris Lattner.

Chris? Thank you, Matthew. LLVM technologies power some of the underlying capabilities that make Xcode great, such as code completion, live issues, and it has three primary features of its own. This includes the LLVM compiler, the Xcode static analyzer, and the LLDB debugger. There's a lot going on in the new release of Xcode, so let's dive in and see what's new in each of these, starting with the compiler.

This year we're releasing Apple LLVM Compiler 4 with a huge number of great improvements, including improvements to the generated code, faster builds, and a lot of other wonderful stuff. Now, one of the most visible improvements to the compiler is the language support. Mike and Matthew have already shown you the great enhancements to Objective-C, which I hope you'll love. Let's talk now about C++.

C++ is a great language. It's also a very large language. Looking back on our clicker, looking back to just last year, we first shipped Xcode 4, which had initial support for C++ in the LLVM compiler. This was not that long ago. Not only did we support C++ in the compiler at that point, we also added it to the IDE as well.

This gave great support for code completion, syntax highlighting, all the other IDE features that you've come to know and expect. Well, we weren't content to just stop there with C++ support, and so we set our sights on C++ 11, the next major enhancement to the C++ language. And later that year, in Xcode 4.2, we released the next big set of features in the compiler.

Of course, C++, it turns out, is a big language, so we kept going. And we added another great set of features in Xcode 4.3 and 4.4. Well, at this point, we have the vast majority of the features in C++ 11, including things like Unicode support, Atomics, and one very specially requested feature by many of you, C++ 11 Lambdas.

Now, we are committed to providing full support for the C++11 standard. And even though we have a few more features to go, I'm really excited to say that at this point Xcode 4.4 is leading the industry in support for C++11, which means that if you have a portable C++ code base, it's really straightforward to bring it right to our platform. Now, language is really important, but it's not the only thing we've been improving in the compiler. Another area that we've been specifically focusing on is compiler warnings.

Now, compiler warnings are an important aspect of the compiler experience, right? This takes the analysis power that the compiler uses to generate machine code from your source and identify issues and problems and places that you can improve your code. So we've made a number of enhancements to warnings this year, including improving our support for format string checking to support Objective-C APIs.

APIs like NSLog and NSString string with format. And as you'd expect, the compiler doesn't just say, hey, you got a problem right here. It also says, hey, here's a fix, right? And it shows you exactly what you need to do to correct the problem and then, you know, move on with making your applications great in other ways.

Now, compiler warnings have been an important part of the compiler, and we've been adding many of them for quite some time now. But this kind of raises an interesting question. While it makes sense to turn on a lot of warnings like this by default. Some of them are not. Some of them are very specific to certain kinds of applications. And how do you get them? Well, normally you'd start out with a flag like, you know, our friend wall here.

Well, despite what you'd expect, wall doesn't turn on all the warnings in the compiler. And so you end up accumulating a pile of other flags and maybe you read some cool blog and they showed you some neat tricks that you could get. But this is really a poor answer, right? I mean, a new version of the compiler comes out, you don't know about all the gray enhancements in it, and how do you know what to turn on? Well, we took -- we took a few of the things that we took and implemented a very simple answer for this problem, which we call weverything.

I don't think I need to tell you what this does. Based on this, which really does turn on all the warning flags in the compiler, you can then choose to opt out of warnings that you don't want, which means that you get maximal feedback from the compiler, and then you can tune it for your code base.

And so you get a great experience, and when a new version of the compiler comes out, you can immediately take advantage of any new warnings it has. Now, the compiler warnings are really powerful because they run every time you build your code, but that's also kind of a limitation because some bugs can't be found in the amount of time you want to spend in line with your build.

To find deeper bugs, we have a tool called the Xcode Static Analyzer, which goes much further. The Static Analyzer uses deep compiler analysis to really understand your code and all the way down to the level of exploring individual paths and error conditions and all kinds of stuff in your code. Now, like the compiler and the rest of Xcode, the Static Analyzer has a number of great improvements, one of which makes all of the existing analysis checks more powerful, which we call cross-function analysis.

Now, here's a very simple example. I know this looks like production code. And you know, we have two simple C functions, bar and foo. Bar calls foo. Really creative here. If you ran this through a previous version of Xcode, it would see no problem with this at all. If you run it through Xcode 4.4, immediately it points out an issue. It says, hey, you're turning garbage data out of your function.

This is a really bad problem because this is the class of problems that could work fine for you on your desktop. You ship it to your customers and suddenly you're getting bad reviews in the app store because your apps aren't working right and you have no idea what's going on because it doesn't reproduce.

Well, now Xcode will find these classes of problems and, you know, of course, that's not enough information to fix the problem, so you just click on the issue right in the editor and out pops a series of steps that are exactly what you need to know to reproduce and, more importantly, fix the problem. If you haven't already, I highly encourage you to run the SAC Analyzer by building and analyzing your code. It will find all kinds of really nasty issues.

Now, beyond cross function analysis, we've also made the analyzer more powerful in other ways by implementing checkers for really important APIs like Grand Central Dispatch, various security APIs, and also for the very popular Malik and Free API, so I think you'll find that the checker is even more powerful than before. Now, like compiler warnings, the SAC Analyzer can be individually controlled in the build settings inspector where you can enable or disable individual checks so you have really fine-grained control over the checks that make sense for your code.

Now, the Static Analyzer and Compiler Warnings are really powerful and they're really great tools, but they're not going to find bugs in your code that just cause it to misbehave, right? If it behaves in some way that you wouldn't expect, that's when you turn to the debugger. And we have a great debugger named LLDB.

If you're not familiar with LLDB, it's very similar to GDB in a lot of ways. It has a great Xcode user interface, has a great command line console interface, and you may not realize it, but LLDB became the default debugger in Xcode 4.3 earlier this year. You may not realize it because the Xcode experience for LLV is very, very similar to that of GDB.

Well, it's just like GDB, except, you know, it starts up a lot faster. Let's see here. It's more correct. The data formatters work more often. It'll even show your variables now and then. I mean, it's basically just like GDB. It's just that, hey, it works. How about that? But LLV has a number of enhancements above and beyond GDB also.

Things like it builds right on top of all the LLVM technologies we've been talking about, which means all the Objective-C, C++11, and other language syntax works right in the console. And so here you can see I'm playing with an NSDictionary using new subscripting syntax. I'm building a dictionary with that curly brace. It all just works, right? I mean, this is what you'd expect from the debugger.

Now, LLV has a number of other great features. It has really powerful data formatters. One really powerful new feature this year is that we've implemented support for hardware watchpoints on iOS devices, which means it's really simple to track down really nasty memory problems even if they only reproduce on the device. If you're familiar with watchpoints, I think you'll really love this.

Now, with all this talk about GDB and LLVM, you may be wondering, what is our plan for GDB? If you look at our technology platform now, we have a default compiler, which is the LLVM compiler, a default debugger, which is the LLVM debugger. Now, Xcode 4.4 and 4.5 still support the older LLVM GCC compiler and the older GDB debugger, but at this point, they're officially deprecated and they'll be going away next year.

Now, I don't know about you, but we are really excited about this because this means that we'll finally have a single compiler, a single debugger, and now we're going to be able to innovate even faster going forward, which is better for everybody. So if you're still using the older technologies, now is the time to move and keep going.

Now, coming back to our technology platform, we've been talking about LLVM technologies. There's more to Xcode's debugging and analysis capabilities than just these LLVM technologies, so let's take a look at some of these right now. We have two great tools for this. One is the Instruments Performance Analysis tool, which can pretty much tell you anything you want to know about how your application is running and what it's doing at runtime, including telling you about memory use, network, disk I/O, system calls, just about anything you could want.

Last year we also introduced the OpenGL Frame Debugger, which can capture and play back the series of OpenGL API calls, and better yet, show you the textures and the resources that your application is using at runtime so you can see what's going into a frame. This year we've gone even farther beyond that by integrating OpenGL performance information directly into the Debug Navigator, and we've even built an entire OpenGL Expert right into the tools. And instead of telling you all about this, I'd really like to invite Ted Kremenek up to show you how it works.

Ted? Okay, great. So here we are in Xcode, and we're looking again at the demo application that we showed you earlier today. And this time, I'm going to go ahead and run this on an iPad 2 that's sitting right here in front of me. So let me switch to that display.

Okay, here we are. So we've got this beautiful photograph of the Golden Gate Bridge, and we've enhanced this application to show a new OpenGL visualization that shows the 3D model of the bridge. And this is going to showcase some of our debugging features because it doesn't quite work as expected.

including expanding to the OpenGL view. Here we go. So great view of the Golden Gate Bridge. And beyond just panning around the bridge itself, I've enhanced this view to respond to touch. So it's supposed to change the camera angle when I touch the screen. But I haven't actually tested this yet, so let's see if this actually works. And apparently it doesn't.

Instead of the camera angle changing, it stopped. So I guess I could call this a feature, but this is actually not the behavior I intended. Let's look again at Xcode. And we can see that we stopped right in the debugger. And on the right, we see this exe bad access message. And that's Unix parlance for you to reference a bad pointer value. Let me pull up the variables view at the bottom.

So we were referencing a field off of this variable ggdpp. If I expand it in the variables view, you can see it's just a bunch of garbage pointer values. The debugger can even tell that it can't safely dereference them because these floating point values aren't getting printed out.

So I have one of two possible problems. Either I failed to initialize the object correctly or I just collaborated somewhere along the way. Let's go ahead and investigate what's going on. Using Xcode's navigation features, let's see where this variable was declared. Here I can see that it's a static global variable. It's a pointer. And it's actually initialized to being a null.

So this means I must have initialized it somewhere or else I would reference a null pointer instead of just some subfield that was garbage. Since it's static, I know that its visibility is restricted to this file, so let's just go ahead and scan downwards. And here we see some lazy initialization logic that appears to be firing when this view starts up.

Now, perhaps I messed up when I wrote this code. Maybe there's some logic bug in this lazy initialization routine. So let's go back to breakpoint and see what happens when I rerun the application and stop at this point. Not much to see here. I'm just opening up the OpenGL view you saw again. And here we've stopped in the breakpoint as expected. The variables view shows that it's still a null pointer, so nothing else has gone on until this point.

Let's look at this helper function to see what's going on. As you can see, it's just standard boilerplate initialization code. We're just creating a bunch of structures, initializing them, and we see them showing up in the variables view. Everything looks fine here. These values look just what I expect them to be. I see floating point values. Let's get out of this function, and immediately we see one of the great new enhancements to the debugger user experience, and that now the return value of a function you just stepped out of shows up in the variables view.

And this is great, because if this value was consumed in some larger expression, you wouldn't have seen it, right? You might have to restructure your code in order to, you know, debug those kind of values. Let's step one more time and see if that value is getting assigned correctly to the variable that we cared about. So I can rule out bogus initialization.

So this means that at this point, I think I just must be collaborating this somewhere else. And to debug this, I could do a variety of things. I could create a whole bunch of breakpoints within this code, and just try and, you know, bisect down to where the problem is happening. Maybe I could even add logging statements.

Instead, let's resort to a far more elegant technique and use hardware watchpoints. I can add a watchpoint just by clicking on the variable and saying "watch" in the variable name, or the field name in this case. And what will happen is when I continue the application, when this memory is modified, the debugger will stop. This is exactly what I want to see. So let's continue. I'm just going to touch the screen one more time.

And here we have our smoking gun, right? We're doing a mem copy right over that memory address, right? We're just blowing away all those fields. And it doesn't take much effort to see what the problem was. It looks like I have a single typo where I meant to copy into this variable, but instead I was copying into the global one.

So easy mistake. Maybe it was copy/paste. But it leaves me a little nervous, like, well, what other problems like this are still in my code? The debugger was great for finding this problem, but if I hadn't actually tested all the code paths, maybe my user is going to experience something that I just didn't test completely.

So in Xcode 4.4 and 4.5, we've significantly enhanced the Static Source Code Analyzer to help you find issues like these. It won't find necessarily all of them, but it will do a vastly improved job of doing so. Let's go ahead and run the Static Analyzer on this now.

This does a comprehensive source code analysis without running your program, and we immediately see an analyzer warning coming up very close to the point where we have the problem. We click on the issue, which says that we're using a garbage value as part of a multiplication. We get this rich diagnosis of a bug.

And we can see from the start of update scene, we declare our variable, and we step into the function copy bridge position. And you can see in the navigator bar at the top, we actually have this abstract call stack that you can dig into. And we can see the analyzer is actually doing a deep reasoning of this code. And it can tell that that memory is not actually properly initialized because that value is not used.

Just simple things like this is going to greatly improve the analyzer's precision. It reduces false positives and increases its coverage over understanding what your code is doing. So the fix is simple. Just change a single character. The power of demos, the fixes are easy. And let's rerun this application. Here we have the Golden Gate Bridge. But now when I actually touch it, the screen, you know, the camera changes just as I expect.

Now, there's one thing about this that isn't really so appealing right now, even though it's not crash anymore, is that the frame rate is still pretty choppy. And we have some great new performance analysis tools in Xcode to help you dig into these problems. If you draw your attention to the debug navigator up the top left, we see this live view of frames per second of your current OpenGL view. And it's color-coded in red because the frames per second isn't really all that great.

Here in these histograms, we have this live view of essentially how you're bound in terms of computing the current frames. Here we see that we're GPU bound. And if I click this Analyze Performance button at the top, it summons that OpenGL expert who's going to go and do an extensive performance analysis for me.

What's happening at this point is Xcode is sampling a current frame from that 3D rendering. It's logging all the OpenGL calls needed to construct that frame. And then once it does so, it runs a series of performance tests on the device itself, essentially trying to manipulate the graphics pipeline to see where the performance bottlenecks might be. Now, this is taking a little bit of time, but if you contrast this to what an OpenGL expert might do, they might run these tests over the series of an entire afternoon, whereas Xcode is running it for you automatically in a matter of minutes.

Now, in just a moment, as you can see, we have this progress bar here, and you can't see it right now, but basically the display has gone black on the iPad because it's running these tests. But in a moment, you're going to see some diagnostics come up here. Great. So immediately, the OpenGL Performance Analyzer says that we're fragment shader bound, and because of that, it's going to run additional experiments.

If I have the Assistant Editor over here on the right, if I click on specific issues, it'll bring me to the shader or the draw call that's responsible for some of the performance issues. And from here, I can really dive in and do an extensive performance analysis. So all of this is really great. From this, I'll be able to improve the performance of my rendering. And we have shown you just a few highlights of the new debugging and performance analysis techniques we've added to Xcode 4.4 and 4.5. We think you're really going to love them. Thank you very much.

Thanks, Ted. We are really excited about these improvements to our performance tools. Static Analyzer with now cross-functional analysis, all the improvements to LLDB, and the new enhancements to the OpenGL ES Debugger with the Performance Detective built right in. We feel these tools are really going to help you guys take all of your applications to the next level. Now, of course, once you're done optimizing your applications, the next thing you want to do is ship it. And Xcode has a full complement of tools built in to help you achieve this goal.

Whether you're trying to ship your application to the App Store with Developer ID or through another mechanism, Xcode has complete integration with the Apple Developer Programs to make this easy. If you're a Mac developer and you want to use Developer ID, there's really nothing more for you to do. Xcode will automatically request and download your Developer ID certificate, and you can get off and running.

If you'd like to ship your app in one of the app stores, Xcode and the Developer Portal automatically integrate to give you guys access to the assets necessary for your applications. Xcode and the Portal will collaborate to give you access to your group's definitions and teams, your devices, all of your provisioning profiles and certificates, pretty much everything you need to do. And this includes updating your provisioning profiles to use the latest features and enhancements.

The latest Xcode includes support for some of the new features and entitlements that were announced just yesterday. Two that I would like to point out. The first is in-app purchase content. Xcode now includes a project template for you to create your in-app purchase content, and will support submitting the content directly to the app store alongside your application. Xcode also includes development time support for working with Passbook and transit apps, so you can adopt these very quickly for your applications.

For OS X developers, Xcode also includes really easy support for setting up and enabling sandboxing for your application. The target editor includes a rich selection of sandboxing options for you to enable, and you can get off and running. Now, when you're ready to deploy your application, Xcode's archiving feature makes it really easy to package up and deploy your content. Simply select the archive option under the product menu, and Xcode will do all the work underneath to package up your content. You'll find all of your archives in the Archives Organizer.

It keeps a historical list of everything you've built. And once you've found the archive that you want to distribute, it's as simple as selecting it and clicking the Distribute button in the upper right. For iOS developers, you have the option to submit directly to the iOS App Store, save for enterprise or ad hoc deployments, or share with another one of your team members.

OS X developers can submit to the Mac App Store, sign with a developer ID, or export to share with, for example, a beta tester. So no matter what audience you're targeting, whether it's a beta tester, a member of your team, one of the app stores, or using developer ID, the Xcode IDE has a complete set of tools to make that possible.

So now is your opportunity to go out and try these new tools. As a reminder, we have two versions upcoming. Xcode 4.4 alongside OS X Mountain Lion, and then later after that, you'll see Xcode 4.5 alongside iOS 6. For this week, we're giving you access to Xcode 4.5 as a preview. And as a reminder, this application version works on both OS X Lion and Mountain Lion, so you can get started right away. And with that, thank you very much.