My name is Chris. I get to give you a quick tour on some more details on what's new in Xcode. Xcode 5 is the product of a real passion and drive for building really great tools. It builds on the foundation of Xcode 4 which is really solid, that has a few additional, very pragmatic things to solve common problems that maybe you've been asking for, as some really big leaps, and also has a nice new look and feel, so let's dive in and see what's going on here. So I hope you've already had a chance to install Xcode 5 on your machines and play with it a little bit and hopefully you'll have already seen the new look.

In a word, Xcode 5 is about deference to your content. It's all about bringing your code front and center so that you can focus on your application, and what you're doing instead of thinking about Xcode. Now, the new look is clean and beautiful. But perhaps, the biggest change is to the new Toolbar.

New Toolbar is now 30 percent smaller, which is a huge improvement particularly if you're using one of our new 11-inch MacBook Airs. Now, when you take Xcode full screen, the Toolbar virtually disappears giving you this amazing full screen experience and Xcode just looks gorgeous, our beautiful Retina displays.

Now, there's many changes in Xcode, one of the big ones is that documentation has been split out to its own full top level window with complete tab support. Documentation is super important and now, you have direct access to a Table of Contents, your Bookmarks, Xcode even makes it super easy to share links right from the ID.

Now, Xcode 5 intentionally feels a lot like Xcode 4, but there's one aspect of the field that we thought could be much improved, and that's in performance. Now, Xcode 5 just feels great. It's fast and responsive, common operations like plugging a device now responds instantly. Tabs, you can create them when you want them and they feel snappy. And common operations like doing an incremental build, searching in your project and building NIB files are now up to twice as fast. I think you're really going to like it if you have not played with it.

Now, there're many big feature changes in Xcode, one of the most obvious is in Source Control. Source Control in Xcode 4 has always been super powerful. But Xcode 5 takes it even farther by directly supporting branch-based development workflows that many of you use to build your features. And of course, the first place you want to start with Source Control is by checking out your project. If you haven't seen it, this is the beautiful new Xcode Welcome window which is just-- just stunning in its simplicity. Now you can start a new project, get going with an existing project or, if you check one out, you dive in to the newly enhanced Checkout Workflow.

The new Checkout Workflow makes it really easy to browse around different repositories, keeps track your favorites and recent locations. Its just generally is designed to get going really quickly. When you jump into the editor, things are even better because now you'll see that you have a new top-level Source Control Menu item.

Why does this matter? Well now, Source Control is available to you all the time, right from the editor. You have common-- you have access to common operations like doing a Commit, and these operations now know exactly which project, or workspace you're working on. So they're completely contact sensitive. It's not a matter of applying Source Control operations to an abstract list of repositories that you have to keep straight yourself. And again, branch-based development workflows Xcode now makes it really easy to create new branches, switch branches, and even merge right from the editor. It's just that easy.

Now, it doesn't stop there. Xcode even brings per line blame information right into the editor. This makes this really easy to find out who changed the line of code, which for me is actually really important because when I finally get to the root of some bug, the first thing I need to do is find out who did it and go point the finger at him.

So now in addition to being super powerful, Source Control Xcode 5 is also super configurable, and we think this is really important because it means that Source Control can work the way you want it to. Now, Source Control can be told exactly what you want-- want you want it to do for you automatically. If you're using an external version controlled tool, you can turnoff Xcode source control entirely.

And if you prefer the left and the right sides of disk to be swapped? Hey, now you can do that too. It's just that easy. Now, while Source Control being super powerful and configurable is great. There's one thing that I really don't like configuring, and that's provisioning profiles.

With Xcode 5 and a new automatic configuration feature, this is a thing in the past. So, what is automatic configuration? In a word, it's super simple. Now, you just tell Xcode your Apple ID, and it automatically knows your connection to the developer program to the App Stores, and that means that Xcode can get your-- set up your provisioning profiles, create entitlements, and it knows your team identities right away, just from that one little piece of information.

OK. So what does that do for you? Well now, Xcode knows who you are, including the many different who's that you may be. It allows you to enter that directly into the project editor which makes it super easy to switch between your different identities, maybe your contractor and you work on different projects, or different clients. Maybe you have work projects and, you know, you love coding so much you have your own home projects, right? Now it's really easy to control this all directly with an Xcode. It's just super easy.

Now, much bigger win of Automatic Configuration comes when you pull in a second feature called Capabilities. A Capability is a high level concept in Xcode that pulls together everything you need to add an Apple service to your application. Things like iCloud or Game Center, they require the client and server to be in sync.

Now previously, setting up iCloud for example would require they do multiple steps with an Xcode, and then multiple steps on the portal even before you start writing code. With capabilities, and automatic configuration, it's now-it can be easier. It's just a matter of turning it on and your feature set up for you automatically.

Xcode handles all the grunt work of sending provisioning profiles, create entitlements, even goes and links in a framework, and updates your Info.plist all for you automatically. So now, you don't have to keep track of how to do this and you just don't have to worry about it anymore.

So now that we've set up our application, we've checked it out, we're ready to go, let's talk about how to design it and let's talk about specifically the interface. Now you all saw iOS 7's great new design and look and you may be wondering how do you get your applications to fit in and feel like part of the ecosystem? Well, Xcode 5 makes it super easy and has several power tools that will make your applications look great. Now, the first feature is Auto Layout.

Auto Layout is not a new technology, but it's super important. It allows your applications to respond to dynamic changes and layout constraints. Well, what does this mean? Well, examples of these are the resolution increase on the iPhone 5, or if-- I'm sure you're all localizing your applications, right? If your strings are changing size because you switch to German mode and everything is crazy long there, you want your application to look beautifully no matter what language people are using it in, right? Well, Auto Layout is perfectly designed to solve this problem and given the constraint changes-- or the control metric changes in iOS 7, it's more important than ever. And this is why Xcode 5 has gone back to redesign how Auto Layout works to put you in complete control of your Auto Layout constraints.

So the best thing about this is it couldn't be simpler. Now, you can add and even delete constraints whenever you want. If you add a constraint, Xcode won't change it on you. And Xcode provides-

And Xcode provides a lot of great features for solving common problems, telling you if there's something that needs to be fixed and adding constraints for you automatically because all the previous on-demand behavior is now at your fingertips when you want it. It's really great. So to wrap-up our quick overview of layout and interface design, I want to talk quickly about the Asset Catalog. The Asset Catalog is a new feature of Xcode 5 that shows up as a single entry in your project. This entry now collects all of your image-based resources such as your Launch Images icons, list images that you use in your project together into one place.

Well, in addition to cleaning up all the clutter from your project, Xcode knows about the multiple different resolutions you need. It knows about what devices you're targeting and what resolution icons and all that stuff that you previously had to just know, naming conventions, everything and it handles it for you.

If you're missing something, it's now immediately obvious. Also because-- also Xcode knows about new iOS 7 APIs and so it can even optimize the loading of your image-based resources using these new APIs. And it does it for you automatically so you don't have to worry about it, it's great.

And building on the Asset Catalog, you saw the great new Image Slicing feature of Xcode. These makes it easier than ever to make your images resizable and it just feels natural. Now, to show you how to bring your application to iOS 7, I'd like to invite up Jon Hess to show you how to do it.

Thanks Chris. My colleagues and I have been working on iOS Application for tracking your runs and exercising application. It lets you seen here by routes, earn achievements and challenge your friends. I want to show you just how easy it is to update this application for iOS 7 using the new features of Xcode 5.

First, we need to get started with a new copy of our application. From right here on the Welcome screen, I can choose to check out an existing project. In the streamline reposit checkout workflow, I can see all my repositories, my recent repositories, or I can focus in right on my favorites. I'm going to grab a copy of JogR and check it out to the desktop.

Now, we have several independent yet related tasks that I want to show you today for updating our application. This is a great opportunity for us to use a Branch. Creating a Branch in Xcode 5 is easy. From right here in the Source Control Menu at the top of the Main Menu, I'm going to choose New Branch. I'm going to give it a Name, and I'm done. Creating a Branch in Xcode 5 is just one step.

Now, earlier when I checked out my project, you may have noticed there are several repositories available for me to access. I have configured each of those in the accounts preferences in Xcode. Another type of account that I can configure is my Apple ID. And if my Apple ID configured, I can choose a team to associate with my application.

By associating a team with my application, Xcode help-- able to help me in all sorts of ways. For example, I can find the right signing identities and credentials to use when building application. It also helps me here in the Capabilities tab where I can see a list of all the Apple services that I can adopt in my application.

I'm specifically interested in the new background modes feature of iOS 7. I want to be able to update our applications so that it continues to get location data as the user runs. Turning on the feature is easy. I'm just going to flip the switch, take a look at available options, and often do location updates. Xcode takes care of all of the details. We have to update Info.plist keys, link new frameworks, change entitlements, provisioning profiles, it's all taken care of for me, and I don't have to remember each of those small details.

That's great because I have trouble remembering those details. Another area where I have trouble remembering the details is with image names. I can never remember if an image is supposed to be named, @2x tilde iPhone, or tilde iPhone@2x. Xcode solves all that for me, there's a new feature in Xcode 5, Asset Catalogs.

With an Asset Catalog, I can name the resources any way that I want. I can get started with an Asset Catalog just like any other document by creating a new instance from the templates. I want to show you how to move my existing content into a new catalog.

From right here on the project editor, I can see my app icon. And I can choose to use an Asset Catalog. Xcode is going to migrate my app icon into an Asset Catalog for me. I'm going to choose to bring my Launch Image along too and migrate them both.

Here in the groups and files tree, I can see my new content, the app icon, and my Launch Images. There're some new empty slots here available for content that I haven't filled in yet. Specifically, there's the 60 by 60 app icon for iOS 7 for iPhones. I have an icon for that right here in my dock. I can just drag it in and drop it into place and I'm done.

I also have all these other images in my project that I'd like to important as well. From here in the Add Menu, I can choose to import content from myproject. Xcode is going to analyze all the files in my project and suggest the ones that are members of the same target as my Asset Catalog.

I'm going to go ahead and choose to Import these and because I'd followed the naming conventions of existing releases of iOS, Xcode is able to aggregate and group all those images automatically. Now, in the groups in the groups and files tree , I can focus on the source code that I edit everyday.

Another area that I want to take a look at today is my Storyboard. I want to make sure that all of my scenes look great with the new appearance of iOS 7. By quickly surveying, the content of each of the scenes, I see they all look great. But over here at the end, I can see that this Segmented Control has quite a bit of padding around it. Let's focus on that.

The Segmented Control in iOS 7 is significantly more compact than its predecessor. This is an opportunity for me. I can focus on my content instead of the Chrome used to manipulate it. I'll move the Segmented Control here to the bottom of the scene. And I want to resize the image to be larger.

Some straight, but honestly, I'm a bit of worried about how this is going to look on older versions of iOS. I could build and run in the simulator, navigate my way to the scene, come back here, make some changes, rinse, wash, repeat, but we have streamlined this in Xcode 5. Using the assistant, I can choose to see a preview of my application to see how it will look in all sorts of different context, specifically I can look and see how it will appear with iOS 6 using these controls in the bottom right corner.

Sure enough, this Segmented Control doesn't fit. It's too tall and it's clipped in that small space down there. With the current layout system that I'm using, Springs and Struts, I can't specify what I want to specify. I want to be able to say that the Segmented Control should have a fixed distance of padding between the image above it and the control itself and between the control and the containing view to this underneath.

Auto Layout is a perfect solution for this. With Auto Layout, not only can I specify those exact sort of constraints that I mentioned there with the spacing above and below the control. But I can also specify things like alignments, I can have a control always be centered, I can even say the two controls should be sized equally, is bigger-- the bigger one of the two of them, until there's not space for both of them, and then I can say, which one should shrink first. Let me show you just how easy it is to get started with all these precision controls for Auto Layout.

In the file spector for my Storyboard, I can enable Auto Layout. And you can see everything in my interfaces is exactly the way is when I-- is-- before I checked on the box. Now, I get to start adding constraints to take over complete control over the dynamic resizing behavior of all the elements in my interface. There's many new ways to add constraints. Constraints are what control this behavior.

One of my favorite new ways to add constraints in Xcode 5 is by directly control dragging between two elements. I'm going to hold the control key and click and drag from the Segmented Control. And by choosing the containing view, I can fix the bottom space from the Segmented Control to its container. By repeating the gesture to the image view above it, I can pin the same vertical spacing between the Segmented Control and the Image.

Zooming in on my Segmented Control, I can see the two new constraints that I've added. But right now, they're orange. Interface Builder is telling me that my constraint network isn't complete. I have fully specified the controls vertical position and size, but I haven't said anything about its horizontal layout. I need more constraints.

I could control drag between the Segmented Control and the other edges and repeat for the image views and labels that I have making up the rest of the interface. But in addition to having these precision editing controls for constraints, Interface Builder also has features to make broad sweeping changes all of your constraints. I'm going to click here in the background and select all my views at once.

And in the Menu, I'm going to choose Add Missing Constraints. Interface Builder analyzes the layout of all the views that are in my canvas and looks at all the interesting constraints that I've already established and finds the constraints that it thinks would be best to complete my layout.

Zooming in on my Segmented Control, I can see the constraints are now blue indicating that I've completed the layout. Specifically, I can see two new constraints, a centering constraint here and a padding constraint on the left fixing the distance from the Segmented Control to the edge of the container. Now, these two controls-- these two constraints together imply that I'll also have an equal distance on the right hand side.

But this isn't the way that I like to think about this layout. I like to think of the Segmented Control as being pinned by equal distances on both the left and the right and that-- leaving that to imply that the control is centered. No problem, with auto layout, you're in complete control of the constraints in Xcode 5. This automatically generated its centering constraint, I can just select it and delete it.

I can replace it with a constraint from the right edge of the Segmented Control of the container. Now the layout is exactly the same but more importantly, it's in the terms that I like to think about it and understand it. Doing the assistant editor, I can see that switching to iOS 6, my application looks great with no compromises. Now, is the more important time than ever for you to adapt Auto Layout in your applications and with Xcode 5, it couldn't be easier. Back to you Chris. [Applause]

All right. Thanks John. Now that you've seen how to design the interface for your app, let's talk about the compiler and language features used to implement it. Where Xcode 4 supported two different compilers, Xcode 5 leaves the last remnants of GCC behind, focusing on a single great compiler technology, the Apple LLVM compiler.

[applause] The Apple LLVM compiler is a great compiler and this is why we use it to build iOS 7, OS X Mavericks, and Xcode 5 with this compiler. Now, you may be wondering why is it 5? What's new? Well, this year, we've gone back to challenge basic assumptions of C that have been baked in since the early 1970s to solve fundamental problems with header files? Oh wait, wait, header files, what's the problem here? Let's think about what happens when you go to compile a source file of your project. Say it's 100 lines a code, it's no big deal, right? This should compile fast.

Well, the compiler starts parsing it and sees an include or an import, and it has start handling that, right? Well, say you pull in a UIKit. UIKit then imports a few other things and the compiler has to go parse that and it has to recursively chase down all the things that your file includes and now copies and pastes all the codes from all those header files together into what's called the translation unit which is everything that that file references.

Now, this thing is something really big. Instead of 100 lines of code, it's tens of thousands. Instead of 10K, it's 10 megs, right? This takes a lot of time to parse. And it's particularly redundant when you think about the fact that that the compiler does this for every single file in your application.

Now, this is not a new problem by any means and we do have a few pretty terrible hacks like Precompiled Headers that helps solve some of these problems. But Precompiled Headers, you can only have one Precompiled Header per source file. You also have to manage your Precompiled Header.

And I don't know about you, but why am I handling a compiler doing something that it should be doing for me? This doesn't make sense. Here we are in the 2013, right? Well, with Xcode 5, there's a new feature called Modules which defines this away. A module is an optimized symbol database for system header files.

What does this do? Well now, things work a little bit differently but they feel very similar. The compiler starts by building a set of modules for the system header files so it pulls all the texts from all of these headers together into an automatized symbol database that makes it super easy and fast for the compiler to query.

And now when you're going to compile a single source file, maybe it sees a reference to UIView, it can just do a simple database query to find out everything it needs to know about UIView. It doesn't have to go parse tens of megabytes of code just to find a way. And this database gets shared across all the files in your project.

Suddenly getting a little bit more interesting? And remember that it's not just the compiler that parses your code. Xcode uses LLVM for all of its source code features like indexing and code completion, syntax highlighting, and even Xcode gets to use these modules. Well, what does this do? Well, the best thing about modules is that they are completely transparent. They're on by default from your projects and you can get them in your applications just by enabling a simple build setter.

If you do this, now suddenly, the need to handle PCH is dramatically reduced, but the compiler also knows about the frameworks you're using, which means that now the compiler can automatically link those frameworks into your application. You don't have to drag frameworks in your project name or get terrible link errors about symbols you have no idea--

But the big story with modules is simply performance and how fast the compiler and our tools go. And I mean, there's lots of examples but to give you one really concrete example, when the Mail app in iOS 7 decided to switch the modules, they saw their total build time decreased by 40 percent, which is a huge reduction in build time. And better than that, their indexing time was reduced by almost two and a half times. This is a major improvement in productivity working with Xcode.

Now, modules work with Objective-C and C and system header files, but we know that many of you are C++-- passionate about C++ and maybe are game developer and you'll be really thrilled to know that in Xcode 5, we're continuing to lead the industry in C++11 support. And at this point, Xcode now supports all the major C++11 language and library features, including things like inheriting constructors which are a great way to define away a huge amount of boiler plate in your C++ classes.

Now, in addition to just being able to parse your source code and be able to handle your program, you also want to-- you also want the compiler to give you a really optimized code as well. And if you upgrade and build your application with Xcode 5, you will very likely find that it runs a lot faster because the compiler is better in innumerable ways. But there's one feature I really want to highlight and that's the new LLVM Auto-Vectorizer.

The Auto-Vectorizer analyzes your code to find places where you could be doing two, four, eight, even sixteen or thirty-two operations at a time by using the vector features of all the modern processors that we're targeting. The Auto-Vectorizer is simply about performance and if you're doing dense number crunching code, you can see massive speedups in your application.

Here's an example of an eight times speed up on a Neural networking program, matrix operations three times faster, scientific code, compression, it's 50 and 60 percent faster, all by enabling a single build setting. The Auto-Vectorizer supports both AMD and Intel chips. It even includes support for the new AVX2 instruction set and the Haswell processors announced just yesterday. That's pretty great and you should try that.

Now, if you use the compiler from the command line, you'll be perhaps excited to know that Mavericks has made this even better than before. Now, Mavericks includes stubs for command line tools built right into the operating system which means that if you install Xcode, you'll find that you already have command line tools and as you upgrade Xcode from the Mac App Store, your command line tools are all automatically kept up to date for you. It couldn't be easier.

[applause] Now, compilers are fun and they build our code and that's important stuff. But the compiler technology does other things for us. It also works in Xcode to help IDE features make us more productive. And this year, in addition to just parsing your code, the LLVM compiler goes just a little bit further and parses your comments as well. Why? I don't know. Well, the great thing about this is, is now Xcode can extract doc comments from your APIs.

And service them right in code completion and in the QuickHelp APIs. So they look just like system help. Now, if you're working on somebody else's APIs, this gives you a lot of reason for that-- for you to really encourage them to please, please document your APIs. Now, the compiler is used in a lot of ways. One of the really exciting ones to me is the Static Analyzer.

The Static Analyzer in Xcode uses deep compiler analysis to find bugs in your program. It's much better if the analyzer finds it than you, trust me. It's-- This year, the analyzer has a number of really great new checks, but also goes much deeper into your code. It can now analyze across method boundaries for both C++ and Objective-C methods. And in C++, it even understands constructors and destructors, which means that now, the analyzer knows about smart pointers and a lot of other really common situations that occur in C++.

And as many of you have started using the analyzer more often, you've made it very clear that you would really like the ability to quickly iterate on a single file in your project and be able to analyze that one project without reanaly-- or that one file without reanalyzing your entire project. Well, with Xcode 5, it couldn't be easier. It has new top-level commands to both analyze a single file and build a single file, make it super easy to get that done.

Finally, to wrap up our discussion of the compiler, I want to give you a quick update on ARC. Now, maybe you know, we released ARC for Objective-C about two years ago and we've seen some pretty massive adoption in your applications. It's been pretty-- you guys have been doing a great job with that. I'm really excited to say that with Xcode 5, now Xcode has completed the transition from GC to ARC. It's a shocking thing.

[applause] And this is one of the major reasons that Xcode 5 is so stable and fast. Now, if you're one of the few people that still use Garbage Collection on the Mac, I want to really strongly encourage you to move on to ARC. Garbage Collection is deprecated technology and will be going away really soon now.

And I think that when you switch to ARC, you'll find that your applications are faster and because ARC has a deterministic programming model, you'll find that it's much easier to understand your code and what it's doing and also to debug it when things go wrong. So, speaking of debugging, let's jump right now into the Xcode debugger and talk about what's new there.

Similar to the compiler story, Xcode previously supported two different debuggers. And LLDB is a really powerful set of debugger technology. It supports not only the modern Objective-C and C++ language features, it even looks deep into the Objective-C runtime and has really powerful data formatters built right in. This is one of the many reasons that LLDB, I'm very happy to say is leaving GDB in the dust. GDB is gone.

So, building on top of the underlying power of LLDB, the Xcode debugger has a lot of great new features. And the one that I want to start talking about is datatips. Datatips are a great way to see the value of your variables right in your code as you're stepping through it and that's where you're already looking anyways.

In datatips in Xcode 5 are simpler, cleaner, more compact and more useful. Datatips show summary information from LLDB. But now, it's also really easy just by clicking the Info button to see-- to print out a variables description. You don't even have to go to the console and hit-- type PO [applause].

And of course, textural is great but graphical is even better. And for graphical resources, you can now see them right in the debugger. [applause] It's great for Bezier Path and images and a number of different things. And you know, for those of you who have occasionally felt the need to give Xcode a friendly poke in the eye, now you can do it right in the debugger.

Moving on from datatips, let's talk about breakpoints. Breakpoints in Xcode are as powerful as ever. And you may not know it, but you can set up really powerful conditional break points and even attach actions right to your breakpoints. This can let you debug some of the nastiest logic problems in your application really simply. And breakpoints can be enabled either individually in the gutter or all at once with the breakpoint activation button. And Xcode 5 moves us right down into the debug bar to be right next to the stepping controls where you're already doing your debugging.

Now, while we're here, you'll see a new control on debug bar as well. And for App Kit apps, there's some great new features. Let's pull one out. So here's our simple App Kit app. Well, right from the Xcode debugger, you can now turn on several different options for example to see the frames for your views.

This is a great way to debug layout problems in your App Kit apps and these show up live as your application is running. You can also have App Kit flash, the area being redrawn in your application which is another great way to debug performance problems. Again, live is your App Kit-- as your app is running.

Now, performance is really important to Xcode. And this is why in Xcode 5, we're pulling lightweight performance information right into debugger with a new feature called Debug Gauges. Well, why are we doing this? We have instruments, right? Well, performance is a really funny thing. It's really, really easy to ignore performance until your app is visibly slow or worse yet, your customers start complaining about it, right? And the funny thing about that is that modern processors are super fast, which means it's really easy for you to be accidentally consuming way too much power without even knowing it because your app appears normal.

Now, we all have kind of a really good idea of what our applications is supposed to be doing, right? And so, debug gauges are all about showing you what's actually happening. So if there is a difference between theory and reality, you can see it right in the debugger.

Now the debug gauges show up right on top of the debug navigator. This gives you information at a glance about what's happening in your application. And if you click on one of these gauges, you get a great details view that shows you more information about that area. Now, debug gauges are not intended to have all the detailed performance information the instrument does because they need to be super lightweight.

They're designed to have less than 1 percent overhead for your application as it runs which is why we can enable them all the time when your app is being debugged. And if you want to get more detailed information, one click gets you right into instruments and-- which gives you the full power to debug any performance problem that you have and your application keeps running exactly where it is with instruments attached and continuing on.

Now, in addition to CPU and memory information, we also have a number of other really powerful gauges, for example one for energy. This lets you see the state-- current state of your application, how it responds to App Map and other important energy events. Now, instead of talking about this, to fully appreciate debug gauges, you just have to see them live. And to show them to you now, I'd like to invite up Ken Orr. Ken.

All right. So I've been working on a new feature in our Jogr app here and I'd love to show that to you now. So we'll start by running. And the first thing you'll notice in Xcode is the new beautifully minimal-- minimalistic debug gauges right here in the debug navigator.

So as Chris mentioned, if I click on the CPU gauge, we'll see the CPU report and then up in the upper left, we have an instant readout of our CPU usage. And then to the right, we'll see how we're doing in terms of the system, and below that, we'll see our CPU usage over time. So let me go ahead and show you that feature. So I'm going to click on these routes button which is going to show us our jogging routes on the map.

And we have one route which is running along the Embarcardero here in San Francisco, so I'm going to click on that and we'll see the details about that jogging route. And the feature that I've been working on is this graph at the top, this nice bright graph which shows you your jogging speed over the course of your jog. Now, you know what, when I-- when I clicked on that route, I actually saw a little bit of a spike in the CPU right here. And I-- that's not something I was expecting to see. So let's just do that again.

And actually it's worse than that. When I click on that route, it slides in, but it's really kind of laggy. I might not notice that if I hadn't actually seen this spike on the graph. So this is something I want to definitely fix. Now, we could jump right into instruments here but since I just wrote this code, I have a fairly good idea where the problem might be. So let's go back to our code and my guess is that the problem is where we're creating the UI Bezier Path that represents that graph. So what I want to do is I want to activate our breakpoints. I'll do that and then let's trigger that breakpoint.

OK, so here we are and create graph path. All right, now I'm looking at this first line of code here. And what I'm noticing is that I'm actually asking for all the samples in that jogging route. So I could be asking for tens of thousands of data points here, when in reality, I only need to ask for one data point for every horizontal pixel.

So, I'm asking for way, way too much data. And that's something that's very easy to fix by just instead of doing maximum samples, we can just say self.pounds.size.width. So that will give us just one data point for every horizontal pixel giving us exactly the right amount of data. All right. Let's build and rerun that.

And then we want to go to the map and we want to look at the reports so that we can see how we're doing. OK. So let's click on a route. OK, that looks much better. So immediately, I noticed that the view slid right in, nice and buttery smooth, just like I want it. And then furthermore, I noticed here in the CPU graph that it was just a tiny, tiny little blip. So, that's the user experience I'm going for here. So I'm happy with that. Yeah, let's just do that a couple of times, it's looking really good.

But actually, as I'm watching the gauges, which is something I always try to do, I notice that the memory of my app keeps climbing every time I bring that view in. Now, I certainly don't expect that bringing in the same view and pushing it out would cause my memory to increase like that. That's not something I would expect. I expect it to go up and then come back down.

So we could see that, yeah, sure enough every time I'm clicking on this path, we get another spike in memory usage. So, certainly something we want to address. This will be a great way to get us a nice one star review. So we don't want that. Let's go back over here to our code.

And again, I have a guess where this might be. So I'm-- I have this caching logic which takes that UI Bezier Path, draws it into an image, and I'm guessing that we want to look in this [inaudible]. So I'm going to enable that breakpoint and then I'm going to trigger it.

OK. So here, we are in cache graph image [inaudible]. All right. Now when I debug an issue like this, the first thing I like to do is I like to go through and inspect all the variables. So I want to make sure that the values of these variables match my expectation. So is anything obviously out of bounds, and the way I do that is I use datatips.

So I can just mouse over image scale and you'll notice now in Xcode 5, that the datatips are so nice and concise, so small, just showing me the value. That's exactly the piece of data that I want to see and that's all that we see. And of course, I can datatip over rect and I get that nice textual summary from LLDB.

And then I can also look at-- so I want to look at self and I want to see its instance variables and I can do that to, you can just twist it right open. And you know, one of the instance variables that I would like to look at is this image.

Of course, there's no summary for that. I don't know what that would show, but the way I want to see the image as you would guess is I want to see it visually. And with Quick Look in the datatips and in the variables view, you can now do this.

And of course, there're many more types that offer Quick Look. So things like, we've got an attributed string. You want to see the string and you want to see the attributes or say a Bezier Path like you've seen. Or even things like colors. These things want to be visual and now they are.

So I'll be honest, I've been using this feature for a little while now and every time that I use it, I am still amazed every time I get one of these Quick Looks. So, I think you're really going to love that. All right, so back over here, looking at our code, looked to the variables, not seeing anything obviously wrong, looking at the code, nothing is jumping out. It's just one of those times.

The problem is not apparent. So actually, Xcode 5 has another tool at our disposal here, and that is the ability to analyze a single file. So I'm going to take advantage of that now and I'm going to run the Static Analyzer on just this file and we'll see what that turns up.

Sure enough, it looks indeed like we do have an issue here. So let's click on this so we can see the details. OK. So, it looks like the problem is that I'm creating a CG image here. Now CG images I'm responsible for releasing those and in fact, I'm not releasing it. So, that would be our memory leak, it's an easy fix so let's just do CG image release, route image and then let's build and run that again.

Make sure that we actually fix the problem. So we'll click on the route, we'll let the graphs settle down a bit and then let's click on the actual jogging route. And then let's go back and forth a few times and see how the memory responds. OK. So this is looking much more like what I would expect. So I see the memory go up, I see it come back down, up down. So, I feel pretty confident that we fixed that issue. So fantastic. All right.

Now, there's one more thing that I would like to do today, and that's-- before I check on this feature, so before I check on my nice new graph, I actually want to reduce the footprint of our app to be smaller than when I started. I'd like to set the bar high for my team so I want to lead by example here.

And of course, the best way to do this, we'd analyze my hit which I can do right from instruments and I can get into instruments by simply pressing Profile, instruments launches with the allocations template and now we're set and ready to go and dig in and find memory that we can get rid off. Really smooth workflow from Xcode instruments.

So, in just a short couple of minutes here, we've seen that we have found, we have fixed, and we have verified both the responsiveness and the memory leak all using the new debug gauges in Xcode 5. And of course, as we saw it with quick look which is available in the datatips and also the variables view, you're going to have insight into your variables like you have never had before. So we think you're going to find debugging in Xcode 5 faster and easier than ever. Thank you. Chris?

Thanks Ken. Let's move on from debugging and talk about the great enhancements to testing. Testing is super important and Xcode 5 takes it really far forward. The idea here is to fully embrace test driven development and do it in a way that you've never seen before. The first feature involved in this is the new test navigator. Navigators in Xcode are-- exist to define and support the common workflows that you want in your applications.

The new Test Navigator shows up just like you'd expect. As you dive in, you can see that the navigator shows you the current state of your test the last time you run-- you've run them. Navigator pulls together all the actions you want to apply to test. It makes it really easy to add test, even test targets.

But what you really want to do is be able to run your test. And in addition to being able to run them all with command U, you can now run a single test right from the navigator or even define an ad hoc group of tests and run it, all without modifying any schemes. That's really simple.

[applause] This is a great way to intervally develop and test your code as, you know, all the way from writing the test first with the APIs to implementing the APIs and making sure it all happens. Now, testing is super important in Xcode 5 and as part of this, we're pulling the OC unit testing framework right into the Xcode family with the new test framework XCTest.

Now XCTest is very similar to OC unit in many ways. But it's the start of a continued investment in testing and will take us much farther than Xcode 5. [applause] Among the many improvements in testing you can now run test from the command line and test just work the way you think-- you know, just work the way they should.

Now, with all these improvements in Static Analyzer and testing, you may find yourself running the analyzer and your test all the time. And wouldn't it be great if you didn't have to do this manually. Well now, with the new feature called Bots, this can happen for you automatically.

A Bot is a humble friendly servant that runs on an Xcode server or an OS X server to handle your continuous integration tasks running something known as an integration, an Xcode lexicon. An integration is a series of reproducible steps that can contain things like doing a build, running tests, running the analyzer, even signing and archiving your application. Bots take the mundane work of running tests off your local machine and put it on a server or it can be happening automatic for you-- automatically for you continuously and shared within your whole team.

So now in addition to just running tests, Bots keeps track of history and Xcode provides a beautiful interface for exploring the history of a Bot. Now you can see exactly what happen in any integration. If there are any problems, Xcode makes it really easy to dive in and find out what went wrong.

Now, this is really important because, you know, some failures are easy, you know, it can again checks in a bozo commit and totally breaks everything, fine, that's easy. But the more complicated cases are when you have a test that fails only on a single device, maybe a specific screen resolution where a process of-- you know, specific processor. These are the kinds of things that's really powerful to have, the tools in Xcode to analyze and understand what is going on. And we think you're going to love it.

Now, Bots can be configured in many different ways, but we have two recommended configurations you should think about using. The first is a continuous Bot. This little guy, checks out your code from SVN or git, builds it, runs test in the analyzer and then as new changes come in, it does it all over again. This is a great way to find regressions as soon after they're introduced as possible which makes it much easier to fix problems.

Now, the second recommended configuration is a little bit different. This is a periodic or nightly build. The idea here is to emulate your production step as closely as possible. So this means that in addition to building or running tests, it also signs and archives your application. Why do you want to do this? Well, this is really great for a number of reasons. First of all, you now have a history of your application over time.

Built the way you do your production steps so you can see your application as it is involved. This also means that as you wake up every morning, you now have a reference build. You can live on and that your QA people or whoever can use as the days build. It's really a great way to pull together your team and all be focused on one thing.

Now Bots are super configurable. Xcode schemes are perfectly matched for Bots. But Bots also build on the power of OS X server. And a server brings a lot to the table as well. A server is the perfect place to archive your logs and your build products giving your team access to them all in one central location.

But it's also really fantastic place to plug in a whole bunch of devices because you get many different Bots for lots of different projects all testing on the same fleet of devices. And with Bots, it's really, really easy. Now to show you how these all works, I'd like to invite up Mike Ferris to show it to you in action. Mike?

Let me get right started here. I've been working on a Mac version-- oop, a Mac version of our social jogging application. And I've added iCloud support so that I can plan my runs and taunt my friends with challenges while I'm sitting on my chair. And I've been writing some tests for the challenge feature with the XCTest framework. I'm using the test navigator to focus on my test. I can see that a bunch of my tests are passing, but a number of them haven't been run yet.

I've actually implemented a brand new test suite for the challenge feature here and while I was in there, I implemented a few other test cases for some things where I noticed we had holes in our test coverage. And since I've added a bunch of new tests, I'll run them all now to bring my status up to date. And I can see that I have some failures. A number of the new challenge tests failed, but also one of these other tests that I added-- and I wasn't really expecting that. So I'd like to look at that first.

This task actually looks pretty straightforward and I don't see why it shouldn't work. So, this actually must be a bug in my application and that's great because this is exactly the kind of thing that UITests are meant to catch. In this case, it looks like a lot of this is mostly working but it's one of my inboxes isn't getting cleared out appropriately. I'm going to command click on the call that's being tested here to jump right to the source code. And I can see that yeah, sure enough, I'm just kind of forgetting to update one of the dictionaries I used to index the jogs. So, I'll fix that now.

And to verify that I've actually fixed the problem, I can just click on the status icon in the test navigator for that one test to run it again and make sure that the problem has been fixed. All right. So that's one less bug in my app and I'm glad that I found those holes in the coverage.

Now I know what's going on with the rest of these test failures. I'm actually using test-driven development to implement this feature so I wrote the test first and now I need to actually go and implement the functionality. So to do that, I'm going to switch to the project navigator to focus back in on my application code. And go to the challenge manager class which is where this feature is going to be implemented. You can see that I have some methods stubbed out here that need to be filled in.

And while I'm working on this, I want to make sure that I'm keeping my test close at hand. I'll use a new category in the related files pop-up that gives me access to test cases that exercise the code that I'm working on. And I'll hold down option while I choose this so that I can get it in the assistant editor.

Now, as I move around and work on the different parts of my model code, Xcode is always showing me relevant test cases in the assistant editor so I can keep an eye on them. Now I happen to have the implementation for these methods in a code snippet. So I'll add those now.

And because the tests are sitting right next to my main code in the assistant editor, as I'm implementing each of these methods, I can very easily verify that I've done it correctly by just running the test as I go. All right. And it looks like I've completed the implementation of this feature.

Now, in Xcode 5, we want to make it really easy for you guys to write great applications and the new testing functionality is a big part of that. But tests are really only useful if they're run frequently. And wouldn't it be great if your test could be running all the time. Well, that's what Bots can do for you. And they'll also perform static analysis and build archives of your application. Bots do this integration work either whenever changes are made to your project or on some sets schedule of your choosing.

The iOS version of our jogging application already has a Bot. And when I'm in Xcode, I can see any Bots for the projects that I'm working on right in the logs navigator. This Bot had a test failure the last time that it ran and if I click on it, I can see a more detailed report. This tells me at a glance how my Bot is doing.

There are issue counts for the last integration, graphs that show how my Bot has been doing over the past few integrations, and a current list of build and test issues that the Bot has found. I can double-click on one of these issues to go right for the code and this actually shows one of the big benefits of having this built right in to Xcode. I can easily close the loop, get right to the place where the problem is and fix it.

And let's go back to the report for now. One of the main reasons of course to have a Bot is to run tests. And I can use the test tab to get a lot more detail about how the Bot is doing with my test. There's a trend graph here that shows me how my test have been doing over the entire history of this Bot. And below, I see information about each individual test case that the Bot is running and how it's been doing over the past few integrations. Here I can easily see which tests are actually failing right now and when they started to fail.

So like with the issue display, if I want, I can go to the code for a test case that's failing just by double-clicking. But another way to approach fixing a test is to actually find out who broke it, track them down and make them pay. [laughter] So, let's do that and I'm going to deputize all of you right now. So, you're going to help me.

I can identify that this is the integration where this Bots started to fail. And if I double-click on the integration, I'll go into the integration report which gives me a lot more detail about the test. And here I can see that this Bot is actually running my test on four different devices.

And not only that, but I can clearly see that a couple of these test failures are only happening on one particular type of device. Now, you can't always be running your test on every different hardware configuration and OS version that your app may support. But the Bots can. Now let's remember our mission though, we're here to track down the culprit here.

The integration report also has a Commits tab where we can see all of the new Commits for this integration. And I can see that in this one, there was only one and I can even jump right in and see what source file changes were made before I go track down Jon to make him fix this problem. Jon we'll talk later.

Now I have a-- we've been looking at the Bot for the iOS version of Jogr and I'm thinking that I really ought to have one for the Mac version as well. So to create a new Bot, it's just as easy as choosing Create Bot from the Product Menu. This Bot is going to build the Mac version of my project and I'll give it a name.

I'd like this Bot to run every time there are new changes made to my-- committed to the repository. And by default, Xcode is going to send-- the server rather is going to send email to the people who have committed new changes whenever the Bots start to fail. Xcode goes off and creates the Bot and it takes me to the new Bots report as the first integration starts.

Now, Bots-- your Bots are working continuously to make sure that your apps are going to be great. And when they find problems, you'll see them right in Xcode. Another great way to keep track of how your Bots are doing for you and your whole team is to use the Scoreboard.

We have one of these up on the wall in our development area on a big TV all the time so that we always know how our Bots are doing. This way, we're always aware of how the Bots are doing and when something goes wrong, we can all pitch in to start fixing the problem. With workspace centered source control, the improved testing support, continuous integration, and the team score board, Xcode 5 makes it easier than ever for you and your entire team to work together to create great apps. Back to you, Chris.

Thanks Mike. Xcode 5 is available-- is available right now. We think that it will help you build better apps faster and easier than ever before. Now, Xcode 5 in the OS X and OS X server are both available for download from the Apple Developer Website. Xcode includes the SDKs for both iOS 7 and OS X Mavericks and it runs on either a Mountain Lion or a Mavericks machine.

OS X works with either Xcode but it itself must be run on Mavericks to work. Now, a great way to get started here at the conference is to run both of these on the same machine and it's really easy to do that. If you have any questions, we'd be really thrilled to talk to you this week in the lab here at WWDC. Thank you all.