Ladies and gentlemen, please welcome Vice President, OS X platform experience, Andreas Wendker.

Good afternoon. Welcome to the 25th WWDC.

So, if you watched the keynote this morning, you will have noticed that this year we have a very strong focus on our developer technologies. We're building out our entire platform ecosystem, and 2014 is going to see some of the largest developed releases in years. We are adding an incredible number of new APIs. We're giving you access to more low-level technologies, and as always, we're moving all parts of the ecosystem, hardware, software, services, and developer tools forward together, which is something only Apple can do.

Our focus on developers is paying off very nicely. As we saw from some of the numbers shown in the keynote this morning, there are now more than 1.2 million apps in the App Store. They have been downloaded over 75 billion times. And this huge success story is, of course, only made possible by you, the app developers.

And you're part of a very, very active community. Since we shipped the last update of our Xcode IDE just a few months ago, it has been downloaded more than 14 million times, and we are adding developers to our community at an amazing rate of more than 120,000 brand-new developers downloading Xcode every single month.

So, let's take a look at what we're doing with our iOS App Store to make you guys even more successful. This year, we're improving how users can discover apps by adding things like related searches, trending searches, and editor's choice badges, which will help promote the most noteworthy apps in the store.

It will also allow you to advertise your apps better by including preview movies, which will play for the users browsing the store. And if you're a developer of multiple apps, you can even bundle them all together and sell them at a discounted price, if you would like. Now, we're not stopping at making the App Store experience itself better. We're also working very, very hard on improving the developer experience. So later this year, we're going to give iTunes Connect, a new, cleaner look. It will have a new-

It will have a new dashboard that will show information about your apps, and most importantly, we are adding variable analytics.

These analytics will tell you how many users visited your app, your store pages, how many users went on and purchased your app.

How many remained active over time. And best of all, collecting all this information is fed right into iOS and it's completely automatic. There's no need for any kind of special libraries or code on your part to turn on analytics.

Now, many developers have also asked for a way to distribute beta versions of their apps before they ship, and we are pleased to announce our new TestFlight service, which will allow you to do exactly that. Users become beta testers by downloading the TestFlight app.

The app will give them access to the beta versions that are not available in the full App Store yet, and they download these apps simply, and they download these apps simply with their Apple ID. There's no need for any kind of special profiles.

Each app can have to, can have up to 1000 beta testers, and notice that this is a limit of 1000 users, not 1000 devices. So-

So, all these users can run your apps, your apps on multiple devices at the same time. And we will even allow you to use the TestFlight service to distribute apps within your own development team, in that case without app review, and again, without any kind of special profiles.

Also, later this year, we we'll ship the final version of Xcode 6. We will allow you to include your app's symbols with your App Store submissions because later next year, we will start servicing fully aggregated and symbolicated crash reports for your apps.

And you'll be able to work through these crash reports within the Xcode IDE. So, we have a huge update for the App Store this year. There are several end-user features that will help discoverability of apps and a completely revamped iTunes Connect with analytics, TestFlight, and later, also better crash reporting. Now, let's move on to the surprise news of this year's developer conference-Swift.

Swift is the brand-new developer, brand-new program language designed by Apple specifically for Cocoa and Cocoa Touch. It works beautifully with our system APIs, and it's designed with the common programming patterns on our platforms in mind. Now, there are a lot of program languages out there. On the iOS and OS X, most of you use an object-oriented variant of C, C++, or Objective-C, which so far has been our system program language of choice.

The problem we were facing was that pretty much all of these languages either fit in the category of high performance but low productivity or in the category of high productivity but low performance. But we want developers on our platforms to have a language available to them that gives them the best of both worlds, and that's why we created Swift.

Swift is very modern. It has all the things you would expect from a new program language. It has a nicely tuned syntax. It allows you to write very compact, very expressive code with features like clojures and generics. Here are a few examples of Swift code next to some typically Objective-C code you might write. You can really see that Swift is a lot more compact. It even has dedicated syntax for a common operation like a respondsToSelector test. And here you can also see that we are using common dot syntax for function and selector implications.

Swift is also designed to be safe. It will prevent you from introducing typical bugs or stability issues simply by enforcing best practices for writing code, so that for example you don't end up working with an uninitialized variable or running out of bounds with an array index. And Swift is fast. We've really tuned the compiler and the language runtime together to optimize the most common operations on our platform.

Here's an example benchmark. This is a Complex Object Sort. You can really see how Swift outperforms Objective-C and, certainly, scripting languages. Now, the best way to tell you a little bit more about Swift is to simply write some code. So, I'm going to ask Ted Kremenek to come up on stage and give you a demo of the basics of the Swift programming language.

Thanks, Andreas. So, I'm going to take you on a quick tour of the Swift language, and doesn't the terminal look beautiful in Yosemite? We're going to fire up the compiler in an interactive coding mode called a Read-Evaluate-Print-Loop, or REPL. I just type code in, it gets compiled on the fly, and executes. We'll start it off with a simple, "hello world." This one line of code is all you would need to write your first working Swift program. Whereas we would naturally want to move on now to doing more interesting things like declaring variables.

Now, you notice, I'm not actually writing the types for these variables. That's because the Swift compiler has powerful type inference that infers that X has the, has the type int because I initialized it with the value 42. Similarly, for S we infer that it has a type string because I initialized it with a string constant, and this means it makes the code feel very lightweight. Now, I have a lot to show you, so instead of me typing everything, I'm going to have some assistance here with the keystrokes but everything is still going to be live in the REPL.

Let's move on to simple containers, like arrays. Now, you can see the syntax is very light and natural. Here I have an array of integers, similarly, an array of strings. Again, I didn't write the types because type inference came in and it inferred the types of the arrays just by the contents of the array that I used to initialize the array.

Now, arrays behave pretty much as you would expect, you know, I have subscripting, which can be used in, you know, subexpressions and so on. But an important thing about arrays is all their accesses are balance checked. This is part of Swift's safe by default design. In a normal-running program, execution would stop at this point. Since we're in the REPL, we can keep on going, but this is really kind of a fundamental keystone of the, of the Swift language.

Now, arrays are just like any other type in Swift. They have certain capabilities, like computer properties that's going to tell me the size of the array, or methods to remove and add elements. And because arrays are containers, they can also be used with this very generalized for...in syntax. It works for collections, ranges of numbers, sequences, and here I'm looping over the values of the array and printing them out.

And you'll notice I'm using a very lightweight string formatting called string interpolation. Essentially, I have a string constant that I can just splat in an expression that gets converted into a string and spliced into the rest of the printed out string. It's very really nice for doing lightweight string formatting.

Swift also has batteries-included support for dictionaries, and these are also strungly typed. Here, type for instance inferred that I have a dictionary that maps from strings to doubles. I can also use the for...in syntax with them as well, but in this case, I get a key value pair all in one go, if I wanted to print it out all the values.

Let's move on to functions. And you still see the syntax looks very similar to variable declarations and you'll see there's this reoccurring theme in the language with the, where the syntax is, it's simple. It's composable. It's very regular. It's very easy to read. So, we start out with the fun keyword, the name of the function, its arguments, in this case we're taking an array of integers, and then the return value is at the end. In this case, we're returning an int. This simple function just loops and, you know, it loops over the array and sums up, sums up the numbers and returns them.

Call syntax looks just as you would expect. This is a very simple example. Let's say we wanted to extend it, all right? So, I'm, I'm doing all this work, I'm looping over the array. Let's say I wanted to return the average at the same time as I'm computing the sum. We can do that in Swift via support for multiple return values, and all I have to do-

-is change the return value to a tuple. The rest of the function looks pretty much as before, except you see at the return site we return a pair. And so when we call this function, we get a tuple back. And if you notice at the top, I put these labels, sum and average, on the tuple pieces. It means I can access the pieces of the tuple by name and because the language has powerful pattern matching, I could just declare two new variables, sum and average, to decompose the value of the return value all in one go.

And of course, the language has been crafted to work beautifully with Cocoa and Cocoa Touch. With this one line of code, I can import in all the APIs from the Cocoa framework on OS X. And I can immediately start playing with it. So, for example, I saw in Yosemite we have this new look and feel. Let's take a peek at the new default system font.

Here's what's going on here, is I am accessing a class method on NSFont that returns me an object for the default system font. And so this is a real object from Objective-C. I can access properties on it, call methods, do everything that you expect. Now, another important piece of Cocoa are protocols, and Swift supports protocols beautifully. Syntax is also very regular and simple.

Here, for example, I'm declaring a protocol scalable that models the idea that a graphical entity is scalable. I should be able to, you know, scale it up in size, scale it down, and I can, it defines a single method that returns a new value that's scaled. And just like Objective-C, I can retroactively add conformants to a protocol, to a class, using something called an extension. They're similar to categories in Objective-C but a bit more powerful. And you see, I've just defined the method right there, and now I can call it.

And so I've returned a font that's twice the point size as the original, all on the fly, here in the REPL. Now, also in Cocoa, we haves structs, right? Structs are simple data types for aggregating data, but despite being simple, they're really powerful in Swift. Let's take a look at our old friend, CGRect. Now, many of you who have used this API are probably used to creating instances of CGRect using CGRectMake.

Well, in Swift, you can also use just a uniform construction syntax to construct values in struct as well. And here we see the actual labels being put on the, on the values that we're initializing. Now, looking at CGRect, wouldn't it be great if it had a property on an area that could tell me the area of a rectangle? You can't define this in Objective-C. Objective-C does not have properties on structs. But Swift does.

I can retroactively now add this computer property to the struct using it in an extension. This is what a computer property look like. It just looks like a variable declaration with a bit of code added on, on the side for the value being computed. And I just defined it, and indeed, laws of geometry have held up. A 10 by 10 rectangle indeed has an area of 100.

Now, once you have properties and methods on structs, why not have them conform to protocols, all right? And this is really, you know, a really powerful concept. So, I can also have CGRect conform to the scale of protocol. It's a, it's kind of a, it's a graphical entity as well, and I could also, you know, I can now call this method and scale up the rectangle I created. Now I have a 20, 20 by 20 rectangle. So, now we have uniform capabilities between classes and structs, methods, properties, and protocols. So, now I have the power to write some really generic code.

Let's say I want to write a function, scale by sizing factor. It takes an arrayable array of scalable things and it returns a new array of the, you know, those elements scaled up by some factor. I can use that, I can implement this very easily for both structs and classes using generics.

A generic function looks almost identical to a regular function except it has this additional bit of, of type information where I'm supposed to find a placeholder type T. And all that matters is that T conforms to the scalable protocol, whatever it happens to be. The rest of the function looks pretty much as you expect. It's going to take an array of T, which, whatever T happens to be when I call this function, it takes the scaling factor and returns in a new array of Ts.

Now, all I want to do is I want to create a new array in which each element is scaled up. I'm going to use the functional map algorithm on array, which takes a clojure to do the transformation on each element when constructed in a new array. The clojure syntax looks like this. It, it's akin to blocks in Objective-C.

And we think clojures are so important that we wanted them to feel really great, syntactically optimized in a language. So, if the clojure is the last argument to the function or method, you can use this really selective trailing clojure syntax where you can omit the, the parentheses around the clojure. And that's it. That's my three-line generic function.

I can use it now to scale up an array of NSFonts. They're twice the size of the ones I created before. Similarly, I can call the same function and scale up an array of structs, completely different data types, but they just conform to the scalable protocol, and it works as expected.

This uniform capability is between structs and classes with methods, properties, and protocols. This thing is going to really finally change how expressive your code can be. And we can't wait to see what you can build with it. Now, this ends what I'm going to show you in the REPL. I'm going to switch the slides and tell you a few more exciting things about the Swift language.

OK. So, as we saw in the REPL, in, it is really easy to write natural and expressive code in Swift while readily tapping into some of the language's most powerful features, like generics. And as you saw, it's really crafted to work beautifully with Cocoa and Cocoa touch. Now, there are many advanced features in the language that I didn't talk about in the REPL.

One of them of particular importance that I wanted to mention are modules. What is a module? It's a logical collection of code that is intended to be built together. So, for example, any framework you build, any target you build in Xcode, automatically gets a module associated with it. And one thing you get from modules are implicit namespaces. This means you no longer have to prefix the name of your classes anymore for fear of them conflicting with somebody else's.

Now, a really great feature we did touch on in the REPL demo were Clojures, or non-S functions. They're extremely powerful in Swift, and they work beautifully with blocks-based APIs in Cocoa. And we think they're so important that we've syntactically optimized them so that was like those one-liners that you want to write, you know, to do something simple, can be written with very little code while maintaining readability.

And because Cocoa-based, you know, blocks APIs in Objective-C will reflect as Clojure-based APIs in Swift, APIs like dispatchasync will read beautifully with a trailing Clojure syntax. In this case, dispatchasync reads like control flow, which is more how the API was intended to be used. So, we think this really changes the readability of your code and how you reason about it.

And perhaps the biggest feature of Swift is that it's fundamentally a thin language under the hood with much the functionality not baked into the compiler but defined in a Core runtime library, which itself is written in Swift. To give you an example of what I mean, Core things like int and array are defined in this runtime library. They're not baked into the compiler.

Thus, the language is really designed from the ground up to be extensible, composable, layerable, to build new things out of it. And we think this really embraces the soul and spirit of Cocoa and Cocoa Touch, where rich APIs and rich frameworks can be combined together to build really truly awesome behaviors in technologies.

Now, the Swift language is full of a ton of great features, which we think are going to fundamentally change how you think about and craft your code. But beyond that, we designed the language with the intention that it would be the basis for truly fantastic interactive tools. In Xcode 6, we have a new feature, Interactive Playgrounds. They're akin to the REPL in that it's like a lightweight coding environment, but it brings forth the full capabilities and rich experiences that we can only deliver in Xcode. And to show you more, I yield the stage to Max Drukman.

Let me show you a little bit of what you can do with Playgrounds in Xcode 6. So, I'm going to start off with a new Playground. I think I'll make this a little bigger so we have a little room to roam. Playgrounds start you out with Cocoa already imported and a string variable for you to play with. I'm going to change mine to something a little more topical.

How about that? Now I'm going to add, how about a date constant? Pretty simple stuff, but you can see on the right side of the editor, I'm getting results as I enter lines of code. That is the results area. I know it's a brilliant name, but just like in the REPL, as you enter code, it gets evaluated and you get results.

So, if I were to do something like style that string, I get the result. My string is styled. Now, you don't have to take my word for it because many of the results in the Playground can be Quick Looked. The Quick Looks in the playground are just like those in the Xcode debugger.

You can even implement your own for custom data types. They're a great way to see results that aren't great candidates for coming across in plain text, like this attributed string or images. So, just like my attributed string, I can Quick Look these images, but we've added a way for you to see the results of your Playground in a more persistent fashion by adding your results to the Timeline Assistant.

Now, the Timeline Assistant allows you to build up a persistent representation of the results of your Playground so you can really get a feel for what your code is doing. The next thing I'm going to do is I'm going to mask that image with a Bezier path that I'll create.

Now, because Bezier paths are created in multiple steps, they're a great candidate for visualizing in the timeline. I can simply add each of the steps to the timeline and get a great sense of how my path is constructed. And it's especially good for spotting how one bad value can have ripple-effect consequences.

I'm going to undo that one. I think I'll get rid of most of these, actually. I'll just leave the final result. Now, as I said, I want to mask my image with this path. So, I'll do that here. I'm also adding in my attributed string to the mask so that it's punched out of the center.

So, the timeline is great for getting a sense of how your code and how your views are doing, but it does more than just present static views. It can also render them live, which is great for animation, which is what I'm going to do next. To do that, I'll just import a little bit more API. See how simple this is? Especially when you don't have to type. And I add in a little code that takes my two images, one that's been masked, applies it on top of the other one, and makes it animate with Core Animation.

Now, as Chris showed you earlier, you can also move around in time in the timeline. So, I can move back and I can scrub around to really get a good sense of how my animation is working. Now, the, the next thing I want to do is I want to add that date I created earlier to my mask, and I'll do that up here, and we can all cross our fingers as I type live onstage.

How about that? So, well, hmm. I, OK, so I've added my date, but that doesn't look all that great. Let's see if I can make that look better by reducing the font size. Well, that's an awfully big date. I think what I want to do is I want to make that date shorter, and I'm betting NSDate has some help for me there.

So, as with any class in Xcode, I can command click on the, the name of that class to jump to the header. In this case, I'll command double click to open it in a new window. Now, notice that this doesn't look like an Objective-C header. It isn't. It's Swift. That's because Xcode creates Swift versions of Objective-C headers for you, so you don't have to translate [applause]. That's right.

So you don't have to translate what you see in the header to what you implement in your code. Now, I have to come clean. I don't know all that much about NSDate. So, looking at the header, well, that's not really doing enough for me. Luckily, in Xcode, we have lots of great sample code and documentation to help me out. But wouldn't it be great if you could combine the sort of hands-on, do-it-yourself style of sample code and the, the sort of show-me-how-to-do-it style of documentation? Yes. Yes, it would. That's why we created Documentation Playgrounds.

Documentation Playgrounds combine the best of both worlds. Because it's a playground, I can play. But because it's documentation, I get adult supervision [laughter]. So, here is a Documentation Playground talking about converting between dates and strings, and here's what I'm looking for. It's talking about date formatters. I'm pretty sure that's what I want. And it even very handily tells me to try setting different values for time and date style. And even more handy, it even gives me the enums to try.

So, let's see. I'm betting short style is what I'm after, so all I have to do is copy and paste, and I can see my result change in the timeline. That's getting close. Let's try this one. Awesome! That's exactly what I'm looking for. Don't you want all documentation to work this way? So, now I know how to format my date, and it's a simple matter of doing that in my Playground.

I'm going to do that by replacing a bunch of this code with some code that has my shortened date in it. Hello. And my, my fancy, there you go. There it is. Now my view is looking exactly like what I wanted. That's a small taste of Swift Playgrounds in Xcode 6. We think you're going to love playing with your code. Back to you, Andreas.

Thank you, Max. So, now that you know a little bit about what the Swift coding language is, how do you start using it? Well, I made that really easy for you. Swift uses the same object model and the same memory management approach as Objective-C. You can import all our system APIs directly into Swift.

Foundation collections are transparently bridged to Swift language arrays and dictionaries, and we even went ahead and modernized our existing Objective-C APIs so that they interact more naturally for Swift code. So, you can adopt Swift at your own pace, if you would like, file by file. You can mix and match Objective-C and Swift in the same project.

We also wrote some great documentation for you. There's an entire new book about Swift that you will find in the iBookstore for free. And we, of course, updated our reference documentation to cover all our APIs in both Swift and Objective-C. Now I know that all of you guys really wanted to be the first ones to submit a Swift app to the App Store, and I'm very sorry to have to disappoint you, but we've already done that because, because this afternoon, we're updating the WWDC app, the app that you guys are using to get around here at the conference, with a version that uses Swift. So, this language is ready for you to use. It's real.

Now, one thing that is really important to understand is that we are planning to evolve this language very rapidly. Among other things, we really want to hear what you have to say about it and incorporate your feedback as much as possible. And so we are not going to promise source compatibility between Xcode releases. Some source conversion might be necessary, and we'll do our best to provide converters on the way if we make major changes.

But the one thing we will promise is binary compatibility for your Swift apps because we want you to be able to try it without delay. So, when we ship Xcode 6 later this year, you will be able to submit your Swift apps to the App Store. And they will run, your apps will run on iOS 7 and later, and OS X Mavericks and later. So, Swift apps are not limited to iOS 8 and Yosemite.

So, we are, as you can probably imagine, really, really excited about Swift. We think it's quickly going to become the programming language of choice for our own code as well as your apps. We're looking very much forward to hear what you think about. Next we're going to talk about gaming. This is another technology area that you are pushing on very strongly. We have many great techno-, technology advances to announce in this area this year. To tell you more about it, I'm going to hand over to Jeff Schtie [assumed spelling].

Thank you, Andreas. We have an amazing games technology ecosystem with APIs, tools, and hardware that allow you to all build brilliant games. Let's take a look. So, Game Center. It's our social gaming network providing features like achievements, leaderboards, friends, and multiplayer. Many of you are already taking advantage of Game Center to differentiate your game, and we have great engagement with Game Center. In fact, last month we had over 130 million monthly active users. So, that's Game Center. Game Controllers. Last year at WWDC, we introduced Game Controllers, the Game Controller MFI program and the corresponding APIs for iOS and OS X.

One year later, Game Controllers are doing really well. Thousands of games taking advantage of Game Controllers for both the best of touch and button inputs. We have Game Controller demo stations at Apple Stores like the one right here in San Francisco, and we're introducing controller forwarding. So, what is controller forwarding? Now you can take an iOS device, snap it into a Game Controller, and then use the integrated inputs of both buttons and motion to control iPads and Macs. It's pretty cool.

So that's Game Controllers. So now let's talk about our graphics APIs. We have SpriteKit, we have add, we're adding many new features to both SpriteKit and SceneKit. We're bringing SceneKit to iOS, and of course, we're very excited about our low-overhead, highly optimized Metal API. So, new for this year is a major push to making building casual games easier than ever. And SpriteKit is our 2D graphics API. We're introducing new features like per pixel collisions in physics, field forces, inverse kinematics with constraints, and, of course, Shaders.

SceneKit is kind of like SpriteKit but for 3D, making it simpler than ever to produce 3D games, and, of course, it's now on iOS. New for this year in SceneKit, you, sorry. SceneKit has everything you would expect from a 3D graphics, high-level 3D graphics API, like the ability to load, manipulate, and render complex 3D scenes. It has some of the same great new features as we have on SpriteKit.

But what's really cool is you can integrate SceneKit and SpriteKit. You can take a 3D object from SceneKit and use that as a sprite in SpriteKit with no overhead. You can take the output of a SpriteKit scene and use it as a texter in SceneKit. It's really, really cool. So, I'd like to invite Jacques up to help me show you a demo of both SceneKit and SpriteKit.

So, let's say you want to use the built-in Physics system for collisions. Last year, you may have gotten something like this. So, that's OK, but it's not great. So, why is this? Well, if we turn on Physics Debug Draw, what we'll see is that the Physics bounding box, boxes do not correspond to the exact shape of the sprites. So, new for this year, you can turn on perfect cell collisions, and now SpriteKit can use the sprites alpha mask to create pixel-accurate collisions. This allows you to create complex interactions and build things like gears or even machines.

We've also added field forces. Here you see an, an attractor interacting with the sprites in the scene. We can add a repulser and see how the tube field forces interact together with the sprites, and we've added many real and imaginary field forces like directional gravity, black holes, magnets, repulsers, and spring forces.

And, of course, we have everything you need for dynamic lighting. One AB, here's a basic scene kit scene and one API call can turn on lighting, and of course, you can select the object in your scene which you'd like to cast shadows. And if you want to take this to the next level, you can add normal maps. So, what we've done here, with a single API call, we've turned on normal maps. SpriteKit uses the existing artwork to generate a normal map automatically, so there's, no extra art was added here. This kind of, this kind of dynamic, dramatic element can really add to your games.

So, let's take a look at the integration of SpriteKit with SceneKit. So, here you have a SpriteKit application you may recall from last year. What you can do now is take a SceneKit node and put it into the, into the scene as a 3D object. That, that allows with no overhead to get a, a tremendous result.

Here we've replaced both the hero and the alien with 3D objects. So what does this allow you to do? You can design your game in 2D. You can set up your complex interactions all in 2D, then you could add your 3D assets in to give your game that extra pop.

So, that's SceneKit with a SpriteKit. Now, let's take a, take a look at some of the features of SceneKit. As I said, SceneKit is kind of like SpriteKit but for 3D. It makes it simpler than ever to build 3D games. Now, let's take a tour of some of the features. Here we have an example of, the built-in 3D Physics Engine. You have the blocks and balls colliding with each other and also with the room itself.

This is, game is using the 3D, built-in 3D Physics Engine and it's obviously fully interactive. And we have 3D field forces. Here you have an attracter in 3D, which is kind of like a space vacuum creating this really cool effect. What's amazing is you can just add a simple attracter to your scene to create this great effect. No other work was necessary.

And you can combine SceneKit and SpriteKit. So, what are you seeing here? So, the paintballs are being shot into the scene as 3D objects using the 3D Collision System to collide with the Taurus, another 3D object. We then take a paint splotch sprite, say that 3 times fast, and paste it into a SpriteKit canvas off screen you don't see. We take the results of that and texture map it onto the Taurus, so it creates this really convincing, cool combination of SpriteKit and SceneKit, made possible by the, the integration of these APIs.

And finally, of course, you have shaders. We have vertex, surface, and fragment shaders. Here you have a simple vertex shader, which is manipulating the model's geometry in real time. We have surface shaders where you can effect the surface and lighting properties of our model, here creating this cool caustic effect. And finally, fragment shaders, which can create amazing pixel-level effects like this glass globe effect here. So, that's seeing a couple of shaders. Now, I'd like to take a minute to have Jacques show you how easy it is to enable some of these features using our Xcode tools.

Thanks, Jeff. So, new in Xcode 6 are built-in tools for SpriteKit and SceneKit. You can edit content right within Xcode. I'm going to give you a quick tour of that right now. So, here we have the SpriteKit editor in Xcode 6. You see the per-pixel scene we had from the iPad demo earlier.

I'm going to make some quick edits to it in edit mode, which I'm currently in, and then I'm going to switch to simulate in simulate mode to see the physics live. So, I'm going to go over here on the right to my media library, which includes all the images inside my project. I'm going to drop one of these squirrels into here, and I'm going to place it using the new snap-in feature and then I'm going to simulate this.

Well, this behaves pretty much as expected because the blue rectangles are the physics body outlines, so this is not falling over. I'm going to correct that by turning on per-pixel physics, which is as simple as selecting the objects I want to use, changing their physics definition to use the alpha mask. Then I'm going to simulate again and the right thing happens.

OK, well that was easy. Let's move on to showing you the new feature of field forces. So, field forces are super easy to use inside Xcode, and I implore you to try them out and play with them here, and it's one of the best places to do that. So, I'm going to drag a theoretical field in here, called a spring field, which acts as if there was a spring connected between the field and any of the nodes that I'm going to enable it on.

So, I'm going to pick some of these balls here. I'm going to enable the spring field on them by setting their physics field mask to something other than 0. I've done that. Now I'm going to simulate this. Well, you notice they all drag towards the center of the spring there, and you notice also as they collided, they collided with the inert pulser not enabled on the field mask.

So, they actually, full physics running, and the field only affecting the balls I selected. Super easy and fun to use. Next up, I want to take you through how to put 3D content inside your SpriteKit scene. So, just bear with me while I go through the steps here.

All right. I'm going to drag that ship in and dump. All right, so that was step 1, 2, and that's it. You can see it's 3D. I'm going to try that again in case you missed it. So, here we go. An alien. OK. So, step 1, that's everything you need. So, this is just a quick preview of some of the great new features we've added to SpriteKit and SceneKit in Xcode 6. Thank you so much. Back to Jeff.

So, thank you, Jacques. So, that was some of our high-level, high-performance, super-efficient 2D and 3D games API. Now, let's go from the high-level right down to the GPU. We've been optimizing the heck out of the graphics stack with a new, low-overhead API Metal. So, why is that? What, what does that give you? Well, many games want to run at 60 frames per second.

So, a little bit of math shows you that you have a bit over 16 milliseconds for every frame. We put that on a timeline, what we can see is that you have to get all your application work done, you have to issue your drawing calls, and the system framer has to turn those drawing calls into GPU commands all within that 16 milliseconds or you'll start to drop frames. And of course that's just one of a number of frames you have to, you have to produce to make a truly interactive experience.

So, let's expand that first frame out. You see, there's two distinct parts. The first part is the application piece. The second part is that system framework, that GPU API. Well, Metal is super-efficient at reducing the second part to the bare minimum. So, what this gives you is more time. More time for AI, more time for physics, more time for more drawing, more time to make your game even more brilliant.

So, Metal allows you to unlock the power of the GPU. It gives you easy access and full control over the rendering pipeline. It has features like the direct control over the creation and encoding of GPU command buffers. It also provides a unified shading language for both graphics and compute with offline compilation. As you saw this morning, Unity, Crytek, Epic Games, and Electronic Arts have all committed to supporting Metal, and today we have Johan Andersson from Electronic Arts here to show us what they've been able to do with their Frostbite engine on top of Metal. Johan.

Welcome.

Thanks, Jeff. It's really great to be here. I'm one of those first-time Mac and iOS developers, so hello. We've been building for the last couple of weeks and you render using Metal for our game engine Frostbite. Well, our goal with using Metal, this new, low-overhead graphics API, is to try and enable the wide set of capabilities of our Frostbite engine on iOS. And to showcase this, we built a new demo in the world of Plants vs. Zombies Garden Warfare, one of our latest console games. Let's have a look. Yeah, will load in a little bit.

So, here we have the zombies, our enemies, advancing on the plants who are defending their garden center. This is the same Frostbite engine that we use to power our triple-A console games, such as Battlefield 4 and Need for Speed, here running in iOS.

One of the biggest changes we saw with using Metal instead of OpenGL was that our rendering submission times on the CPU became five times faster. This is really quite impressive and it's a, it's a really good benefit because it frees up 80 percent of one of our CPU cores which makes it a lot easier for us to build full games, games with even more animations, physics, and audio. Uh-oh! It doesn't look like it's going that well for the plants here. Let's see what they do.

Thanks, everyone. We're really happy with the result we're getting, and let's take a closer look at some of the action we have here. So, this is rendered in real time in Frostbite with Metal on an iPad Air, and it's interactive. Nicholas here is moving around with the camera.

And one of the key benefits that we're getting from Metal is that we get fine-grain control over the GPU and overall system. We can build command buffers efficiently in parallel and we can control them. We can explicitly manage GPU resources, which significantly reduces overhead for us and makes it a lot easier to give a significantly better and stable frame rates.

Now, Nicholas has paused in this scene here. This is really quite the interesting scene with tons of stuff going on. And there's tons of V effects, debris, and this large animated character is interacting. And there's a lot of components coming together to be able to create these type of environments here.

And here we have two very detailed and great-looking characters, sunflower and cactus. We're running dynamic shadows for everything in this scene and not just the characters, but everything really. And this is really quite heavy but it makes the characters and everything fit in with the, regardless of where the lighting condition is in the environment. Well, let's look at it again.

We've been working on, on this for just a couple of weeks but we're really quite interested in all of the results we're getting. We're really happy about it. So, yeah. Yeah, so here we have the big animated robot again. It's a zombie robot. I'm not sure how that works, but he seems to be very well animated [laughter].

So, we're rendering up to 1.2 million triangles per frame. That's really quite a lot, and we're really happy that we can do that. And together with that, we're doing around 20 different rendering passes for our HER rendering, for shadows, for aimed occlusions, for particles, and for distortion. And as you can see in the background, we have this nice [inaudible] effect going on that sort of frames the action a little bit more.

And we're really happy that we can, I'm really excited and really impressed by the amount of geometry and effects that we can push through the GPU. It's really quite extraordinary. And this enables us to use the same content and the same features that we're using for building console games but here on iOS.

It makes it significantly easier to, to work with this as a platform. So, Metal for us is literally a game changer. It, it's a key enabler for a new set of full 3D games on iOS, and we at Electronic Arts are super excited to support it and put this in the hands of our game teams and see what they can create. Thank you.

Thanks to Johan and Electronic Arts. That was simply stunning. It's amazing the power of the GPU that Metal allows you to unlock. So, it has never been easier to take an amazing idea and to brilliant, build a brilliantly successful game. We can't wait to see what all of you are going to build. Thank you very much, and I'll hand it back over to Andreas to talk about extensions.

All right. Extensions represent, represent another very important new technology direction that we are opening up for third-party developers on both iOS and OS X. They represent the ability to hook into various kind of system behaviors, and they allow users to expand and customize our Core operating system functionality.

Extensions are bundles that ship inside your apps. They get downloaded from the App Store with your apps, and they get removed from your system if you use an uninstall to your apps. So that the user doesn't get flooded with unexpected new behaviors, they stay in full control of which extensions are active in the UI. They get to expressly activate each extension they wish to use. It uses insisted preferences and settings.

In technical terms, extensions are short-lived, out-of-process services that get launched by our OSs on demand. If configured to do so, they can share data with the apps they are embedded in, for example, to access keychain items or any other kind of preferences. Extensions are of course sandboxed, and we even developed this cool new remote view technology that hosts an extensions user interface inside our system apps and dispatches user events back to the extensions process without the app being able to see it. So extensions are designed to be very secure. And since extensions typically share a lot of code with their apps, we now allow you to use bundled frameworks on iOS.

So you're not limited anymore to static libraries. You can now bundle resources and binaries in fully supported frameworks. Now, here's a list of the extension points that we are making available in this year's iOS and OS X releases, and more will follow in the future, but we think this is a great starting point. Let's go over these one after the other. There are many online services out there that allow users to post comments or share things like pictures and videos.

And while we support the largest ones directly in our OSs, we realize we can't support them all. So, if you are running one of these online services, sharing extensions are a great way to let users post comments, links, and media to your service from within any app they might be running.

Actions allow you to take user data, anything from text to images, audio, and more, and transform that data into a new representation. For example, you could write an extension that takes source code and Xcode and reformats it to your wishes, perhaps with the three-space indentation. And Photo Editing extensions are actions that manipulate images, but we make sure that we keep the original around so that edits are nondestructive. Safari actions manipulate web pages. Now, they have a lot of flexibility because they get accessed to the full DOM on the way in and out. So they can completely re-render an entire web page while the user is browsing. For example, to do a language translation.

Notification Center widgets allow you to place click-at-a-glance views inside the iOS and OS X Notification Centers. You can use them for displaying pretty much any kind of status information or for offering helpful little utilities to the user. They're mostly designed to display short, concise data but they also allow for simple user interactions, and among other things, they're great launch points to jump out into full app.

Document Providers extend the newly designed iCloud Document Picker and allow you to access additional storage mechanisms. For example, in an enterprise that uses a third-party Cloud service. And we offer a similar mechanism on OS X and remote file-sharing services can annotate Finder with their sync status. Another very important new mechanism is the ability to provide third-party keyboards. You can use them to support additional languages or any kind of input methods that you might think about.

Creating extensions is as simple as creating apps. The extended export with all the things you might need, such as new templates, additional scheme settings so that you can launch the apps that actually host your extensions. We improved our XPC service debugging capabilities, and we even added additional simulators for some of the extension points. So, extensions are a very powerful new mechanism to customize our operating systems, and we think they're going to be very, very popular with our users. Next, we're going to talk about new APIs in iOS 8, and for that I'm going to hand over to Toby.

Thanks, Andreas. Good morning. Well, as you heard this morning, we've got a pretty big release for you this year. In fact, this is almost as large as the original iPhone SDK. Now, we took a focus, we took a very focused approach to this release. The major theme this year is integration. Integration with the OS. Andreas just told you how your apps can plug into the system and even other applications. We're integrating across our devices with our new Cloud of Continuity features and we're providing deeper integration with the hardware and even with the world around.

Let's start by taking a look at two of our more popular applications. Underlying each of these is a very rich set of API. We've introduced a new Photos framework this year and have greatly enhanced the media API with many long-standing requests. Combined, they form the foundation of a photographic platform that brings your applications in right alongside our own.

The new Photos framework gives you direct access to the user's photo library with no need to import a copy of anything anymore, and you can even make changes directly with the appropriate permission. And with iCloud Photo Library, you can access the user's entire collection of photos and movies without having to worry about whether they're local or stored in the Cloud. We take care of that for you.

The new Camera API gives you full manual control over the camera settings, which I think is something that many of you have wanted for a while. You can set the, the lens position explicitly. The white balance or color temperature and various exposure settings, like the shutter speed and ISO.

And these are all the same APIs that our applications are using. A great new feature lets you grab a burst of photographs, each with different exposure settings, and with the video tool box, you can now access the hardware H264 encoder and decoder directly. [Background applause] Yes, thank you.

Now, we announced a number of great new initiatives this morning, and we're going to cover them all in great detail this week. I want to touch on just a few of them now. First, Local Authentication. This lets you ask the user to authenticate using touch ID right in your application. It's a very simple API, and we tell you whether the authentication succeeded or not. At no time, though, do you get access to the user's biometric information. That's stored away securely so that not even our own applications can get access to that.

Handoff lets you start a task on one device and pick it up seamlessly on another Mac, phone or, or iPad. You create an NSUserActivity to encapsulate an activity in your app such as opening a web page, and then as the context changes, you update that activity. And note that this contains only the metadata for the activity such as the document URL or scroll position.

You need to find an alternate means for getting the actual data across to the other devices. Now, once you've created this activity, we'll take care of advertising it across all of your devices. We're going to tell only the devices which are actually near you, so you don't need to worry about your computer at home revealing when you're surfing the web at work.

Health and wellness has become extremely popular lately, with new applications and devices exploding on the scene every day. HealthKit provides a platform where your applications can store and share health-related information. We can import some kinds of data automatically from standard supporting devices such as your blood pressure and glucose levels, and your app can read and write over 60 different kinds of information, ranging from fitness to nutrition to medical information. Now, all of this is extremely sensitive, of course, and so we give the user extremely fine-grained control over who can access what. Now, I'd like to talk about design a little bit.

Last year, of course, well, we completely revamped the iOS UI and I told you at the time that we were only just beginning. Now, that wasn't a threat. We've continued to add refinements, but just not at quite the same breakneck pace as we have before. Interactive notifications let you provide the user with custom actions right there in the notification banner. And as you heard this morning, they even work on the lock screen.

Now, because your users want to focus on their content and not the chrome around it, in landscape, we're automatically hiding the status bar and shrinking, or hiding, the navigation bar and tool bars. And we have a new compact style for action sheets in landscape. We're continuing to push support for dynamic type throughout our own applications, and we've greatly enhanced the API in UIKit and WebKit to make it even easier for you to adopt.

And finally, we have a new settings pane, which combines your applications preferences with all of the various system privacy preferences such as whether the user wants to receive notifications from your app. We've put them together in one place here now and given you a simple API so that you can take the user right here from within your application.

Now I read this quote on John August's blog a couple of months ago. "Adding landscape to the iPhone isn't impossible, but it means not doing something else, and right now the many 'something elses' are worth a lot more." That really resonated with me because we've been spending a lot time thinking about how to manage the proliferation of UI layouts.

When we launched iPhone seven years ago, it was pretty simple. You had one screen size and two user-interface orientations to deal with. A few years later, we added iPad and now you have to use a global user interface idiom to select between your iPhone and your iPad layouts. Then we added iPhone 5 with its larger screen size, and now you've got a total of six screen bounds to have to contend with. And that's getting to be rather a lot. And so we've been working to try and rationalize things for you.

Now, in iOS 8, you can use a single storyboard across iPhone 4, iPhone 5, portrait and landscape, and here's where things get interesting, on the iPad 2. Now, hang on a second. We've always encouraged you to design explicitly for iPad's larger screen size and not just blow up your iPhone UI, and we're not backpedaling on this message now.

Different screen sizes demand a different user experience, and so we've been teaching storyboards and our view controllers how to adapt themselves to the environment that they're in. In this example here, it's actually the same split-view controller class running on both the iPhone and the iPad. On the phone, well it looks and behaves like a single-column navigation browser, and on the iPad, you get the split-paned master detail view that you're probably pretty familiar with.

We're introducing a new notion called size classes to try and express this idea of how big something is. Broadly speaking, you can think of the iPhone size UI as a compact size class and the iPad UI as a regular size class. But don't make the mistake of thinking that size classes are bound to a particular device.

They're a lot more general than that. For example, in this split-view controller on iPad, it has two child-view controllers. The one on the left here, well, it kind of looks like an iPhone UI, and in fact, it has a compact size class whereas the one on the right has a regular size class.

This idea of things adapting themselves to the space that they're contained in forms the basis for something that we're calling adaptive UI, and this is what makes it possible for you to use a single storyboard on iPhone 4, iPhone 5, and the iPad. Now, I'd like to ask Max Drukman to come up and give you a quick tour of how easy this is to do in Xcode. Max?

I missed you guys. Especially you, Craig. All right, I'm going to show you how size classes in iOS 8, if I can get the right screen up, allow me to create a single storyboard that is adaptive for both iPhone and iPad. Here's my party finder app, NO.SLEEP. @DUBDUB. It's a pretty simple little thing. There's a login screen on the left and a, a list of parties on the right.

Now, the astute among you may notice that my layout is square. Why is that? Well, because size classes are, they're, wow! Since size classes aren't, they're not real, one size class doesn't necessarily map to one device and one orientation. The layout canvas in, in interface builder is also that way. Wow. Could've done that better.

Now, just because I'm, so, I'm laying out my interface this way. I still want to see how it looks on real devices when it gets in peoples' hands. For that, I have the preview assistant. In Xcode 6, the preview assistant allows me to add multiple devices and orientations so I can see how my interface is working in as many devices and, and layouts as I want. And here you can see that I've already specialized for one of the size classes so that my interface looks different on an iPhone in landscape orientation.

Now, if I select my other view controller, we can see my party table and this I haven't specialized at all. That's because table views, like many views, are themselves adaptive, and so there's no specialization that's necessary at all. Well, let's go back to my login screen. Now, Interface Builder starts you out in the size class for any width and any height.

So this is where you lay out what is common about your app across all size classes. It's a great place to do edits that you want reflected everywhere. For instance, if I want to move this shiny little graphic up into the corner, that will get reflected in both landscape and portrait.

But because one size class does not fit all, I can also tell Interface Builder to edit in different size classes. In this case, I'm going to choose compact height, which is the size class that maps to an iPhone in landscape orientation. And now, when I make an edit, for instance moving all these objects up, that will only be reflected in a landscape orientation.

Now, if I add an iPad to the mix, we can see yet another take at positioning and sizing these same elements. And once again, these are all the same elements with the same logic, styles, connections still attached. They're just positioned and sized differently because they have different constraints. So, if I were to change the nature of something, like the background image here, that will get reflected in all of the size classes. That's a quick take at size classes in iOS 8 and one storyboard to rule them all. Back to you, Toby.

Thanks, Max. Well, so that's just a taste of some of the things that we have for you in iOS 8, and we can't wait for you to get your hands on it and start playing with it. Now, I'd like to talk about iCloud. iCloud is an important and thriving part of the Apple ecosystem. We have well over 400 million users, and we're continuing to improve and add new features to it all the time. First, let's talk about iCloud Drive.

So, we introduced documents in the cloud a few years ago, of course, and it provides a seamless, in-app experience to getting your files from device, device, to the Mac. And that's great, if you happen to have the same application running on your phone, your iPad, and your Mac, but that's not always the case.

iCloud Drive gives you a folder right there in Finder, where you can manage your files directly. And we're even making this available on Windows too, in the Explorer. Now, if you're already a document-based app, it's actually pretty easy for you to add support for iCloud Drive. On the Mac, well, you get it basically for free with AppKit. On iOS, however, you can't access the files in iCloud Drive directly without some form of user intervention.

Well, that's done in this new UIDocumentPicker class, which lets the user select the files that they want to use in your application. We then dynamically extend your application sandbox around those files so that you can read and write them directly, without having to make a copy of anything anymore. And this even works across different application containers so that multiple cooperating applications can all work together on the same files.

We told you earlier how document providers let you extend your device with alternate file storage systems, and these are all managed by the UIDocumentPicker. And so once you're adopting that, there's nothing else for you to have to do in your application to take advantage of these document providers. And that's iCloud Drive. We think it's pretty easy.

Now, I'm really excited to be able to tell you a bit about CloudKit. Simply put, CloudKit lets you write client server applications without having to write the server part. Let's say you've got a hot idea for a coffee shop review service or, I don't know, a photo sharing service.

Well, here's what you don't have to do with CloudKit. You don't have to write any server code, you don't have to operate a 24-by-7 service, and you don't have to deploy any servers. And in fact, once you become wildly successful, here's something else that you don't have to do. All-

All you need to do to build a client server application with CloudKit is write your iOS and Mac app, and we take care of all of the rest of it for you. So, when we were designing CloudKit, we asked ourselves the question, "What do you need in the cloud to be able to all of this?" Well, a database seems like a good place to start. We've got records and relationships, queries, all the things you come to expect from an OS-equal database.

We have an asset API to efficiently store and retrieve large blobs of data. And we have a subscription service. You can think of the subscription service as kind of like a long-running query on the server, and as new records are matched by the query, iCloud will send out push notifications to all of the devices that have registered an interest in that subscription. We've built a developer portal so that you can go and take a look exactly at what's going on with your service in the Cloud.

And of course, you're going to want users. Well, it turns out, we've got rather a lot of them in iCloud, and every single one of those iCloud users could be your user as well. There's no account to create, no signup, or any hoops they have to jump through, and we think that's pretty huge for you.

As Craig told you this morning, it's basically free up to these maximum limits. Now, that's one petabyte of asset data. To put this in perspective, let's say that you're building a photo sharing service and you're using the same image size as some of your popular competitors. That would let you store 10 billion photos in iCloud for free. And we think that's pretty huge too.

We're doubling down on this technology ourselves. iCloud Photo Library and iCloud Drive are both built on top of CloudKit and we see this as the foundation for our services moving forward. We think this is really cool, and we've been working on it for a while and can't wait to see what you do with this. We think this is going to open up a whole new class of application for you. And that's what we have for iCloud. Now, I'd like to turn it over to Andreas to tell you about OS X Yosemite. Thank you.

All right. Let's talk about OS X. Yosemite is a big new release with an all-new look. We carefully evolved this look from our previous releases to make it truly beautiful without being disruptive. The basic ideas behind the redesign were to increase consistency, to reduce visual noise and clutter, to make animations more subtle, and increase the vibrancy of the UI for more liveliness. Let's go over the cornerstones of the new look and what they mean to app developers. We started by completely redesigning our window chrome. We made our toolbars and our title bars simpler and more compact.

But for non-document-based apps, we went a whole lot further and defined a new style of window chrome. Many of our apps now use a combined toolbar in which we merge the title bar and the toolbar into a single, compact row. This is a great way to give users more space for their content, but it only works well if you have few enough toolbar items to leave enough space so that the user can grab the window and drag it around on the screen, so this is not recommended for all apps.

Now, for several of our apps, we also moved the search fields, which have historically been located at the far right side of our toolbars, smack into the middle of the window if searching is the primary way of interacting with that app, such as is the case in Maps and Safari.

And for sidebar apps, which have essentially no toolbar items, we went yet another step further and used only partial title bars. These windows, they have the normal window controls on top of the sidebar, but otherwise they stretch out the content all the way to the edges of the window.

Now, one thing that is interesting about our new UI is that it uses a number of new transparent materials. For example, if you scrolled some window content under the title bars, that content will still show through in a heavily blurred way, giving the user a better sense for the entire document. And the new translucent sidebars still at the desktop background shine through, so that really gives the user a way to customize the entire look and feel of the system.

Now, if you're using our standard AppKit controls, such as a layer with scroll view, your apps will automatically inherit the right new look, and for more custom cases, you're exposing a number of new APIs that will get you the same effect that you see in our, in our system apps.

One thing you should watch out for is the readability of your text. While the new translucent effects are very beautiful, they are not a great fit for primary user content, so use these effects selectively. Now, we've also changed the system font in our UI. We changed it from Lucida Grande to Helvetica Neue, and that's how you pronounce that.

So, we hand-tweaked the metrics of the new system font so that they are very, very close to the metrics of the old Lucida Grande font, with a result that strings have almost the same size and usually fit in the space that you've allocated in your UI so far.

Now, to help with binary compatibility, AppKit will actually detect, AppKit controls will detect if your strings are being clipped. And in that case, they will ever so, ever so slightly compress the strings and make them fit into the available space. In addition to the system font, we've also updated our application icons and the glyphs used throughout the system. We've tried to remove unnecessary variations, and we've standardized on three basic shapes of app icons: circle, square, and tilted rectangle. Our application icons are now, now more uniform, they use more vibrant colors, and they also remove unnecessary variations and adornments.

Our AppKit controls now use animations that are more meaningful, and in general, they support a lot more styles for, to support the new appearance settings in addition to vibrancy settings. Specifically for vibrancy, they push out their colors a lot more strongly, which can really help its readability on translucent surfaces.

And another big change that Jeff just mentioned is that Yosemite strongly de-emphasizes dashboard widgets in favor of the new Notification Center widgets. While we still fully support dashboard, we are now moving over to running native widgets inside Notification Center, and if you're a dashboard developer, we suggest that you quickly adopt the new technology, which we believe will be even more popular with our users.

I'd also like to take a moment and talk about our accessibility APIs. Accessibility is a topic we care about deeply, and along with the new look, we made it dramatically simpler to let your applications work with voiceover and our other accessibility technologies. We took, we took some lessons we learned on iOS and created a new API that requires much less coding. So, please take some time and add this important capability to your apps. It has never been easier and it will change people's lives.

So, that was a quick tour of the new look in Yosemite. Once we've shipped this release later this year, users will expect that your apps fit in with the new look of Yosemite. So, please take some time over the next few months and change the style to fit in with what we've done in our system apps. Next, we're going to talk about Xcode, and for that section I'm going to hand over to Matthew [inaudible].

Thank you, Andreas. Now, you've already had a sneak peek into some of the features of the new Xcode tools for iOS 8 and OS X Yosemite. Playgrounds. A powerful and interactive way to work with, and play with, Swift. The new integrated SpriteKit and SceneKit design tools, enabling you to design truly amazing 2D and 3D applications. And universal storyboards with size classes. A great way to conceptualize and design your applications for both iPhone and iPad. Three great new features, and we are just getting started.

Universal storyboards, size classes, and autolayout combine to enable you to design for all devices using a single interface document, and we're bringing this to another area, Launch Images. With iOS 8, you can now provide an Interface Builder document and, at runtime, have the OS generate all of the necessary Launch Images for you.

So now you no longer need to provide the individual assets and you can use the same great design tools for your interfaces and your launch presentations. Now, storyboards have been a great addition to the iOS tools for development, and we are extending their use even further this year by bringing them to you for OS X.

Storyboards work with the new view controllers in OS X Yosemite to make it really easy to design great Mac applications. You can design your apps using scenes and then connect those scenes together very simply using the familiar Interface Builder gestures. Interactive workflows, such as popovers and sheets, can now be designed wholly in the Interface Builder canvas, and containment relationships such as tabs and splits-those use the new OS X view controller APIs to make customization and configuration really easy. So now you can use storyboards to design all of your interfaces for both iOS and OS X.

We have some other great design tool additions for you. Asset catalogs now include support for more asset types, including vector art like PDF and also supports marking images as templates for the OS to use as stencils at runtime. Interface Builder documents are now searchable, both in the editor and projectwide.

Now, this searching works on both strings and on property values like connections and class names. So, investigation and making mass change is really simple. And for iOS, we are bringing custom fonts into the Interface Builder canvas.

So now these are rendered live, and getting the layout and precision you want is really easy. Now, in addition to designing applications to work on multiple devices, you want your apps to ship to as many people as possible, and for this release, shipping to a worldwide audience is even easier. For this release, we're including support for XLIFF, the industry-standard format for managing and exchanging localized data.

Xcode now includes a workflow to automatically export all the necessary content for localization. We'll run the necessary processes on your source and interface documents, and in just a few clicks, you have XLIFF to send to your localizers, and integrating the changes back from them is just as easy. Now, a benefit of this is that you no longer need to use strings files for your development regions. You can work solely in your source and interface documents.

And if that wasn't enough, we're going to bring the localization content into the Interface Builder preview editor as well. So, now in addition to size classes and devices, you can pick from any of the localization languages in your project and view the results. If you've not yet localized, fret not. You can use one of the built-in pseudo localizations to see how your interface will respond. So, now more than ever, it is easy to ship applications for everybody.

So we have a lot of great design tools that work together to make a really live and interactive experience. But there's been one piece that's been missing, and that's your custom controls. Starting today, that is no longer, because your custom controls are now rendered live on the Interface Builder canvas.

I was pretty sure you were going to like that. So, let's go look at a demo and see how it works. So, here we have a photo kind of scavenger hunt application called Shutterbugs, and on the main screen we have a custom control. It's showing the image from one of the scavenger hunts. It's masked to a circle and has some adornments around it. So, let's take a look in Xcode 6 on how we will work with this custom control.

Here's my project. On the left-hand side we have our universal storyboard, and on the right-hand side I have the code for my control. It's written in Swift, and I'm also taking advantage of an iOS framework so I can reuse this control across my applications. Now, in this case, we see our custom control is currently rendering as just the big white box here on the left. But surfacing it in the editor as designable is really easy. All you need to do is add in the IB designable keyword to my class, and the tools will take care of the rest. Now, my custom control is just rendered inside of the Interface Builder canvas.

Now, you're looking at it going, "That doesn't look like the picture did." There are some values, like the photo and the name, that I typically specify at runtime on an individual instance. We'll get to that in a moment. There are some other properties of my control that I would like to allow people to customize in Interface Builder, and the metaphor for that is using the inspector.

We've made that really easy, too. So, for any property that I want to expose, I can now add the IB inspectable keyword, and I will do that on a handful of the properties that I would like to expose. Once I do that and go back to Interface Builder and select my control, at the top of the inspector are now controls for my items, for my properties.

So, let's adjust this a little bit. I can make the border thicker. I can also pick a different color font for the bezel. So, just like that, I've been able to customize the control with the limited capability that I wanted to expose to my developers. Now, let's go back to the image content I was talking to you before. In some cases, you really want the closest representation to your control as possible, but you don't necessarily want to set values that are going to work for everybody at runtime.

We have a great mechanism for you. There's new API on our controls called Prepare for Interface Builder. And this is your ability to provide all the necessary setup and configuration of your control for how you want it to look while you're designing. Now, this is just for design. It won't ship this way, but it gives you all the ability to surface your controls in the way you want. Now, I've been working with my, thank you [applause].

There's still more. I've been actually working with my application and localizing it, and I'd like to see how my progress is doing. So for that, I will switch the assistant over to the preview editor, and here I will zoom in a little bit so we can see the results.

Now, in the bottom right of the preview editor is now a list of all the localizations for my project. I can switch into any one of them-let's pick Spanish-and we'll see that the interface updates. Now, it looks like I'm doing pretty well. The controls at the bottom updated, but we'll see that the name for the control did not. That's an indication to me that there's still more work for me to do, but I didn't have to build and run to find that out.

Let's select a, select another language and make sure that everything's looking correct. I've selected German here, and now we'll notice that our interface is doing somewhat of the right thing. I've been using autolayout to lay out my controls, and it's keeping the items from overlapping, but it's causing one of the controls to get clipped unnecessarily. That's not quite the UI I would like. So, that's not a problem. I can just go back over here into the Interface Builder canvas and I can lower the priority for one of those constraints.

Doing that, we'll now see that on the right-hand side, it lays out correctly. So, just like that, I've been able to design my interface with my custom controls and make sure it looks good in all languages. So, that's just a quick overview of some of the great new tools for Interface Builder.

Now, in addition to great design tools, we also have some great new debugging tools for you this year. And it starts with queue debugging. Oftentimes when working with blocks, it can be difficult to keep track of where your blocks are coming from or going to. Now, when you're debugging your application and viewing by queues, you will have not only the executing blocks but all of the pending blocks available as well. And disclosing the pending blocks will show you the enqueueing backtrace, the backtrace on where this block was added to this queue.

And the pending backtrace is, the backtrace is not just for pending blocks. As you are executing and evaluating your own blocks, the pending, the backtrace is also included there too. So, now even more of the history is available to you. Now, you may be wondering, as my block moves from queue to queue to queue, do you keep track of it? And the answer is yes. If you have a very well-traveled block, all that information will be available to you during debugging.

Next up are debug gauges. The debug gauges are a great way to get an overview of kind of the performance of your application, and for this release, we're adding two new gauges in the form of network I/O and disk I/O. These gauges give you insight into some of the more intensive operations for your application, showing read and write activity and also giving you access to the list of active resources in use. We've also updated the debug gauges for graphics to work great with Metal. So, now you have all the same debugging and profiling tools to tune your games in Metal.

And we've also updated the iCloud gauge and utilities to work great with CloudKit and with iCloud documents. A new addition that's really helpful is that this iOS simulator now supports custom configurations. So, it's separate user data and applications. This allows you to simulate having multiple users on your machine so now testing synchronization and sharing with iCloud is a breeze.

Testing is a very important and key area to us, and we are bringing you two great new additions in our testing frameworks. The first is asynchronous testing. XE test now includes a flexible API to allow you to test your longer-running systems. You can set up your tests with predefined expectations, and those expectations can be evaluated as your test runs.

When you get to the end of your test, if your expectations have been met, your test passes. If not, your test fails. This simple approach makes it really easy to test your asynchronous systems right alongside with your other tests. But to go a step further, for this release we're moving beyond correctness testing, and we're also adding in performance testing.

With performance testing, you have a simple blocks-based API to identify areas of your application that you would like evaluated for performance. Now, these blocks are treated specially. When the test executes, we evaluate this block multiple times so we can get a sampling of your performance. And when the test ends, we surface the performance results right inside of the editor.

Now, as part of this, you can also establish baselines as points of comparison for your test, which means that as you improve your tests, that'll be highlighted in the editor as a win. On the off chance though that your performance regresses, those will also be highlighted in the editor as areas for investigation.

Now, as part of this, you also have access to all of the details running for the test. So you have each of the integration values, you also have access to the baselines, and even the standard deviations for your test. So you have complete control of your tests. Now, as part of performance testing, thank you.

I do agree, performance testing is very cool. Now, as part of this, a part of performance testing, you also want to analyze your tests, and we have by far the coolest profiling tools on the planet, Instruments. So, for this release, we wanted to bring together testing and profiling. So now, in the context menu from any test or test bundle, you can profile them right into Instruments. So, you can quickly look down regressions or even look for opportunities for improvement.

Now, to sweeten the deal even more, Instruments has a brand-new design and layout that has been optimized for a smoother user experience and to make investigating issues even easier. In addition, in this release we're also adding in support for performance counters for iOS, which is a great new addition to our profiling tools.

Inherently, though, when you are writing performance tests, you are identifying areas of your application where performance is sensitive or critical. Xcode and the compiler can make use of this information with a new feature called Profile Guided Optimization, or PGO for short. With PGO, your performance tests are used to profile your application, and that information is used in subsequent builds to optimize your code for better runtime performance, so the result is performance testing and performance improvement all in one. And that's PGO.

Now, to take advantage of many of these new workflows continuously during development, we've also updated the Xcode bots with a new streamlined interface, more configuration options, and support for all of the new testing workflows. The new integration reports for bots give you even more details about your integrations.

We separated out new from pre-existing issues, and we also tracked down individual issues to committers and individual commits. So, you can quickly find the guilty or the more responsible party for any issue that comes up. We also have more scheduling options and support for custom triggers, which you can run your own scripts before or after any integration.

And the new testing reports give you access to all of the details about your tests, highlighting regressions and improvements. You have access to all the same data for your performance tests and including the baseline workflows for managing those on your server. These reports are also available for the local testing workflows, so you can take advantage of them on your desktop too. So, now even more great reasons to use Xcode bots in your daily integrations.

Now, we have one more feature for you today. And this feature really brings together the liveness of the design experience and the debugging experience, and we're calling this feature View Debugging. With View Debugging, you have a live, interactive way to dive into the details of the user interface of your running application, and I'd like to give you a demo now of the now more visual way to debug your applications.

So, here we are, back in our project. Let's just simplify our view a little bit here. And remember, we were running our application over here in the simulator. Now, if I wanted to get more information about this interface, I could pause and use some of the debugger introspection tools, but there's an easier way now.

In the debug bar, there's a button here to capture my view hierarchy, and I will click that. And you'll see that now the main view is replaced with a snapshot of my application. Now, this snapshot is not a screenshot. It's actually an encapture of the entire view hierarchy of my interface. Let's change perspective a little bit to see if that helps.

We have implemented this for you using the SceneKit APIs to give us this gorgeous 3D interaction. I can adjust the interface to expand the items a bit to make it easier to select things. You'll see that I can select items directly on the canvas. I also have access to the hierarchy in the debug navigator and in the jump bar, which makes selection really easy.

Now, as I select items on the canvas, you'll see that the inspector's update will show attributes about the items I'm selecting. Here's some information about the main title. I can select one of the progress items, and we see that's actually implemented with an image, with a regular and highlighted state.

I can select even one of the labels and I'll see information about the texts, the lines, line breaks, and other properties. Now, at certain times it's, it's difficult to see exactly what you want because there might be too many things on screen. We've given you the ability to adjust the range of interesting views by peeling items off from the front or the back so you can narrow down your, your visual focus. Now, in some cases it may be easier to work without the wireframes so you can look at just your contents, or if you wanted, you could look with just wireframes, which is really helpful when trying to work through layout issues.

Now, we also wanted to make sure that this worked great for not just property settings but other things you might be working with. So, I'm going to zoom in here and select one of these labels, and you'll see that I can now enable constraint debugging too, and I can visualize in 3D all the constraints that are going on.

This is an amazing tool, and you guys are going to have a lot of fun working with it. And that's the new View Debugger for Xcode.

So, Xcode 6 is packed with features that I know you all are going to love and enjoy using. We look forward to seeing you guys in the lab, and have fun this week with the new Xcode 6.

So, we announced a large number of new technologies today. iOS 8 and OS X Yosemite look better than ever before and expose an incredible number of APIs so that you can get even more out of our operating systems and the underlying hardware. We are supporting these products with a new version of our Xcode IDE, version 6, which we run on OS X Mavericks and Yosemite. And among other things, it of course gives you access to our new Swift programming language specifically designed by Apple for Cocoa and Cocoa Touch.

So that you can get ready for our product launches later this year, we will make developer previews available for download today on the WWDC Attendee Portal. You will find all these products, iOS 8, Yosemite, even things like OS X server there. And of course, there are numerous sessions here at the conference that you can learn more about these products. There are more than 100 sessions and even more labs where you can meet Apple engineers one on one to get your specific questions answered. So, I'm looking forward to more amazing and innovative apps from you guys, and I hope to see you around later this week.