Alright, good morning. Thanks so much for coming out this morning to learn all about what's new in Cocoa Touch. Now normally, Eliza would join me up here a little bit later although this year actually you're just going to be hearing from me. So, she'll be back in later years. Don't worry about it. This morning we're going to talk about things in three main categories.

We're going to start with some framework updates including things like performance and security. Then we're going to talk about some API enhancements across a number of different existing APIs in the SDK, including notifications and messages. And then we're going to end with Siri Shortcuts. So let's get started with our first topic: Performance Updates. Now we're going to talk about performance across three main areas: scrolling, memory, and auto layout. Now before we get in to it, it's important to keep in mind one little bit of background information about scrolling.

Scrolling on iOS follows a pretty common pattern in most places. We load content to be displayed into the views and then we're just moving that content around. And while we're moving it around, most of those frames are really cheap to generate because we don't have to load anything new.

But every now and then, a new view first becomes visible and the one frame when that first happens is quite a bit more expensive to generate than those other cheaper ones. Now, of course, once that one frame is loaded, we're just back to moving content around, so the amount of work we do on the CPU goes back to being pretty small for most of that other scrolling.

So what's happening during that really expensive frame that causes that one to be more than all the others? Well, let's take a look from the perspective UI Table View but everything we look at here will really be the same for UI Collection View or really any of your own custom views that you may build that behave in similar ways. So the work in that expensive frame probably starts in your implementation of TableView, cell For Row At index Path delegate method.

Now the first thing we're going to do in there is get the cell that we want to display. And so we're going to try and dequeue it ideally from the reuse queue although if one is not available already in the queue, we might actually have to do some memory allocation in order to get it ready.

Once we have the cell, we're then going to populate it with your model data. Now how expensive that is will vary depending on your application but it can be including a fairly large amount of expensive operations like reading files, loading data out of databases, or other things of that nature. So you'll definitely want to look at the expense here in your own apps but it tends to be this is where a good portion of it will exist.

Now, you may think looking here that that's the end of the expensive work but even once you return from this method, there's actually more work that has to happen in order to get the cell prepared to have it show up on screen. So, of course, next, we have to lay out all of the content in that cell. We need to size all the views and position them in the right spot. Now, this can actually be a pretty substantial amount of the total time that we're spending because it can include other expensive operations like measuring text.

Once everything is properly sized and positioned, then it's time to generate any content that would need to be drawn using drawing calls and to do that we have to call draw Rect on all of the subviews within that cell. Again, this can be a pretty large amount of the time because we'll also be doing things like drawing text.

So overall, there's a lot of work that has to happen across this whole piece of code and it has to happen in a really short period of time. On our 60-hertz devices, you have 16 milliseconds to complete all this work in order to make sure you don't drop any frames, and maintain smooth scrolling. On our 12-hertz iPads, on the iPad Pro, you have only 8 milliseconds to complete all of that work. So, it really needs to be done as quickly as possible.

Now, to help with that, in iOS 10, we introduced a cell prefetching API and the idea with the prefetch API is to take some of this work, populating your cell with model data, and pull it out of this critical section that's happening on demand in that short window, do it earlier, and do it on a background thread so it can happen asynchronously with some of the other work, in particular those cheaper scrolling frames we talked about.

Now adopting this is really easy. It's just a UI Table View Data Source Prefetching protocol and it only has two methods, only one of which is actually required. And the idea here is to move some of that expensive work of loading things from files or reading your database into here so that you don't have to do it on demand.

You data is already prepared when the cell is needed for display. So this in most cases can be a really big win although while we were looking at some of our own apps in iOS 12, we actually noticed a case where this was causing an issue instead of helping us. So let's take a look at what that looked like.

Now here's an example of a trace that we took while scrolling on an iPhone 6 Plus. The vertical bars across the top, those represent frames that we want to display. The alternating light and dark blue colors represent frames that we did swap to the display as they were changing.

And that double wide light blue bar, that is a place where we drew the same frame for two full frame durations. So for a customer looking at the device while this was happening, that looked like a dropped frame or a scrolling hitch, which obviously is what we're trying to avoid.

So what was happening in this case? Well, here you can see that red bar is representing the time that we're spending in the critical section we just talked about, all the self-[inaudible] index path, layout, and drawing. And here, it's actually taking longer than the 16 milliseconds we had to draw the frame.

Now because the device can only swap new frames onto the screen at fixed positions in time, once we miss that deadline, we ended up displaying the same frame for two full durations, which was obviously not great. So why did that happen here? In this case, we're looking at an app where we actually had implemented the cell prefetching method so our data should've been ready. Ideally, this could've been done more quickly.

Well, if we look at a little more of the trace, we can see what was going on. The cell prefetching API was being called at the same time that we were requesting the current cell. Now it wasn't being called for the data for the current cell. It was being called for data that we might need in a future cell, but it was getting run at the same time. And so there was now contention for the CPU as we tried to both load the current frame and also load data for a future frame that we don't actually need yet.

So because of that contention, it actually caused both tasks to take a little bit longer. Now in iOS 12, we're much more intelligent about scheduling these background prefetch operations so that rather than happening concurrently and causing some CPU contention, they'll now happen serially, shortening the time that you need to take to load the current cell and helping avoid dropped frames in many cases.

So once we had that fixed, we kept profiling our apps and we actually found another case where there was a bit of a surprising cause of some dropped frames. Now what we found was that when the device was not under load, there was no background activity, all we were doing was a little bit of scrolling in the foreground app.

Counterintuitively, we could actually drop more frames than times when there was some small amount of light background work going on. That didn't really make a lot of sense. And to understand why it was happening, we had to drop down a level and take a look at the behavior of the CPU when it was scheduling our workloads. So let's take a look at another trace.

Here, we've got the same situation. Double wide blue bar is causing us to drop a frame or rather is our dropped frame. Now here we can see a graph of our CPU's performance over time. Now during most of those cheap frames, our CPU performance is staying pretty low.

There's no background work going on. All we're doing is scrolling things and that's exactly what you would want because when we're not doing expensive work for scrolling, you want to keep the CPU as low as possible to preserve battery life. So that was great. What wasn't great is that it took a little bit of time before it could ramp up. You heard about this yesterday in the keynote.

Now when it did finally ramp up, it was already too late to have completed the work to load the cell that we needed to display and so we ended up missing that frame again. Now because we own the full software stack from top to bottom, in iOS 12 we took all the information we have in the high-level UIKit framework about what scrolling is happening and when these critical sections are occurring and pass that information all the way down to the low-level CPU performance controller so that it can now much more intelligently reason about the work that's happening and predict both when these bursts will occur and how much CPU performance will be required to meet the deadline for the historical demand that your app has had. So once that change happens, where the load starts right here, we end up seeing that we've ramped the CPU far more frequently or, far more quickly, to the exact amount of perform it needs to make sure that we hit that deadline and don't drop frames.

This has caused a really great improvement across many different scrolling scenarios around iOS. So all of your applications will get all of this enhancements, both of them and a number of others, for free with no additional work on your part, but there are a couple of things that you can do to make sure that you get the most out of both of them. So first of all, if you haven't already adopted that tableView cell prefetching API or the Collection View one, definitely look into that because having your data ready is one of the best things you can do to make sure that loading cells is as quick as possible.

Of course, it's also important that you profile your full critical sections of your cell loading and reduce that demand as much as you can. iOS 12 will now try to match the CPU performance to the needs of your application during this period but the best thing that you can do will always remain to reduce the amount of work that you have to do to make sure that you give your customers a really smooth scrolling experience. So that's scrolling in iOS 12. Next, let's turn our attention to our next performance topic: memory.

Now, you might wonder why memory is showing up right here in the middle of a performance discussion, but I assure you that that actually makes a lot of sense and, in fact, the reason is because memory really is performance. The more memory that your app is going to use, the more that it will have an impact on the performance of your application. So to understand why, let's take a look at a really high-level overview of what the overall memory on the system might look like in a common situation.

So, of course, you can see here, a lot of the system's memory is being used by other applications and the system itself. Your app is using some amount for the moment. And there's some that's being kept free to service new allocation requests as they come in. Now, most of that memory is probably not truly free. It's likely including things like caches or other things that can be quickly thrown away to make sure that the memory is available to satisfy demand right away but in general it's probably actually being used for something, but it is readily available.

So let's look at what happens when your application requests some memory. Maybe you'll make a small request, something that can be satisfied by the amount that's currently available in that free pool. Well, if that's the case, it'll be return right away to your app and you can continue on with your work.

Now, let's say, though, that your application makes a larger request, and maybe it doesn't need it for a long period of time, so you might not be real worried about it. Perhaps you're just going to load an image off disc and decompress it, perform some quick operation on some of the pixels and then throw it away. So it seems like a quick operation that you don't have to worry too much about.

Well, we'll make that big request and now that is more memory that is currently easily readily available to the system. So it won't be able to satisfy it immediately and we'll have to go find that memory from somewhere else. And, in fact, the most likely place to come from is from other applications or things on the system.

Now, that might not worry you too much because you're trying to get the memory for your app right now, so you're not so worried about what's happening elsewhere. But, of course, this will have an impact on something else later that your customers will be expecting will be working, but more importantly to you right now, it will have an impact on your app as well because the system has to do work to go get this memory for you. The fact that it's not readily available means that the kernel has to go find it and perform operations on the CPU in order to make it available.

And that time it's spending getting that memory for you is time that could be better spent doing whatever your app does best. So finding ways to either chunk these larger requests or just reduce those overall peak demands can actually have both a big impact on the performance of your app while you're using it and also improve the customer experience across other apps later.

So there's many ways that you can reduce the total memory usage of your apps and starting with a profile and instruments is a great way to look at that. But for this morning, we're just going to take a look at one new technique that iOS 12 brings along that helps reduce the memory usage of your apps and that's Automatic Backing Stores. So let's say we want to draw this lazy prairie dog in portrait mode on an iPhone X. Now, how big is that going to be? Portrait mode on iPhone X, 375 points wide and, to preserve our aspect ratio, it'll be 250 points tall.

So how much memory will that use? Well, 375 by 250 at 3x, with 64 bits per pixel because this is a deep color device, is going to be 2.2 megabytes of memory to draw a prairie dog. That seems like a pretty decent amount, but in this case that's actually probably memory well spent. We're actually trying to represent this full-fidelity image and that's the amount of memory that's needed to draw it into this buffer. So that's probably expected.

But now let's say that we were going to draw a lower-fidelity version of our prairie dog, maybe something in black and white that we were going to sketch out with core graphics, maybe it was drawn with an Apple pencil on an iPad. That might look something like this.

So how much memory is our low-fidelity prairie dog going to use? Well, it'll actually use the exact same amount of memory. Now here, that clearly is not as good of a use of memory. It's all grayscale. All of that deep color information is not even being used in this image. So hopefully we could do much better and iOS 12 introduces automatic backing store support to help make that exactly be the case.

So all of your views now that implement draw Rect will have their backing stores defined by the depth of the content being drawn into them. So in this case where we're using Core Graphics to sketch out only grayscale content will actually automatically use an 8-bit per pixel backing store instead of a 64-bit per pixel one. This reduces the memory demand for that drawn view by an order of magnitude down to 275 kilobytes from 2.2 megabytes. That's a really big improvement across many different applications, both yours and ours.

So Automatic Backing Stores are enabled by default for all apps built with the iOS 12 SDK. All implementations of draw Rect on UIView will have this happen automatically as well as all content that you draw with UI Graphics Image Renderer into offscreen bitmaps. Now in the case of UI Graphics Image Renderer, we don't necessarily know what you're planning on doing with the image that you get out at the end.

So in cases where you actually know that the automatic behavior is not what you want, from Image Renderer, you can specify the specific backing store style that you want, for example using the new Range API to specify specifically that you want an extended-range image. Now you can learn all about this and many more techniques around UI Image in the Images and Graphics Best Practices Session later this week.

So that's our second top for performance. Next, let's move on to Auto Layout. Now Auto Layout in iOS 10 has some really great improvements. The team has been working incredibly hard to optimize Auto Layout for your apps as much as possible. So you'll find that Auto Layout is now faster by default in iOS 12. We'll talk about a number of ways that's the case.

But while they were profiling and optimizing Auto Layout, they also were looking across the system at many of our own apps and how they were using Auto Layout and they found a number of cases where there were some common pitfalls that different apps were falling in to. So we'll show you some of the simple best practices that you can follow in order to optimize your app layout as well.

So this morning, though, let's look at how Auto Layout is faster by default in iOS 12 by looking at the asymptotic behavior of Auto Layout as we add more views in some common user scenarios. Now, we're looking at the asymptotics because we really want to look at what happens as we dramatically increase the number of views. This can really make performance issues show up quickly when we go to a really like absurdly large number of views. That just helps us see it though. The optimizations really do apply and make things faster even for small numbers of views.

So let's start with a really common pattern, the simplest case really, Independent Sibling Views inside of some container. Now, these views are positioned with constraints against the container or other views but not against each other. They're independent of one another. Now in iOS 11, the cost of these independent siblings, as you continue to add more, grew linearly.

So that's actually pretty great. That's exactly what you'd expect for a situation like this. Basically, what we're saying is that there's a fixed constant cost for each additional new view that you added into your hierarchy that was positioned independent of those other views. Now because that was already growing with the exponentials that we expected, that remains the case in iOS 12; however, the team has worked really hard to reduce that constant cost to make additional views as cheap to add as possible.

So let's look at a more interesting example next. And in this case, we're going to take a look at Dependent Siblings. So this is the case where you have multiple child views and they're now, they have constraints between each other. So their layout is dependent on one another.

Now, unfortunately, in iOS 11, you'll find that the asymptotics here weren't quite as nice. In fact, it was growing exponentially. So the more views that you added, the surprisingly larger cost you would find as you added additional ones. Now, the team worked really hard to identify the source of this exponential growth and fixed the algorithm so that is no longer the case. So on iOS 12, these now grow linearly.

And, of course, the team's also been working to reduce those constant costs for these cases as well. Now in addition to dependent siblings, there's another common type of layout that you'll find and that's Nested Views, when one view is inside of another and there's constraints out to those outer ones. This is obviously also a pretty common pattern in your apps and, unfortunately, here as well in iOS 11, we found some exponential growth. And again, great news. The team has also made this linear in iOS 12 as well.

So there's a number of really great improvements across Auto Layout in iOS 12 and you'll see these improvements in your apps as soon as you start running them on iOS 12 yourselves. To learn more about all of that, get a better sense, develop a good sense of how to get some gut feel for the performance of different layouts and here are some of these topics I was talking about that are common pitfalls. Definitely check out the High Performance Auto Layout talk later this week.

So for our final framework update topic, let's turn to Swiftification. As you heard, iOS 12 introduces Swift 4.2. And for Swift 4.2 we really wanted to make sure that UIKit had a really great feel when used in Swift across your app, especially where it interacted with other Swift Standard Library or places that Swift had common patterns.

So, we audited all of UIKit and made sure that everything feels like it fits really naturally. Even better, we made sure that all of the changes that we made to UIKit are all automatically migratable so there's no additional work that you should have to do in order to get these updates.

Now, these updates fall into really three categories that we'll talk about this morning, although there's actually a ton of improvements and consistency improvements that you'll find as you look at the SDK. But today we'll talk about nesting of types, constants, and functions. So let's first look at nesting types.

Now in Swift 4, there were a number of types that were in the global name space, things like UI Application State. For types like this that have a really strong use along with another class, we've now nested them within this class. So we looked at all the enumerations and other global types of this sort and now have moved them to be child types of the relevant class. So this becomes UIApplication.State. This sends a much stronger message about the relationship between these two and makes them easier to find as well.

Now in comes cases this can also help improve understandability and remove some confusion. So in this case, let's look at UI Tab Bar Item Positioning. Now do you think that's UITabBarItemPositioning or UITabBarItem Positioning? It could actually be either. Those are both classes. And in Swift 42, it is now perfectly clear that it is, in fact, UITabBar ItemPositioning.

So in addition to nested types, we've also nested a bunch of constants. So if we look here at Swift 4, we had NS notifications were all in the global NSNotification.Name namespace and their associated user info keys were actually just global constants that were floating out there. So for consistency with AppKit and to make it easier to find and associate these types together, they've now all been nested under the class that they're used with. So something like did Change Status Bar Orientation is now under UI Application did Change Status Bar Orientation Notification and its user info key moved along with it so that they're all co-located.

Now we've also audited all of the other global constants all throughout UIKit and nested all of them in appropriate places. So things like UI Float Range Zero and UI Float Range Infinite have not just become properties on UI Float Range so they're both easy to find and easier to use. In places to take a UI Float Range, you can now just type .zero or .infinite and, in fact, because they're now properties, Xcode can suggest them as auto-completions for you in places where they make sense.

Now in addition to constants, we've also audited all of our global functions. So things like UI Edge Inserts and UI Image had some global functions for operating on different types. Now in Swift 4.2, these had become methods on the appropriate type. So it's now really easy to inset Rect or get png Data from an image in a really natural Swift feeling way.

Now, here was one other big class of functions that I want to mention this morning and that was all of these string conversion functions for all of the many types in UIKit, CGPoint, CGRect, CGSize, CGVector, all of them, there's quite a lot, both to and from strings. Now, when we looked at these and tried to decide where they should go, we realized that they actually have two different use cases. One is for encoding and decoding.

But the other is that they're commonly used to print things when you're just trying to get some debug descriptions. And those are two very different uses but, in fact, Swift has first-class support for both of those cases. And so we've made sure that all of these types will work really great with Swift's built-in support for both. So in Swift 4.2, all of these types will conform to Codable so that you can very easily do things such as encode and decode JSON for all of these different types.

Of course, debug printing in Swift is actually even easier than in Objective-C because you don't have to do any additional conversion. The built-in introspection of the types can allow you to print them directly. So in Swift 4.2, you just actually pass these types directly to your print functions if you want to print them out for debug purposes or log them.

And then finally, you may already have some existing code that was using the behavior of the old string conversion functions and need a compatible functionality going forward. And so for that we've actually just renamed all of these and moved them to be properties on NSCoder. This really helps to emphasize the fact that the intent of these methods was to be used for encoding and decoding, so it's a pretty natural fit for them to go over there.

So these are just a few of the consistency improvements that you'll find across the iOS 12 SDK for Swift 4.2 but you'll find many more as well. Now speaking of encoding and decoding, NS Secure Coding, in iOS 12 there are now new secure by default encoding and decoding APIs.

Adopting NS Secure Coding for all of your encoding needs on NS Keyed Archiver is really key to ensuring that you're protecting your customers from both malicious and corrupted data. You'll also find that the older insecure APIs are not deprecated. So you can learn all about that and get much more detail on it in the Data You Can Trust Session on Thursday at 9:00 a.m.

And that's framework updates. Next, let's turn our attention to some enhancements to a number of existing APIs and we'll start with notifications. Notifications has a number of really great improvements in iOS 12 but we're going to focus on just three this morning. Interaction within custom notifications, grouping of notifications, and access to your notification settings within your own apps. So let's start with interaction.

Now custom notifications have for a while now allowed you to define a predefined set of actions for those notifications. In iOS 12, this set of actions is now no longer static. It can be defined programmatically and you can change them at runtime. In addition to these actions, and even better than that, the notifications themselves can now be made interactive. So for example, here, you can see Messages is now allowing you to reply quickly to a message inline directly in that notification.

Now in addition to interaction, iOS 12 now includes grouping of notifications by default and the default behavior will be to group all the notifications for a particular app into a single group. But, of course, your app may have custom needs to have more granular groupings so something like iMessage will group all of the messages from a particular conversation together and separate from all the rest of the notifications for that app. Now you can adopt this in your app as well by just tagging your notifications with a particular thread identifier and then all the notifications for that threat identifier will appear in a single group.

Now the UI updates for notifications in iOS 12 also include some new ability for users to customize the delivery behavior of their notifications. But, of course, your apps may also include some existing, more granular controls for notification management within your apps as well. And iOS 12 introduces a new API that makes it easy for your customers to get directly deep linked into your notification settings UI exactly when they're looking for those more granular controls. So you can learn more about all of these notification things in What's New in User Notifications and Using Grouped Notifications later this week.

That's notifications. Next, let's talk about messages. Now messages in iOS 12 includes some really new and exciting features in the camera. And you can bring all of your iMessage stickers directly into the camera as well. If you're using the Xcode sticker template, this will work automatically by default with no additional work on your behalf.

But if you're building a more custom sticker experience using the MS Messages App View Controller, some small amount of adoption is required. Now there's a new MS Messages Supported Presentation Contexts API that you can add into your user info plist and then specify that you want to appear both in the messages context and the media context.

Once you've done that, your apps will appear both in the App Strip and also within the camera. Now if at runtime you need to figure out which context you're in so that for example you want to customize the display of your stickers a little bit, there's a new API for that as well.

By checking the presentation context, you can quickly see whether you're in messages or in the camera. Now in addition to these features, iOS 12 also brings a new access for interaction to your messages apps. In compact mode, previously swiping horizontally down in your messages app would switch between apps. In iOS 12, these horizontal swipes and interactions that move horizontally are now available for us by your apps directly so they'll interact with your apps rather than switching to a different app.

And that's Messages. Next, let's talk about automatic passwords and security code autofill. Now iOS 11 introduced automatic passwords or password entry into your apps. And in iOS 12, we're taking these a whole step further. But let's go back to the beginning for a minute and talk about the entire experience.

So for users that have passwords stored in iCloud Keychain, since iOS 11 it's now been possible to have those automatically get populated into your app in your login flows. Now in iOS 12, these passwords can also be stored into iCloud Keychain from your apps both from your login window flows and also from your password change request UIs.

As soon as a user logs in, they'll be prompted to save the password to iCloud Keychain. Now even better, iOS 12 can automatically generate passwords in your new account flows and in your password change flows. Adopting this is really easy. You just make sure that you've tagged your password fields with either the password text content type, if it's a login field, or the new password text content type if it's either a new account or password change field.

If your services have a specific requirement on passwords for example if they got required or disallowed characters or if they have other requirements such as maximum number of consecutive repeated characters, you can specify these requirements as well to make sure that the automatically generated passwords are fully compatible with all of your requirements.

Now, the final bit of friction during some of your login experiences is when you have to take that two-factor authentication code, get it out of a text message and into your apps. IOS 12 makes this really easy by automatically identifying these notifications, noting the security code in them, and suggesting it right in the Quick Type candidate bar so that it's really easy to get it right into your app. Now the only thing you have to do to make sure this works in your app is to be sure that you're using standard iOS text interaction APIs in order to accept these passcodes.

With all of these new features, iOS 12 is enabling a much more secure future with unique, strong passwords used for every service that you never have to memorize or type ever again. You can learn all about this in the Automatic Strong Passwords and Security Code Autofill Session later this week.

Now, our final API enhancement topic is actually a bit of a review but now with a little bit more context. So in iOS 11, we introduced Safe Area insets. Safe Area insets are a really great way to make sure that your content is avoiding any overlap from other parts of the user interface such as bars on the top and bottom of the screen.

This is really great on iPhones where bars are pretty straightforward, but it's really powerful as well. Safe Area insets give you that safe area coordinate in the local coordinate space of any view in your application, so it scales even the much more complex interfaces, things like iPad Split View which has different height bars on the master and detail side of the Split View. The Safe Area insets in any view underneath these bars will be appropriate for the amount that they're overlapped by the bar on their side of the split.

So this is really great on devices with rectangular screens but it also is really powerful on devices that have non-rectangular screens like iPhone X. Now, you can see here we've got our larger bars at the top and bottom than we have on devices that have home buttons. And the Safe Area insets obviously have just grown to accommodate that larger size.

Now, unique to iPhone X is that there are Safe Area insets even in cases where no bars are present and this extends the landscape mode too where it can really help you make sure that you've got a rectangular area at all times that's safe to display content and will never be clipped.

So I want to thank you all for those of you who have adopted Safe Area insets and updated your apps for iPhone X. It's been a really great experience over the last year and I'm sure most of you have already done that. If you haven't, now is a really great time to do so.

Your customers will always prefer apps that are being kept up to date and support for iPhone X is a really visible indicator of that being the case. So if you haven't, definitely go do it now. And to help make sure you have all the information necessary to do that, you can check out the UIKit Apps for Every Size and Shape Session later this week which will tell you both all about Safe Area insets and all of the other related inset APIs all throughout UIKit making it easy to make sure you have apps that scale to every shape and size.

So that's our framework updates and our API enhancements. Next, let's talk about Siri Shortcuts. So Siri Shortcuts is an exciting new API in iOS 12. Siri Shortcuts makes it easy to get common actions out of your app and make them accessible via Siri. Now, Siri Shortcuts can be suggested proactively right on the coversheet making it easy to access actions that you would want to access at the exact time and place that you want to access them. Even better, they can also be suggested right on the Siri watch face on Apple Watch. Now not only are Siri actions suggested proactively but they can also be set up to be executed using a custom voice phrase.

Now, adding Siri Action Support to your apps is really easy. You can use two APIs. There's NS User Activity, which you may already be using for support for Handoff and Spotlight integration, and there's also support for Siri Intents for more complex scenarios where you have more custom interactions. So let's look first at NS User Activity.

Now as I mentioned, NS User Activity is a common API with Handoff and Spotlight and this could be a really great API to use if your Siri Shortcuts should get your customers back to a specific place in your app, for example loading a particular message or document, the same as you would do if you were trying to hand that off to another device. If you're already doing this, it's really easy to add support for Siri Shortcuts. You just set Eligible for Prediction to true. And if you're not, this may still be a great way if your shortcut fits into one of these categories.

Now, if your app has other more custom needs or if you just want a lot more control, you can adopt the Siri Kit Intents API. Now Siri Kit Intents provides a number of predefined intents that you can easily adopt on your own. These are the same as the Siri Kit Intents in previous years. Now if your apps have more custom behaviors, though, you can now in iOS 12 define your own custom intents.

Custom intents can be really flexible and they do anything that you would want. In this case here, I've created one to help me create my WWDC slides next year. Now the categories that you could put your intents in to are pretty broad already. So here I've used the Create category. But if your intents are even more generic than that, there are even more general ones available such as General Do, Run, and Go options.

Now once you've created your intent, you also want to make it really easy for your customers to create these custom shortcuts to get to them. And so there's now an API from right within your app you can allow customers to create a custom voice shortcut. So here I've got a button that will just bring up a new panel enabling me to create a new shortcut right within my app as soon as I finished an operation. So if you're doing something like ordering a coffee in the morning and you notice it's something that might be done again, this is a great opportunity to offer to create a Siri Shortcut to do that next time.

Now even better, you can also combine these shortcuts together using the new Shortcuts app available from the app store. So you can learn all about this and much more in the Introduction to Siri Shortcuts, Building for Voice Siri Shortcuts, and Siri Shortcuts on the Siri Watch Face Sessions later this week.

So we've talked a lot this morning about what's new in iOS 12, but there are also a number of great sessions that are worth mentioning that aren't necessarily about what's new. So if you're new to creating apps for iOS, there's a really great session you should check out called I have This Idea For an App. So definitely check that out.

And if you already have an app, and are just looking to add more polish, there's a couple other great sessions as well, A Tour of UI Collection View and Adding Delight to Your IOS App. So thanks so much for coming out this morning to hear what's new. Look forward to seeing you in the labs and I hope you have a great week. Thanks.