Welcome this morning to What's New in Cocoa Touch. Thank you for coming by. We've been putting together a lot of new changes for iOS 6, and I thought I'd take you through a quick tour of some of the bigger changes that we're making. So we'd like to get started with some of the things that we're doing for appearance.

So in iOS 5, we spent a lot of time making sure that we added a lot of customization opportunities to UI kits so you guys could, you know, your designers could give you a bunch of artwork, and you'd be able to scan and customize UI kit in order to really fit the design of your app.

So we've made a lot of changes in that for iOS 5. We're doing some additional stuff for iOS 6, and we'll start with UI popover background view. So popover background view was introduced in iOS 5 so that you could put your own popover artwork in place, and then put your own view controllers in that. And if you were customizing this, you might have gone and done something like, say, try to duplicate the iBooks look.

And you'd get this little sort of beige popover view, and you'd get this little sort of You made your background view clear, and you still got that inset and the drop shadow that we put onto the default popover. So if you override wants default content appearance, it's a new class method on UI popover background view, we'll stop doing that, and you'll get a completely flat look for the popover. So if you've been getting that inset and it's been driving you crazy, you can get rid of it now.

Wait till you see what we have for you later. That'll be good. UI Stepper, not our most customizable class ever. Pretty much you dragged it out of IB or you allocated it and this is what you got. So you'll be able to tint it now, right? You can choose really terrible colors like this one. This is why I'm an engineer and not one of the designer guys. You'll also be able to set the background image for a particular state, right? So instead of getting that gray chrome with the inset, you'll be able to set your own background images.

You'll also be able to set the divider images for the left and right segment states, right? So as the user is tapping on the plus and minus images, you can set the left and right divider images to get exactly the kind of pressed or unpressed look you want. And you'll also be able to set the increment and decrement images for particular states.

So if you want to use an up arrow and a down arrow or something else that means increment and decrement to your application, you'll be able to do that. So the HIG sort of still applies. They should be increment and decrement and you should stick with that. But you'll be able to put your own images in.

UI switch, our other not quite so customizable class. You'll be able to put tint color on this also. And you can also put a thumb tint color in there as well. So you'll be able to tinker around with that. And we've also gone ahead and added image customization for the on and off images as UI Navigation Bar and Tab Bar.

When you put a nav controller as the review controller in iOS 6 or put that view into any other view, you'll see that there's now a shadow image on the navigation bar, and if you're using a tab bar, there's a shadow on that as well. You'll be able to customize and turn that on and off. It's kind of subtle, so it doesn't show up very well in screenshots here, so we didn't put one in, but you'll be able to set your own images, or you can set it to nil and get rid of it.

Toolbar, of course, on the iPad now can go at the top or the bottom of your view or view controller, so you'll be able to set the shadow image for a given toolbar position. So if you're putting it at the bottom or the top, you'll be able to control that as well.

And UI bar button item, we've also now added some things for set background image for state, style, and bar metrics. The bar metrics change depending on whether you're in portrait or landscape on an iPhone, idiom device. And this is mostly to be able to do things like for the done button and the edit button and stuff like that. So you'll be able to customize images for all of those things now as well.

UI page control, another little tiny control, the little dots for the page indicators. You'll now be able to tint those, both the background color and the page indicator color. So you'll be able to fit that directly into your app's design as well. We have some new UI image API that allows you to create images directly from data. UI image is pretty smart. It speaks almost everything that image IO can do.

But if you are going to give us a raw NSData, we do need to know the scale. We can't really derive that out of whatever metadata might be inside that NSData. We can't guarantee it. So you'll have to tell us the scale on the way in. So there's a convenience method for that and an initializer. And we've also set it up so you can create images from CI images now. So image with CI image scale and orientation.

You'll be able to move back and forth between CI image and UI image much easier. UI page view controller has a new mode. So remember the book mode from last year? We were able to page through, and it looks almost exactly like the iBooks transition. Page view controller now allows you to set up a scrolling mode with view controllers. So if you initialize it with UI page view controller transition style scroll. I wish I had autocomplete for speaking for that. That would be great.

You'll be able to kick that into a mode where you can use gestures in order to just have view controllers come on the screen and scroll through automatically. The option for inter-page spacing is a way that you can adjust the spacing between view controllers so it doesn't look like they're all butted right up next to each other. There are also some new delegate methods.

We had page view controller did transition to view controller before. We're now introducing page view controller will transition to view controllers. So you have the opportunity when the gesture begins for you to find out that that happened and which view controllers are going to be coming into as child view controllers into the page view controller.

If you implement presentation count for page view controller and presentation index for page view controller for that sliding mode, we'll go ahead and automatically put a UI page control down at the bottom of the page view controller and keep track of that. So as you update it and things slide, that little indicator is going to update. And I'd like to show you that right now.

And because you have a captive -- I have a captive audience, you're all going to see pictures of my dog. So, this is Bud. This is a really simple app. It's a view.iview controller that just goes and loads an image, and then the delegate is holding an array, in this case five of them.

You can see the page control at the bottom there. And all of this scrolling stuff is just taken care of for you. So there's no -- this is a couple of delegate methods, and I just took a UI page view controller, allocated it, parked it into the view of the root view controller. I think I inset it a little bit. And this is his please stop taking pictures of me look. And you can see as I'm scrolling through, the page view -- the page control is updating at the bottom.

All I'm doing is telling the page view controller which of the page -- of the view controllers is highlighted -- is selected. And it just updates all of that for me. So very small amount of code there. It's basically maybe 25 or 30 lines after creating a new sample. Right? So not much -- not much to that.

That's Page View Controller. So those new delegate methods, you do have to implement both of them, both the count and the index, the presentation count and presentation index, in order to get that page control to show up. There is one appearance session, Advanced Appearance Customization on iOS. So if you've been doing a lot of customization with UIKit, please come by. We've got one of our own engineers and one of the engineers on one of the teams that uses all the API who has a lot of experience in customizing UIKit, and they'll be talking about the best ways to handle customization in UIKit.

Next on our tour, UI Table View. We've made a bunch of changes to UI Table View to try to make it a little bit easier for you guys to use it. There's some new features in there as well. Table View is really the workhorse of UIKit for a lot of navigation style applications, and there were some things we thought we could do better. So we're going to roll those out now.

Chris Parker We've changed the way UI Table View cell reuse works a little bit in iOS 6. So you used to be able to do register nib for cell reuse identifier, right? You'd give us a UI nib instance. We'd instantiate those things out of the dequeuing mechanism. You can now register a class up front for cell reuse identifier. So you've got your custom UI Table View cell class. You register that with your identifier. And now in iOS 6, what we're going to ask you to do is call dequeue reusable cell with identifier for index path.

And this method has a couple of real-time changes. It's got really neat kind of properties. And remember writing this code, right? Dequeue reusable cell with identifier. Check to see if you got a cell. If you didn't get a cell, allocate it to the thing, fill it out, you know, and then go through and configure your cell.

If you call dequeue reusable cell with identifier for index path, you will always get initialized instance. It will also be the right size for that index path. So you'll be able to do layout inside. And you'll be able to do layout inside your content view at that point knowing that the size is correct. So on iOS 6, you don't have to write that other code.

So we're making sure you can write less. So UI Table View Header Footer View is also a new class in iOS 6. It's a way to be able to do cell reuse for headers and footers as well. And it's very similar to UI Table View Cell itself. You can set a tint color. You'll have text and detail text labels. There's a content view. There's a background view for highlighted state.

All of these things work very similar to UI Table View Cell, including the way reuse works. So you'll be able to initialize with reuse identifier. You'll get a prepare for reuse method on your table header footer views. And the same thing. You'll be able to register those, and you'll call DQ reusable header footer view with identifier. You'll get a new instance. It'll be cooked.

It'll be the right size. Header view for section and footer view for section are how you can return these to the table view system. And you'll be able to also, in that index on the right-hand side, you know, when you put up a table view, and you've got the table view, you'll be able to do that.

So you can now actually theme those as well with colors. The section index color is for the actual text, and then the section index tracking background color is what color to use when the user puts their finger down on the index and starts moving around. So you can now also theme those things as well.

There are also new table view delegate methods. So the delegate is how you're finding out about things like user events as well as when views come in and out of the table view. So we always had table view, will display cell for row at index path. We're now introducing will display header view for section, will display footer view for section.

did end displaying cell, did end displaying header view, and did end displaying footer view. So now, as you're scrolling through, that delegate is going to get called back on all of these methods and tell you when the cells are coming in and out of the view hierarchy. So you'll be able to respond to events there.

And how many people actually have installed the seed? How many people were able to get through on the Wi-Fi to install the seed? Okay. If you've been fooling around with the refresh control, you've seen this. It's available on TableView, and it's very easy to use on TableView Controller.

The UI refresh control is a subclass of UI control, and when you pull down, you're going to see that round refresh circle, the arrow chasing its tail, and then if you pull down farther, we're making that extend, and then you release it, and you get the little indeterminate progress indicator.

That is a UI refresh control. It's set up just by calling init. It is a UI control, so you're going to set a target action on it so that when that control starts refreshing, you'll get a message on the target of the action. You can find out whether or not it's refreshing.

You can tint it, and if you're using it via UI TableView Controller, when you pull it down and you hit the threshold, we'll fire its target action automatically. You're responsible actually for calling end refreshing in order to get it back into its normal state, but you can also trigger that programmatically just by calling begin refreshing, right? But you will have to call end refreshing on your own.

So UI Collection View. If UI TableView is the workhorse of navigation in UIKit, UI Collection View is how you're going to do things that involve more than one column and do really sophisticated layout with it. So, you know, TableView is great for showing something vertically. Collection View is far more flexible.

If you've installed the seed on your iPads, you've noticed, hey, look, there's a clock app now. That clock app is using UI Collection View and its default layout for this view. This is basically a grid. It's got a bunch of regular sort of, you know, everything is the same size. They're laid out really cleanly.

There's an add button there. It's really -- it looks like a grid. It looks like the rest of the clocks. This is all possible with the default layout. But you can also do far more complex layouts like this one. This is the alarms layout inside the same application. It's a weekly kind of calendar. It shows all the alarms that you've got set on your iPad.

So the parts are really familiar. UI Collection View has a data source as a delegate there, UI Collection View sells, but it has this other layout object. So the system works the same way. Collection View asks its data source for the number of sections in a Collection View. Once it finds that out, it starts asking for the number of items in a particular section. Once it finds out how many items, it starts asking for cells for an item at the particular index path. You're going to vend those UI Collection View cells at that point.

The one difference between this is UI Collection View cell versus UI Table View cell. Table View cell, remember, has all of those custom, those default styles. You know, there's one for subtext and detail text and things like that. Collection View cell is really simple. It's a cell. It's just a view. It's got a background view. It has a selected background view. So these are how you're going to be able to do highlights and things like that.

And then it's also got a content view, and the content view is where you're going to put all of your stuff. Right? That's... it. You can do anything you want inside that, but there's no default styles or anything like that. This gives you tremendous flexibility in how you lay things out and how all of your appearance stuff is going to work.

So the delegate is very similar. Right? That's where you're going to find out about user events that are happening as the user taps on various things in the interface. Right? So you'll get should highlight item at index path. Collection View should select item at index path. Or did select item at index path. All of those things are events that you can respond to, and you'll get messages about them on the delegate.

The layout is really where Collection View's power lives. So the layout is a way to be able to have the Collection View be told where each item should go. So Collection View is really good at laying things out in a grid. The default layout mechanism is called UI Collection View Flow Layout.

And by default, it's a way to have the collection view be able to be told where each item should go. And by default, it's just going to sort of throw things out into this very regular pattern. And you can put section titles or supplementary views and decoration views and things like that. It's not just about putting the cells in as well, and those are all controlled by the layout.

But this isn't very interesting. And if you have to have everything be the same size, it's not particularly flexible. So Flow Layout also allows you to do things like this, where not all the cells are the same shape, not all the cells are the same size. The rows don't have to be the same size. You can think of it a little bit as type.

You can think of it as typing into a word processor and having things wrap. You'll be able to set things up so that you get exactly the kind of look you want. If Flow Layout doesn't do it for you, you can go right on to customizing and subclassing UI Collection View Layout yourself.

And you'll be able to do things like custom layouts that do stacks of things or custom layouts that don't fit readily into a grid. Right? This -- This is the Flow Layout. This guy is actually -- this other one, the alarms one, is actually a custom layout. It's not amazingly complicated, but it's one example of how you can exactly position all of the various elements of your collection.

There are two collection view sessions, introducing collection views and advanced collection views and building custom layouts. I hear that the demo in introducing collection views right at the end of the session is pretty amazing. So if you guys want to see the kinds of things that are possible with UI collection view, you should definitely go to that talk.

UI view controller. Again, another workhorse of UIKit. UI view controller is how we've been composing API and UI for a while, right? We've been vending a lot of things as UI view controllers now. They're really how we put together interfaces in a really flexible way. It allows you to use navigation controller and things like that really effectively.

We're working on trying to make UI view controller easier to use. One of the things we looked at was in view unloading. So view will unload and view did unload. These are called automatically in iOS 5 when you get did receive memory warning, right? You're going to take some steps to release some caches and things like that.

And then we're going to go ahead and call view will unload, and then we were taking the view out of the view hardware, we were unloading it from the view controller, and then we would call view did unload. There are actually two interesting things here. One was we were trying to help everybody control memory in an automated fashion. And we really wanted to make sure that we were doing it in a way that was really easy to use. And we really wanted to be able to make sure that everybody was using only exactly what they needed to use.

The catch is these are really hard to write. It's very easy to wind up in your view will unload and view did unload leaving a dangling pointer reference behind and then when we go ahead and unload those views, suddenly your app crashes. And memory warnings are hard things to actually debug around, so it's a tricky situation to be in.

Also, we did science. We do science at Apple occasionally, and this is one case where we did it, and we realized that the memory savings from cleaning up a pointer here and there in view will unload and view did unload is absolutely nothing compared to the fact that Core Animation is already taking the back end sort of layer out when it's not displayed anyway, and so all of that memory is the little bits of memory that you were cleaning up is completely dominated by what Core Animation is doing. So in iOS 6, these are deprecated. We're not calling them anymore.

That was not what I thought you guys were going to do. We also recommend that in iOS 5 and before, you don't implement them anymore. So if you're going to be deploying -- building on iOS 6 and deploying back, I think the earliest deployment target you can get in Xcode these days is 4.3.

Don't implement it. Don't bother. Write less code. If you were doing some things in ViewWillUnload and ViewDidUnload, you should look and figure out whether those things are more appropriately done either in the dialog or in ViewWillDisappear and ViewDidDisappear. But this was tough to figure out, and when we were running this in test code, we discovered that we fixed an entire class of crashers that really just were worth fixing. So that's why we're deprecating this.

The forwarding callbacks. When we introduced containment in iOS, what was it, 4, 3, 5? We introduced containment a while back, and it was a way to formalize parent and child view controller relationships. One of the things that we did was set it up so that parents forwarded their appearance callbacks and their rotation callbacks to their children. So if you were overriding automatically forward appearance and rotation methods to child view controllers to return no, then you were on the hook for doing that stuff yourself. We're splitting this into two methods.

We're deprecating that first really long one that I'm not going to say again. And we're putting that into should automatically forward rotation methods and should automatically forward appearance methods. So these still return yes by default. We're still going to go ahead and forward those. But if you override the latter one, should automatically forward appearance methods, we're going to ask you to do something a little bit different.

If you were overriding this and doing the forwarding by hand, you were sending viewWillAppear and viewDidAppear to the child view controllers yourself. It's tricky to get right in terms of when animations are happening and getting that in the right order and making sure that the state machine is preserved so that viewWillAppear always happens before viewDidAppear, and sometimes it's easy to get those reversed, things like that.

Rather than have you keep calling those by hand, and if you're forwarding it, UIKit also takes steps to make sure that some of those viewDidAppear or viewDidDisappear occur at the end of the run loop. We're going to ask you to call a different method. It's called beginAppearanceTransitionAnimated and endAppearanceTransition.

beginAppearanceTransitionAnimated, you're going to tell us if the view is appearing or it's disappearing. It's appearing if it's true, is appearing is no if you're taking the view out of the view hierarchy, and whether or not that appearance transition is animated. And then when you're done with that transition, you'll call endAppearanceTransition.

What this does is it goes ahead and calls viewWillAppear and viewDidAppear or viewWillDisappear and viewDidDisappear, and it makes sure to call them at exactly the right time so that the rest of UIKit is self-consistent in terms of animations and things like that. This is a new method in iOS 6. But it turns out it exists back in iOS 5. So if you're compiling on iOS 6, we've retro published it. It's available for use back in 5.0.

I'd like to talk a little bit about rotation and interface orientation. So this is our old friend, should auto rotate to interface orientation. Remember what happens when we rotate the device, we go through and if it's a navigation controller like this one, we're going to go ahead and ask a whole bunch of questions about the child view controllers and whether the top view controller supports that.

It's going to get asked, should auto rotate? It says, sure, let's auto rotate. We go ahead and rotate the device, and then we counter rotate the interface in order to make sure everything looks right. But interface orientation and rotation are kind of combined in this concept. And when you start looking at how that works, it gets a little more confusing when you move to something like an iPad.

Right? Because the iPad has a whole bunch of view controllers that tend to get nested. If you're using split view controller, you're kind of in this mode now. If you look at that guy right there, that's a view controller. He's a child view controller of another view controller, which is the child of another view controller, which is the root view controller. So we're four levels deep here.

And while this thing has an interface orientation, it kind of doesn't make a whole lot of sense. And one of the questions is, should this even be allowed to deny rotation, right? One of the things that we've been looking at is the fact that many times people are conflating interface orientation with layout and thinking things like, oh, hey, yeah, if I'm in landscape, I must be wider than I am tall.

Well, that's clearly not the case here for that highlighted view controller, right? He's taller than he is wide, but the interface orientation is landscape. And so trying to pile together the idea of layout with your orientation isn't quite right. We'd like you to think about layout as something that you're responsive to as the bounds of your view changes, right? Parent view controllers can take a child view controller, park their view in any aspect ratio they want. Your view controller should be responsive to that kind of layout. So we're looking at how to deal with some of these things. So it conflates interface orientation with rotation. It conflates interface orientation with layout. And in a lot of cases, it's meaningless.

We saw the child view controller case a minute ago, but a form sheet is another good example, right? It's this little small thing. It hovers in the middle of the screen. It doesn't really have interface orientation. So what we're looking at doing, and this is available in the seed, is we're going to change things a little bit. Should auto rotate to interface orientation, we're going to look at moving to the side a little bit. And we're going to go with supported interface orientations.

This is a bit mask of the interface orientations that your view controller supports, right? And preferred interface orientation for presentation is used when you're modally presenting a view controller. You're doing a full screen presentation, it's going to come up. Sometimes your view controller will support all the interface orientations, but it really prefers to be in landscape and the devices in portrait.

A great example of this is from Scott's demo yesterday when he called up the preview of the movie, right? That movie player came in, it came up in landscape, you saw the device rotate, right? He rotated the device in order to see it. So if you're going to be presenting view controllers with different orientations from the one that's on screen, you'll have that view controller return preferred interface orientation for presentation.

There's also a new method in UI application, supported interface orientations for window. You'll be able to turn supported interface orientations on and off for a given window at that level, but if you don't implement this, what we're doing now is we're going to believe what you told us in the Info.plist. So if you only want your application to do landscape left and landscape right, go ahead and declare that in the Info.plist. All of this is not on by default.

I'm getting a lot of like, oh, my God, this is, wow, big change. It is. It's not on by default. We'd like you to experiment with it, and the way you're going to experiment with it is by using UI application supported interface orientations is enabled. It's an NS user default key.

You can set this in your argument domain right from Xcode, or you can register it as a user default with NS user default. So we're going to set this in our user defaults register defaults. This will turn on a mode where we will start asking supported interface orientations, and we're only going to ask it at two times. We're going to ask it when you rotate, but we'll ask it of the root view controller and of the topmost presented full screen view controller.

It used to be really easy to wind up in a situation where you'd have supported interface orientations, and somewhere deep in the hierarchy, one of those things is going to say supported interface orientations. Should auto-rotate interface orientation? No. And then suddenly, it breaks. You have no idea why it's not rotating.

You have to go through and find all of the places where you've implemented that method and get it exactly right. Declaring supported interface orientations helps alleviate a lot of that. So please turn this on in the seed with your applications. Let us know what's working and what isn't working. we'd like to be able to turn this on pretty soon.

There's a UI view controller session called the Evolution of View Controllers on iOS. It's going to talk a lot about effective use of view controllers and how best to work alongside UIKit and the view controllers that we vend. So let's talk about Auto Layout, another thing that's coming from OS X to iOS.

View layout in iOS 5, pretty constrained, right? You can do explicit layout by calling set frame on your views. You're probably writing a lot of layout subviews code there in order to make sure that when things change, you're positioning all of those views exactly right. Not very flexible, tremendously powerful, lots of control.

You can use auto-resizing masks, springs and struts, right? You can set flexible width for, you know, particular left margin, right margin, flexible height for, you know, things like that. And that allows you to say, well, this view is always a fixed distance from the bottom, a flexible distance from the top, but it's always relative to its super view, right? And the minute your designer comes along and says, hey, I've got this great idea.

I want to have a button that's always 20%. 20 points to the left of another button, no matter where that other button is. And now you've been using springs and struts, everything's been great, and your designer just came to you with this great idea, and now you're like, oh, man, I've got to write all this layout subviews code. Constraints allow you to express the relationships between two objects, and once you've expressed those relationships, the frames get calculated automatically all the way down the view hierarchy for you whenever the layout changes, right? So the way you'll express this is by bringing in NSLayoutConstraint. LayoutConstraint.

LayoutConstraint has constraint with item. You're going to set up a constraint between two items. LayoutConstraint with item attribute related by two item attribute multiplier constant. There's that autocomplete thing again. And if we wanted to express that, it's really item one attribute is equal to some multiplier times item two attribute plus the constant.

All the math geeks out there are going, it's y equals mx plus b. This is so cool. Those relationships can also be greater. They're equal to, less than or equal to. In this case, we're going to use an equal to relationship. And the way it looks with those two buttons is this.

We're going to set up the constraint between button one's right edge. It should be equal to button two's left edge, NSLayoutAttribute left. The multiplier is going to be 1.0, but you can play around with that and see scaling effects in the equation. And the constant is minus 20.

That's 20 points to the left, so the right edge of that button is going to be 20 points to the left of the left edge of the second button. As these constraints change, if you set the constraint on that second button to move, the first one's just going to line up on its own. You can also set up minimums and maximums and things like that. LayoutConstraint.h defines the relations, so you can do less than or equal to, equal or greater than or equal to.

It also is going to define a bunch of attributes, so you can do left, right, top, bottom, leading and trailing space. You can do heights, center, X, center, Y. You can also line up on baselines. So, for instance, text fields vend their text baseline out as one of the attributes you can line up on.

Constraints are also there's a visual format. You can do all of this in IB, by the way. If you've got your nib up and you're clicking around, you'll see constraints show up in the inspector. You can set the relationships up between two objects, and it will emit those directly into the nib. They'll get loaded and set up for you automatically.

There's also a visual format, which is really easy to use. It returns an NSArray of constraints, because that one constraint that we did earlier just describes one thing. But you can set the visual format up to say, well, this view is 20 points from this other view and 30 points from this view, and it has a minimum width of 60.

You can set up their optional. There's a whole evaluation hierarchy here. You can make them prioritize so that certain constraints must be satisfied at a greater priority than other constraints. The maximums and minimums are really interesting, because you'll be able to do things like handle localization by setting constraints on your text views.

And then as the strings get longer or shorter, all of the constraints that are bound to that text view are going to go ahead and update. So the buttons will always be in the right place as your localizations change. It'll be a really, really handy way to be able to do localizations. And it can apply to any two views.

Those two views don't have to be in the same place. They don't have to be in the same direct sub-view hierarchy. They don't even have to be peers. They just have to have a common ancestor. So when you add the constraint to the view hierarchy, you have to add that constraint to the nearest common ancestor. If you do this in IB, it's all taken care of.

The Auto Layout session is, there are several, but the UI kit one, the introduction to Auto Layout for iOS and OS X. State restoration, another thing coming to iOS from OS X.

Right. So user hit the home button. All of these things got their little opportunity to encode a bunch of Restorable State, everything wanders off, and the app gets killed.

User relaunches the app. We're going to start restoring state. What happens here is this delegate method gets called, "Application will finish launching with options." It's a new method in iOS 6, and if you're using state restoration, what you're going to want to do is take most of the things that you were doing and did finish launching and move them up. So if you were initializing things that are required for your apps, run, move it into, "Will finish launching with options," if you want to be able to use state restoration.

Once we've gone through that, just before we call didFinishLaunchingWithOptions, we're going to run through and start asking you to create view controllers based on identifiers and identifier components. You can think of them like key paths. ViewControllerWithRestorationIdentifierP athCoder is going to get called. It's a class method that will get called and ask you to return a view controller for this particular thing. Here's the coder we used to write it out. And then those view controllers will get called with DecodeRestorableStateWithCoder. And that's where you can pull out all of that stuff you put in in the first place when the app started to go down.

State Preservation and Restoration sessions, Saving and Restoring Applications, State on iOS. This is a way to be able to do things in a really fine-grained fashion. One of the really cool things about the way State Preservation is working in iOS with view controllers is we're doing a bunch of this stuff for you. So, Table View Controller is going to go ahead and scroll away its scroll position and things like that. So, Navigation Controller is going to tell you about the navigation stack that's been pushed onto it by giving you those component paths.

So, we're doing a bunch of work on your behalf. What we'd like you to be able to do is concentrate on the state restoration bits that are unique to your view controllers and your applications. This should make it a lot easier to be able to get the user back to that state where they left off right after the app got killed.

One of the things that we talk about a lot in the hallway is what makes a great user interface. User interfaces are -- they're kind of funny things. Great UI design -- somebody said this on the hallway the other day. Great UI design allows expression and nuance in how the user interacts with your application.

And It's a neat statement. It's a little bit about just how you're able to give the user a really great user experience, but we also want you guys to be able to express the things that are important in your application in a really effective manner. Great UI design allows expression and nuance in how the user interacts with your application. This is running on my iPad. It is a UI label. It is an NS attributed string. It is one label. We are bringing styled text to iOS.

Getting piped all the way through our API. So if you go look at UILabel, you'll see set attributed text. You can do this on UILabel. You can do it on all the strings that you feed to UIPickerView. UITableViewCell has attributed text setters now.

We support a bunch of different attributes. UI kit NSAttributedString.h is defining things like the font attribute, paragraph styles, foreground color, background color, baseline offset, strikethroughs, underlines, shadows.

You'll be able to do all kinds of things with this. Chris Parker We now also have a string drawing category on NSAttributedString. Size, draw at point, and draw on rect are the really basic ones. Just go ahead and splat this attributed string onto the screen at this point.

There's also some more sophisticated string drawing API, Draw with Rect Options Context and Bounding Rect with Size Options Context. The former actually does the drawing. The latter will tell you how big a particular chunk of rendering has turned out to be. These are really, really powerful for being able to draw directly into images. So the options are things like truncating the last visible line, right? If it's going to hit the end and you're not going to be able to render the entire string, we'll go ahead and put an ellipsis there.

Things like line fragment origins to be able to find exactly where things are starting. Font letting and device metrics are also used. And that string drawing context is an object that's basically telling you -- that's your opportunity to tell us exactly the parameters of how you want it to draw. So things like the minimum scale factor and tracking adjustment. Or the actual scale factor. And actual tracking adjustment for the context. And the total bounds of how big you want that drawing. So this is really, really powerful stuff.

And hopefully it's going to be able to help you guys write really fantastic styled text apps that really express what you want to the user. So introduction to attributed strings for iOS. The advanced attributed strings talk. So we've got text engineers from UI kit who are going to be here to tell you all about all about attributed strings.

There are a lot of other sessions. There's also a lot of other things in UIKit, things like UI Activity View Controller, which is a way to be able to take advantage of all of the new social stuff that's going on, including as well as doing all of the things you could do before, like mailing something to someone or tweeting it or printing it, things like that.

Please take a look through the headers. Lots of other sessions going on. The social stuff, new social services, the Twitter framework has now been brought into the social framework. So there's Facebook integration for Chinese users. We've got Sina Weibo and a number of other social things that are going on there.

It works with Apple accounts. So all of the things that we did for Twitter integration to be able to make it easy for you guys to tweet from your applications without having to handle all of the authentication business, we're doing for all of these other services now as well. So you don't have to handle any of that stuff.

Game Center. You heard Scott talk about some of this at the end of the keynote a little bit. Challenges are available. You'll be able to send challenges not just from the Game Center application, but from within your application yourselves. There's a new consolidated view controller, and you'll get some control over the authentication API for Game Center as well. There are, I think, four or five Game Center sessions. Please check your schedules if you're using Game Center to go find out. There's a lot of new stuff here.

There's a new map application. You'll see maps look fantastic in all of your apps when they're brought in from MapKit. But there are now new ways to launch maps and indicate points of interest. And also there's new APIs for being able to write transit apps that will interact with the map application. PassKit.

You saw PassBook as well in the demo. PassKit is a way to be able to have downloadable cards for your applications. It has coupons and boarding passes, event tickets, things like that. They get pushed to the device. They're signed. There's an entire API both for e-mail and e-mail. You can use the API both for interacting with PassBook cards on the device as well as all of the server API that you would have to implement in order to support it. There are a couple of talks about that this week. Please go to those as well.

In-app purchases. There are new aspects to in-app purchases. You'll be able to track downloads and payment transactions. You'll be able to do content purchase right from within your application. And Apple can host your content. So if you're going to be doing things online, Apple will be able to host your content. your content.

EventKit, there are new APIs in EventKit to get proximity information and time-based alarms, you know, proximity information for your reminders and things like that. There's also a really great data privacy talk, and if you're interacting with core location reminders, address book, photos, or EventKit, we're taking new steps in order to make sure that the user gets to control exactly when your app gets access to their data, right? We're trying to make it very clear about what's happening and make it easier for you guys to know exactly when the user's allowed access to their data.

There are new messages for users so that you can find out, so that you can provide a reason why you need this information from the user. And also there's some API for when to present and not present UI. So if you've been denied access to something and you just want to hide a button, there's API for that as well. There's this data privacy session is happening. I think it's tomorrow, but check yourself. You can find out more about that in the next few weeks.

So if you're interested in that, check yourself. And if you're interested in the next few weeks, check yourself. And if you're interested in the next few weeks, check yourself. There are a number of related sessions this week. Building concurrent user interfaces in iOS. Anything you can do to not block the main thread is a great idea, so we've got some engineers talking about that.

Keyboard input in iOS, if you're doing any kind of sophisticated custom keyboards and things like that, we'll have an engineer talking about that. Enhancing user experience with scroll views. It's the Josh and Eliza show, again. Go see that. That is a fantastic talk every year, and it's everything about, you know, real-time data privacy. And I'm sure you'll be able to find out more about that. So we're talking about, you know, really advanced techniques in using scroll views effectively.

Up and running, making a great impression with every launch. Got a couple of UI kit and Siri engineers talking about how to get through application did finish launching as fast as possible and the kinds of things to do to really get a great impression from your app every time the user launches it. Polishing your interface rotations.

Rotation is -- the rotation experience is a key part of being -- of using iOS. It keeps the illusion of how fluid everything really is. Please go see that if you're doing anything with rotations. Building advanced gesture recognizers, right? Nobody wants to be overriding begin and end touches and all that other stuff. Gesture recognizers are really powerful. We've got to talk about that. And internationalization tips and tricks, right? Tim said to get your apps ready for China.

It's not just China. It's every country that we release in, you guys have an opportunity to sell your apps in. And if you're going to be doing that, internationalization is a key part of it. Okay. All right. Thank you. More information about all of this stuff, Mr. Jake Behrens, our UI frameworks evangelist, would be happy to talk to you. There's documentation online at developer.apple.com. The forums are open.