Accessory Developers, Meet iOS 8

Written by: on July 3, 2014

WWDC 2014 was packed with new features for developers to take advantage of in iOS 8.

Among them were technologies that present new opportunities for accessory manufacturers, but often the technical side of that development doesn’t get the coverage it deserves. What follows is a discussion of what accessory manufacturers should be excited about (we certainly are!) as we look forward to the iOS 8 release.


HomeKit is Apple’s answer to address, as best they can with software alone, the growing divergence in home automation protocols.  Through a common set of HomeKit APIs for applications and a transport-agnostic communications protocol for accessories, Apple is attempting to reign in manufacturers under a common umbrella to simplify life for their users.

Apple has created a unified communications mechanism for accessory devices dubbed HomeKit Accessory Protocol (HAP). Accessory devices can communicate via Bluetooth Low Energy (BLE) or over Wi-Fi/IP. For Bluetooth LE, HAP sits on top of the standard GATT profile as a defined set of services and characteristics. On the IP side, HAP is implemented using JSON over HTTP communication, using structured data to essentially create GATT over an IP transport.

Bluetooth LE device discovery uses standard advertising and scanning mechanisms, although the advertisement packet on these devices is HAP-specific to support authentication. IP device discovery is handled using Bonjour, and thereafter the iOS device treats the accessory as a RESTful API endpoint. Apple has created a common bi-directional “pairing” mechanism within HAP that is transport-agnostic. This mechanism also secures all transactions between the iOS device and an accessory.

Of course, software alone is only part of the equation. Many connected home manufacturers use wireless radio technology that we likely won’t see in a mobile device (e.g. Z-Wave) that keeps them from connecting to your phone or tablet.  Apple would like to see manufacturers address this in the form of “bridge” or “hub” devices, which is a special device configuration that speaks HAP but intrinsically has no attributes. Rather, a bridge aggregates multiple accessories together that cannot connect directly to iOS, and links them into the HomeKit ecosystem.

Further details of HomeKit Accessory Protocol are covered under the MFi program NDA, so if you are interested in building for these technologies it is strongly recommended you get signed up at right away.


HealthKit was noted in the WWDC keynote as a way for users to aggregate all their health accessory data into a single store on the device. Health and fitness application developers will have access to this data and statistics through new HealthKit APIs, and users can benefit directly through the bundled Health app on the device.

But how an accessory get its data into HealthKit? Bluetooth LE is at the core of HealthKit, with several of the adopted GATT profiles centered around health data. Apple has made it super simple for devices using this technology to integrate with iOS 8.  In fact, accessories that adopt one of the following standard profiles will integrate directly with HealthKit in the core OS:

This means that accessory developers don’t even need to develop a companion application to interact with the accessory device to provide data to HealthKit; iOS does all the software work. This doesn’t mean that other accessory options are left out of the game. Apple encourages developers who may be using other BLE profiles with CoreBluetooth or a more unique EAAccessory implementation (i.e. a Bluetooth Classic or USB devices under MFi) to build the new APIs for storing HealthKit data into their existing companion applications.

New Potential in EAAccessory

Without diving too deep behind the wall of MFi, suffice it to say that in the past it was difficult to create an accessory device that 3rd parties could communicate with directly in their own applications. This was partially because the accessory manufacturer was responsible for declaring the applications that would talk with the accessory ahead of time, and there was no robust way to expose the accessory’s features from a core application to others on the system. This may also change in the near future, as they announced in iOS 8 that multiple applications can now hold simultaneous sessions with a single EAAccessory protocol.

If this hurdle persists, however, an opportunity has opened up in the form of iOS 8 extensions. Accessory developers can now build actions into their core accessory application that exposes pieces of the accessory functionality via UIActivityViewController. With an action extension’s view controller being optional, this can allow a relatively direct path to the accessory from a 3rd party app without too many unnecessary UI components getting in the way of the experience.

There are sill limits to this method, but if the accessory communication can be boiled down to one or more user actions (e.g. print, scan, launch rubber missile), then the door is opening to allow those features to be packed into an accessory’s official application, with exposed extensions to let 3rd party developers (or maybe even Apple applications) to attach to that functionality.  Expose a storage-based accessory to all applications through a storage provider extension, or perhaps control a piece of office equipment with a suite of new actions developers can integrate.

Combine this with the new ability in iOS 8 to generate embedded frameworks, and building SDKs for 3rd party integration of an accessory just got much more interesting.

Remember Core Services

The Apple Notification Center Service (ANCS) isn’t new with iOS 8 (it was introduced last year in iOS 7), but with all the focus on wearable accessories it bears repeating; the official specification was released last October. ANCS is a persisted service on most iOS 7+ devices exposing active notification information via Bluetooth LE. While the service doesn’t (yet) support clearing or any other writable functions, it is a clean mechanism for getting up-to-date notification information on a remote accessory.

With iOS 7, implementations of the adopted Bluetooth profiles for Time Service and Battery Service were also added to iOS for an accessory to gather information about the device to which it is connected. In iOS 8, MFi accessories can now access similar data over IAP (iPod Accessory Protocol).

Double Encore is an MFi-Certified Development Licensee, and we would love to further discuss your accessory product ideas on iOS using these upcoming technologies.

Dave Smith

Dave Smith

Dave Smith is a Senior Engineer at Double Encore, Inc., a leading mobile development company. Dave is an expert in developing mobile applications that integrate with custom hardware and devices. His recent focus lies mainly in integrating the Android platform with embedded SoC hardware. He is a published author and speaks regularly at conferences on topics related to Android development. You can follow Dave on Twitter and Google+.

Add your voice to the discussion: