ANUSH NADATHUR: Thank you.
Welcome. Thanks for coming.
My name is Anush Nadathur and I'm a software engineer on HomeKit.
Today, my colleague Naveen and I are going to talk about what's new in HomeKit for iOS 9.
Now for the past few years we have seen a proliferation of home devices in the market.
What this gives you is a tremendous opportunity to influence the experience people have when interacting with these devices in the comfort of their own home.
Apple introduced HomeKit in iOS 8 so that we can work together to bring home automation to a much wider audience than in the past, and to deliver a consistent user experience for our customers.
We had a great session last year, but for those of you who may have not seen it, here's a brief recap.
HomeKit provides a common protocol that all HomeKit-enabled accesses implement and interact with iOS.
On this protocol, we have defined profiles that describe many of the commonly used accessories.
However, we also made it flexible so that you can define profiles that define custom features of your accessory and still be HomeKit-enabled.
One of the key features in HomeKit is to provide a common view of the home across all HomeKit applications.
So what that means is if you use app A and switch to app B, both get the same home data.
This is critical for our customers because that delivers the consistent user experience that we want them to have.
If your accessory implements one of the Apple-defined profiles, Siri works right out of the box.
Yeah. And the HomeKit framework on iOS models a home very naturally.
So we have objects which describe rooms, zones, which are a collection of rooms, and of course, accesses that you can control.
Now, none of this would matter to our customers if their data is not private or secure.
HomeKit was designed with privacy and security from the very beginning.
All communication between iOS and the HomeKit accessories is end-to-end encrypted, and we never use keys across different sessions.
So when you have a key, that key cannot be used to dig up data in the past or in the future.
And all home data is encrypted on the device using keys that are local to that device.
So your data is completely private and secure.
So that's HomeKit in iOS 8.
So let's talk about what we have in store for you today.
I'm going to go over features and enhancements for HomeKit in iOS 9, and Naveen will go over updates in our accessories space.
So let's get right to it.
We've got some great features for HomeKit in iOS 9, but we have also added enhancements based on feedback that we have received from developers in the past year.
So please keep those feedback coming.
We absolutely love them.
So let's begin with a small change that we made but has a tremendous impact on your daily development.
Let's take an example of a light in a bedroom and we move it to the living room.
In iOS 8, if your app comes to the foreground, we would have notified your app of this change using home manager did update homes delegate callback.
Now, this tells you something has changed but also gives you a new set of objects that now you have to use and figure out what exactly has changed in your home.
We thought we should do better, so in iOS 9, HomeKit is going to maintain your objects and only update properties that have actually changed.
[Applause] Thank you.
So what that means is, in our example, you're going to get a single delegate callback: home did update room [unintelligible].
I think this is going to simplify your code base and let you focus on your features for your app.
That's not the only enhancement that we have added.
Let's talk about another one using an example.
Let's say I have a living room, and I have a photo of the living room that I want to show in the app.
So what that means is you need to be able to associate and find a HomeKit object representing a room across relaunches of your app.
Now, a room in HomeKit is represented using a HMRoom class.
This has a name property, and names are not immutable.
So any HomeKit app can change this.
To solve our problem, we need something more persistent.
So in iOS 9, we are introducing persistent identifiers across all relevant HomeKit classes.
So you are going to have a unique identifier property on these classes.
These are unique applications, and now you can use this to associate context data in your app and apply that and associate that with the HomeKit object.
Next I want to talk about user management in iOS 8.
Your app had the following three APIs to let users manage people in their homes so they can add users, remove users, and list users in their homes.
In iOS 9, we are deprecating these and replacing it with a much simpler API, manage users with completion handler.
So this API presents a full view controller that is going to let users manage people in their homes.
Developers need to move to this new API in iOS 9 so that our customers can get a much richer experience with respect to home sharing.
I want to stay on a related topic, user capabilities.
When you share your home with a user, they can control the accessories in the home, but they cannot make any configuration changes.
For a good user experience, your app needs to show capabilities that are only relevant to that user.
To achieve this, you now need to know the privilege level of that user.
So, for example, if they are not an administrator, you should not let them edit the name of a room.
So we are going to give you APIs to let you figure this out.
So on HMHome, we are adding a new property, current user.
That represents the currently signed-in user on that device.
You can use this and pass along to a new method on HMHome, home access control for user.
That returns a HMHome access control object, which encapsulates the privileges of that user.
Let's see what this class looks like.
It has an administrative property that will be set if you are the administrator of the home.
So now you can update your apps and use this property and share only relevant features for that user.
Moving on, let's talk about a great feature in iOS 8, scenes.
Now scenes allow our customers to control multiple accesses with a single command.
So I can have a good night scene where it switches out all of the lights, secures my home, and sets the temperature down to a comfortable level with a single command.
This is a very powerful feature.
In iOS 9 we want our customers to use this even more.
To help this, we are introducing predefined scenes.
There are four common events that most people experience every day.
They are getting up, you leave home, you return home, and then you go to bed.
Now that you know what these four predefined scenes mean, you can apply context to them.
So in your app, you can actually make suggestions to let customers configure these four predefined scenes with meaningful actions.
And to have a good experience for our customers, predefined scenes cannot be deleted from a home.
Let's walk through the APIs.
A scene in HomeKit is represented using a HM action set object.
We have added a new property, action set type, that describes the kind of scene that you are working with in your app.
We have four constants that correspond to the four predefined scenes I talked about earlier.
We also have a fifth type, the user defined type, and this is set on the scene that your app creates.
How do I access these predefined scenes in a home?
They are automatically populated for you as part of the action set property on an HMHome class.
But we also have a convenience API, built-in action set of type.
That takes the action set type and returns a HM action set object that corresponds to one of your predefined scenes.
So that's the APIs, but we want to make scenes even much easier for our customers.
So now Siri works even better with scenes in iOS 9.
Siri now recognizes the names of all scenes and simply speaking the name of the scene will actually execute it.
This is a great way for our customers to use scenes.
Now let's talk about the experience of adding an accessory to your home.
Let's say I have two accessories from the same manufacturer, and they can have the name of the manufacturer as part of the accessory's name and a model number, and when I add this accessory to the home, I can always look up the packaging and figuring out I am adding the right device to my home.
But a better user experience for our customers is to give some kind of indication that provides more information about the accessory.
Let's say, for example, we can give them visual clues, present an icon that tells them the type of accessory they are adding is a much better experience.
To attain this feature, we are adding accessory categories in iOS 9.
This information is available to your app during setup of that accessory.
So when you browse and you are finding these accessories, it is already available for you.
And it specifies the primary category of that accessory.
Moving on to the APIs for this, we are introducing a new class, HM accessory category.
This has a property category type that gives more information about that category, so, in our example, you will have category type light bulb and category type fan.
And the way you access this category is use the category property on an HM accessory.
So this is available when you browse for these accessories.
So we recommend that you use this new feature and enhance that user experience for our customers during first-time setup.
Now let's talk about HomeKit and the Apple Watch.
Yeah. As announced in Monday's keynote, HomeKit is now available on Watch OS.
Now, this means you can now go out for a run without your iPhone, come back, and if you have your watch with you, you will be able to unlock your door and get back in.
How cool is that?
All your home data is mirrored from your iOS device onto the watch, so you can make changes on your phone and they will automatically synch to the watch.
You can view homes from the watch, control your accessories, and execute all your scenes.
We cannot wait to see the creative experience you are going to deliver to our customers with HomeKit on the Apple Watch.
Finally, I want to talk about a new feature in iOS 9, and I am really excited about it because I spent a lot of time on it.
[Laughter] Let's talk about triggers.
Now, in iOS 8, we have timer triggers, so that lets you execute scenes that specify time of the day.
I can have an evening scene that executes at 7 p.m. every day.
But what if I could do something like this.
I return home, I unlock my front door, now that generates an event.
Let's say it's before 6 p.m.
and I have a motion sensor that's right next to my front door.
That gets activated and detects motion.
If I have an arrive home scene, I want that to be automatically executed.
And your home is ready and welcoming you.
I'm happy to say you can now do this in iOS 9 with event triggers.
One or more events activate a trigger.
Let's talk about what kind of events we support.
We have events corresponding to the state of an accessory, so this would correspond to our front door unlocking.
And we also have geofence-based events.
So you can generate events corresponding to when I leave home or arrive home.
Let's go through these and how we represent them in the APIs.
For the state of an accessory, we have a new class, HM characteristic event, and that takes the characteristic you want to be the source of that event and a trigger value that, when that characteristic meets that value, that event will automatically be fired for you.
For location-based events, we have a HM location event class that takes a CLRegion.
You can configure the CLRegion, and when that criteria is met, the HM location event class will automatically fire.
Let's walk through an example of our front door being unlocked and capture that as a characteristic event.
Here's how you do it.
Create a HM characteristic event class, give it the front door current state characteristic as a characteristic that you want to capture.
And for the trigger value, just specify door state open.
Now this event would be fired when it's part of an event trigger as soon as your front door unlocks.
I talked about conditions.
Conditions get execution of a scene in a given trigger.
We support three types of conditions: time-based, so I can have something corresponding to before 6 p.m. We also support the state of an accessory.
This would be our motion sensor detecting motion.
Finally, we also have significant events in a day, like sunrise and sunset.
Let's go through each one of these and see how we create them in the APIs.
Conditions are represented as predicates, NS predicates, in the APIs.
And we have convenience measures for all of these.
You don't have to worry about them.
It's very simple to create them.
On an HMEventTrigger, class, we have a class method predicate for evaluating trigger occurring before date with components.
That takes an NS dates component that you can configure.
And you can use this, for example, to create the before 6 p.m. condition.
We have one for after date with components.
We also have the third one, which is predicate for evaluating trigger occurring on date with components.
This is really useful.
You can use this to create a condition for a specific day for example, Sundays.
Let's walk through an example of creating our condition for before 6 p.m. First, we create an NS dates component and set the hour property to 6 p.m. Next, we just use that NS dates component and pass it along to a convenience API predicate for evaluating trigger occurring before date with components, and that's going to give you an NS predicate corresponding to before 6 p.m. Next, the state of an accessory.
So we also have a convenience API on the HMEventTrigger class, namely predicate for evaluating trigger with characteristic, that takes a characteristic and a matching value that needs to be met for that condition to be evaluated through.
So for our motion sensor, here's how you would create a condition corresponding it to being detecting motion.
Just call the convenience API, specify the front door sensor characteristic as a source of the characteristic, and for the matching value, set it to true.
This would mean motion has been detected.
It's as simple as that.
Finally, significant events in the day.
We have two convenience APIs for this: predicate for evaluating trigger occurring before significant event, that takes an optional applying offset parameter, which is an NS dates component.
And the second one, as you guessed it, is predicate for evaluating trigger occurring after significant event.
We have two constants defined for significant events: sunrise and sunset.
Let's walk through an example for condition for our event trigger that would correspond to 30 minutes before sunset.
How do we go about doing that?
You first create an NS dates component and specify the minute to negative 30.
And now, just use our convenience API, predicate for evaluating trigger occurring before significant event, give it sunset as the significant event, and give the offset that we just created above.
With this, we can now gate execution of a scene if that event fires after 5:30 p.m. As long as it's before 5:30 p.m., it will always execute that scene.
So now we have events that can trigger our event trigger, and then we have conditions.
How do we tie it all together?
That's when you create an HMEventTrigger class, and the method takes the name.
You can give one or more events that activate a trigger.
Once a trigger is activated, we evaluate the corresponding condition.
The condition is optional, so if you don't specify a condition, it just means we assume it to be true, and we will always execute the corresponding scene associated with that event trigger if any one of your events activates.
Now let's walk through a completer example that I talked about earlier.
We have created a characteristic event corresponding to the front door being locked.
We created our two conditions, which is before 6 p.m.
and the motion sensor detecting motion.
How do we tie it all together and create our event trigger?
First thing you need to do is create a compound predicate because we want both our conditions to be ended and evaluated.
Both have to be true for us to execute our scene.
For that, just use NS compound predicate and predicate with subpredicates, and specify the two subpredicates that we just created earlier.
Next, create an event trigger object, give it a name, arrived home, and for the events that can activate this trigger, just specify an area of one element, which is a front door characteristic that corresponds with it being unlocked.
Finally, we just need to associate the arrive home predefined scene to this event trigger.
Use our convenience API on our home, built-in action set of type, give it the home arrival type that now returns your predefined scene corresponding to arrived home, just add that to the event trigger.
It's as simple as that.
Now I'd like to show a demo of this example I just talked about using our HomeKit Accessory Simulator and our HomeKit catalog sample app, which has been completely rewritten in Swift.
There you go.
So over here we have our HomeKit Accessory Simulator.
This simulates HomeKit accessories that are used by our developers to develop their HomeKit applications.
And over here we have our HomeKit sample app that, you know, that you can use that accesses all our HomeKit APIs.
I want to show you a demo of event triggers.
Now, you can see that I have a door lock, a motion sensor, and a bridge with two lights behind it in the HomeKit Accessory Simulator.
And I have added my accessories to my home.
So let's go down to the scenes section of the app, and I have configured two of the predefined scenes in this app.
I have the "bye, house," that corresponds to leaving home.
Let's see what that looks like.
That sets the light to black and switches off all the power on our lights.
I am going to go ahead and hit cancel because I don't want to make changes on this, and let's go down to the "hi, house," that corresponds to arriving home, and let's see what that looks like.
Now, that sets the lights to on and sets my stereo light to green and the kitchen light to blue.
Let's try to see these two scenes in action and see what happens.
So when I execute the "bye, house," it switches off the two lights.
And when I execute the "hi, house," which corresponds to arriving home, that switches on the two lights behind the bridge.
Now, let's simulate leaving home and now create our event trigger.
I am going to go down to the trigger section of the app and select add trigger.
You are presented with three options.
For our example, it's the front door being unlocked, which is the source of our trigger.
That corresponds to a characteristic, so I am going to go ahead and select characteristic.
I am going to give it a name now.
So this is the name of my event trigger.
And now let's go ahead and select the characteristic corresponding to the front door being unlocked.
So let's go down to the characteristics event of the app.
So add a characteristic.
And now go down to the front lock and select unsecured.
This will correspond to the door being unlocked.
I am going to go back and hit done.
So now I have captured my front door being unlocked as a source of my trigger.
Next, let's add our two conditions.
For that, let's go down to the conditions section, add condition, and since we are going to use before 6 p.m., that would mean it's time.
Go to the time section, and we have two ways to add time-based conditions.
One is, of course, the significant events, sunrise and sunset, but I am just going to use 6 p.m. at my example.
And I want to select before.
I am going to go ahead and hit save.
Now I have captured my first condition.
Now let's do the second condition, which is the motion sensor detecting motion.
Go add my second condition.
Now I am going to select characteristic because this is an accessory, which would mean I need to capture a characteristic as a source of that condition.
Select condition, find my sensor, and set motion to be detected.
I am going to go back and hit done.
So there you go.
I have my event trigger, given it a name, given it the source of my event, specified my two conditions that both need to be met.
I tie it all together, I just need to associate my arrive home scene to this.
Let's go down to the scene section and just select "hi, house."
And go ahead, hit done.
Now that saves the entire event trigger.
Now, let's see this event trigger in action.
For that, first I am going to go ahead and unlock my door and see what happens.
I have a view over here that shows the door state and the motion sensor so that it's easier for you to see what happens behind the bridge.
If I hit unsecured, which corresponds to opening the door, nothing happened.
And why is that?
The door opens, so that causes the event to be activated.
It is before 6 p.m. So one of my conditions was met, but the second condition was not met because, as you can see, motion detected is set to no.
So this is working as expected.
I don't expect my scene to be executed.
Now let's go ahead and close the door and set the motion to detected and see what happens.
I am going to go ahead and unlock the door.
There you go.
That switched on the lights and executed my arrive home scene.
How cool is that?
This is an awesome feature, and I work on this every day.
But what is really exciting to see this work, when I see that light goes on, it just gives you, you know, that happy feeling.
For those of you who have used the Accessory Simulator, you see there's a motion sensor.
This is new in iOS 9.
We have added new categories of accessories.
To talk about this and new features we have added for our accessory classes, I'd like to invite Naveen.
[ Background Sounds ]
NAVEEN KOMMAREDDI: Thank you, Anush.
Good afternoon, everybody.
I am Naveen Kommareddi, and I am here to present to you even more features in iOS 9 for HomeKit accessories.
Starting with remote access and new features and enhancements for Bluetooth Low Energy HomeKit accessories and new accessory categories.
So let's get started with remote access.
With remote access, you'd be able to control your accessories even when you are away from your house.
So let's take an example of a thermostat that works with HomeKit here in your house.
You would be able to securely connect to it.
But what if you are away from your house?
How do you control this thermostat?
Say you want to come home, but you want to set it to the temperature even before you come home?
How do you do that securely?
Well, in iOS 8, remote access is supported if you have an Apple TV third generation.
All you need to do is sign in with the same Apple ID as the one you used on your iOS device, and you'd have secure access to your accessories.
Now, this is great, but what if you don't have an Apple TV?
Because we know that not every one of our customers may have an Apple TV.
[Laughter] So in iOS 9, I am very excited to announce that we support HomeKit accessory protocol, HAP, over iCloud.
Yes, it is really exciting because what this means is you can now control your accessories and get notifications from them no matter where you are, and even if you don't have an Apple TV.
Let's pause to think what this really means.
To accessory manufacturers who have thought about providing secure and remote access to their accessories, you know it's a hard problem to solve.
We built and deployed a dedicated iCloud service to securely relay HAP messages between iOS devices and accessories, and we scaled the infrastructure that runs the service to handle billions of HAP messages.
And we thought: How can we make this better?
So to use this service, the accessory manufacturers and all our customers will now get it for free.
But most importantly, privacy and security.
The end-to-end connections between iOS devices and accessories are HAP secure, and privacy is maintained.
Even Apple can't see the content of the communication.
This is extremely important.
Now, with HAP support over iCloud and Apple TV, our customers will now have more ubiquitous access to their accessories.
Now, moving on from remote access to Bluetooth Low Energy.
So we are working with several of our partners to bring more Bluetooth Low Energy accessories that that work with HomeKit.
Let's say a Bluetooth door lock.
Now, if you are within Bluetooth LE range within this accessory, let's say a door lock, say 20 to 30 feet, you can securely connect to it and control it.
But what if you are far away, like in the corner of your house or in the backyard?
How do you securely connect to this accessory and control it?
Wouldn't it be great to have a mechanism or a feature that would connect these two endpoints together?
Well, in iOS 9, you can do exactly that with HAP secure tunneling.
HAP secure tunneling enables an intermediate device to associate over Bluetooth Low Energy and expose it as an artifact over Wi-Fi to an iOS device.
Now you have a device that is a HomeKit accessory that provides range extension with HAP secure tunnelling.
So what's even better is this range extender will also be able to provide remote access to this Bluetooth accessory and any other Bluetooth accessory that works with HomeKit.
What this means is not only can you reach your accessories no matter where they are in the house, but you can also reach them wherever you are, home or away.
Ultimately, privacy and security.
The end-to-end connection through this intermediate device is still HAP secure, and privacy is maintained because this intermediate device, the range extender, cannot see the content of the communication.
We didn't stop there.
We added several more enhancements, starting with notifications.
Your Bluetooth Low Energy accessories now have full support for notifications, regardless of the state of connectivity.
So whether they are disconnected or connected, they can send HAP notifications to your iOS devices.
We also added support for metadata.
This way, custom characteristics can describe themselves fully to HomeKit applications.
And finally, we added support for multiple transports.
With this, you can now have a HomeKit accessory that can work over IP or Bluetooth LE simultaneously, and the iOS device will be able to recognize that it's the same accessory regardless of the transport that the accessory uses to communicate with it.
Really a compelling feature.
Now, let's move on to the last topic of our presentation, which is accessory categories.
Last year with iOS 8, we added support for several accessories that are most commonly found in your house, like your lights, fans, switches, plugs, garage doors, et cetera.
Now, adding native support for accessory categories is an evolutionary process in iOS, and in iOS 9, we added support for more devices in iOS so that you can connect more accessories in your house.
Starting with window coverings.
You can now use iOS to control your awnings, blinds, and shades, and motorized doors and windows.
Alarm systems are also a new category.
Now, this is a category that several and alarm system and security system providers have asked for native support, and which listened to them.
But we also found that alarm systems can be really complex with a lot of features, but what we did is to distill the key and the most used features in an alarm system service.
Now, you as an accessory manufacturer will be able to add more features using custom characteristics, of course.
Alarm systems typically work hand in hand with sensors, so we added support for several sensor categories: motion, air quality, and smoke being just a few of them.
And last but not least and this is a category I am very excited about is programmable switches.
A programmable switch is a HomeKit device whose main purpose is to generate events.
iOS makes this accessory compelling.
So to understand this better, let me walk you through an example.
So let's say it's bedtime, and you're in your bed, you stow away your electronics, charging somewhere, but you don't know if your house is secure.
Your lights are probably off in some far corner of the house.
But fret not.
You have this programmable switch, nothing but a simple switch with a button.
Now, you press the button.
It generates an event.
And you know now in iOS 9 we support event triggers.
So our users will be able to map this event to a trigger, which will execute this beautiful predefined good night scene.
Now, iOS, wherever it is, wherever the phone is, it will get this trigger and execute all of it magically.
Powerful but simple.
Now, programmable switch and all the other new accessory categories are available, as Anush mentioned, in our updated version of the HomeKit Accessory Simulator, so that you, as developers, can develop apps to support these new categories.
The HomeKit Accessory Simulator is one of the several tools available to you as developers and accessory manufacturers.
We also have HomeKit Accessory Tester, which is also being updated to support many of the new features that we talked about today.
Now let me talk a minute about HomeKit Accessory Tester, HAT.
We urge you, as accessory manufacturers, to exclusively use HAT all through your development cycle because this way you will ensure that your accessory is compliant to HomeKit specifications and also ensure that your accessories work with past and future versions of iOS.
Now, HAT also provides the debug information that may not be available to you when you use iOS, but the most important reason is that we use HAT at Apple to certify your accessories.
Now, HAT is also one of the tools that is exclusively available to members of Apple's MFi program.
Now, if you are already a member of this program, then you'd be able to get updated specs and tools in the near future at the MFi portal.
If you are not a member of the MFi program and you are making a HomeKit accessory, you need to enroll so that you would be able to download the specifications and tools.
And here is a link to get you started.
Now, in summary, today you learned about many new features, like HomeKit and Apple Watch, event triggers, a new way of remote access, and several features for Bluetooth Low Energy accessories.
We at Apple are really excited about all these features, and we can't wait to see what you are going to do with them.
If you have any more questions, any questions on HomeKit, here's where you can get more information from.
Thank you very much for attending our session.