This document looks into whether key features are supported and/or possible by examining existing standards, protocols, and libraries on the target platforms of the AnnoWatch project. The document will proceed in the following order:
- Requirements: What is the feature-set AnnoWatch requires.
- MFi: A brief foray and examination of Apple's MFi program. Includes clearing it with our requirements.
- Bluetooth: A look into the various bluetooth profiles and services needed for the device to fulfill its functions, along with their compatibility with desired Bluetooth standards.
- Conclusion: Summary of findings and recommendations
In order for a watch or any wearable to be considered "SMART", it must be enhanced by, or capable of some minimum interaction with other networked "SMART" devices. We have identified the following key feature(s) that the wearable must support:
- Notifications: The ability to forward and signal to the user that notifications have been received on their primary device.
- Media Control: The ability to control playable media on a connected/paired device.
These capabilities must also be supported by a low-energy/low-power communication medium, as power savings is a key priority for the project.
Apple's iOS is a necessary platform for wearables to support when targeting the smart accessory market. However, interactivity with iOS via other hardware products is restricted by Apple's "Made for iPhone/iPad" quality control program. This program is designed to filter out products that do not abide to the company's standards from interacting with their devices. Participation in MFi requires a membership fee of USD $99 per year, and that you work with an MFi licensee for accessory development. To manufacture oneself requires inventory and financial reporting system auditing (source).
It is a key to this project that MFi not be required. As we are not incorporated, nor in the position to financially support MFi, the project can only continue if compliance is not required. The purpose of this text is to examine our requirements, and determine whether we can proceed without its use.
The definitive answer at the moment is no, we don't need MFi. Apple lists on their FAQ pages who should and shouldn't be required to join the MFi program. For developers targeting existing Bluetooth profiles, they have this to say:
Who does not need to join: Developers and manufacturers of accessories that connect to an Apple device using only Bluetooth Low Energy, Core Bluetooth, or standard Bluetooth profiles supported by iOS. Learn more about Bluetooth.
Therefore, we can proceed without worrying about MFi.
Both media control and messaging form part of a common feature-set available across almost all smart-devices. Communication is almost exclusively done via Bluetooth (and particularly Bluetooth Low Energy). These protocols are completely distinct, each supporting different profiles, bitrates, and features.
The below summary focusses exclusively on what Bluetooth Profiles are needed, and whether they are supported either directly or via a workaround specifically for Bluetooth Low Energy on the platforms we wish to interact with.
| Profile | Summary | BLE iOS Support | BLE Android Support |
|---|---|---|---|
| GAP. | Device discovery | Yes. | ? |
| GATT. | Service/attribute sharing | Yes. | ? |
| HID. | Input devices (keys, etc) | HID over GATT. | ? |
| AVRCP. | Audio/Video controls. | HID over GATT. | ? |
| MAP. | Message handling. | Via GATT ANCS | ? |
Sources:
Canonically, iOS supports all the necessary protocols for our feature-set. However, the Bluetooth Low Energy specification does not support all of these protocols. Chief lacking is MAP and audio control profiles. Despite this, it does appear workarounds exist. For example, Apple Control Center provides support for notifications over GATT (see docs). This is supported thus by BLE, and therefore makes notification reception possible.
TODO