Thanks so much for coming to What's New in Cocoa Touch. It's really great to see a packed house here today. I know that we have a lot of new attendees in the house this week, and so for those of you who have never been to a WWDC, who have never been to a What's New in Cocoa Touch talk, this is really a great opportunity for you to get a taste of all of the new things that we're releasing in the SDK this year, and as you know this is actually the biggest SDK release since the SDK itself.

So this WWDC is going to be absolutely huge, and this session is your opportunity to get a taste of those technologies, and I'll be pointing throughout the session and, again at the end of the session, to all of the other related sessions to the technologies that I'm talking about so you can get an idea of what other talks that you want to see this week and one of the labs you're going to want to go to and that sort of thing.

So to begin, I want to talk about this core idea of what we've set up of what iOS 8 is really all about from the SDK perspective, and that's this idea of Adaptivity. Adaptivity is going to pervade everything that we do in Cocoa Touch in iOS 8, and adaptivity means several things.

On one hand, adaptivity is a design philosophy. It's a way of architecting your app, and we're going to give you an idea of how we want apps to be built from now on using a design philosophy that encourages code reuse, generic code that adapts from context to context and is able to go from devices like iPhone and iPad seamlessly.

Additionally, adaptivity encompasses a whole set of things that we are providing directly from UIKit to you. Things like Adaptive View Controllers. Adaptive view controllers are something that we have written with the design philosophy of adaptivity that when you use in your app can allow you to do things like take a simple primary, secondary view controller pattern, have it on iPhone, have the same code that puts that on iPhone put on interface that you'd expect on iPad and do that without any device checks, and it will all be the same code running on both devices. We'll show you how to do that.

Similarly we've taken the philosophy of adaptivity to view controller presentations and we'll show you how to build code that presents something like a full screen modal view controller on iPhone and something more appropriate like a popover on iPad. Again, without any device-specific checks because we're focusing on reusable adaptive code that is the theme of Cocoa Touch on iOS 8.

Additionally, we're going to be pushing a new user interface concept that we want all applications to adopt and that's dynamic or dynamic text and adapting to dynamic text. This was actually a feature that was introduced in iOS 7 that users can change their preferred text size. In iOS 8, we've extended the idea such that all apps built into iOS respond to dynamic type and are adaptive to that, and we want to show you how you can do that.

We recognize that one of the common places that users interact with text is actually in lists in the form of table views. So we took it upon ourselves to make it easier to take a simple table like what you would see in settings, respond to the user's dynamic text choice, make the text bigger, and make the rows bigger as well.

Finally, adaptivity refers to the ability, this opportunity actually to extend the system, to adapt the system to your user's needs and desires by bringing your functionality into system apps as well as other third-party apps. We saw in the keynote that we can do things like add a photo filter right within the Photos app without ever having to go to your application. So these are the kind of things that we're going to be talking about throughout the talk. The first part is particularly about the design philosophy, and then we'll move into listing off a lot of the things that are especially new about the API.

So to begin, we'll talk about this design philosophy of Adaptive Layout. So, I said it before but I'll say it again, the key of what we mean by adaptive layout is something that is reusable. A bit of code that is generic, that transcends device boundaries and orientation boundaries. So the first thing we want to talk about is the simple idea of interface orientation.

This has been a stalwart concept through the API since the SDK was introduced, and we actually want to move now to a place where when we're writing our apps, our layout code doesn't have to care what the interface orientation is and that's going to be the theme of what we're talking about now. So we can imagine that a designer gave us a design for a Photos app, and they say, okay, this Photos app on portrait in an iPad looks like a grid of rectangular thumbnail photos and there's five columns in that grid.

Similarly, they give us the spec and say, if that iPad is in landscape, show us similar, show similar thumbnails but seven columns of them. Now, the naive way to approach this would be, okay, let's hard code in five columns of things for portrait and seven columns of things for landscape.

But to become adaptive, we want to take a deeper understanding of why we have five columns in portrait and why we have seven columns in landscape. It's pretty easy to understand with this example that the reason is the portrait view is 768 points wide, and based on the thumbnail size that we want to achieve, it just so happens that we can fit five across so we have five columns.

Similarly when we go to landscape, we now have 1024 points in the width dimension, and based on the thumbnail size that we wanted to achieve, we can now fit seven columns. The difference here is that when we take that logic that we say, okay, we can fit this many columns in this space as opposed to there are seven columns in landscape then the actual interface orientation is not a relevant thing in determining what your layout looks like anymore. All that matters is what the canvas size looks like.

So there's also another decision being made under the hood here if we just sort of focus in on this view, and that's we've made these rectangular spread out thumbnails, but the Photos app on the iPhone has actually much more compacted thumbnails that are square in shape. And the reason it's that way on the iPhone is a very similar vein reason. It's because the size of the iPhone is different.

And so, we compact the layout when we are in a compacted size, and so we can actually think about that decision, the compacted iPhone style layout versus what you see up here-the more spread out rectangular thumbnail layout-as also being determined by the size and not actually based on a device, iPhone versus iPad. So we're now going to begin to think of this interface as determined by the idea that it has regular-sized dimensions. The height is regular; the width is regular. And we're thinking of this semantic-based sizing idea as a new thing that we call Size Classes.

Size classes are a very simple enumeration that gets us thinking about canvas size when we do layouts rather than interface orientation. We have independent horizontal and vertical size classes, and either one of these axis can be either compact or regular. And that simple choice can allow us to choose between what we may now think of as an iPhone style interface and an iPad style interface.

It really isn't about the device. It's about the canvas size that we have. And we'll continue to talk about this idea throughout the session, but part of what makes that key is that you may end up in a situation where you are showing something, displaying your view on say an iPad where the size of that canvas is actually comparable to that of just being on an iPhone, and if you've written adaptive code that simply uses the size rather than the device to do its layout, you'll get an iPhone style layout when appropriate in smaller spaces on an iPad.

So, the situations that we can end up in are on the iPad having regular height and regular width. This is true in either orientation. On the iPhone, the width becomes compacted and using that bit of information, the Photos app can choose to shrink to its more compacted square thumbnail-based layout. Similarly, when the iPhone goes to landscape, it still has a compact width but also takes on a compact height. So you can use both of those pieces of information to decide what happens in your layout in your app.

So, we've wrapped up this concept of size classes and are exposing it to you via a new class in UIKit called UI Trait Collection. UI trait collection is a handy bringing together of a few pieces of information including the horizontalSizeClass, the verticalSizeClass, the displayScale, and the userInterfaceIdiom. Now what makes trait collections convenient is they're hung right as a property on UIViewController.

So you can access them from your view controller. You can also get them from the current screen, and then using that information, you have your size class. You can make the determination of what is the right thing to do for you. So as a simple example, we can think of what we did with Photos and implement a size class did change method.

And for Photos, it just needs to consider what the new size class is, and based on whether the horizontalSizeClass is compact or not, the Photos layout chooses to use either its compact squares-based layout, if it is a compact horizontalSizeClass, or otherwise it uses its rectangular thumbnail, more spread out layout.

And then this particular snippet is modeled to be on a collection view controller, so it just takes that layout object and applies it to its collection view as a new layout object. Now, some of you may be noticing this unfamiliar scribe to you on the screen. If this is your first time seeing Swift, congratulations. Here is your intro, and you can see just how easy it is to understand. And this will give you an idea of how easy it is to start adopting Swift immediately with all Cocoa and Cocoa Touch APIs.

So with that, I'll talk about quickly another new API that we've added to support your layout in iOS 8, which is Margins. So margins coincide with an API release in iOS 7, which is layout guides. Layout guides help you know about hard lines on the screen. In this case, the top and the bottom of the screen, where the top is denoting there's a navigation bar there.

So the layout guide tells you about that navigation bar in case you'd like to avoid it. If there was a toolbar at the bottom of the screen, your layout guide would also denote the top of that toolbar. In this case, it just denotes the hard line that is the bottom of the screen.

But there's another concept in this UI that isn't covered by layout guides and that is the whitespace that is inset in the content from the edges of the screen. So, in iOS 8, we're introducing an API on UIView, which is layout guides which tells you about that whitespace and allows you to set whatever whitespace you want for your layout. So that's a property on UIView.

It also comes with native support for autolayout, and that's in the form of new NS layout attributes, including left, right, leading, trailing, et cetera. There's a bunch of these. If you've been using autolayout in your code, you'll find this natural and familiar. So, to learn more tricks about building adaptive layout apps, there's going to be a great talk tomorrow in the Mission called Building Adaptive Apps with UIKit.

So now I'm going to be moving on to talking about some of the ways that we have adopted the philosophy of adaptive size class-based design to build things that you can use out of the box that are adaptive without you having to do any work. So we'll start by talking about Adaptive View Controllers. This is a great new feature.

And to begin to dive into this, I'm actually going to go back and talk a little bit more about this idea of orientation which, or rotation, which we touched on with the orientation segment of the talk. So, now I'm going to have us kind of ask ourselves this question, what is rotation, really? Because asking ourselves that question yields a result that helps us write adaptive code. And that result is, it's just an animated change of the size of the view. So, if we consider a view that's onscreen, we might have been thinking of when the device rotates, that view rotates with it and this is a rotating view.

That perspective actually complicates the idea of what we have to do in our layout. And so, beginning in iOS 8 we're encouraging you to take a different perspective towards how rotation works, which is just think of it as a view that happens to have, in this case, a regular height and a compact width, and when the device rotates, something happens to that view.

And the thing that happens to that view is it undergoes an animated size change, and perhaps it goes to a compact height and a regular width. I don't want to confuse you in that standard on an iPhone in landscape, the width is actually compact, but this is an illustrative example of what might happen to your view. As your view changes size, it can go to any new size and any new size class, and that's really all that's happening when you're undergoing a rotation.

And part of the advantage of thinking about rotations this way is merely as size change is that once you handle rotations as size changes, any other situation that you might end up in where your size changes, you will have handled because you will have written your code in a way that it can handle size changes especially those that are animated. So in order to move in this new direction, we're taking a lot of API that used to exist in iOS 7 while it still exists in iOS 8, but we're deprecating it. This is just a subset of the rotation API that is deprecated in iOS 8.

And what I really like is what we're replacing this with. Thinking about things as size changes, you can just implement one method. We'll transition to size. And since that takes a transition coordinator, if there's interesting things you want to do-if you want to animate along with that size change whether it be rotation or anything else that changes the size of your view controller-you can use that transition coordinator to do an animation, and you just send in a block with that transition coordinator and those changes will be animated along with the size change, which may be a rotation of your view controller. So in this case, I've used the size change to simply change the number of columns in my photo layout based on the new size.

So beyond just view controllers themselves with rotation, we've built some view controllers that allow you to adapt to the hierarchy from device to device in a way that makes it so that you write less code. And so, many of you have probably written something like you see on the screen, a primary, secondary view controller pattern and you do this using a split view controller, and then you embed a navigation controller as the master view controller of that split view controller.

And then when you would go and take this same design pattern of a primary, secondary view controller, you would end up on the iPhone with a navigation controller as your view controller, and that meant you would have a device idiom check saying, am I on an iPad? If so, build this view controller hierarchy. If not, build this other view controller hierarchy with a navigation controller as an iPhone.

While on iPad just as we want to make it so that you no longer need to care what your interface orientation is, we also want to make it so that you no longer need to care what your interface idiom is. And to do that we're making it so that you can build this interface on an iPhone with the split view controller as the root view controller.

And it will still contain a navigation controller as its master view controller. Then when you want to, you know, push another view onto the stack, you can just call show view controller on this. It will do exactly what you would expect from a navigation experience, pushing a view onto the stack, and when you would execute something that would be the equivalent of showing a detail on iPad, you can just call show detail view controller.

And on the phone, it will do exactly what you would expect a phone interface to do, which is push it onto the navigation controller because that's all that's available on the phone. But that same set of APIs, that same call sequence calling show view controller and show detailed view controller on iPad, will yield what the user would expect on iPad, which is a detailed view controller over on the right of the split view.

So, UISplitViewController is really a workhorse to be used in iOS 8. The key to it is that it's now available on all devices, allowing you to build view controller hierarchies that don't depend on what device you're on. It's the same hierarchy on iPad and iPhone, and split view controller will adapt for you.

So with that it handles the primary, secondary controller pattern transparently for you, and also to go along with this, split view controller has a whole host of new updates to its API and its release. I can't even begin to talk about what they are. If you'd like to learn more about them, there will be a great talk tomorrow morning called View Controller Advancements in iOS 8.

So, moving on to Adaptive Presentations. This is another way that the view controller system is helping you have code that is simple and device agnostic but that does the right thing on each device. We want to help you build something like a full screen modal presentation on iPhone and get something more appropriate like a form sheet on iPad or even a popover, and do this without code that checks what device you're on. It'll be the same code on every device.

So in particular, one thing that is really changing its paradigm is popovers. Prior to iOS 8 popovers were only available on iPad, and we would use them in the form of UI popover controller. Well, that paradigm is changing significantly because we're now no longer requiring the use of UI popover controller to present a popover. Instead, popovers are presented via the API as a presentation style for view controller.

So that means if you present a popover or a view controller with a popover presentation style and the presenting view controller horizontalSizeClass is regular, it would just appear as you expect a popover to appear. With that same code using a popover presentation style, if the presenting view controller is compact in the horizontal dimension like you would see on an iPhone, it would just appear as an oversheet so that you get what you would expect on iPhone.

So we're taking this, these concepts, and we're bringing adaptivity to some other view controllers that we ran like search results, which you may be thinking, well, that's not a view controller. Well, we're fixing that because UISearchDisplayController is replaced by UISearchController, and UISearchController is crucially a view controller subclass, and that means that it can take advantage of all of the power of adaptive hierarchies and presentations that we've just talked about. That's all at your fingertips with the new UISearchController.

This new UISearchController is also able to be fully customized in the way that its UI appears and how it's presented so that you can adapt the search controller into your application even if you have a fully customized UI like that in FaceTime, it will look the way that you want it to look. We're doing something similar with alerts in iOS 8, and we're taking UIAlertView and UIActionSheet and replacing them with UIAlertController.

I kind of thought you guys might like that one. UIAlertController is also a UIViewController subclass so that we can internally use all of the power of adaptive presentations to our advantage and to your advantage so that things look great. Of course, UIAlertController adapts its styling to the context so that when you present it on an iPhone or on anything that has a compact horizontalSizeClass, you get an action sheet appearance.

You can get an alert appearance also but in the action sheet style, you get something that looks like what you expect an action sheet to look like, and the same code that presents that action sheet on an iPhone, in a regular horizontalSizeClass like an iPad will appear in a popover without you having to write any device-checking code.

So you can learn more about how all of this adaptive presentation machinery works by checking out A Look Inside View Controllers, Thursday morning in the Mission. I've seen this talk a couple of times. It's really great if you want to understand the nitty-gritty behind how all these presentation controllers work, and especially if you're thinking, hey, this built-in UIKit stuff is fantastic. I want to build my own presentation controllers that are also adaptive. This talk will teach you how to do that.

So, what we've been talking about for a while is tools that we're giving you via the API to write adaptive code, but there's another step to writing great code and that's Testing. So we're giving you another great tool that we're excited about in the iOS simulator and that is the ability to resize the physical simulated hardware.

And, so I don't know if you can see it on the screen. It's a little small, but you'll find in your SDK if you haven't found it yet, and you launch the iOS simulator, there are two new devices that you can select. One is a resizable iPad and one is a resizable iPhone. You can use these to actually punch in custom values for the hardware size of the iPad or the iPhone and test the adaptivity of your code on the fly.

We're really excited for how this kind of thing can make, can change the way we architect apps because we can architect things the way that we intend and then test that our intentions are doing what we thought that they were going to do. So I actually stole this app you see on-screen from the A Look Inside Presentation Controllers talk that I just mentioned, and it has a custom presentation controller, which is the view that slides out from the right and it's designed to take to take up a third of the screen.

I went and tested it in the resizable iPad to make sure that if it was in a compact width, it would do the right thing, and sure enough, the guys who wrote this are really great and it does do the right thing. It presents as an OverFullScreen presentation in the compact width.

So, let's talk about some of the new things in iOS 8 for UIKit for customizing user interface. Of a new class called UIVisualEffectView, the UIView is subclass, and it's a view that takes UIVisualEffectObject that parameterizes custom rendering modes for the view itself and the content inside it. So we're shipping a couple of different effects that you can use with the visual effect view to get the effect that you want, and the first one is the UIBlurEffect.

Believe me I've been waiting for you guys to get to be able to use this too. So UIBlurEffect will give you a live blur over the content where you use it. The second effect that we're shipping is the UIVibrancyEffect. Now, a vibrancy effect if you don't know what that is, that refers to the separators in Notification Center. It may be a little bit hard to see on this screen, but you can pull out your phone, pull down Notification Center. Take a look at those beautiful color-changing, color-dodging separators, and that's vibrancy. Another thing-I heard a clap over there, thanks [laughter].

Another thing that we're introducing is Image Assets. Image assets are something that encapsulate the 1X, the 2X, the iPhone, the iPad representations of your image in the home matrix thereof, and it comes with some API that makes it really easy to get the right images out of the image catalog because we can use something like image named and add a parameter to it that takes TraitCollection.

And since TraitCollections are hung right on your view controllers, you can take that TraitCollection from self and viewDidAppear or something and apply it directly to an image view in your view controller, and you'll have the right image. The if statement that is implied in figuring out 1X, 2X, iPhone, iPad, et cetera, is all encoded within the TraitCollection, which you don't have to do any work for. It comes directly with your view controller. Thank you.

Another UI feature is Condensing Bars. You may be familiar with this if you've used Safari on iOS 7, and it has a similar concept. When the user scrolls, the search bars [inaudible] shrink. Well, we've extended that concept throughout the iOS 8 SDK and given you access to that sort of behavior in your app.

So if you have a navigation bar, you can make it so that when a user scrolls the navigation bar gets a little bit smaller, or if you have a view that has a navigation bar and a toolbar, you can make it so that when a user scrolls, the navigation bar shrinks and the toolbar disappears all together.

So to learn all about some great things you can do with interface customizations, we have a talk that is tomorrow called Creating Custom iOS User Interfaces. So, I alluded earlier to a feature that is, that we're pushing in iOS 8, which is dynamic type everywhere. All of Apple's apps have adapted or have adopted dynamic type and are adapting to the changes that are required for that.

One of the things that we realize is that table views are a very common place where text is displayed and something that we would want to respond to user text size changes. And so we have made it easier in iOS 8 for you to respond to these types of changes by allowing you to have dynamic type rows without actually implementing the delegate method tableView:heightForRow AtIndexPath:.

I know that a lot of you have been asking for this over the years, and so now our solution to that is cells can encapsulate their size and logic inside themselves.

It gets better, actually, because the cells natively support autolayout. So, yeah, it does get better, right? And so if you have constraints in your cells, UIKit can derive the appropriate height for those cells from the content in them and the constraints that you place on them. You can do something like this where I'm not implementing the delegate method heightForRowAtIndexPath.

Instead in my cells initializer, I set some constraints. In this particular cell, I have a text view that will hold some content. I set a vertical constraint that just adds some padding around that text view using the visual format language. I do the same thing on the horizontal axis, adding padding on the right and left of that text view, and then when this cell is created, it will be populated with some text.

The table view will know how wide it is. We'll be able to take the content that's in that text view and the margins that I've set up with autolayout and determine what the appropriate height for that cell should be based on that content and the width of the table.

If you really like to learn more about that or if you just like to hear me talk, come back to this same room two days from now where I'll be presenting along with my very esteemed colleague, the beloved Dr. Olivia Gunish [phonetic], and we'll be telling you all about what's new in table and collection views. So moving on to my favorite feature of iOS 8 SDK. It was actually kind of hard to wait until this part of the presentation, but App Extensions. App extensions are just fantastic.

You've seen this in the keynote, but app extensions are just going to change the way that we write apps and the way that users enjoy what we produce for them. We can do things like in Photos, taking a photo, bringing up a sheet that shows the extensions that we have, selecting your extension right there in Photos, applying something like a filter to that photo, and ending up in Photos where we always were. We never had to leave the app.

And your content is right there for the user at their fingertips. We can also have sharing extensions, which allow users to share to your sharing service right from whatever app they're in. They can share photos, videos, text, and other content without having to do a do-si-do over to your app.

This will be a better experience for the user, and it means more people can share to your app because it will be less work for them to do so. We also have Notification Center widgets. You can write a fantastic Notification Center widget that can end up on my phone and I can see it every day, and I can be extremely grateful for you, to you for doing that.

So app extensions open a lot of doors. Some of the big things in iOS 8 that you can use app extensions for, of course, Photos, sharing, Notification Center. It's also possible to build extensions that don't actually have a user interface, and a great example of this is the Bing Translate action without UI that we saw in the keynote.

Additionally, you can build custom file providers. This is something that will allow the user to use documents from your cloud storage solution as seamlessly as if those documents were on iCloud drive, just by your extension providing them to apps within the system. Additionally, iOS 8 makes it possible to write custom keyboards that will be shared throughout the system.

The front row likes that. Yeah. To learn more about building app extensions, we have two great talks today and tomorrow that will explain to you everything you need to know about building upon this just absolutely tremendous technology that is just going to-iOS 8 is the sign post. It's different from here on out.

So some updates to notifications. Notifications have changed a bit in particular in the way that we model how users approve of notifications that appear onscreen. It's always been true that users have to approve push notifications, and it wasn't true previously that users would have to approve local notifications. You could show a local notification without the user giving approval to that. So in iOS 8, any notification that shows UI on the screen is going to require one-time approval from the user.

The flip side to that is you can send push notifications that don't show UI to the user, that simply shuttle data to your app, and those will not, by default, require user approval. So you can just send notifications to your app, and the user doesn't have to, doesn't have to worry about it.

Notifications can now also have actions associated with them. That is, if you want to display something that has a reply button or other actions, those can be tacked on to your notifications, and whatever action the user selects, that will be shuttled over to your app for your custom logic to be invoked based on that action. Notifications can also be location based in iOS 8, so you can pop up a notification when the user enters or exits a significant area that you want to show them a notification about.

Finally, we've increased the payload push size from 256 bytes to 1K.

Four times the love for everyone. If you want to learn more about this, there's a great talk, What's New in iOS Notifications, tomorrow afternoon in Nob Hill. So we're introducing a doc picker in iOS 8. And it looks beautiful-looks like that. It's, of course, available on iPad and iPhone, and what's great about this is we now have system UI for selecting documents.

You no longer have to write completely custom code starting from scratch to give a user a document picking experience. If you want to be able to interact with documents in your application, you can use the UIDocumentPickerViewController [inaudible] and, of course, since it's a view controller it gets to take advantage of all the adaptive presentation and hierarchy machinery that we talked about earlier.

This document picker has access to documents in the local scope, and seamlessly also in the iCloud drive scope, and finally anybody who is supplying a document provider extension to the system, those documents will also appear in the document picker. It's all similarly completely seamless and easy for the user and your application just gets a URL back for the document that it needs to open.

To learn more about document picker support, we've got a great talk on Building a Document-based App in the Marina on Thursday. A quick word about SDK Modernization. We made a few changes throughout the headers in the Cocoa and Cocoa Touch APIs, and I just want to give you a quick rundown of what that's all about.

We've annotated all the designated initializers of class with an NS-DESIGNATED-INITIALIZER annotation so you know which ones are the designated initializers, which, of course, you need to know if you're going to be a good subclassing citizen. Additionally, all of the return types for initializers have changed from id to instancetype.

That will make some of our autocomplete better. And we've introduced additional properties in place of classic Cocoa methods, in particular like the NS object protocol where hash used to be a method. Hash is now a property for NS object. And these changes enhance the experience for use with the Cocoa and Cocoa Touch APIs, both in Objective C and, in particularly, with Swift. So, Handoff is an opportunity for your app to participate in a feature that we talked about in the keynote, which is continuity.

Continuity is the thing that allows users to do something like start an email on their phone, go to their computer, finish that email, and it's all seamless experience. Well, with handoff, we're giving you the opportunity to have user activities of your own so that they can do that not just with mail or with other built-in activities, but with your activities as well. So handoff has a built-in support for activities in AppKit and UIKit, both natively support activities in their document classes, and you'll be able to use that out of the box. To learn more about handoff, check out the Adopting Handoff in iOS talk tomorrow in the Mission.

So, there's a whole lot of stuff that has changed here. Lots of new things. We also have several brand-new frameworks in iOS 8, and I don't really have time to talk in any kind of depth about these things, but I want to give you an idea, a taste of what is out there so you can see what other sessions that you'd like to attend because these frameworks allow you to build apps that you simply could not build before iOS 8. And that's fantastic. So, of course, first is one that we've already touched on. Notification Center will support you building extensions that add widgets to the Notification Center on iOS. So that's notificationcenter.framework, and you can learn about that by checking out the Building App Extensions talk.

We also have a brand-new Photos framework. This will give you complete read/write access to the photos library. This means you can do whatever your application needs to do to provide the best user experience possible. It can delete photos. It can do non-destructive edits. It can do whatever it needs to do so that the user gets what they need.

While this isn't actually in the Photos talk or in the Photos framework, I do want to take this opportunity to point out that iOS 8 also brings custom Core Image filters, and so you'll be able to use these on your photos as well as videos in iOS 8.

With brand-new framework called CloudKit, and this framework is absolutely spectacular. I really can't say enough good things about it. It gives you more control than you ever had over the data that you put in the cloud. And what really makes this spectacular is you can use CloudKit to build a client server application without building the server side.

You can define that on the client side and let Apple take care of it for you. So, you know, I can't even wait to see what startups come out of this. This will be fantastic, and we love CloudKit so much that we built iCloud Drive and Photos in the cloud on top of it. It's a fantastic technology, and you'll love building your apps on top of it.

Another new framework is HealthKit. HealthKit brings all of the biometric information from the various devices that your user has all into one place. So this information is shared across apps rather than siloed into one app that has one biometric device information and another app that has another biometric device information. It's all shared. So you can use that to create a perfect experience for your user based on all of the biometric data that is available from all of their accessories.

Similarly, we are introducing a HomeKit, which does the same thing for connected home devices. It puts all of that information in one place so that you can build an app that does everything that a user needs for their connected home, accessing all of those things in one place. We also have a new local authentication framework.

This allows you to leverage the power of biometric authentication in your own app. And as you probably know from having watched the keynote, this means that you get to use Touch ID right inside your application. That's great and we have a talk that you can go check out to learn more about how to do that.

We're also bringing SceneKit to iOS 8. SceneKit is a great framework for building 3D renderings, and we've had it on the Mac for a year. We're now bringing it to iOS. Now we have a great cross-platform solution for doing 3D rendering. Those of you who have already used SceneKit, you're going to love this; those of you who haven't, you're also going to love it.

Everybody is going to love it. So that's all the brand new frameworks. That's not all the changes though. I'll point out one other framework that has made some significant changes, which is Core Location. Core location now makes it possible to get the user's location details indoors, and by that I mean, you can get what floor the user is on, not just where they are.

Isn't it great to build apps that you just have never built before? I'm excited. We also have new APIs and core location that will make it easier to save power when getting significant location updates. So that'll be better for everyone. I'm a big power magnet myself, so using these will enhance everyone's experience.

We're also changing the user approval model around core location so that users can now choose to approve your app either all the time for location use, or only give it, you can just request to be approved only when you're in use. So the user can rest assured that your app is not using location and not draining the battery, not stealing any secrets when your app is not in use. So that's a change to core location.

So, to finish up here I want to reiterate some ideas about the design philosophy because, really, iOS 8 is a mark in the sand for how we think about building apps in addition to all of its new API. So, we're going to be centered around building reusable code that is device agnostic, that is interface orientation agnostic, that is adaptive, so we can use the tools that are presented in iOS 8 to simplify our layout by using things like size classes so we're not worrying about what the specific size of things are. We use a size class to make a determination whether it's compact or regular, and we can test those things out using the resizable simulator.

We can use the iPhone and iPad code in a unified way so that we only have one bit of code that does the right thing on all devices, and we're bringing adaptive view controller technology to you that will allow you to do that. You can integrate into the system now using app extensions so that the user can do more things in more places than ever before, and your app can be more useful for them than it's ever done. And finally, as we just covered since we've introduced several brand new frameworks, there are things that you just could never do before that now you can do. You can expand your toolset using all of these brand-new things.

So, if you want more information about anything in this talk, you can always talk to our inimitable frameworks evangelist Jake Behrens. Check out our documentation on developer.apple.com, or hit up the dev forms where people like me can answer your questions. I have a whole bunch of related sessions that you can check out. I'll get out of your way. I don't want to block anyone from writing this down. There's actually another screen after this for anyone who wants to check out more related sessions. I don't see too many people using pencil. These are the additional related sessions.

And we also have a lot of labs. Of course, WWDC is packed with labs all week, more than I could ever even bother to call out, but Cocoa Touch Labs are-the next three days you'll be able to find me and a couple dozen of my colleagues to answer all your questions related to building UIKit applications. And I really hope you're able to get an idea of all that we have to offer in this WWDC, and I hope you have a fantastic week. Thanks for coming.