What shipping hardware companion apps teaches you about scope
Notes from building iOS apps that talk to physical products: where the schedule goes, and what to fix early.
Shailendra Kumar Ram
An app that talks to a physical product is not a normal iOS project with a Bluetooth library bolted on. The protocol is usually still moving while you build against it. The hardware behaves differently across manufacturing revisions. And the bug reports arrive as a video of a device blinking, not a stack trace.
The protocol will change after you implement it
Firmware and app development run in parallel, so the characteristic layout agreed in week one is rarely the one that ships. Isolate every byte-level detail behind a single protocol layer that the rest of the app never sees. When a field moves or a command byte changes, that should be a small edit in one file, not a search across the view models.
Buy the older hardware revision
Test devices tend to be the newest build, which is the one your users are least likely to own. Earlier revisions run older firmware, negotiate smaller MTUs and respond more slowly. They also surface timing bugs that never appear on current hardware. Keeping one of each revision on the desk is the cheapest QA available on this kind of project.
Instrument the connection itself
Crash reporting says nothing useful about a connection that succeeded and then went quiet. What you want on hand when a support ticket arrives:
- Time from scan start to first discovery, and how often that times out.
- Disconnect reasons, grouped. User-initiated, out of range and supervision timeout are three different problems.
- Retry counts per session, which reveal a degrading connection long before anyone reports it.
Where the schedule goes
Most of the schedule goes to what happens after the connection drops, not to making it work in the first place.
Connect, read, write and display is usually a small fraction of the work. The rest is reconnection after backgrounding, state restoration when iOS relaunches the app, what the UI shows while the device is out of range, and which failures are worth interrupting the user for. Scope that recovery behaviour alongside the feature, not after the first round of testing. It is the biggest single difference between an estimate that holds and one that doubles.