Welcome, everybody. Welcome to What's New in Cocoa. My name is Ali Ozer. I'm the director of Cocoa frameworks at Apple. So today we're going to talk about what's new in Cocoa. We're going to talk about changes in AppKit and Foundation frameworks and some related areas in Mountain Lion. And we're also going to give pointers to other talks, because there are many other talks that go into a lot of depth about what we're going to talk about. And also pointers to labs. We have labs throughout the week.

The topics we're going to cover-- first, iCloud with a focus on NS document handling. Then we're going to talk about high resolution gestures and layer-backed views. Notification center. Some new APIs we've added in Cocoa to support XPC. Some exciting changes in Objective-C, and a bunch of other topics. As I said, there's a lot to cover. So with that, let's dive into iCloud.

Now, the things I want to talk about here are just focused mostly on NS Document support. I'm also going to talk about autosave, which we introduced in Lion. I'm also going to talk about a few new changes made in File Manager. But before I start that, I want to do a quick demo. So here we have a machine with a user signed into iCloud. I'm going to launch TextEdit. As you know, TextEdit is an NS Document-based app. And when you first launch it, you get your new iCloud open panel.

Right now there are no documents, so this is what you get by default when you have no documents. Note that this open panel can also show your local file system. By clicking up here, you get your traditional open panel looking into your local file systems. You can change the view modes and so on just through these buttons here.

There's a new document button here. I'll go ahead and press it. And now you've got a new document. Now note that I can still bring up the open panel. and it's actually non-modal. I can interact with my document while I'm interacting with the Open Panel as well because it will enable you to manipulate your document directly from within the app without having to bring up a modal panel. Okay. So let's go ahead and type some stuff in my document. I'm going to literally type some stuff. Now look here.

I typed some stuff into my untitled document, and within just a few seconds, it actually got saved automatically, and it got put into iCloud, and within a few more seconds or however long it takes, it will appear on your other machines where you're signed into iCloud. So we are saving untitled documents now visibly because we want them to be available on all your machines. You don't want to be in a situation where you're at work, you're working on a new document, new ideas, then you forget to save, you go home, and the document isn't there. We want the documents to be available at all times.

Now, let's see. I want to show you a few other things. We made some changes to the file menu. There are now new items for renaming documents and moving documents. I'll show these in a second. We've also brought back Save As as an alternate to the duplicate menu item for those of you who missed it in Lion.

The title bar menu, which is available on NS document-based apps, also has similar functionality, rename, move to, et cetera. There's also a richer revert submenu, which actually gives you access to some interesting versions you might want to directly revert to. Now I'm going to use some of these menu items.

Let's, for instance, use rename. If you can see up there, the title bar now turned -- you can rename directly in the title bar. I have renamed my document, renamed here. I will also go ahead and move it from here, and I will choose to move it to desktop.

And the document moves out of iCloud onto my desktop. I can, again, move it back from here, or I can just simply drag it from here into the open panel. So the open panel does have these richer document manipulations directly. It allows richer manipulation of documents from within the app without having to go out to the finder.

Okay. So the last thing I want to show you is some of the support we've added in this document for handling with iCloud error conditions and some other things you might encounter. And I'm going to show just one of them. And I'm going to go ahead and turn off Wi-Fi. Normally not a good thing to do in a demo. I'm going to come ahead -- come into my document here and type more stuff.

And when I do that, you'll notice that I get this gentle popover telling me that iCloud is not reachable. Now my document is still being saved. It's being saved locally. It's just I'm getting warned that the document is not going to my other machines. Now, this popover is truly gentle.

I can still continue typing. And it will dismiss itself. However, it's just sort of there, you know, reminding me. And if I bring up the title bar menu, I can still see the warning here until the error corrects itself because, let's say, the shuttle bus gets out of the tunnel and I can access iCloud again. So this is sort of a non-modal alert situation that you might get in other cases as well.

You can imagine, you know, network is not always predictable. So with that, let's go back to our slides. So let's go back to our slides. So I showed you the iCloud open panel. It's a nice, clean look into your files. And you also still have access to, of course, all your local documents through using the more traditional view.

The Lion file menu looks like this, and we've added two new items, Rename and Move To. And we've made these available on your title bar menu as well, which you can just get by clicking on the title bar there, Rename, Move To. And of course, you have a richer Revert To menu, as I showed.

This is a bigger picture of that non-modal alert you might get. One thing I didn't show you during the demo is our conflict resolution. If you edit the same document on two different machines and somehow do create a conflict, you will get a panel like this. You can choose to keep one of the documents or both of the documents and maybe deal with it later. So it's fairly straightforward, and this is, again, built into an S document. So, you know, you're looking at all these features and wondering how much new code do you need to write.

Of course, when I ask a question like this on stage and it's a Cocoa conference, you know that the answer isn't going to be 1,000. It's not going to be 100 lines of code either. It's not going to be 10 lines of code. It's not going to be one line of code.

In this case, it's really free. It's zero lines of code. If you have an S document-based app, that's autosave enabled, and you've adopted the iCloud containers entitlement. So if you've already done this, your app will magically start working with the iCloud like I showed you in Mountain Lion.

Now let me give you a quick recap of autosave because I just mentioned that autosave was One of the big, of course, benefits of autosave is that it eliminates the need for Command-S. Users no longer have to hit Command-S to rename their -- originally save their document. They don't have to hit Command-S on an ongoing basis to continue saving that document. You know, it's -- the document -- the model is that the document on the screen is exactly the same as document that's on disk.

Another benefit of autosave is that we can now quit apps, restart the system, apply software updates without much hassle, because the system can now, at any point, quit your app, saving your changes beforehand without having to ask you, do you want to save your changes? So this is another benefit of autosave.

And with iCloud, we now have a third benefit to autosave, and that's that autosave greatly reduces the chance of conflicts. I mean, if you can imagine a user using a machine somewhere with a manual saving, it's going to be a lot easier to save the changes and they don't hit save for a few hours, then they leave that machine, go elsewhere and work on the same document. That's just going to create conflicts, and having to deal with conflicts is really not, you know, a good user experience. But by autosaving constantly -- and, you know, that's the model -- we really do reduce the chance of conflicts greatly.

So please, if you have a document-based app, adopt autosave. And even if you don't have a document-based app, autosave is a great model for the Macintosh user experience, of course, moving forward. So how much work is it to adopt autosave? Well, it turns out it's a lot more work than adopting iCloud, and by that I mean it's one line of code you have to write, not zero. You override this method and return yes.

There are a few other considerations. If you put up your own UIs, custom UIs, or if you touch the files behind NS documents back, you need to ensure serialization of those accesses. You need to save more efficiently if your document format is large, and you might need to take versions into account. Although versions are automatic, there are some things you can do to make the experience better.

And I will give you a pointer to another talk later in the week where we'll cover these in more depth. Now, I also mentioned NS File Manager. We made two API additions to File Manager to make working with iCloud easier. Now, these are methods you likely won't need to use if you're an NS document-based app, because we really do everything for you in an NS document-based app.

However, if you're not an NS document-based, these are methods you might want to look at. There's a quick way to check the current iCloud user now. This is pretty fast. You can call it from the main thread. It returns an opaque object that you can copy, you can code, Ubiquiti identity token. This will return nil. If the user is not logged into iCloud. You can also hear about changes to the current iCloud user by listening for this notification.

So with these, if you need to deal with iCloud at a lower level, these are good APIs to consider. Okay, so with that, let's switch to high resolution. And I'm saying this time it's for real, because some of you may know that we've actually been talking about high resolution for a while now. And to show that, I want to get on our high resolution time machine.

Now, I don't literally mean time machine, the backup mechanism we have. I mean a literal time machine. I don't really mean a literal time machine, because we don't have such a thing yet. So I do mean just a little browser through past WWDC. So I'm going to put up some slides, some with quaint fonts.

And the first one comes from 2002, where we apparently put this slide at the last bullet item telling you that NS image is a high-level resolution-dependent abstraction of images. As you know, resolution-dependence is what makes high resolution possible. And we're telling you about this. And we're telling you about this 10 years ago. And then fast forward two years, 2004, we told you in big font, one point is not equal to one pixel.

Also in 2004, we gave you this panel that lets you actually run at higher resolutions to test your high-resolution apps. In 2005, we put up this slide, Stuff You Should Not Be Doing. It's all about 64-bit. Somehow we snuck in there. Don't assume one pixel is one point.

Again, the same message. In 2006, we told you, use vector art or provide 1 and 4x bitmap representations. Back then, we were recommending 4x. We are not these days. In 2007, we put this gorgeous rendering of Aqua. It looks super, except we didn't quite get the window title corner there right. There's a little pixelated. I guess that's why we didn't ship back then. Also in 2007, we told you to be ready by 2008.

2008, we were quiet. 2009, we were quiet. In 2010, of course, we introduced the iPhone 4 with the gorgeous retina display, a revolutionary device. And last year at WWDC, we did talk to you about resolution dependence, again, in the context of Mac OS X. We talked about the new core screen scaling, and we also said back to the Mac. We explicitly said back to the Mac last year at WWDC. This is an actual slide. And, of course, earlier this year, the gorgeous new iPad with the retina display, and as most of you probably heard yesterday, we introduced the new retina display MacBook Pro.

So anyway, it's been a long path, but we're finally here. And, yeah, so let me just talk to you about how we do high resolution. High resolution on OS X is -- uses an integral to X scale factor, so it's a simplifying assumption like we do on iOS. By default, existing apps do run at 2X.

So existing Cocoa apps, even one you shipped last year or the year before, will run at 2X. It will have crisp text, crisp pads, crisp PDFs by default for the most part. The only thing that you might need to do is provide 2X bitmap artwork, because artwork is clearly 1X, of course.

It will be scaled up, so you will get not as crisp as possible artwork. However, though, most applications should work well, and many elements should work -- should look crisp. We do want you to, of course, take advantage of the retina display as quickly as possible by providing 2X artwork. There's a low resolution mode where apps run at 1X. This is for maximal compatibility.

This is magnified to 2X on screen. It's the default for Carbon applications and also for some Cocoa applications, which we know have trouble. And users can also select this if, for instance, an app they're trying to use on the retina display isn't behaving or maybe it has a plug-in that's not behaving.

They can actually bring up the app and say, "Hey, I'm going to use this." They can actually bring up the info panel, and you see a checkbox in the bottom there, sort of analogous to the 64, 32-bit checkbox we have, and they can click open in low resolution. So if an app seems to have troubles, this is a one-user way to fix it.

Now, high resolution on OS X has some things to deal with. For instance, a user might actually move a window from a retina display to a 1X display on the same device. And that requires rebuilding the window, maybe redrawing the content so it looks optimal on that display. A lot of AppKit classes have automatic behaviors.

I already talked about NSImage. It has support for multiple representations, and it can choose between them on the fly, depending on what kind of window it's drawing into. NSView has automatic scaling of layer backing. If you told NSView to be layer backed, it will automatically do the right thing.

NSTextView has support for fractional advances by default. If your app is linked against 10.8, we use fractional spaces, which gives you much more gorgeous text on retina displays. And NSColor has support for patterns, where most of the time you don't have to do anything to get correct pattern behaviors. Same for shadow with shadow behaviors. It's all automatic. And AutoLayout also helps in creating Nib files that are definitely resolution independent.

Now, one API I do want to talk about is block-based NSImage. This replaces most uses of the lock focus method in NSImage, which is a popular method. Lock focus draws in a single bitmap representation. It's not appropriate for different contexts. It will capture NSImage in 1X or maybe 2X, but it will not change dynamically. This new method in Mountain Lion, ImageWithSize flipped drawing handler, it takes a block that will be called to recreate the image. Let me give you a code snippet.

In Lion, here's what you might do. Create an image, lock focus. And let's say you go ahead and draw a red oval, and unlock focus. Now you've created an image at a certain size with a certain color profile, and so on. The mountain line equivalent would be like this, where you create your image using this new method, and you provide a block which does the appropriate drawing. We will call this block whenever needed, but we will not call it all the time. We will actually cache the results. For instance, if your window moves from one screen to the other or the color profile changes, et cetera, this might get called.

Now, high resolution, you can actually enable 2X modes on your Mac right now. I know all of you have ordered the new machines, but you don't have to wait for the delivery. You can actually do this today. Download the graphics tools for Xcode package. Open Quartz debug. Choose UI resolution from the menu bar and enable high display modes.

There's a checkbox, which you can just go ahead and check. Once you've done that, in system preferences, you get all these great new modes. For instance, on a 27-inch Apple display, you'll see 1280 by 720, but it's the high DPI mode. We're 4 pixels make up a point.

So you can actually test your apps right now. Okay, so let's move on to gestures. As you know, we've been adding a lot of great gesture support to the system and also to AppKit over the years. In the Mountain Lion, we've done more. First, we have some automatic behavior changes.

These are changes that you will get without having to do anything. One is accelerated scrolling. If you actually do quick scroll gesture three times in a row, the acceleration curve ramps up. And that allows you, by continuing to scroll, to get to the bottom or top of a long document much more quickly than before.

There is new overlay look -- overlay scroller look and behaviors in Mountain Lion. For instance, if you put two fingers down on your trackpad, the scroller becomes visible now. It appears. That lets you sort of get a sense for where you are in the document and how big your document is.

And if you roll over a visible scroller, it will expand now, allowing you to get a better grip on it. This is, again, all automatic within a scroll view. And also, smooth scrolling option, which used to be an option system preference, is now on by default all the time.

Now, some behaviors you might choose to adopt. Magnification. As you know, magnification is achieved by pinching in and out. And the scroll view now has support for it out of the box. You call allows magnification, yes. And then you can set the magnification factor. You can set other parameters. There are also some convenience methods. For instance, you can magnify to fit a certain rect. Just call this to just magnify a certain rect within your scroll view.

So fairly easy to use. So, at this point, let me just do a little detour and talk just a bit about animation and one of the ways we do animation in Cocoa, and that's the protocol, animatable property container protocol. It has a bunch of methods, but one of the methods is this animator method.

The animator method returns a proxy, and this proxy acts like the object, except that it animates most property sets, property changes, or other methods sent to it. For instance, NSView conforms to this protocol. That means it has the animator method. A bunch of other classes do as well, such as NSWindow and NSLayout constraint.

Now, if you told a scroll view, set magnification 2.0, that happens immediately. There's no animation. The scroll view will simply magnify to 2.0. But if you did want to magnify in an animated fashion, you can talk to the animator. So simply, my scroll view animator, set magnification 2.0. Similarly, you can send one of the other methods, magnify to FitRect, again, to the animator. And many other classes work this way.

If you want to animate, which is often appropriate when simulating a user action, this is what you might want to do. OK, so back to ScrollView. Smart magnification is something new we've added to NSScrollView. This is a feature that first appeared in Safari. This is two-finger double tap to automatically zoom into areas of interest. scroll view has default behavior where if it's at 100%, it will magnify to 150%. If it is at anything other than 100%, it will go back to 100%.

will support this out of the box, where it will smart magnify image attachments, it will smart magnify tables, it will actually dive into tables as you continue to smart magnify. And you can also customize this in your own view subclasses. You can either listen to event or respond to method, or you can override this convenient method for smart magnification at point in rect and return the rect of interest that the system should magnify to.

Quick look. This is three-finger tap. It used to be three-finger double tap in Lion. This, for instance, brings up in Lion, it brings up the lookup panel, dictionary or thesaurus lookup, for instance. There are new responder methods you can listen to and take custom action. This is implemented by TextView as well to actually do a quick look on attachments that may be in the TextView. And by default, if you don't respond to this, NS application still does a dictionary lookup like it did in Lion.

And the last thing I want to talk about in this section is NSPageController. NSPageController is a new class, and it's for efficient swipe navigation of views. And when I say efficient, that is really one of its primary goals here. NSPageController really tries to keep the user experience very responsive. So it's going to be doing asynchronous caching of your content, and just doing a lot of things in the background to make sure the user experience remains fluid. It's got three transition styles.

And these are all things you've seen in the system. The first style is history. This is something like you might see in Safari, where the model is new pages are coming in from the right side, and it's appropriate for something like Safari, where the user is just choosing new pages to move forward to. Here's how it looks.

Pages are coming in from the right side. And, of course, the user can still push them out of the way if they want to go back. The book style is appropriate for books, PDFs, or even pictures. Here the model is you have a pile of things in front of you already, and you're pushing pushing them out of the way towards the left. Here's what that looks like.

So again, it's appropriate for a book or photos, and this was preview just with a pile of photos. And finally, the strip style, where your views are just laid side by side. This is something like you see with full screen spaces, where you're just moving them left to right and just choosing which one you want to go to. So pretty straightforward. Page controller model is that it manages an array of content, arranged objects. This is appropriate for like the book mode, where you already know what you have, and there's a selected index pointing into this array.

Or you can create content from navigation history by using this method, navigate forward to object. This adds new objects to the history, and as you go back, it will also remove them from history. Now, again, earlier I talked about animation. You can, for instance, tell the page controller's animator to set selected index or to navigate forward to object, and it will animate instead of doing it immediately. Always something good, something to keep in mind there. Okay, let's move on to layer-backed views. Just a quick recap.

We added this feature for layer-backed views in 10.5. You make a view layer-backed by calling setOnceLayer, or you can actually enable a checkbox interface builder. This creates a core animation backing store for the view and all its subviews. This gives you smoother animations. It also gives you better responsiveness. However, fundamentally, drawRect is still called as before whenever that layer needs to be updated.

Think of the layer as bitmap that corresponds to your view, and we call drawRect to update it whenever it needs to be updated. In 10.7, we added this property, layerContentsRedrawPolicy, with which you can control how often drawRect is called. It's really a great idea to look at this and set it to the right value that's appropriate for what you're doing. In 10.8, we're adding new APIs to update layer contents declaratively. If in your NSView subclass you override this method, once updateLayer and return yes, instead of drawRect, we will actually call this new method called updateLayer.

and this allows animations to work better on background threads. We don't actually have to call the main thread anymore as much to cause you to do things. And it also enables memory savings if you declare that you're actually sharing various image resources or other resources between your layers.

So each layer does not actually have to have its own bitmap, which might be possible in some cases. Here's how you would use this. Here's traditional draw rect. You set the red color and you just fill the rect and fill the contents with red. With the update layer approach, you simply go ahead and set the background color of the layer to red.

NSColor.red.cgColor. If you had image, for instance, and NSImage, you wanted something faster than just a red box, you can do that by setting the contents to an NSImage. And one high-resolution tip here, if this NSImage has 1x and 2x representations in it, we will do that. Do all the work to make sure the right representation is used wherever that layer might be hosted, 1x or 2x window.

Those of you looking at this and who dealt with core animation might notice this new construct here, NSColor.redcolor.cgColor. If you're that challenged like me sometimes, this is also NSColor.redcolor.cgColor. We have added a new method to NSColor. It's CGColor. It returns a CGColor. If you've dealt with core animation -- That's something that should have been there for a while ago, but finally it's there. You can also go the other way, color with CG color.

So both ways. There are many other improvements with layer-backed views. For instance, there's improved subpixel anti-aliasing handling with layer-backed text. It used to be you had to call some CG APIs, and now we do it for you, and it's much better most of the time. A better management of flippantness, where there's an agreement between the flippantness of layers and views. We support nested animations and much, much more.

Okay, Notification Center. You saw Notification Center yesterday. It's our new notification feature in Mountain Lion that appears on the right side of your screen, and it looks like this. The API for it is called NSUserNotificationCenter, and first of all, just a clarification, this is not to be confused with NSNotification or CFNotification or CFUserNotification. We really like the word notification. It's fun to say, notification. So we decided to use it. Again, in more APIs, but NSUserNotification is a brand new API to this new Notification Center.

NSUserNotification instances, as you can imagine, represent notifications. You can set properties such as title and informative text and so on. And the NSUserNotificationCenter class is a singleton which allows management of notifications. You can schedule notifications. You can actually go through the list and trim them and so on. It also has a delegate which will get called whenever the user interacts with your notification. And, in fact, your app may be relaunched if necessary, if it's not running and the user clicks on a notification of yours and your response is needed. needed.

Let me show you a usage example, a fairly straightforward one. You want to post a notification now. You create a notification. You set a friendly greeting note, that title, hello. And then you deliver the notification, and this is immediate. Let me show you a delayed notification. This is a notification we posted in 30 seconds.

The way I'm going, you might sense something murky is coming up. Let's say you want to schedule a notification at the same time next day. So I want to schedule a notification at noon tomorrow. Right now it's noon. I want to do it at noon tomorrow. Here's what you think you want to do. 24 hours a day, 60 minutes, an hour, 60 seconds a minute. There you go. That looks good.

But some days have 23 hours. Some days have 24 hours. In some other exotic locales, maybe things are even different. So this is not good. If you want a schedule notification for an absolute time rather than a relative time, like 30 seconds from now, you really have to get your date computation right. Now, I'm not going to tell you all about this.

However, you need to take care of how you set absolute dates. And we had a whole talk about this topic last year. You can actually go to developer.apple.com/videos and listen to the -- or watch the Performing Calendar Calculations presentation. It really goes into good depth on this topic.

A few other notes about user notification is that notifications are presented only if your app is not frontmost. That's because if your app is frontmost, we assume your app is actually going to be doing something to tell the user that something's up. Users control how notifications are ultimately presented.

The user might choose not to see your notifications. For instance, during a presentation, notifications aren't popping up, you know, showing you all the mail I'm getting while I'm trying to talk here. So notifications may be disabled and you can't control this. You just post them and the user gets to see them however they wish. The guidelines for notifications is that they should be used sparingly. Don't put up a notification every time, you know, whoa, this happened, that happened, ooh, ooh. And consider cleaning up.

Now, the system will do some cleanup for you. It will only show a certain amount of notifications. But if your notifications are such that when a second one is posted, the first one is really meaningless, you can actually go and delete that first one. And so it won't appear in the user notification list, for instance.

Okay, now let's switch gears and talk about XPC and the Cocoa APIs we've added for XPC. We introduced XPC last year as a part of Lion. It's a new inter-process communication mechanism, and Cocoa XBC is the Cocoa-level APIs for this. Now, one reason we're interested in an inter-process communication mechanism is that in today's sandbox application world and so on, we really want applications and various helper processes to run with as minimal privileges as they need to get their job done.

And we want to sort of separate processes to these different islands of privilege. So, for instance, one process that has both full access to the network and full access to the file system and full access to your tax records is probably not a good thing. So we separate them into separate processes. And one way to get them to work together is through inter-process communication. And that's one of the things that XBC does for you. It really makes it easy to do that sort of thing.

And we're now introducing Cocoa APIs for this to make it even easier. Ali Ozer Ali Ozer: Now, we do have some -- I'm sorry. We do have some inter-process communication mechanisms. In Cocoa already, for instance, distributed objects. Why are we doing this? Well, this new API is secure.

It's more secure than distributed objects, and we'll see why. It's robust, more robust than distributed objects, because it's got a strong sense for error handling and so on, while distributed objects relied on exceptions, which is not a good thing to do when you're dealing with a relatively unpredictable resource like the network.

Cocoa XPC is asynchronous. All messages are one way, while DO was actually not one way, and that meant that your application could again hang waiting for the other side. And one other thing about Cocoa XPC is that it's Cocoa. Now, distributed objects was certainly Cocoa-level APIs. However, XPC, Mach messaging, sockets, et cetera, these other technologies, which are also available, they are not Cocoa, and they require converting of objects down to these lower layers, what we call impedance mismatch. You know, you want to send a string across the wire, you have to convert it to a lower-level representation before you send it across. Cocoa XPC has the advantage that we remove that impedance mismatch problem.

There are three major classes in this subsystem. NSXPC connection represents a connection, and it holds the object that your process is exporting, and it holds a proxy to the remote object from the other side. It also holds the API for these. It also holds error handlers. NSXPC listener is a class you would instantiate in a server or in a service.

It listens for new connections and talks to the delegate. NSXPC interface defines the APIs the objects respond to. As you might imagine, we really want to define the APIs between these processes clearly and concisely so that it's very clear what the communication paths are, and we're not opening up any more possible means of communication than necessary. To define interfaces, we use, of course, the NSXPC listener.

We have a great tool at our disposal, App Protocol, and that's what we use. This is the Objective-C protocol mechanism. Let me show you how you might create a simple protocol using Cocoa XPC. Let's say we have a server which compresses things. Let's say you just want to give it the ability to compress files.

Here's the method you might create. Now, I said that these APIs are asynchronous, so there's no return value. So this one just says go compress the contents of this URL. And that's good. I guess I won't hear about it. So it's a reasonable method, but it's really not very good from a user experience point of view, because we have no idea whether it succeeded or not.

If you want to get results back, you can't just put a bool return or an unnecessary return directly, because those would make the method asynchronous. But we have added the ability to sort of provide reply blocks that will be called when the job is done. And that version of this method would look like this. You can say compress data, here's some data, and come get back to me with the compressed data.

Here's how you might use this. I get my compressor. This is the remote object proxy for my connection. And I tell the compressor to compress the data. And here's the reply block I want to get called. And the reply block will write that compressed data out. And this will happen in my process. So that block that's highlighted right now executes asynchronously. So this method quickly returns. Execution continues. And at some later time, your block will be called to complete the job.

Secure coding is a new facility we're adding as a part of Cocoa XPC. It's a new protocol, and this protocol allows objects to declare that they respond to new decoding methods. Now, these are the NS coding methods. You might be familiar with them. For instance, decode object for key. A method such as this fetches the object identified by key from the archive, and it executes its init with coder methods or other methods for decoding the object.

The problem there is it's executing code, and by the time you're deciding I really don't want this object or this was some foreign object, it might be too late because some code got executed. An example is you might be expecting a string out of your archive, but somehow some object that already happens to be your process executes, and maybe the archive is filled with some set of bytes that causes that object to do bad things. The new methods we're adding allow you to specify exactly what class you're expecting, and if that class isn't what's encountered, the reading of the archive aborts.

So you say decode object of class. You can also specify a set of classes if that object might be one of several, or you can say, you know, I just want a propertyless class, which is one of our seven propertyless classes like string, array, dictionary. Okay, so let's now move on to Objective-C, and you saw some of these yesterday.

Some great new features, mostly around new syntax that makes code a lot less verbose and easier to write. There's new syntax for NSNumbers at 42. This is equivalent to the code that we used to create for the integer 42. At yes is equivalent to creating an NSNumber object from a Boolean. You can also do expressions in there. At open paren, 40 plus 2. More interestingly, this can be used to actually put an enum value in there, and that's some enum value with an at paren that creates an NSNumber with that.

You can also do this with NSStrings from C strings. And we already have, of course, a facility for creating constant NSStrings. We've had that for a while, but this now allows you to do it directly from, say, a function call. Now, one thing to watch here, though, that the return value of that function should be UTF-8 or ASCII, which is a subset of UTF-8, and make sure it doesn't return null, because otherwise that results in a runtime exception.

We have syntax for creating NSArrays at open bracket. Again, just list your objects. We have syntax for creating NSDictionary's at open brace, key, colon, object, and so on. We also have syntax for accessing those elements, array sub one, array sub n, et cetera. And also for dictionaries, dictionary sub your key.

Now, this syntax for accessing elements out of collections is actually available to you, because there are two methods you can override in your own collections, and you can implement this bracket syntax for your own objects as well. The first one is called index subscripting. The second one is called keyed subscripting.

As you know, ARC, automatic reference counting, relies on naming conventions and also relies on names, method names, and so on, to be named properly to decide how it does automatic retain and release. But sometimes you have a block of code or some misnamed API that doesn't quite follow the guidelines. We've added further abilities to declare nonstandard behaviors, and these are exposed with macros in Foundation.

For instance, if a method releases its argument, which is not something we say you should do, but some methods, including I think at least one in Foundation does it, so NS releases argument. And we have a bunch of other things like this that you can actually decorate your methods with, and some of these actually apply to IVARs if you want to carry that behavior onto an IVAR.

So these are good things to look at as you're converting your code to ARC. I mean, ideally, of course, we'd like you to rename your methods and make sure they're named properly, but sometimes that's not very easily possible. There are a number of other great features in Objective-C, automatic properties and multi-synthesis. You don't have to write at synthesize anymore. There is enums with fixed underlying types that helps us make our APIs better.

And Garbage collection is gone. We believe that automatic reference counting is really the way forward there. Now let's talk about some of the remaining topics. As I said, we have a lot of stuff and now with a little less depth. One of them is NS sharing service. This is the new feature we introduced yesterday in the keynote.

This allows your application to -- just allows users to share things easily with a uniform UI from various apps. For instance, in Safari, I can go click that button up there and I can say Twitter and up comes a Twitter sheet right inside Safari. Very direct, very easy, very straightforward and a nice UI.

This enables sharing of text, files, media, and really any other document format or whatever you want. It allows customization of the picker itself, so you can actually add items to that picker or remove items from that picker if it's appropriate for your application. You can also customize the UI for invoking the picker. You don't have to use a button. You can use a menu or you can use something else that's appropriate for your application. You can use a totally different custom look and so on, so that's totally up to you.

The application sandbox, as you know, application sandbox is a very important part of developing applications for the Macintosh. We've added two new features, and these are actually part of Lion SU, and of course they're also in 10.8. One is support for related items. These are files and folders that need to be accessed with a user document.

The user chooses a document in the open panel, but you want to give access to the application for some other items that are related to it, but you don't want the user to have to access it. The user doesn't have to necessarily go and one by one pick those. For instance, sometimes media folders sit next to the presentations that they're with. Another example is text edit. Text edit edits RTF files.

However, if the user drags an image into it, the file becomes RTFD and its name changes. You want that to be automatic. You don't want the user to have to go open, run the save panel again, for instance, just for that. So that's this support. The other one is security scoped bookmarks.

These are persistent access to your application. You want that to be able to access the user-chosen files and folders. Let's say your application allows the user to specify a downloads folder. You want that access to persist even if the application is quit or even if the system is rebooted and so on.

So that's what you'd use this for. Auto Layout, great technology that we added in Lion, and we've added a few more features now in Mountain Lion. One is support for text field wrapping. Previously, text fields just wanted to lay themselves out as if they're one line. If you wanted to wrap, you had to write some code. You no longer have to. You can actually specify the preferred width, and the text field will wrap when it gets to that.

There is improved support for NS split view. We now respect subview constraints. And also, you can specify different holding priorities for the different subviews, such that as the split view is collapsing or expanding, the different subviews will behave more appropriately to their content. You can actually specify individual holding priorities.

There's automatic localization now. As you know, most of the time when you specify constraints, they allow controls to resize and reposition based on content. And this content could be localized titles, for instance, for the buttons or other content. And leading trailing support enables right-to-left languages, so your whole interface can actually flip to give you a right-to-left interface.

And let's say your application deals in gigabytes. It doesn't bother, concern itself with anything smaller than a gigabyte. Well, it might just choose to use gigabyte-type units and above only, for instance. And you get this kind of output. Let's say you have 42 kilobytes and change. This is what you get by default. This is what Finder gives by default. Now, you can choose to get just the number part.

Let's say you're putting them in separate UIs. Or you can get the unit parts separately. Or if you want, you can get both that short version and the exact byte count, which is something that, for instance, this utility might do to give you an exact byte count of how big the disk is. And let's say you have a number in the gigabytes. By default, you'll get two decimal points, 12.35, which is, again, what Finder does.

: If you show it as megabytes, you get one decimal point. If you show it as kilobytes, you get no decimal points. So pretty good behaviors, reasonable, fairly good user experience. Let's say you're running in French, you get this output where your commas for thousands of operators have been replaced by spaces. And let's say you're running in Arabic with Saudi Arabian localization, you'll actually get this, where not only you're getting right-to-left rendering, you're also getting actual Arabic digits in this case.

NSString has support for localized number formatting. Now, it's always had this, but it was pretty weak. It just localized your decimal point. Now, it's methods like this, localized string format or init with format locale. These localize your decimal point but did not go any further than that. You have to use NSNumber formatter if you want to get richer localization of numbers.

But now, NSString will actually localize thousand separators and digits as well, sort of like we saw with byte count formatter. But because of compatibility considerations, we only do this for apps linked against 10.8. So as you relink your app with the 10.8 SDK, this is one of the things that you should consider and maybe look over your uses of these methods.

Automatic reference counting brought zeroing weak support, which means objects, when they're released, pointers that point to it can be zeroed out rather than left dangling, meaning they're not pointing at the least objects. And this support is--we've added this support to our three collection classes, MapTable, HashTable, and PointerArray. I'm just going to show you how this works with a code snippet.

So you go ahead and create an object, and then let's say you go ahead and create a map table. Now this API here, Strong to Weak Objects Map Table, is a new API we've added in 10.8. It specifies that you're creating a map table whose keys are strong, but the objects are zeroing weak. And then we go ahead and put the object in the table, and at some later time, the object is released.

If you ask the table for that object, you'll get back null. So actually the reference in the table has been cleared out. So this is pretty cool. The zeroing Wix port is pretty useful and should make for more robust programs. Now note that this actually works under manual reference counting. Actually I called object release up there. So this is not just limited to automatic reference counting. It also works under manual reference counting.

One other collection topic I want to touch upon is shared key dictionary. This is a new API that lets you create fast remutable dictionaries when you know the set of keys you're going to put in them. There's only two APIs for this. The first one lets you supply those keys and get back an opaque object, which is the shared key set.

And using that shared key set, you can now go ahead and create instances of an insurmutable dictionary. Here's how you might use it. First, create your shared key set with, for instance, the three keys color font underline, and then create your dictionary. Now you can use the same key set to create multiple dictionaries. In fact, that's one of the things that gives you a performance benefit for using this mechanism.

The performance benefits are that, one, we use minimal perfect hashing, so we eliminate collisions, which makes for faster lookups. And two, if you create many dictionaries with the same key set, there's actually going to be memory savings because we no longer have to save the keys in every dictionary. So this will result in increased memory savings. savings.

This class is flexible. It allows for keys that are not in the original key set. However, of course, the more you do this, the decrease, some of the performance benefits will decrease, because now you're using other keys that we didn't account for at the beginning. However, it will work.

So the last topic I'm going to talk about here is the behavior change in Resume. Now, as you know, as you might know, Resume is the facility that recreates your state after you log out and log back in. Now, one thing we've changed is that on login, apps that were hidden at logout time are partially relaunched.

We launched them enough to make them look like they're launched. However, they're not really running. So what do I mean here? Here is a snapshot of a system right after a login. Now you'll notice that TextEdit, Photo Booth, et cetera, they have their little dock lights on them. And in fact, if I hit Command-Tab, you'll notice that those applications are also in Command-Tab list. However, take a look at Activity Monitor. It shows that these applications at the top have used zero CPU time, are using 24 kilobytes of memory, and have one thread.

The last time any app ran like this on a Mac was for the original Macintosh. So these are pretty tiny apps here. So what's really happened is we've launched them enough to get us all the benefits of looking like they're launched, but they're really not really launched. So if the user goes and interacts with these apps, clicks on them, chooses them in the Command-Tab, et cetera, the app will be fully relaunched, and it will act just like normal. So there's really no difference in the user experience here. Now, one thing you might want to note here is that sometimes some apps might want to be relaunched on login if they are hidden because they're doing some background work.

For instance, Mail is fetching messages, and one way it can do that -- of course, in some cases, you might be able to use a background daemon to do this or maybe get notifications for this sort of stuff. But in some cases, the app maybe needs to be launched to do the work. We have a facility to allow this.

So what if your app does need to be relaunched? Well, an app will be relaunched on login if it opts into auto-termination, which you do by putting this key, "Sports automatic termination," in your Info.plist. Now, once you've done this, you can now call "enable automatic termination," "disable automatic termination," and these nest as a way to disable and enable automatic termination.

For instance, if you're doing something that should continue or that shouldn't be interrupted, that's what you would do. So if you happen to be not auto-terminable at the time, meaning you've called "disable automatic termination," you would be relaunched even though you're hidden. So that's one way you're a signal to the system that I am doing something important. Even if I'm hidden, do relaunch me.

Now, you can imagine something like mail. If it wasn't showing unread counts in its dock icon because the user didn't choose it, mail wouldn't have a reason to do this. But if the user is doing that, maybe mail would call this. So you could actually call this dynamically, depending on whether you're doing something important or not. So don't -- you know, don't do that. Don't blindly call this. Just actually see what's appropriate. But we really want you to adopt auto-termination.

This is a facility we added in Lion. It's useful for not only this, but a lot of other things. With auto-termination, we can actually have the system control your process's lifecycle independently of your app lifecycle, which gives the system a lot more leverage in adjusting the system's performance. And if you want to hear more about auto-termination or resume, we do have a talk from last year, developer.app.com/videos, "Resume an Automatic Termination." nation in Lyon.

So in summary, there is a ton of new user and developer features in Mountain Lion, and we'd really like you to look over this list and adopt the ones that make sense. Some are actually very little work, and the others are just few lines, and it'll make your applications much better. We have our documentation, our release notes, AppKit and Foundation, and our header files.

You can just look for occurrence of 10.8 to see what's new. If you want to browse through the header files, this is one quick thing to look at. And here is where you go for more information. You can email Jake and our documentation and dev forums. So thank you.