Creating a mobile app that communicates with a custom wearable device via a Bluetooth Low Energy connection seems like an unusual experience, that wouldn't possibly happen to you, would it? Well, let me tell you that the Internet of Things is here and it's full of interesting opportunities, so we, as a community, should keep learning and get ready to seize them! During this talk, I'd like to tell you a few stories and lessons learned about my experience creating iOS apps and SDKs to interface with several smartwatches made for monitoring physiological signals. We'll go through code samples, tools, unexpected bugs, clever ideas and bad mistakes, hoping we'll learn something together in the process.

3. TODAY'S ADVENTURE
> Wearables & My Story
> Coding with BLE on iOS
> The importance of protocols
> Connection stability
> Testing with wearables
> Logging & monitoring
> Remote maintenance
> The End

4. WEARABLES

9. TODAY A WEARABLE WILL BE
> A piece of HW that sits somewhere on your body
> Easy to carry with you
> Provides useful data via sensors
> Uses BLE for data exchange with the outside world
> In need of an app to communicate with
> Custom: you know / have power on the internals

10. IOTMAYBE JUST A
SPECIAL CASE

11. WEARABLES
&
ME

15. BLE & IOS

16. CORE BLUETOOTH
The framework is an abstraction of the Bluetooth 4.0
specification for use with low energy devices. That said,
it hides many of the low-level details of the specification
from you, the developer, making it much easier for you to
develop apps that interact with Bluetooth low energy
devices.
— Apple Docs

17. CORE BORING!
!

18. PERIPHERAL
> Has data
> Advertises its presence
> It's our wearable
> CBPeripheral

19. PERIPHERAL
> It exposes services
> Services contain characteristics
> Characteristics allow data exchange
> You can define your own

22. CENTRAL
> Wants data
> Scans for advertising peripherals
> Connects to peripherals
> Explores services and characteristics
> Reads, writes, is notified by characteristics
> It's (part of) our app
> CBCentralManager

23. THE
BLUETOOTH
DANCE

24. 1 - THE DANCE FLOOR

25. SCANNING
let central = CBCentralManager(delegate: self, queue: nil)
let serviceUUID = CBUUID(string: "ABC00001-A0B1-FFFF-1234-1A2B3DD11001")
// Set the delegate (someDelegate: CBCentralManagerDelegate)
central.delegate = someDelegate
// Start Scanning
central.scanForPeripherals(withServices: [serviceUUID], options: nil)

26. 2 - POTENTIAL PARTNERS

27. DISCOVERY
var peripheral: CBPeripheral?
// CBCentralManagerDelegate discovery handler
func centralManager(_ central: CBCentralManager,
didDiscover peripheral: CBPeripheral,
advertisementData: [String : Any], rssi RSSI: NSNumber) {
if thisIsMy(peripheral) { // Check before connecting
central.stopScan() // Please do!
self.peripheral = peripheral // Keep a strong ref!
// Step 3 here
}
}

28. 3 - WANNA DANCE?

29. CONNECTION
// central: CBCentralManager
// peripheral: CBPeripheral
central.connect(peripheral, options: nil)

31. FAILURE HANDLER
// CBCentralManagerDelegate method
func centralManager(_ central: CBCentralManager,
didFailToConnect peripheral: CBPeripheral,
error: Error?) {
// Recovery
// Notify users
// ...
// Give up? !
}

33. CONNECTION HANDLER
// CBCentralManagerDelegate method
func centralManager(_ central: CBCentralManager,
didConnect peripheral: CBPeripheral) {
// Start dancing!
// !"
}

34. UNENCRYPTED CHARACTERISTICS
No BLE encryption on the device side
> You can interface with the device immediately
> It will go back to advertising mode when disconnected
from the app
> It will need a new scan to be found (or a direct
connection via UUID)

35. ENCRYPTED
CHARACTERISTICS
Manual interaction required

36. ENCRYPTED
CHARACTERISTICS
Saves pairing at the OS level
(see Bluetooth settings)

37. ENCRYPTED CHARACTERISTICS
> The device reconnects automatically to iOS
> You'll need to retrieve it from known peripherals:
let peripherals = central
.retrieveConnectedPeripherals(withServices: [serviceUUID])

38. ENCRYPTED CHARACTERISTICS
The pairing can be "delicate":
> You can't retrieve the device anymore
> You can't connect to the retrieved device
> You can't exchange data with the device
You can't solve this with code:
> Soft solution: kill your app, forget device
> Hard solution: restart your phone

39. AFTER CONNECTING
peripheral.discoverServices([serviceUUID])
peripheral.discoverCharacteristics([charUUID], for: service)
peripheral.setNotifyValue(true, for: characteristic)
// In your CBPeripheralDelegate
func peripheral(_ peripheral: CBPeripheral,
didUpdateValueFor characteristic: CBCharacteristic,
error: Error?) {
if let data = characteristic.value { // data: Data
// Enjoy your data! !
}
}

40. WHAT NOW?

41. THOU SHALT HAVE A SHARED PROTOCOL
> Available services and characteristics
> Commands and command format
> Response format (how to parse bytes)

42. PROTOCOL EXAMPLE
// Command Characteristic
let charUUID = CBUUID(string: "ABC00001-A0B1-FFFF-1234-1A2B3DD11002")
let char: CBCharacteristic // We have already discovered this
// Available Commands
enum CommandId: UInt8 {
case test // 0
case readTemp // 1
case writeTemp // 2
}
// Issuing the Read Temperature command
let readTempData = Data(bytes: [CommandId.readTemp.rawValue])
peripheral.writeValue(readTempData, for: char, type: .withResponse)

43. PARSING THE RESPONSE

44. PARSING THE RESPONSE
// Inside didUpdateValueForCharacteristic handler
const uint8_t *data = (uint8_t *)[characteristic.value bytes];
uint8_t packetID = data[0];
if (packetID == TEMP_RESPONSE_ID) { // ID for the temperature response packet
uint32_t timestamp;
memcpy(&timestamp, &data[1], 4);
int8_t temperature;
memcpy(&temperature, &data[5], 1);
// Work with temp value & timestamp
}

45. OBJ-C? !

46. MESSING WITH THE PROTOCOL?
// V1
enum CommandId: UInt8 {
case test // 0
case readTemp // 1
case writeTemp // 2
}
// V2
enum CommandId: UInt8 {
case test // 0
case reset // 1 <=== NEW COMMAND HERE! !
case readTemp // 2
case writeTemp // 3
}

47. DEVICE RESET!

48. RECAP
> We know how to discover our custom wearable
> We know how to connect and pair it with iOS
> We know how to subscribe to its characteristics
> We know how to parse device data
> WE KNOW HOW TO DANCE! !"

49. CONNECTION STABILITY

50. CONNECTION STABILITY
> Your wearable device measures critical data
> It needs to be always connected
> The background is a completely different story:
For iOS apps, it is crucial to know whether your app is
running in the foreground or the background. An app must
behave differently in the background than in the foreground,
because system resources are more limited on iOS devices

51. BACKGROUND MODE

52. STATE PRESERVATION AND RESTORATION
let queue = DispatchQueue(label: "mySerialDispatchQueue")
let options = [CBCentralManagerOptionRestoreIdentifierKey:
"myCentralManagerIdentifier"]
let centralManager = CBCentralManager(delegate: self,
queue: queue,
options: options)

53. AS A RESULT...
> Your app will continue working in the background
> If your app is suspended, the system will track:
> the services it was scanning for
> the peripherals it was connected / connecting to
> the characteristics it was subscribed to
> Related BLE events will make the system relaunch your
app in the background

54. ERROR #1
ASSUMING APP RELAUNCH WILL ALWAYS WORK
If the users kills your app, there's no coming back from it
SOLUTION
✅ Let your users know

55. ERROR #2
ASSUMING THE BACKGROUND WILL JUST WORK
If the BLE connection is dropped in the background and the app gets suspended, it
won't be relaunched
SOLUTION
✅ Try to reconnect immediately
✅ If you need to do some processing, start a background task

56. UIApplication.shared
.beginBackgroundTask(expirationHandler: (() -> Void)?)

57. ERROR #3
ASSUMING YOU HAVE INFINITE TIME
"10 second" rule: each BLE event renews your background time for about 10
seconds.
SOLUTION
✅ Have your wearable ping your app more often than every 10 seconds
✅ Start a background task if you miss a packet

58. ERROR #4
TRUSTING IOS CHANGELOGS
iOS updates break the Bluetooth in subtle ways
SOLUTION
✅ TEST, TEST, TEST each iOS release

59. TESTING WITH
WEARABLES

60. BASIC TESTING
> Write your unit tests
> Do your TDD
> Automate your tests
> Maybe add some UI testing
> Use continuous integration
> Involve your QA engineer colleagues

61. ...WITH WEARABLES?
> Focus on full system integration
> Involve all the components
> Track exactly what you're testing: HW revision, FW
version, OS, ...
> Have clearly defined test scenarios and store test
reports
> Sadly, the simulator won't work here

62. THE HUMAN SIMULATOR

63. YOU'RE NOT ALONE IN THIS
Make sure these people are your best friends:
> FW developer: custom FW, insight about the device...
> QA engineer: test scenarios, collecting reports...
> Your colleagues: will run around with you !

64. SAMPLE TEST SCENARIO
> Custom FW that simulates disconnections
> Move around the room, app in foreground, see what
happens
> Send the app to the background, see if it dies on you or
if it recovers the connection
> Check what happened (HW + SW)
> Repeat this on every FW / App / OS update!

65. LOGGING AND MONITORING
> NEVER forget about logging
> Remote logging (in the cloud)
> Via the app (no internet access on device)
> Session reconstruction from start to finish

66. A CASE SOLVED BY
LOGGING

67. REMOTE MAINTENANCE

68. REMOTE COMMANDS
// Note: this is only a partial implementation
enum RemoteCommandId: Int {
case ping = 0
case checkStatus = 1
case resetDevice = 2
// ...
}

69. REMOTE COMMANDS
struct RemoteCommand {
let id: RemoteCommandId
let delay: Int
let params: [String: Any]?
// ...
}

70. REMOTE COMMANDS
struct RemoteCommand {
// ...
static func parseRemoteCommand(userInfo: [AnyHashable : Any])
-> (Bool, RemoteCommand?) {
if let cmdIdInt = userInfo["command"] as? Int,
let cmdId = RemoteCommandId(rawValue: cmdIdInt) {
let delay = (userInfo["delay"] as? Int) ?? 0
let params = userInfo["parameters"] as? [String: Any]
let cmd = RemoteCommand(id: cmdId, delay: delay, params: params)
return (true, cmd)
}
return (false, nil)
}

71. SILENT NOTIFICATIONS
{
"aps" : {
"content-available" : 1
},
"command" : 1, // Check Status
"delay" : 0 // Now,
"parameters": [
// Your custom parameters
]
}

72. RECEIVING AND PARSING
let executor = RemoteExecutor()
func application(_ application: UIApplication,
didReceiveRemoteNotification userInfo: [AnyHashable : Any],
fetchCompletionHandler completionHandler:
@escaping (UIBackgroundFetchResult) -> Void) {
// Check if this is a remote command
let (isCommand, command) = RemoteCommand.parseRemoteCommand(userInfo: userInfo)
if isCommand {
executor.run(command: command)
}
completionHandler(.noData)
}

73. EXECUTING
// Note: this is only a partial implementation
class RemoteExecutor {
let peripheral: CBPeripheral
let char: CBCharacteristic
func run(command: RemoteCommand) {
switch command.id {
case .checkStatus:
// Turn command into Data
let cmdData = Data(bytes: [CommandId.checkStatus.rawValue])
peripheral.writeValue(cmdData, for: char, type: .withResponse)
default:
break
}
}
}

74. RECAP
> Know your BLE basics
> Use encrypted chars, but know that the iOS BLE stack can get stuck
> Don't be afraid to resort to ObjC
> Keep your connection stable, especially in the background
> Always test at the system-integration level
> Don't trust iOS updates
> Flood the cloud with logs
> Implement remote maintenance

75. THANK YOU!
ALBERTO GUARINO
@albeguarino