Hello. Good afternoon and thank you for coming to What's New in WatchOS. In this session, we're going to give you a high-level overview of the new features you as developers, designers and product leaders can take advantage of to create great Watch experiences. And we're also going to dip into the details of the new APIs and interface builder options. My name is Lori Hylan-Cho, I work on the Watch frameworks team, and I am beyond thrilled to be here, to share with you the awesome new options for creating great Watch experiences in WatchOS 5.

We've come a long way since our humble beginnings in 2015. And a great Watch experience now consists of several components, of which a Watch app is likely to be only one. Notifications, complications and Siri shortcuts work together to create a Watch experience that allows for brief and meaningful interactions with the right information at exactly the right time.

And of course, with Series 3 Watches that support cellular, and the new Wi-Fi options that let you join networks directly from the Watch, more and more Watch wearers are venturing out without their phones. So, it's important to create a Watch experience that feels complete. Let's take a look at the features we've added to WatchOS 5 to help you deliver this kind of a great experience on the wrist.

Ask any Apple Watch user what they like most about their Watch, and one of the first things they'll say is notifications. We're making notifications even richer this year with a few key improvements. Creating dynamic notifications with images and text has been an option since WatchOS 1. But if the user missed the notification when it arrived, chances were they'd never see it at all, as the Notification Center would display the static version. This was intentional, as we have more time to display the notification when it arrives than we do when displaying it from Notification Center.

In WatchOS 5, we'll do our best to show that beautiful dynamic notification with no code changes or recompilation required on your part. We worked hard to make this possible for its own sake but being able to show dynamic notifications from Notification Center also makes possible the next two features I'm going to tell you about.

The first of these is grouped notifications. You probably already know that you can have multiple categories and different notification interfaces for each one. And you might already be specifying a thread ID and the push notifications that get forwarded from iOS to the Watch. In WatchOS 5, this will cause notifications to be grouped automatically in Notification Center as you saw in the previous slide. Specifying a category and thread ID also opens up another possibility.

Getting the same behavior as the built-in messages app, where new notifications with the same thread ID that come in when the original one is still on screen are appended to the existing interface. We made this kind of grouping behavior optional to give you a chance to handle being called multiple times for the same notification interface controller.

To opt into this behavior, select your notifications category in the interface storyboard for your Watch app. And check the handle's grouping box in the attributes inspector. If the original notification is on screen when additional notifications that have a matching category and thread ID arrive, did receive notification will be called again on the existing notification interface controller. So, you should be prepared to append content to the existing notification interface. Perhaps by adding a blank line and the new body content to an existing label. Or by adding a new row to a table, as you saw on the previous example.

And speaking of did receive notification, its signature has changed in WatchOS 5. This version, with the completion handler has been deprecated, in favor of this simplified version. We did this, so we'd have a clear boundary for when you're done processing your notification data. And we'd know that everything is ready to be shown on screen. We encourage you to do only the work necessary to display the notification and to do it as quickly as possible.

By the way, it's not necessary for the user to keep their wrist up to see all the notifications with the same thread ID as they come in. If you're handling grouping and the dynamic interface for your notification category, all the messages with the same thread ID will expand to a single platter when the user taps on the group and Notification Center. And if additional messages on that thread come in, they'll be appended live is when the long look was first on screen.

So, here's a big one. In WatchOS 5, you can now bring some of your apps' functionality directly into the notifications you send by including elements that let the user interact with content in the notification itself. For example, you could let a user pay for their ride and rate their driver, notify a user that their meter is about to expire, and let them extend their parking time, or give a diner an opportunity to not only confirm their dinner reservation, but to let you know they'll be a party of three instead of four.

So, let's see how all this works. If you're creating a new notification interface controller, a dynamic interactive interface will be created for you automatically. If you already have a dynamic interface for your notification category, select the category in your Watch App's interface storyboard and check that has interactive interface box.

In both cases, you'll notice that the old dynamic interface is still there, in addition to the dynamic interactive one. The dynamic interface will be shown in WatchOS 5 when the notification first arrives, and now in Notification Center as well, as I mentioned before. The dynamic interface will be shown in earlier versions of WatchOS so, you'll want to keep that one around for backwards compatibility.

Once you have a dynamic interactive interface controller you can add buttons, switches and other interactive elements in the object library, which is now available at the top of the screen as a popover menu. You can even add gesture recognizers with your notification, though you should be aware that the system gestures will take precedence over any gestures you add in the same areas.

Once you've designed your notification interface wire up the interactive elements to your code, the way you would any other interactive element in your app. As you can see here, I'm dragging my IB action for up button tapped to the button in my dynamic interactive interface. So, the amount of time will increase by 15 minutes every time the button is tapped. And with all this button tapping you may have already forgotten that notifications have always launched your app when tapped.

This is still true for a regular dynamic and static notifications. But, we obviously had to disable this behavior for dynamic interactive notifications. Because we have interactive elements in them now. You can still launch your app from an interactive notification, if you need to. You just have to do it explicitly by calling a new method, performed notification default action.

Similarly, if you include a button in your notification interface that should dismiss the notification after taking action, as in this case where tapping the extend button should both commit the changes to my rental time and dismiss the notification, you do this by calling perform dismiss action at the end of the IB action function associated with the button.

You could also process the changes made in the body of the notification using a standard action button. Since action buttons always dismiss the notification. Wait, you're probably thinking, action buttons are shared between all the notification interfaces. And some of those buttons wouldn't make sense if the interactive elements weren't there. Well, new in WatchOS 5, you can now adjust the action buttons that are shown at runtime.

There's a new notification actions property on the notification interface controller that returns the array of actions that will be displayed for the notification. You can set this property to a new array of UN notification action objects in your did receive notification call back. which gives you the flexibility to add or remove buttons to suit your interactive interface. And in an upcoming seed, we're going to allow changes to actions any time after did receive notification is called. Which will give you the flexibility to change the action buttons based on how the user interacts with the elements in the interactive notification interface.

So, that's a lot of information about notifications and the options for creating them so far. But I have two more things to tell you about before we move on. Critical alerts are a new kind of notification that will cause a prominent haptic and a sound to play even when your Watch is silenced or in do not disturb mode. And thus, they can be used to deliver extra urgent information. If your Watch app integrates with a medical device or is used by emergency responders, this kind of alert might be for you.

Critical alerts require an app entitlements and explicit permission to be granted by the user separate from regular notification. The opposite of a critical alert is one that can be delivered quietly. That is, rather than interrupting the user with an in the moment notification that takes over the screen, you can now choose to send notifications directly to Notification Center. You'll notice that no indicator will appear unless a prominently delivered notification is also in Notification Center. But the swipe from the top of the screen will still reveal the quietly delivered notification.

If you choose to deliver notifications quietly in your app, you don't have to prompt the user to allow notifications when the app is first launched. Instead, you can request provisional permission. This gives the user a chance to see what kinds of notifications your app sends before having to decide whether they want to see them as they arrive. Whichever option you choose as a developer, the user still has ultimate control over how they receive your notifications. They can choose to deliver notifications quietly by swiping left from a notification in Notification Center or change their notification preferences in settings.

To sum up, notifications are now more dynamic. Users will see your dynamic interface from Notification Center in addition to when the notification first arrives. We're also offering grouping by thread ID for the first time on the Watch. So, you can design notifications that behave like the ones like the built-in messages app.

You can now bring more of your app experience directly into the notification your app delivers with interactive controls and action buttons that can be defined at runtime. And you can also choose to deliver notifications with the appropriate level of urgency. To learn more about notifications you can attend one of these sessions. I highly recommend Designing Notifications, that will give you some great tips for how to design effective interactive notifications.

Okay, now that we have your user's attention with notifications, let's turn our attention to the features we're adding to make your Watch apps more awesome. The first has to do with local audio playback. Some of you have already made forays into audio playback on the Watch by taking advantage of URL session for downloading files to the Watch. And WK audio file queue player to play them.

With WatchOS 5, we're going to make developing audio apps for the Watch even easier, and the resulting experiences more delightful. In WatchOS 5, we're offering a new background mode for playing local audio files. So, you can now focus on your app's main purpose, audio, rather than trying to figure out how to build something else like a workout app just to be able to play audio.

We also exposed AVAudio player and AVAudioEngine directly, which means you can use the same methods and properties you're already familiar with if you've been building iOS apps that play audio. In fact, you can share your code between your iOS app and your Watch app by moving your playback related code to a framework.

One thing that's different from iOS, is that playing longform audio on the Watch requires headphones or an external speaker to be connected just as when playing from the built-in music app. For this reason, Bluetooth routing is part of the session activation process. If you set your route sharing policy to longform, as you should, will automatically connect to the headphones with Apple wireless chip, like AirPods or Beats Studio3, if they're already in use.

Or, will show a route picker to let the user choose other headphones or Bluetooth speakers when you call the activate with options completion API in a session that's new. You could also use the MP now playing info center API to populate the now playing app with information about what your app is playing. Which means your apps info will show in the now playing complication.

And you can handle the media remote commands that make sense for your app; from play and pause, to next and previous, to even like and dislike. And last, but not least, it's now possible to control the volume from your custom playback UI with the new volume control view. Available in the object library and interface builder.

The control automatically takes on the tint color of your app when at rest and responds with the color changes you're used to from the system volume control when turning the digital crown. There's a whole session devoted to creating audio apps for WatchOS which I highly encourage you to attend to get more details about the new APIs and best practices for working with audio. And we'll also be prepared to talk about background audio at the WatchOS runtime and conductivity lab on Thursday.

If the primary function of your app isn't playing audio, but your app would benefit from being able to control audio playing elsewhere on a system, whether it's on a Watch or on phone, as in the workout app, where you can swipe left during a workout to see now playing controls. You'll be happy to hear that were exposing a now playing view that you can embed in your apps.

You can find the now playing view in the object library in interface builder. It's designed to fill the screen. So, it works best in apps with page layouts. Note that the now playing view is a systemwide control that's meant to control audio coming from other apps. So, it will show whatever the user is currently listening to, whether it's on Apple Watch or iPhone.

While we're here, I want to point out a couple of other new options and one change in behavior. In previous versions of WatchOS, if you added a 38-millimeter asset but forgot to add the same asset for a 42-millimeter device, the asset would be missing on the larger device.

Now it will automatically fall back to the 38 millimeter size if the 42 millimeter size is missing. But you can skip worrying about providing assets of different sizes altogether by instead adding a PDF in the universal selection of your asset catalog and setting the new auto scaling option to automatic.

This will cause the right sized asset to show up at the right place at the right time. We've also exposed the title textiles in the font menu to give you more options for differentiating your text within your interfaces. These textiles are compatible with dynamic type, so they'll increase or decrease. They'll scale up and down, as the user changes their font size in settings. And the large title style is available in both interface builder and as an API.

Since I'm in the process of building an app for skating workouts, now would be a good time to talk about the improvements we're making to workouts in WatchOS 5. We completely rewrote the workout API in this release to make it simpler, more reliable, and more resilient. And we've moved the built-in workout app to use it. We're hoping you'll move your fitness apps to it to.

It's now easier than ever to start a workout and collect the right data with a new initializer from HK workout session and the new workout builder API. You create the workout session, get the builder from the session and start collecting data. It's that simple. This is what it looks like in code.

You create and configure the session with a health store and a workout configuration, which includes the activity type. Grab the HK live workout builder that's associated with the session and begin collection. The relevant data for the workout type will be collected automatically, even across pauses and resumes, to give you a correct and consistent HK workout artifact with a correct elapsed time. And because no app is perfect, if your fitness app crashes during an active workout session it will automatically be relaunched.

Just use the HK health store recover active workout session API and the session and builder will be restored in their previous state. To learn even more about the new workout APIs, as well as options for collecting health and fitness data check out New Ways to Work With Workouts or visit the health and fitness technology lab tomorrow afternoon.

Next up, your apps now have a place on the Siri Watch face with Siri Shortcuts. As you saw on the keynote, Siri Shortcuts are meant to help users accomplish tasks that they perform frequently with more ease than ever before. And the Siri Watch face surfaces these, the common tasks, at the right place and time with a little input from you as app developers. I want to focus on how to use shortcuts to make a great Watch experience and how that experience differs depending on whether your Watch app is installed.

First, a few words about what makes a good shortcut. As the name implies, shortcuts are about helping Watch users see useful information and perform common tasks quickly. Whether it's launching your app to a specific screen with options preselected, or getting to the awesome outcome your app enables, such as ordering your morning coffee, booking a fine dining reservation, or re-upping your chocolate supply. Think about glanceable information and one or two tap interactions.

Shortcuts can be user activity based, or intent based. User activity based shortcuts are great for when the goal is to launch your app with a specific context, such as navigating straight to a screen where the user can log a meal they've eaten, or in this case, delivered. Intent based shortcuts make more sense for tasks that don't necessarily require your app to be launched. Such as placing your regular coffee order.

If your shortcut is intent-based, when the user taps your shortcut platter on the Siri face, they'll receive a quick confirmation screen. Did you mean to order that coffee? If the intent supports background execution, it will run without launching the app, when the user confirms. Otherwise, the confirmation will launch or restore the app and hand it your intent.

How the user has interacted with your app in the past is taken into account when predicting what shortcuts to show. You should donate intense or user activities as the user performs the main functions of your app. For example, an audio app like Audible would donate an IN media, play media intent when the user starts or resumes playing an audiobook.

Shortcut surface on the Siri Watch face based on relevance with the most relevant items appearing at the top of the up next section and less relevant ones at the bottom. Previous user interactions intense performed or donated and user activities that have been marked both eligible for search and eligible for prediction inform relevance. But to appear on the Siri Watch face, you must also give the system explicit hints about when or where a shortcut is relevant by creating a relevant shortcut.

A relevant shortcut consists of a user activity or intent-based Siri shortcut, an optional Watch template that defines the title, subtitle, and image that should appear in the shortcut platter, and an array of relevance providers that define the time, location or situation in which your shortcut would be most relevant. We've already talked about user activity and intent-based shortcuts, so let's talk about the other two components of a relevant shortcut.

A Watch template is an optional IN default card template, that consists of a title, an optional title, and an optional image. If you don't provide a Watch template, we'll pull the necessary information from the IN shortcut, but you should take the opportunity to provide informative strings so the user understands what they get when they tap your platter.

A relevance provider focuses on the date, location or situation in which the shortcut would be most valuable. Think about when and where your shortcut would be relevant. Is it something the user might glance at or tap on at any time during the day? Is it relevant at a specific date and time, or is it based on location? Since a relevant shortcut takes an array of relevance providers it's possible to specify more than one kind.

For example, if your shortcut would be relevant at both a time and a place. Again, these relevant providers act as hints to the system. As the user interacts with your content, actual usage will inform its placement. If the user fails to interact with shortcuts that appear on the Siri face, they'll drop in relevance.

Once you have relevant shortcuts, the next step is to supply them to the relevant shortcut store so they can be considered for the Siri Watch face. Relevant shortcuts can be supplied by both your iOS app and your Watch app. iOS relevant shortcuts are synced periodically from iPhone Apple Watch and they're merged into consideration with the Watch relevant shortcuts. If your Watch app supports the iOS shortcut, the Watch app handles execution. If it doesn't, or if the Watch app is not installed, the shortcut executes on the phone, over Internet.

A subset of relevant shortcuts can surface on the Siri Watch face, without Watch OS support. If they are intent-based shortcuts that support running in the background and can run without accessing encrypted data, which is separate from off. Again, these shortcuts are going to execute on iPhone over Internet. The richest experience for users will always be with a Watch app that can handle the shortcut locally, either by launching the app or by executing the intent in the background.

You'll want to update your relevant shortcuts periodically. If the user launches your app, for example, by tapping one of your shortcuts on the Siri face, you'll have the run time to accomplish the update. But shortcuts that provide glanceable data are useful to the user without launching the app. Think about the carrot whether example from a couple slides ago, were you could tell that it was 72 degrees and cloudy just by looking at the platter. You didn't have to tap.

To help with this case, we added a background refresh task called WKRelevantShortcut RefreshBackgroundTask. When you get this task before sure to check if your data needs to be updated and then supply new relevant shortcuts. We factor in user engagement when scheduling these background tasks and glances count as engagement.

If you have an intent-based shortcut, your intent might update applications when it executes in the background. Since the intents extension is in a separate process from your Watch Kit extension, we're now supplying a new refresh background task called WKIntentDidRun RefreshBackgroundTask to let your main extension run and update any snapshots or complications that may be stale after your intent executed.

Now that you have your shortcuts available at the turn of the wrist and a tap, you should know that users can set up shortcut phrases on the phone and use them to execute your shortcuts at any time. These shortcut phrases are synced to Apple Watch. So, you can use raise to speak to say, for example, mint me up and kick of an order of a mint mojito from Phil's Coffee. Your shortcut platter does not need to be showing on the Siri Watch face for your shortcuts to be invoked with a shortcut phrase.

So, in summary, use Siri shortcuts to provide relevant information and quick interactions to your users. Create relevant shortcuts on both iPhone and Apple Watch and add them to the shortcut store so they can be considered for the Siri Watch face. And finally, your users will have the best experience with a WatchOS app where they'll be able to do more with your shortcuts directly on the Watch. For more on Siri shortcuts, I recommend checking out one of these sessions or labs, especially the one about Siri shortcuts on the Siri Watch face, which will go into much more detail about the APIs I covered today.

So, we covered a lot of ground today. Here's what we talked about. We want you to make your notifications more engaging and actionable by creating dynamic interactive interfaces for your notifications. You can now bring audio into the background with AV foundation APIs, media remote commands and access to now playing info.

You can make your fitness apps more robust and reliable with the new workout builder API. And you can provide value on the Siri Watch face by creating relevant shortcuts. If you have any questions about what you've heard today what you built for Watch OS so far, or what you're going to build next come visit us in the labs. We'd love to see what you're working on. Thank you for coming and have a great WWDC.