Before you hire for an iOS BLE integration, check these five things

ยท 7 min read

Hiring an iOS developer for a hardware integration goes wrong in a specific way. The engineer is competent, the firmware works, and the project still runs three months long. Almost always the work started before the project was ready for it, and the app developer ended up absorbing a delay that was never theirs.

What BLE integration actually contains

People scope this as connect and read data, which is the first fifth of it. The full list:

  • Scan, connect, and handle every way both can fail.
  • Pairing and bonding, if the device needs them, plus what happens when a bond goes stale and iOS still thinks it is valid.
  • GATT discovery, and caching it so reconnection is not slow.
  • Throughput: MTU negotiation, chunking, and whether writes need responses.
  • Background modes, where the rules change and the duplicates flag stops working.
  • State restoration, for when iOS kills the app while connected and relaunches it later.
  • OTA firmware update, including what happens when it is interrupted.
  • Error recovery: Bluetooth toggled off, device out of range, battery dead mid-transfer.
  • App Store review notes explaining why the app needs Bluetooth, with a demo path for a reviewer who does not have your hardware.

Estimates usually cover the first three and get ambushed by the rest. The last one alone has held up releases for a week, because a reviewer in Cupertino cannot pair with a sensor sitting on a desk in Pune.

The five things that must exist on day one

  • A written protocol document. Not a promise that the firmware team will explain it on a call.
  • Firmware in a flashable state, and a person who can flash it without a two-day round trip.
  • At least two hardware units per developer, in their hands, already through customs.
  • One named firmware contact who answers protocol questions within a working day.
  • A decision on whether Android is in scope now or later, because it changes the architecture rather than adding a port at the end.

The GATT spec is the real dependency

The single most common cause of a stalled BLE project is that the protocol was never written down. Everyone believes it exists. It lives in the head of one firmware engineer who is busy on the next revision.

A usable spec is not long. It needs the service and characteristic UUIDs, the properties on each one, the byte layout and endianness of every payload, the units, the error codes, and the expected connection lifecycle. Something as plain as this is enough to start:

Service  180D  Heart Rate
  Char   2A37  Notify      [flags:u8][bpm:u8|u16 LE]
  Char   2A38  Read        [location:u8]

Service  F000  Device Control  (vendor)
  Char   F001  Write       [cmd:u8][len:u8][payload:0..18]
  Char   F002  Notify      [cmd:u8][status:u8]  status: 0=ok 1=busy 2=bad-arg
  Char   F003  Read        [fw_major:u8][fw_minor:u8][build:u16 LE]

Lifecycle: device advertises F000 in the scan response only.
Idle timeout 90s, device initiates disconnect.
MTU: request 185, firmware caps at 158.

If nobody can produce this in an afternoon, the project is not ready to hire for yet. Writing it is a day of firmware time and it removes weeks of guessing later.

Where the time actually goes

For a typical sensor or controller integration, with hardware on the desk and a spec in hand:

  • Week one: scan, connect, discover, read. Fast, and it is the part that makes everyone optimistic.
  • Weeks two and three: the protocol layer, chunking, and the first honest look at throughput.
  • Weeks three and four: reconnection, backgrounding, and state restoration. This is where the estimate usually breaks.
  • Weeks five and six: OTA, if it is in scope. Treat it as its own project rather than a feature.
  • Ongoing: field testing on real devices, in pockets, in cars, with the screen off. Nothing on a desk predicts this.

Signs you are not ready yet

  • The protocol will be finalised while the app is being built.
  • There is one prototype unit and it lives with the hardware engineer.
  • Nobody can say whether the device supports bonding.
  • The firmware contact is a company rather than a person.
  • OTA is assumed to work but no one has confirmed the bootloader can resume an interrupted update.

None of these mean stop. They mean spend a week closing them before you start paying someone to wait. An app developer blocked on a firmware answer costs exactly the same as one who is writing code.

A day of firmware writing down the protocol saves a month of an app developer inferring it.

If you want a second opinion on whether your integration is ready to scope, send over the protocol document and the device description and we can go through it.