HomeKit in iOS 8: Explained

HomeKit in iOS 8: Explained

HomeKit is the name for Apple's home automation framework for developers. With HomeKit, our iPhones and iPads will have a rational way to configure, communicate with, and control "the internet of things" around us, including connected lights, speakers, security systems, appliances, and more. Both locally when you're home and remotely when you're away, through apps and through Siri, Apple's virtual personal assistant. HomeKit is doing all this seamlessly, but also securely and privately. So, how does HomeKit work?

Managing your HomeKit

HomeKit is based on a "Home Manager" and a common database, stored in iOS, that contains all the information about the home, its rooms, the accessories inside them, and the services and characteristics of those accessories. Having everything stored all in one place makes for a more consistent experience across apps. so, for example, whatever you have set up in your light control app, will be the same in your speaker control app. Same home name. Same room names. Same accessory names.

Homes and rooms

Home Manager, as the name implies, lets you manage "Homes", including designating a primary home if you have more than one. Each home has to have a unique name so you can specify which one you're referring to, including via Siri. For example, you can have "Main" and "Vacation" as home names.

Home are made up of "Rooms". Rooms also have to have unique names, but only within their Homes. So, for example, you can have "Main Bedroom" and "Vacation Bedroom". Again, that's so you can refer to them specifically, and so can Siri.

Rooms can be grouped into "Zones". These could include, for example, "Upstairs" and "Downstairs". Any number of rooms can be grouped in a zone, and the same room can exist in multiple zones. However, zones also need unique names within the home, for you and for Siri.

Rooms are what contain your "Accessories". Accessories are the specific physical devices connected to your iPhone or iPad — the scales, speakers, locks, etc. Accessories also need unique names within a home, so they can be specifically accessed by you or Siri. So, "Main Bedroom Lights" and "Main Bedroom Speakers" are fine. "Main Bedroom Lights" and "Main Kitchen Lights" are not. (If you have multiple similar accessories in different rooms, you'll have to get more specific or creative with their names.)

Services and characteristics

Accessories have "Services". These represent what an accessory can do. Services may or may not have names. If they're meant to be commonly used or accessed via Siri, they'll need a unique name to the home, just like the accessory itself. For example, a light bulb that lights up is a service that needs a name. Other services include garage door openers, door locks, thermostats, IP cameras, switches, and custom services.

If a service is not meant to be commonly used, and would be better accessed via an app interface, they shouldn't have a name. For example, a maintenance function that updates firmware shouldn't have a names. Apple also defines some default service types, which Siri recognizes through natural language as well.

Services can be grouped into "Service Groups." These could include, for example, "Night lights" that includes room lights, garage door opener lights, outside lights, and appliance lights, or "Party speakers" that pipes audio around the house. Service groups can include any number of services from any number of different accessories, and are intended to make it easier to control specific services across a range of accessories. The same service can be included in any number of different groups, so the same light can be in "Night Lights" and "Game time", but each service group needs a unique name per home for you and Siri.

Services have "Characteristics". Characteristics are the interactive part of services. For example, whether a light bulb is on or off (the power state) is a characteristic. They're not named but they're recognized by Siri because Apple has defined certain types, like power state, lock state, target state, brightness, model number, current temperature, and custom characteristics.

Some characteristics are read-only, like current temperature. Some are read-write, like asking for and re-setting the temperature. Some are write-only, like commands. So, for example, you can command any accessory to "identify" and it'll flash, beep, or otherwise show or tell you what and where it is.

To help developers and manufacturers think outside the presets, HomeKit allows for custom services and characteristics to be defined. They're not understood natively by Siri the way Apple-defined services and characteristics are, but they allow for potentially much greater and more diverse functionality.

Actions and triggers

Actions write to characteristics. For example, close the garage, lock the doors, turn off the lights, turn down the temperature, etc.

Actions Sets are collections of actions that are executed together. For example, "Good night" could make sure your garage door is closed, front door is locked, night lights are on, day lights are off, TV is off, and coffee maker is set to help wake you up in the morning. "Game time" could make sure the lights are set to red, the sound system is on max, and everything else in the house is off or muted. Action sets aren't executed in a specific order. They all just happen as soon as they can, all at once if possible. Again, an action set needs a unique name per home for you and Siri.

Triggers execute action sets at predefined dates and times. They can be single use or can be set to repeat. They can have delays built-in. Triggers can't be used through Siri, but they can be run by iOS in the background, unlike the rest of HomeKit, and also require unique names per home.

Taken together, action sets and triggers let you create "scripts" to automate the control of any and all of your HomeKit compatible accessories.

Adding accessories to Home Kit

Because HomeKit is a framework for developers and not an app — there's no Home.app for HomeKit there way there's a Health.app for HealthKit, Photos.app for PhotoKit, Passbook.app for PassKit, etc. — any app that ties into HomeKit has to be ready and able to help the user manage their accessories.

That means, if a HomeKit app is launched and no "Home" is detected, the app has to walk the user through creating and naming it, then creating and naming the rooms in it, then providing the accessory browser so the user can find and add accessories to the home, name them, and assign them to the proper room. HomeKit can also report back to any app whether or not an accessory is accessible or not accessible, for example out of range, offline, turned off, etc.

There's a special kind of accessory called a bridge. It's used when an accessory has several parts but only the main part can connect to Home Kit. For example, if an amp can connect to HomeKit but the speakers use an incompatible format, the amp would serve as a bridge to the speakers. Once a bridge is added, you can add the satellite accessories as well, and the bridge will handle the heavy lifting of translating between HomeKit and whatever format they use. So, add the amp, control the speakers through the amp.


Thanks to the integration with Siri, HomeKit also looks like a huge win for accessibility. Voice control plus a consistent experience across apps will hopefully lead to more apps and accessories being more accessible to more people with visual impairments.

HomeKit for developers

Apple has made it easier for developers to work with HomeKit by building a Home Kit Accessory Simulator right into Xcode 6. It acts just like a real accessory and allows developers to test apps as though they were connected to a real accessory.

Apple also cautions developers that there are a lot of delegates to be implemented for HomeKit. Because there's a shared database, and multiple apps can make changes, and accessories can be added and removed, and have their states changed, there's an equal and opposite price to be paid for the convenience and consistency. That price is paid through the delegate methods. It's how HomeKit tells an app what's going on beyond that app so it can always be up to date.

HomeKit partners

HomeKit, like HealthKit, and like PassKit before them, will depend on the quantity and quality of manufacturers and developers that support it. If past history is any indication, that means we'll get some amazing apps and accessories, some okay apps and accessories, and some barely thrown together web views meant to control gizmos of dubious construction and utility. As much as we complain about the level of control Apple exerts, we often complain even harder about those things outside Apple's control.

Traditionally, though, Apple has paid even closer attention to the quality of hardware partners than to the App Store. How long it will take for our favorite lights, speakers, security systems, etc. to update for HomeKit remains to be seen. However, iDevices, iHome, Sylvania, Texas Instruments, Cree, Chamberlain, Marvell, Skybell, August, Honeywell, Haier, Schlage, Philips, Kwikset, Broadcom, netamo, and Withings have all already been announced. More, no doubt, are to come.

Security and privacy

Not surprisingly, Apple takes HomeKit security and privacy very seriously. They've built it, reviewed it, and then reviewed it again. There's end-to-end encryption between connected devices and accessories, and adding a new accessory requires a setup code that comes from the accessory, typically on the packaging or a label. Likewise, Apple stresses that they don't believe privacy includes storing information about your home and your accessories on their servers.

Locally, HomeKit apps can only be used while in the foreground. That makes sure people can see just exactly what's going on and when, and never have to worry about something happening secretly in the background. The only exception to this is triggers, which give iOS the ability to set off an action set. However, they need to be expressly set up by the user to do so.

Bottom line

HomeKit tackles a big, complex problem and tries to make it small and simple enough to fit onto your iOS devices and into your daily life. It's important to remember this is HomeKit 1.0, and there will almost certainly be kinks to work out and updates to come. However, if HomeKit comes even close to fulfilling its potential, we're going to find ourselves at the beginning of something truly remarkable, for our iPhones, our iPads, and for whatever comes next.

More of iOS 8: Explained

Have something to say about this story? Leave a comment! Need help with something else? Ask in our forums!

Rene Ritchie

EiC of iMore, EP of Mobile Nations, Apple analyst, co-host of Debug, Iterate, Vector, Review, and MacBreak Weekly podcasts. Cook, grappler, photon wrangler. Follow him on Twitter and Google+.

More Posts



← Previously

Debug 45: Jim Ray on the Web and BBQ

Next up →

Alone is an amazing new sci-fi game you should probably get

Reader comments

HomeKit in iOS 8: Explained


The potential is huge. A few years ago I installed the integration system for a billionaire's winter home. He didn't want to carry keys. So when he gets home, he enters his pass code on the keypad at the front door: door unlocks, alarm disarms, lights turn on, thermostat goes back up. This took quite a bit of wiring and programming between systems, but in the end, it was pretty cool.

I assume something similar could be done with a wearable or anything with BT-LE for location awareness. Or gestures from a watch. Or Siri commands.

We have done other functions like that. Most common are Good-night and Away. Good night turns off all TVs and speakers, interior lights off, exterior lights on, pool water features off, temperature set, and arms the alarm in stay. This involves a pretty hefty cost, but it makes life easier & in the long run, it can save money in electricity. (We also run lights at 70-80 % rather than 100% when switched to On)

I agree: great article.
You mentioned that there isn't a Home.app; does this mean that it will be up to 2nd/3rd party app developers to create it? Won't this still require compatibility between the app and the controllable devices? With Crestron or AMX, they provide modules, or you write your own, then all the hooks, cross points, buffers etc are up to the programmer. So who makes the modules to allow "myHome.app" to control my schlage lock or Honeywell alarm?

What I meant was there's no Apple made Home.app, so every HomeKit app developers make need to be able to handle the management of accessories. (Adding and naming homes, rooms, and accessories.)

So by that explanation, when I say "Hey Siri, it's bedtime," my alarm system, thermostat, lights, televisions, consoles, and garage door would all have had to be pre-set up through each individual company (or be connected through a bridge of one that is) to talk to each other, or have each one recognize the command irrespective of the other devices? OR would each vendor create their own HomeKit-communicating app (or hooks with menu options within their current apps) to modify settings?

Good article Rene, but the grammar nazi in me couldn't keep this in. I was taught the end quote came after the period, "like this." Am I wrong?

English is an art more than a science. I put the period in the quotes if the entire sentence is in the quotes. "Like this." I put it after if only part of the sentence is in the quotes. So, not "like this".

I noticed that there is a little bit about the accessibility feature on the article could you explain more about it how would it work for a visually impaired person? Or person in a wheelchair that can't tear? The reason why am asking this question is because I am visually impaired myself

Sent from the iMore App

Thanks for the overview. I'm very excited but still have questions.

For a truly automated home, Triggers, actions that take place automatically, initially setup by you but without your input at the time, are a necessity and Apple has included them.

You explain that iOS will run these in the background.

Many of the needs for Triggers all revolve around the same data point, you are not actually home. In this case, can Apple assume that an iOS device will be present? Some home automation devices don't need a hub and/or they use bluetooth and, even if Home Kit can work over the cellular network, wouldn't you need an iOS device in the local vicinity to translate? An Apple Hub? An updated Apple TV?

Also, this sounds like a whole lot of fiddling around, although completely worth it, to get things just right. With Apple not storing this info on iCloud, will we have to manually duplicate our whole setup across each of our devices? Does there seem to be some sort of sync across devices?