A companion app for a physical product fails differently than a normal app. The bugs that reach customers are almost never a misaligned button. They are: the app connects on an iPhone but not on a three-year-old Android; the connection drops when the phone locks and never comes back; a firmware update leaves the device in a state the app does not recognize; a user walks out of range mid-sync and the app shows stale data forever. None of these appear in a simulator, because a simulator has no radio.
QA on a hardware companion app therefore costs more and starts earlier than on a pure software product. Teams that treat it as a week at the end ship a one-star rating alongside a working device.
Build the test matrix first
Three dimensions multiply, and pretending otherwise is how coverage gaps happen.
- Operating systems. Current and previous major versions of iOS and Android at minimum. Permission behavior, background execution limits, and Bluetooth scanning rules change materially between versions, and code that works on one is routinely blocked on another.
- Physical devices. Not just flagships. Bluetooth stacks from different chipset vendors behave differently, aggressive battery-optimization layers from several Android manufacturers kill background connections outright, and low-RAM devices expose race conditions fast phones hide. A working minimum is six to ten physical handsets spanning current flagships, mid-range devices a few years old, one deliberately weak device, and both screen sizes on each platform.
- Firmware versions. The one software teams forget. Once units are in the field, multiple firmware versions are live simultaneously and the app must work with all of them. Keep a rack of devices flashed to each supported release, including the oldest you promised to support.
Keep the matrix in version control next to the test plan, and make adding a supported OS or firmware version an explicit decision with a cost attached.
You need a hardware test rig
Testing against one prototype on an engineer's desk does not reproduce failures. What works is a small dedicated bench: several units powered from controllable supplies, a way to force firmware versions quickly, a means of putting a unit into specific error states, and — the underrated item — control over RF conditions. A shield box or a simple attenuator reproduces weak-signal behavior on demand instead of walking down a hallway hoping the bug appears.
On the firmware side the equivalent discipline is hardware-in-the-loop testing, and the two benches should share fixtures and version labels. That is what ends "it works on my desk" arguments.
The scenarios that actually find bugs
Organize the test plan around interruptions and state transitions, not around screens. This list finds more real defects than any amount of UI walkthrough:
- First-run pairing on a factory-fresh unit. Every tester's phone holds stale bonding data. Pairing is where most users abandon a product, as covered in pairing that does not lose users.
- Re-pairing after a factory reset on either side, including when the phone still holds a bond the device has forgotten.
- Phone locked, app backgrounded, app force-killed — then the device sends data. Three different code paths on each platform.
- Walking out of range and back. Reconnection must be automatic and must not duplicate or lose queued data.
- Bluetooth toggled off and on, airplane mode, Wi-Fi lost mid-sync.
- Permissions denied and granted later — including the Android case where scanning needs location permission and the user says no.
- Battery dying mid-transaction on the device.
- Firmware update interrupted at several points, including power loss during the write. The app must recover the device, not brick it.
- Two phones, one device and one phone, several devices.
- Clock changes and long-running behavior — leave a unit connected for 72 hours and watch for memory growth and connection decay.
- Offline operation and later reconciliation, which deserves its own suite — see offline mode in a companion app.
What to automate and what not to
Automation pays off unevenly. Unit tests on the app's parsing, state machine, and data layer are cheap and valuable — mock the transport and test protocol handling hard, because malformed packets and unexpected state transitions are where firmware and app disagree. UI automation with XCUITest and Espresso is worth building for the core flows that must never break.
What resists automation is the radio. Neither iOS Simulator nor the standard Android emulator gives real Bluetooth, so connection-layer testing needs physical devices. A simulated peripheral advertising the same GATT profile is excellent for developing app logic in parallel with firmware and useless for validating radio behavior — use it for velocity, not for sign-off. Cross-platform stacks add their own layer of surprises, discussed in React Native with BLE.
Beta testing with real users
Internal QA will not reproduce a household with a microwave, a mesh router, and a four-year-old phone. Run a structured beta through TestFlight and Play Console closed testing with 20 to 100 participants who own the hardware. Give them tasks rather than asking for feedback, and add an in-app report button that captures logs and device state automatically. Store review has its own failure modes — permission strings, background mode justifications, and account-deletion requirements are common rejection causes covered in publishing an app to the App Store and Google Play.
After launch, QA does not stop
Ship with crash reporting and structured logging from day one, and define the release health metrics you watch: crash-free sessions, pairing success rate, sync completion rate, reconnection time. Then accept that the platforms will force you back into the lab: Apple and Google ship major OS updates annually with betas months earlier, and testing against those betas is the difference between a quiet fall and a support flood. That recurring work is part of the ongoing cost described in app maintenance costs after launch.
Budget and schedule
As a planning figure, QA for a hardware companion app typically consumes 20–30% of total app development effort — more than a pure software project, because of device procurement, rig construction, and the scenarios that must be run by hand on physical hardware. That maps into the ranges discussed in what a BLE app costs to develop, and it needs its own line in the schedule laid out in how long it takes to build a companion app. Start writing the test plan when the protocol is defined, not when the UI is finished.
Projects House develops connected products where firmware, app, and cloud are tested as one system on a shared bench. If your app and your hardware disagree in the field, describe the problem through our contact form.