How to Plan an iOS App for a Bluetooth Device

What the hardware changes

DetecFit connects an iPhone to custom fitness hardware. The app handles calibration, displays live sensor charts and records workouts. A connection is only one step in that flow. The user also needs to know when the device is ready to measure, when readings are arriving, and whether the session has been saved.

The DetecFit case study shows the app screens and describes the CoreBluetooth integration. Use the checklist below to work out what the same kind of product would need from your hardware.

What to bring to a first estimate

• A working prototype, its firmware version and instructions for resetting it. Include a second unit if the app needs to distinguish between nearby devices of the same model.
• The Bluetooth LE protocol for the first user flow. List the relevant services and characteristics, which values the app reads or writes, and which readings the device sends as notifications.
• Sample packets and their decoded values, with units, byte order and sampling rate. Include a command response and an error response if the protocol defines them.
• The supported iPhones and iOS versions, plus what you expect when the phone locks or the user switches apps.
• A firmware contact who can confirm undocumented behaviour and provide a new build when needed.

If the protocol is still changing, scope an initial device test. Confirm that a real iPhone can find the intended device, complete one command or measurement, and recover after the device powers off and returns.

Decide what the first release must preserve

Write down what happens to a session if the device disappears halfway through. If the hardware buffers readings, agree how the app identifies the missing range and avoids duplicate records after reconnecting. If the hardware cannot recover those readings, agree how the app shows the gap and what it saves.

Specify foreground and background behaviour separately. For example, a device may need to continue measuring while the screen is locked. Check which activity must happen on the phone during that time and which data the device can retain until the phone is available. Test the expected behaviour on the iOS versions you support. Apple’s Core Bluetooth documentation

Scope cloud sync separately from device communication. If users need their history on another phone, decide which records must sync and how the app behaves offline. The iOS development cost guide covers how integrations and backend work affect the estimate.

Test the awkward moments on real hardware

1. Start from a fresh install. Try granting and declining Bluetooth permission, then check what the user sees when Bluetooth is off.
2. Scan with two identical devices nearby. Confirm the user can identify the correct unit before starting a session.
3. Disconnect the device mid-session, reconnect and inspect the saved record for gaps or duplicate readings.
4. Lock the phone, switch apps and return. Compare what happened with the agreed requirements.
5. Run a full-length session at the expected sampling rate. Check that the display stays responsive and that the saved data matches the device output.