Good morning. Welcome to "What's New in Cocoa." My name is Ali Ozer. I'm the Director of Cocoa Frameworks at Apple. So I got a packed agenda today. We're going to give you a high-level coverage of the changes in Cocoa in OS X Yosemite, and we're going to give pointers to related sessions and relevant labs as well.

And the topics we're covering are New Look, Extensions and Handoff, which are big user features you saw yesterday. And then we're going to talk about some APIs such as Storyboards and View Controllers, API Modernization effort we've been doing. Of course, we're going to talk about Swift and some implications on Cocoa and Cocoa Touch APIs, and a number of other topics as well. And since I don't want to put this badge on every single slide, pretty much everything we're talking about today is new in OS X Yosemite or in some case to iOS 8 as well. OK, so with that, let's get started with New Look.

There are various components to New Look. You saw them yesterday and you've probably seen them if you installed Yosemite on your machines. There's an updated look for controls, there's translucency and vibrancy, there's new window styles, and there's also a new font in Yosemite. So let's take a look at updated look for controls. Here is the good old Sound Preferences Panel in Mavericks, and here is the same panel in Yosemite.

So one thing to notice is that, you know, there is a lighter - there is lighter, brighter colors, there is a clean and simpler look. I'm not going to go into the details here. We're going to do more of that in some other talks. But it is sort of a lighter, fresher look of course. And another thing to notice is that the controls are pretty much metrics compatible, so that's important thing to note.

Here's another comparison. This is the Add a New Mail Account panel. One thing you'll notice of course is the default button in Mavericks is pulsing, continuously pulsing while the one in Yosemite is not pulsing. Another thing to notice is the focus ring. The one in Yosemite is a lot cleaner while the one in Mavericks is a bit fuzzy. They both sort of wrap the control, but the Yosemite one has a cleaner look that's of course in line with the overall look of Yosemite.

Now, we have gotten rid of these long-running animations like the Default button, but we have some subtle animations in its place. You'll notice the Radio buttons, as you operate them, they sort of gently respond to your clicks or your touches just like that. And you'll see this in other - some other cases as well such as checkboxes and search fields.

Now, the good thing about all these, all these updated looks for controls, they're all automatic in your applications. When your application runs on Yosemite, it will pretty much inherit all these looks and behaviors. I mean unless you're doing something very custom using custom artwork on Saw and your apps will get the Yosemite look. In fact, we do not even support the Mavericks look for applications on Yosemite.

OK, let me talk now about translucency and vibrancy. So translucency, as you saw yesterday, translucency is the combination of transparency and blur, and it enables the personality of the desktop or the content that you're looking at to come through in your windows, and in a very aesthetically pleasing way. So let's look at places where we use translucency. Here is your default desktop picture.

You bring up a Safari window and this is sort of the Favorites view. You'll see that the whole window has a translucent background here. This is usually not the case in most cases. You know, once you start looking at content, the translucency is usually limited to the sidebar.

For instance here in your - and I'm sure what's your favorite app, Xcode. Mail also has the same sort of treatment in sidebar where you get the translucency in the sidebar area. Another use of translucency is something like a preview application. Here I have an image and I haven't scrolled it yet but once I start to scroll, you'll see that the image is going to start coming through the toolbar, title bar area of the window. Now note that this case is what we call in-window translucency while the other cases were behind the window or through the window translucency. There you're seeing to the desktop. Here we're just seeing through the title bar for the content of the window to my document view.

Other cases of translucency include the menu bar. I'm sorry, the menus and sheets as well, and popovers as well have this sort of treatment. So, translucency is automatic in many cases, sheets, menus, popovers, etcetera. Source lists, these are the table views and outline views which are configured to look like those sidebars, will also get a translucency automatically in most cases, and also title bars and toolbars will get translucency in a number of cases. Let me talk about that.

Whenever you have a window and you have a scroll view next to the title bar like in the case of Preview, you will get translucency treatment for that title bar area just like Preview does. This is the case for an app like TextEdit as well. Now, in other cases where you want to do more sophisticated things or you're not getting translucency automatically for your title bar, you can use this new Window Style Mask called NSFullSizeContentViewWindowMask.

In addition, we have properties such as titleVisibility and titlebarAppearsTransparent on NSWindow. And we'll have other talks where we're going to depth about these, but these new features allow you to do highly customized windows with translucency. An example is the Messages window. For instance, the Messages window has the sort of split look with the content area on the right and then the sidebar on the left for your - for the messages.

And if you put this on top of our desktop here, you'll see that there is through window translucency on the left side and in-window translucency for the messages content on your right side. The good news is we have APIs for you to do this sort of thing in your own applications as well where appropriate. So you can do sophisticated designs like this.

Now vibrancy goes very much hand in hand with translucency. Now translucency in general is of course averaging the foreground and the background as it blurs the background. And sometimes this could result in reduced contrast and it could even result - reduce overall impact of what you're trying to show the user.

Now, vibrancy, what vibrancy does is it helps pull the elements out by blending in fancy ways, for instance by using Color Dodge, Color Burn or variants of such blending modes. Let me show you an example here what I mean. Here is a little view, vibrant view which includes some texts and an image and they're now being treated with vibrancy.

If I were to remove vibrancy from this, you get the sort of slightly, you know, less punch to that. It's more grayish. It's not as impactful. I'm going to put the vibrancy back in, and it's really adding that punch that allows the user's content to come through and separated from the background and, you know, present it to the user. So this is vibrancy.

Now, vibrancy is automatic in contexts in most cases where we're applying translucency, and it's for controls and other NSViews where appropriate, but it's not appropriate for all cases, and I'll give an example of that in a few seconds. Now, to enable vibrancy and also translucency explicitly in your applications, we have a new view called NSVisualEffectView. You create it. You specify what kind of translucency you want, either in-window or behind-window, and you specify what kind of vibrant appearance you want. You have choice of dark or light.

And then, you populate it with vibrant-capable controls. And you can recognize such controls because they return YES from this new property called allowsVibrancy. And as I mentioned earlier, some controls offer vibrancy. They opt-in to vibrancy at appropriate times. Let me give you an example of that. Here's a window with two image views in it. On the left, we have an image view with a template image, and on the right we have an image view with just a regular image. Now, this is on a regular no translucency window. I'm going to put this on dark vibrancy.

And as you saw, the viewed imagery on the left is applying the vibrancy and treating the template image to give it the appropriate look on top of a dark vibrant background while the elephant image remains put. It's not affected at all. Similarly, if I'd switch to a light vibrancy, again, you're getting the vibrancy applied to the template image while the elephant image again stays put. So the NSImageView is dynamically deciding between being vibrant and not depending on its content.

We made some changes in NSColor. We've updated existing system colors to be consistent with, of course, the overall look of Yosemite, and we also made it so that some NSColors have appearance-specific variants. So what that means is - well, let me give you an example. Here's some text views drawing - drawn with the system color, and here is the same text drawn on a dark vibrant surface.

These are both using a new system color we've added called secondaryLabelColor, and you'll know that - note that in the dark vibrant case the text is actually appearing white. So it's a fairly different color. So you need to - you know, if you're ever assuming that colors stay put through the lifetime of an app or in different contexts, you know, it's good to stop that assumption and just use NSColors as is without taking them apart.

We have a new font and you've seen that. It's - the new font is Helvetica Neue. It's been optimized for OS X with metrics similar to Lucida Grande. Now, you should obtain this font with methods such as systemFontOfSize, which is of course what happens by default when you drag elements out in Xcode Interface Builder.

And now, for compatibility, if you're - for existing binaries, so applications are already out there, the applications which are linked against the 10.9 SDK or - and earlier, we do two things. One, if we see explicit references to Lucida Grande in a UI element, we assume that you really meant Helvetica Neue, and we just do a replacement.

In addition, if we find that the text clips or wraps because it's too wide for the area it has, we will compress it so it fits. So that, of course, ensures compatibility for existing applications. Now, note that we do not do this once your application is relinked, rebuilt against the 10.10 SDK. There, we want you to take a look at your app and correct any places where there may be problems.

Now, for instance if you're finding that some of your controls are too tight and not fitting, now I'd like to recommend you actually look at Auto Layout as a way to not only fix this problem but also make your application more forward looking and more easily localizable and so on.

The last thing I want to talk about here in this section is NSSegmentedControl. We have a new style of segmented control, SegmentStyleSeparated. It allows you to do things like the back/forward button you see here in Safari. It's also visible in a few other apps as well. And that's the new style of button that represents the back/forward buttons and other similar kinds of uses that you can switch it.

We have two related sessions for the new look, one this afternoon, "Adapting Your App to the New Look of Yosemite" and the another - another one, tomorrow, which is more advanced talk where you can learn about how to use vibrancy in more sophisticated ways and create windows like that Messages app you saw. OK, so now let me talk a bit about extensions. Again, extensions is a feature you saw yesterday.

Extensions provide access to your app's functionality and content in other apps. For those of you familiar with the services menu from earlier OS X releases, so it's sort of - the services menu is sort of a spiritual precursor to this feature. It's a much more limited scope version of the extensions feature.

Extensions run in a separate process from the app in which they have been invoked, which, of course, means there is security, performance and stability benefits. And extensions are delivered with apps as distinct bundles within the application. So, as you ship an app on the App Store or wherever you may ship it, you may bundle the extensions inside of it and the users can enable those extensions if they find them useful. Now, to add an extension to your application, in Xcode, you would go ahead and specify that you want a new target within your application project. And then, on OS X, you have choice of four extensions.

Action Extensions are, like the extensions you saw yesterday, the Markup Extension. They work within NSTextViews and WebViews and - the translate extension you saw in the afternoon is a - or maybe in the morning after which, was also another example of this. Finder Sync Extensions let you customize Finder's drawing in a safe manner. Share Extensions allow you to extend the Share menu.

And Today Extensions allow you to augment to Today view in the Notification Center, for instance like reminders, and you saw examples of this yesterday. Now, to use extensions, there are three new APIs, three new classes. Let me just show you how you would use these in your extension.

Inside of your extension, you have a Principal class. This is something you typically specify and tell us. For UI-based extension it would be a subclass of NSViewController or UIViewController. The principal class has a point with the ExtensionContext, which is basically the central point for that extensions data, and ExtensionContext has an array of NSExtensionItems where each NSExtensionItem represents a data that the user want to operate on.

For instance, in the case of the Markup Extension, the image that the user wants to edit will be represented by an NSExtensionItem. In turn, each NSExtensionItem points in an array of ItemProviders, and ItemProviders are basically what makes the data for that ExtensionItem available. There might be one, there might be more, and the extension can choose which provider it wants to use.

It's pretty straightforward to use these APIs. Inside of your extension, to get the array of items, you would just say extensionContext.inputItems, and then, you know, you work on them or you let the user work on them as in the case of markup. When you're done and you want to return the results, you put them in an array, or maybe that's an array of one, of course, if there's only one result, and then you call this API completeRequestReturningItems completionHandler. Now, if it turns out the user canceled the operation or there was an error, you can call this other API cancelRequestWithError. So, it's pretty straightforward. We have two sessions for extensions, one this afternoon, "Creating Extensions Part 1," and another one tomorrow morning.

So, let's talk about handoff. Again, a feature you saw yesterday at the keynote. Handoff enables users to seamlessly transition activities between their devices. And there is a simple base API here called NSUserActivity and their related APIs in NSApplication, NSDocument, NSResponder, and also in their UIKit counterparts as well because, as you know, this is a cross-platform feature. NSUserActivity encapsulates handoff information about a single user activity.

So, you create one with initWithActvityType, and you specify a sort of an identifier or the activity the user might be doing, whether it's browsing a web page, playing a game, editing a document, whatever. And then you go ahead and you set various information that would enable re-creating that activity on another device, as we can see here maybe the level, the location, the score that you're in the game.

And then you can go ahead and set a title which is user-visible title for that activity, and then at appropriate times you make that current or you tell it's no longer current. And the system apparently - the system looks at what activity is current and makes it available to other nearby devices as appropriate. So, you just need to worry about telling us when it's current and when it's not current.

That's pretty straightforward. In NSApplication, we have several APIs. The first one here indicates to you that the user has indicated an interest in moving an activity to your device, and you can return yes if you are handling it, or you can return no and let the system handle it. The next API application continueUserActivity actually gives you the NSUserActivity, which has the data from which you can re-create the activity.

Now, if you're using NSDocument, there's easy handoff support for iCloud documents. You really just have to do one thing and that is to add this key to your Info.plist for your document type indicating that you are supporting handoff for this document, and you specify a unique type identifier as you can see here, com.apple.TextEdit.editing. Now, if you're going to do something more sophisticated, for instance, specify the selection or some other viewing parameters with that handoff information, you do have a handle to the UserActivity off of the NSDocument that you can set the parameters in.

Next, I want to talk about Storyboards and View Controllers, which is a set of new APIs we're adding to OS X. Now, if you've done iOS development, you're very likely familiar with the concept of Storyboard, and Storyboard is a visual representation of the user interface of your application. So, it's giving you a higher level view of your user interface. It's higher level than creating individual nibs and maybe setting targets and actions together.

And if you want to just create a Storyboard application fairly straightforward in Xcode as you're creating your new app, you just go check this checkbox. Be simple. That's it. And will give you a default template that you can modify from there. Now, Storyboards specify different parts of your UI as different scenes, and then you would use segues to connect or transition between these Storyboards, between these scenes.

There are two classes, NSStoryboard, NSStoryboardSegue. These are very parallel to their UIKit counterparts. We also have a new protocol, SeguePerforming. This collects the SeguePerforming methods because on OS X, we have two classes that respond to these methods that's ViewController and WindowController as well, so they both respond to these SeguePerforming methods. In addition, these two classes also provide access to the Storyboard via a property. So, you can get - find out the Storyboard that they came from, that they were created from.

Now, we have two new View Controllers as well that of course help you create better Storyboards, TabViewController and SplitViewController and they - they've - you know, in spirit they're similar to the iOS counterparts. There's a few differences. Let me tell you how these work. So, you have a TabViewController, the TabViewController has an array of NSTabViewItems. Now you might be familiar with NSTabViewItem - it's a class we had for a long time.

We augmented just a bit to work with ViewControllers. Each TabViewItem, in turn, has a new property ViewController, and that might point to a ViewController in the case of a TabViewController setup like this. So, that's pretty straightforward. Let me show you how you create one of these structures. There are two ways to do it.

To add a child-view controller to a TabViewController, one way you could do it is you just first create an item, NSTabViewItem tabViewItemWithViewController. You go set - and that creates, so that creates that relationship there. You can go ahead and set the properties on the item - for instance it's a label and whatever else you want. And then you go ahead and add the item to the ViewController with addTabViewItem. So, this is one way to do it.

Another way to do it is simply take the ChildViewController, this guy here, and add it to the TabViewController directly with addChildViewController, which is a generic API we expose NSViewController. This will automatically create the TabViewItem for you and insert it in there. So, this is the - this is the approach you want to use if you don't want to deal with the item at all.

But if you do want to set properties on the item later, you can still get the item corresponding to that ChildViewController, and then you can set the properties just like you did in the other case. Now, let's look at SplitViewController, and no surprise, it turns out to be very parallel. SplitViewController has an array of SplitViewItems, which point to their ViewControllers. To create it, you do the item, you add it, or you create addChildViewController.

Got it? OK. Very parallel. OK, now we have some methods for View Controller presentation. If you want to do your own manual presentation rather than going through segues, you can present a View Controller as sheet, you can controller - you can present it as a modal window or as a popover, you can also of course dismiss View Controllers.

You can transition between View Controllers with this method here. The options give you the - how you want to transition. One little tip there, the options let you go slide left or right; you can also choose to slide forward or backward, which is a much more international savvy way of doing it because in an art - the right to left language it will go the other way, which is appropriate for the user's UI. We also have methods which will be familiar to you from iOS, methods that lets you see a - well - thanks.

I should have talked about this first, I guess. Anyway, viewWillAppear and the like and also methods to find out when layout appear. So, pretty straightforward stuff and a good addition to the class. One more thing about View Controller is that it's now automatically added into the responder chain. Oh there you go.

And again, let me just show a picture. I've been trying to read those two bullets. Here's your view, here's your responder chain, you have your ParentViews all the way up to the Window's ViewController. You have Child Views pointing at the View, and the ViewController would sort of hang on in the side - you know, I'm not part of that whole group there. Well, now it's part of that group. Note that we tried doing this for all apps and we ran into responder chain cycles, not a good idea. So, this happens - this change is effective only for apps built against the 10.10 SDK.

Let me now talk about something a little different, API Modernization. There have been many advances in Objective-C in recent years, for instance @property, that's been around for a while now, instancetype, enums with explicit underlying types, NS-REQUIRES-SUPER and a new one we just added, NS-DESIGNATED-INITIALIZER that lets you identify designated initializers. And then 10.10 and iOS 8 SDKs - we made a concerted effort to adopt these in a lot more of our APIs.

And why are we doing this? Well, these allow us to state the APIs more precisely, more correctly, and that of course has many benefits. The APIs are now more self-documenting. You don't have to go to the documentation as much. It's much clearer, right? They're on the other file when the API does.

It allows the APIs to be more consistent. You don't ever ask a question now. Why is this a property and this other thing that looks very much like it not a property? It allows Xcode to be more helpful - you now get much better context-sensitive completions in some cases.

It allows the - it enables the compiler to warn and to detect and warn about potential bugs, and this is really a big win, I mean it will really find some errors. And last but not least, it allows better exposure of our APIs in Swift. Swift, for instance, has a stricter definition for the property is and by declaring the properties explicitly in Objective-C, we allow them to be exposed properly in Swift as well.

Now, one consequence of all this is that as you build your applications against the new SDKs, you may see new warnings and errors in your build. Please pay attention to them because some of them might actually be potential or real bugs lurking around in your code. OK, now I will just talk a bit about one of these areas here and that's the @property change. Now, we've converted many accessors, many getter/setter pairs and getters in our APIs to @property.

And obvious ones, for instance if you look at NSControl, the target property and objectValue property are now real properties, and you'll notice that the target property is weak, and I'm going to talk about that in a second. But we also converted with our computed properties or possibly computed properties to @property. For instance integerValue and stringValue and NSControl might be computed off of the objectValue property, but we don't want to expose that implementation detail in our API, so we make them all into properties.

Now, you don't care as the API consumer. Another thing we have converted into property is something like description, which is obviously a computed. Every time you call it, it's going to generate a description. But that's also a good property we believe, and we made it into a property.

So, use property for anything that's about the value or state of an object or its relationship to other objects. So, then you might be wondering, what is not a property? Well, OK, not every method which can be expressed as a property should be. Not every method that looks like a property should be. You know, sometimes if it looks like a duck, it's not a duck.

The canonical example is the retain method, you know, the good old retain method for those of you who still remember what that is. It returns a value, it takes no argument, it looks like a getter but it's not a duck, it's neither on a property either. So, what are some examples of bad - what are bad candidates for @property? So, methods which do things such as load, parse and toggle - these might return like a parse state, they might return a result, they might return a Boolean, and they might take no arguments, but they are not properties. You can usually recognize these because they have a verb prefix on the name.

Generators like init methods, copy methods, some of these also have hit the first rule, of course, or objectEnumerator. These guys are returning new results every time. They are not returning values that are results that are item potent, meaning the same every time. So, they're not good candidates for properties. Another category is methods which change state such as nextObject, not a good candidate for property as well.

So, you have to make sure the methods also swim like a duck and quack like a duck before you make them into properties. Now, earlier you saw a weak property on NS - on the target property. We use zeroing weak for targets now, that's declared with the weak attribute on the target.

Now, this is effective only in applications linked against the 10.10 SDK. Previous or other applications' existing binaries, targets still have the assigned behavior. Now, we're also using weak for delegates and data sources moving forward in new APIs. For instance, here's a new API we added this release. However, we're not changing the existing delegate and data source methods to use weak properties. There's too many compatible illustrations for that one.

Now, as I said, we've done these in our APIs, but you can also modernize your code as well if you'd like, and it's a good idea because it might help you find bugs in your code and, you know, get the benefit I've shown. The Convert to Modern Objective-C syntax refactoring tool, which is actually in Xcode today, has been augmented to do some of these changes as well.

You can see some of them in this panel you get, and you can choose which ones you want to do and go ahead and do them. Now, one word of warning though, this tool doesn't do all the changes. It also may not get everything right. For instance, it might not get the exact type of property right. So, you really need to review the changes offered up by this tool and accept them or tweak them as needed.

The next - I'm going to talk about Swift, and there are a lot of sessions about Swift, so I'm not going to go into any language details or anything else about - I'll try to teach you Swift, anything like that. So, I hope you'll be able to go to those sessions and enjoy those. Swift - I'm just going to talk to you basically about the API interactions within the context of Cocoa and Cocoa Touch.

Swift is a new language for Cocoa, and it provides seamless interoperability with the Cocoa APIs and of course Objective-C code. Now, as you know, API is - API design is near and dear to our hearts. I've given a few API design talks in the past, so we think deeply about API considerations.

And existing API guidelines we have in Cocoa for Objective-C pretty much apply to Swift as well. And with just one exception that I'll talk about later, the init methods, there's really no changes in APIs as they're exposed in Swift. Now, this doesn't mean of course as we start adopting more of Swift features in our APIs as with more APIs forward, we won't be taking advantage of some of the new and exciting features of Swift that Objective-C does not offer.

So, we're going to be doing that over time of course. So, let me just show you how some Cocoa APIs come across in Swift. First, properties, here's a pretty obvious one. The NSRect - the frame property in NSView type, that's NSRect, pretty straightforward. Here's how it looks like in Swift.

Now, as I'm showing you these slides, if you're ever confused about which line is Objective-C, which line is Swift, just look for the lack of semicolon that identifies the Swift lines. Here's another one, Storyboard property off of NSViewController, here is what it looks like in Swift. Note the exclamation mark there on the Storyboard which indicates that the property of this could be nil and the get, which indicates that this is a read-only property.

And here is one more case, this is the subviews property off of NSArray which is of course declared as an NSArray in Objective-C which implicitly means an NSArray of ID. It comes across to Swift as an array of AnyObject, where AnyObject is the counterpart to ID. Now, this is one of the refinements I'm talking about. As we move forward, you know, we want to declare this API better because we - this is really an array of NSViews of course.

Right now, this is not coming through to the APIs here, but these are refinement that we'd like to do here and other places. And more importantly, as you define your own APIs and Swift within your programs, you know, take advantage of Swift's unique features to express your programs better.

Now, let me show you some mapping of methods, for instance methods with no arguments. Here's a simple case, displayIfNeeded. Here's what it looks like in Swift, and here's what the call looks like in Swift, displayIfNeeded with open and close paren at the end to indicate that this is a method call, pretty straightforward. Here's a method with one argument, an addSubview method.

And here's what it looks like in Swift. Now, note this aView here, and one thing to note is that this aView: is not a label - the name of this method is addSubview. This aView is simply the name of the variable, the name of the local variable for that argument as it exists in the Objective-C header making its way into the Swift interface here.

So, really the method signature of this method is addSubview, and it takes an NSView. Calling something like this is again also pretty straightforward, addSubview and then your arguments right there. Now let's look at the case with multiple arguments. Here's a new method, performSegueWithIdentifier that takes a segueID and a sender.

And the first part of the name goes outside the paren, and then any labels for second and further arguments go inside the paren like this. Note that the segueID is again the variable name for the local argument that goes there, and the sender goes right there with the sender. Since the label and the argument name are the same, Swift collapses them for you into one. It doesn't repeat the word sender.

So, note that in this case, the segueID is not part of - and it's not a label, it's not part of the name of the method but the sender is. So, really the method signature for this is performSegueWithIdentifier, a string argument and then sender: which is an AnyObject argument. An invocation of this is pretty straightforward as you can see here.

So, Cocoa APIs omit explicit label on the first argument. We saw that with the example from the previous slide. Here's another example. For instance this is how you call a delegate method, splitView canCollapseSubview, it works very well. The first part of the name includes the type of the first argument, and then the other labels describe the other arguments. Here's another example with three arguments, setResourceValue. Value is the first argument and forKey and error are explicit labels on the subsequent arguments. This results in natural method names that are easy to read, easy to speak, and easy to really craft as you're developing APIs.

Now, you might be thinking when to use - when should you consider labels on the first argument because Swift will - does allow you to put labels on the first argument in method names, it's just not the default behavior. One case is where arguments are equally weighed subparts of a whole. For instance let's say you had a method called moveToX y.

In Swift it would come across like this, and maybe this doesn't look so good. Why is X treated somewhat differently than Y? You might consider method names like this. It is actually the kind of structure you will see in free form functions in Swift where you have the ability to put labels on the argument.

But it's better in these cases to sort of think about if these are all equally weighed subparts of a whole, is there some combo type that represents them? For instance, in this case a CGPoint or an NSPoint. There are many other benefits to using a combo type. You're not schlepping all those arguments all over the place. Also, using a combined single type is a more atomic approach to APIs. Rather than specifying the arguments one by one, you're specifying this one whole thing to represent them.

And, you know, we have many other types to represent combined types, NSDate, NSDateComponents, UIColor, NSColor, NSRange, CGRect, we have a new SCNVector3 type to represent the points in 3D space and so on. So, you know, use such types where appropriate and it - and it gets rid of this problem. Now, earlier I mentioned init methods. Init methods are an exception to the label thing, it's another case to the rule with - about the first argument. Here's initWithFrame in Objective-C.

Here is how it comes across in Swift. Again, frame here is a label, and the way you call this is NSView - this is the sort of the constructor syntax, initializer syntax with the frame argument as a label in this case. So, you've now at least seen this in some of the code you read and in slides yesterday.

And there is the - yeah, the frame label. Now, convenience constructors - as you know in Objective-C we've had initializers, init methods. We've also had what we call these constructor methods like this one in NSColor, colorWithPatternImage. And these were just another way to say the init method except you didn't have to call alloc, hence the convenience aspect.

Swift recognizes these patterns and it - in fact, it reflects it as an initializer method just like this. So, Swift recognizes that this method is really init with a patternImage argument. So, this actually comes across in Swift just like initializer does which is actually great because it simplifies that dichotomy between convenience constructors and regular init methods.

Now, let me talk about one more thing about APIs and that's enumerated types because this one is really, really pretty cool. Here's a new enum we've added recently, a few releases ago ByteCountFormatterCountStyle. Note that it's got four values, but it's sort of hard to figure out what's different about those four. You know, they are these long words which are nice and descriptive, but it's sort of like, what's going on there? Here's what this looks like in Swift - it's really like a breath of fresh air like wow, you know, file, memory, decimal, binary, that's really cool.

And the usage is pretty neat too. Here is that enum. To call it you might say NSByteCountFormatter CountStyle.File. However in context where the argument's type is known, you really just have to use .File and, you know, now I can fit that bullet into one line, and I'll improve our slides moving forward, that's pretty cool. So-- thanks.

So, let's talk about Gesture Recognizers, which is another new API we've added. And again if you use Gesture Recognizers on iOS this is - this will feel familiar to you. Gesture Recognizers allow you to eliminate large chunks of code by doing the mouse tracking for you and just generating an action at the end for the appropriate gesture. It also helps disintegrate between various types of clicks and drags which might sometimes be hard to figure out. There's a new class GestureRecognizer; it's got five subclasses. And you can also create your own subclasses because we provide API that's specifically designed for subclassing an NSGestureRecognizer.

There's going to be more about gesture recognizers at the Storyboards and Controllers talk, which is this afternoon at 4:30. Now, if you must deal with events yourself or deal with other kinds of events other than mouse events, there is a block-based events tracking API. This also helps eliminate a lot of code by taking over that loop that you might often have to write.

This - whoops, let me show you the thing, there you go. So, this allows you to pass the mask of events you're interested in a timeout and there's a block that's called and the tracking will continue until you tell it to stop or until timeout, timeout is achieved. Thanks.

We have some new Accessibility APIs. The new APIs are simpler. They are expressed - the accessibility values, the accessibility values for various UI elements and UI properties are expressed directly as properties. There's no need to subclass. Good, somebody's used the old APIs. And there are better compile time warnings as well because there are now the actual properties being used here. Let me give you an example.

Before you've had this accessibility attribute value method which you had to overwrite, and you had a series of if statements to deal with it. Now you can either just go ahead and overwrite the accessibilityLabel method, fairly straightforward, or you can actually just set the property as well if you're not subclassing the, subclassing that class for other reasons. So, you know, much cleaner - a much cleaner approach.

Let me talk a bit about power, and here I'm talking about power, the kind of power that comes out of a wall socket. But even that kind of - even with that kind of power comes great responsibility, because we need to use it wisely. A new API we've added across the system in a number of classes in Cocoa is this concept of quality of service. It's NSOperation, NSOperationQueue, NSThread and so on.

This allows indicating the nature and importance of the work you're doing and lets system manage resources between your process and even across processes where possible. So let me talk about what the values of this QualityOfService property are. I'll just go through use cases for it. The first one, UserInteractive, is an interactive session with the user such as a drawing program or maybe scrolling an email message. You really want 60 frames per second there for the user, and that represents that kind of work.

The next layer here, UserInitiated is like when the user clicks on email message, they want it to appear there very quickly, but maybe you don't have the same 60 fps continuous behavior, although you still want to give, you know, whatever is possible to get that to happen as quickly as possible.

Utility QualityOfService is something like periodic mail fetch. The user expects it to happen, expects it to happen fast on a regular basis but, you know, it can be off by a few seconds if the system is busy with other things. We have a Background QualityOfService, which is like indexing, which needs to happen but could be delayed if there are more important things happening. And then the Default which allows the QualityOfService to be inferred from other operations that are going on. Sometimes you might have a dependent operation that will dictate what the resulting QualityOfService here is.

We also have a new API, new class called NSBackgroundActvityScheduler. This is basically a Cocoa-level interface to XPC Activity APIs. This allows you to schedule maintenance or background kinds of tasks, for instance, periodic fetching of mail or maybe indexing, and so on, and you can provide again quality of service that you want on this operation.

We have a number of talks about power. Here's pointers to two of them. One is tomorrow morning, "Writing Energy Efficient Code, Part 1" and also Part 2 as well that you can go through after this one if you want, and "Power, Performance and Diagnostics: What's New in GCD and XPC," and that's Thursday afternoon at 2. Now, let me talk to you a bit about NSStrings. We have a new API, NSString Encoding Detector.

This is to allow detecting encodings of random bags of bytes which come from who knows where, who knows where they've been, but you need to show it to the user and, you know, typically we - the encodings if there are some bad characters in there or either badly generated or corrupted along the way, it becomes pretty hard to make heads or tails out of it, and that's what this API tries to do. We have a number of options.

Among the options are the ability to specify which encodings to include, consider for sure, or which encodings to exclude. So we can give hints to make the operation more focused. You can tell us whether you want lossy conversion or not. If encoding conversion is not possible without loss, we'll just do it anyway and maybe some characters are lost.

And finally, or not finally, this is just another option, you can provide a language hint which allows the encoding conversion to again focus more if it knows what language the encoding it was intended to be in. We have two small new APIs, containsString and localizedCaseInsensitive ContainsString. You might be thinking, you mean though these weren't there? Well, they were, you know, you could use range of string, but after some years we've decided, you know, even though these are just one liners--

Yeah, even-- thank you. Even though these are one liners and, you know, that sort of offends the API sensibility of why create a one line convenience, they're really good for discoverability, you know, containsString is a little more discoverable than a range of string. So, here we have them. OK, the one other thing I want to talk to you about since this might impact your apps is Tagged Pointer Strings.

What we do here is we take a whole NSString object and we stuff it into the base pointer. Now, this is something we're already doing with some objects like NSNumbers and NSDates, and now we're doing them with NSStrings as well. Let me give you a visual guide of how this works. Here you're creating a UTF8String.

Typically you have your object pointer, the base pointer which is the pointer, and then that in turn points to an object which contains the isa plus some bookkeeping information and then the bytes of the string. So, we just take all that and we shove it just like that into the base pointer. I mean, you saw how that works. And now we don't need - it's not a pointer anymore, so we can get rid of the pointer. So, now in that 64 bits, we have the whole string with - along with some bit keeping information.

Now, it turns out we can do this for about 25 to 40 percent of your strings in some applications. There are some things to watch for. There is no isa pointer. Now, you weren't supposed to be accessing the isa pointer, but if you were, you will really crash for now. There are different performance characteristics: Some operations get much faster and some get a little slower.

And there are better out-of-bounds checking. We've made sure that these can do much better for out-of-bounds checking. We try to do a bit of out-of-bounds checking, but there are some cases where we miss and this actually does a better job. Since all of these three are potential compatibility concerns, we actually make it so that these changes enabled for 10.10 linked apps or later but not earlier apps.

And so of course only for 64-bit apps because trying to shove all of them to a 30-bit pointer is not fun. Let me talk a bit about formatters. And here we have a bunch of new formatter classes, NSFormatter classes. The first three are fairly straightforward, MassFormatter, EnergyFormatter and LengthFormatter. We also have a DateIntervalFormatter that will - should take two dates and show you this -

Thank you. And a DateComponentsFormatter, which will show you a duration such as 3 hours, 25 minutes. And these have some various customization options. For instance the last one could be customized to say, you know about 10 minutes remaining.

And now note that these are for formatting only, not for parsing, so it's for output of data. We have a formatting context property on all our NSFormatters, and here is what it looks like, and I'll just explain to you what some of these are. Well, what formatting context does is it tells the formatter where the result of the formatting is intended to be used, and that allows it to give a different result where possible.

For instance, if you're formatting dates in French, BeginningOfSentence would look like this, Juin with a capital J, while the MiddleOfSentence would use a little j. Now, this dynamic here, one is pretty cool because what it does is depending on whether the result is used in the context of NSString formatting, depending on whether it's used at the BeginningOfSentence, MiddleOfSentence or Standalone, it will use one of the other three options to do the right thing. So, it's - that one is usually the one you want to use unless you definitely know where the result is going. There was internationalization talk this morning. If you missed it, you can catch it on video of course.

Let me talk a bit about iCloud, and you heard about iCloud yesterday, of course. We have new APIs, the CloudKit APIs. This is a new framework for managing structured data on iCloud and for sharing such data between users as well. And CloudKit is also, as an implementation detail, the back-end for iCloud document storage as well.

I'm not going to talk about CloudKit anymore other than just telling you there are two great sessions you can go to this afternoon and Thursday afternoon. Now, iCloud document storage, as you know, iCloud document storage is something we've had for a while, and NSDocument and UIDocument provide support for it.

So, it has a new back-end in the form of CloudKit, and we also have another feature where document versions are now available on iCloud. In addition, you've heard about iCloud Drive yesterday where all applications can now read and write files from iCloud, thanks to the iCloud Drive as well.

Now, in moving to the new back-end and taking advantages of some of these other changes, some of the way we worked with iCloud documents has changed. Now, of course if you're using NSDocument and UIDocument, perhaps you don't have to worry about these, perhaps you do. Handling of non-downloaded files has changed.

Previously, there would be a file with the same name as the non-downloaded document, and we just fill in over time. Now, such files are tracked with invisible files with different names. If you're using APIs such as MetadataQuery, MetadataItem, FileCoordinator, you're probably in good shape and you probably don't have to worry about this.

Well, if you're enumerating the iCloud container yourself, you need to ignore hidden or unrecognized files, but better yet, just switch to one of these other APIs if you can, and the higher level the better. We also have some APIs on NSURL that allow you to get metadata for possibly undownloaded elements, and this is like getPromisedItemResourceValue forKey error and there are few other methods like this as well.

Just a quick update on Core Data: We have a number of new APIs in Core Data. NSBatchUpdateRequest allows you to do batch updates, and that's actually pretty cool on, you know, small memory situations as well if you're going to do a lot of updates efficiently. NSAsynchronousFetchRequest is a new class for doing asynchronous fetching.

It provides NSProgress support, which allows you to monitor progress and also in fact cancel the operation as well. And finally, of course, it's worth mentioning that the new back-end for iCloud is also underneath Core Data as well. So, there's infrastructure improvements. We do have a related session, "What's New in Core Data," Thursday morning.

Auto Layout, we have some - we've been improving Auto Layout all along. Auto Layout remains a very important facility in our frameworks both on iOS and OS X. We have some new APIs here, I'm just going to talk about a few of them. These allow you to activate NSLayoutConstraints directly.

As you might know, a LayoutConstraint has pointer to the views that it's defining a relationship for. So, rather than talking to the views, you can now talk to the LayoutConstraints directly to activate them, deactivate them, which is a much cleaner model. So, what this means is these three methods here - the two methods plus the property replace these four existing methods effectively.

NSCell is on its way to formal deprecation, I think we've been saying this for a few years now. I mean it still is. So, some NSCell APIs have been promoted to their corresponding control subclasses, and so you should use the controls where possible, you know, don't use cells controls now, have the APIs hopefully and you can refer to them.

NSCell-based TableView has been deprecated, use the view-based TableView that also allows you to get some of our new - the new features we've been showing you with new look and so on much more easily. NSMatrix-based NSBrowser is deprecated. Use the item-based NSBrowser APIs. And NSMatrix is also on its way out since it's so NSCell-based.

One of the most common uses for NSMatrixes was of course that radio button behavior where you click one and all the others turn off. Now, sibling radio buttons with the same action will now operate as a group. So, this is a way to get NSMatrix functionality without using NSMatrix.

OK, now I'm going to go quickly through some other new stuff. You can slow this down when you're watching the video, if you want to catch more about it. So, NSTableView and OutlineViews, you can create these statically now. If you just have a fixed TableView with like five rows and you don't want to do anything else, you don't want to provide data source, you can do that now. There's a way to do it. NSImage allows you to specify fancy resizing behaviors. You can specify capInsets.

You can also specify resizingMode, and you can also use such NSImages as masks for a digital effect viewpoint, so that's pretty good. NSBitmapImageReps allow you to specify in DNS and other bitmap format so you can actually support BGRA data for instance, if you're into that sort of thing. And asset catalogs in Xcode now support more formats like JPEG images, and PDFs, and also allow you to do slicing and then use of course the NSImage capInsets API to expose that slice information. You can do letterpress text effects with AttributedString.

Popovers now have a much easier way to detach. You don't have to worry about creating the window or whatever, just respond to this delegate method. ComboBox, DatePicker, PopupButton, SearchField, and SplitView now all do right-to-left properly and will flip as you might - as the user might expect, and so you don't have to worry about this.

NibLoading has a new API to do custom setup in your view subclass for live views support in Interface Builder. So this is just to use in the context of Interface Builder if you want to do something custom, well, for debugging purposes. OpenGLContext, you can now query some properties so you don't have to go down to the CGLContext.

FileCoordinator has methods for asynchronous waiting. So, rather than having to call these methods on your own background queues, you let the file coordinator create and manage the queues for you, it's a much better way to do this. NSWorkspace has methods - as you're opening URLs, you can now specify exactly which app you want to be used.

And NSURL also has a lot of new APIs. One for instance will allow you to resolve alias files with URLByResolvingAliasFileAtURL. OK, and we have last two, NSProcessInfo has methods to get the operatingSystemVersion, and you can do operatingSystemVersion comparisons if you must. And NSXPCConnection has support for NSProgress support across processes, which actually is a pretty cool feature as well.

OK. So no more pictures of food because we're done. Here are the things we talked about, many exciting features, some of these are free, some not. Now, as you go down to lunch, I expect you to try to adopt these in your applications, see how it's working and come find us at the labs, so if it doesn't work. And here is information about who to contact, Jake Behrens, he's sitting right there, he's a pretty great guy.

And one note, our release notes for Yosemite are not yet available. We hope to make them available very soon. And the related sessions I've shown you most of these, "What's New in Interface Builder," I hadn't shown you that before. That's tomorrow afternoon. And with that, thank you very much.