Building a Companion App for a Smart Device: Architecture and Pitfalls

For a hardware company, the app is part of the product. A beautifully engineered device with a frustrating app gets one-star reviews, because customers don't separate the two. And companion apps fail in ways ordinary apps don't: a device that won't pair, data that arrives late, a firmware update that bricks something, a support team that can't tell what happened.

This guide covers IoT app development from the companion-app side: the architecture that works, onboarding and pairing, how data flows from device to phone to cloud, firmware updates, commerce around the device, and the store rules that apply. It draws on two kinds of hardware-adjacent apps I've built: SuraSole Golf's smart-insole app and Bartesian's commerce app for its cocktail machine.

Key takeaways

• Treat the app, the firmware and the cloud as one product, with a shared protocol document and versioning between them.
• Onboarding and pairing decide first impressions. Design them like checkout: few steps, clear errors, recovery paths.
• Plan connectivity explicitly: Bluetooth to the phone, Wi-Fi to the cloud, or both, and what happens when each is missing.
• Firmware updates are a core feature, not an afterthought, and must be resumable and safe.
• App Store rules have special cases for hardware, such as features enabled by a physical product without in-app purchase.

What is IoT app development?

IoT app development means building the software around a connected device: the mobile app people use to set it up and control it, the cloud services that store its data and push updates, and the protocols that connect them. The app is usually the product's front door, so pairing, reliability and support decide how customers judge the hardware itself.

Choosing the connection model

The choice shapes everything else, so make it with the hardware team early.

Onboarding and pairing

The first five minutes with a device decide its rating. Good onboarding:

1. Explains why permissions are needed (Bluetooth, local network, sometimes location) before asking.
2. Shows the device's own state ("Hold the button until the light blinks blue") with clear visuals.
3. Finds the device automatically by filtering for your product's identifiers.
4. Handles failure gracefully: Bluetooth off, device out of range, already paired to another phone, weak Wi-Fi.
5. Confirms success with something tangible, such as a live reading from the device.

For Wi-Fi devices, provisioning (getting the home network credentials onto the device) is usually done over BLE during setup, then the device connects directly.

Data flow and storage

• Define a versioned protocol between firmware and app (commands, data packets, error codes), documented in one place both teams maintain.
• Buffer and timestamp data on the device when the phone isn't connected, and sync it when it is.
• Store readings locally on the phone first, then upload to the cloud through a queue, so nothing is lost on bad networks.
• Decide what the cloud is for: history, sharing, analytics, support diagnostics, multi-device access.

From the field: For SuraSole Golf I built the app for pressure-sensing smart insoles: BLE pairing, background reconnect and real-time plantar-pressure streaming from both feet, rendered as live heat maps and weight-shift charts at 60fps and synced against captured swing video. For Bartesian I built the companion commerce app around its cocktail maker: a 40+ capsule catalog, subscribe-and-save, member pricing and a loyalty programme. Both show that a companion app is as much about the experience around the device as the connection to it.

Firmware updates

Over-the-air firmware updates are how you fix bugs and add features after devices ship:

• Ship the update path in version one, even if the first update comes much later.
• Use the chip vendor's update mechanism where it exists (many BLE chips have proven update libraries).
• Verify before installing (signatures and checksums), and keep a fallback image on the device if the hardware supports it.
• Make updates resumable, with clear progress and instructions not to walk away.
• Roll out gradually, just like app releases, and watch failure rates.

Commerce around the device

For many hardware businesses, recurring revenue comes from consumables and memberships: capsules, filters, refills, premium features. The companion app is the natural place to sell them:

• Subscribe-and-save for consumables tied to usage.
• Member pricing and loyalty points that reward owners.
• Smart reminders based on usage data (only with clear consent).

Physical goods like capsules use your own payment methods (Apple Pay, cards). Digital premium features in the app generally use in-app purchase, with Apple's guideline 3.1.4 allowing features that depend on specific hardware to be enabled by that hardware.

Support and diagnostics

Hardware support teams need facts, not guesses. Build in:

• A device information screen (model, firmware version, battery, connection status).
• Exportable diagnostic logs the user can send with one tap.
• Crash reporting and connection-event logging in the app.
• Remote configuration to change behaviour without an app release when a firmware issue appears.

Building for Android phones

Android is where IoT apps meet the most variety. Request the Android 12+ Bluetooth permissions (BLUETOOTH_SCAN, BLUETOOTH_CONNECT) and location permission on older versions, run long sessions in a foreground service, and test on several manufacturers, because some ship aggressive battery optimisation that stops background connections. Tell users how to exempt the app from battery optimisation when the feature truly needs it.

IoT app development cost

As planning ranges: a companion app that pairs over Bluetooth, controls the device and shows its data typically takes 600 to 1,000 hours. Add a cloud backend with device data, dashboards, user accounts and firmware updates, and a full platform runs 1,200 to 2,500+ hours. The biggest cost drivers are the number of device models and protocols (BLE, Wi-Fi, MQTT), Wi-Fi provisioning, firmware update flows and the amount of testing on real hardware.

Choosing an IoT app development partner

Look for apps they've shipped for real hardware, not demos. Ask how they test pairing and reconnection across phone models, how they work with firmware engineers on the protocol, and how they handle firmware updates that fail halfway. A partner who asks for a device sample and a protocol document in the first week is a good sign.

Store review for hardware apps

Reviewers almost never have your device. Provide a clear explanation in the review notes, a video of the full flow, and ideally a demo mode that simulates the device. Without these, "we couldn't test the app" (guideline 2.1) is a common outcome.

FAQ

How do I build an app for an IoT device?

Decide the connection model with the hardware team (Bluetooth, Wi-Fi or both), define a versioned protocol between firmware and app, design onboarding and pairing carefully, store data locally and sync to the cloud through a queue, and build firmware updates and diagnostics in from the first version.

Is React Native good for IoT and hardware apps?

Yes. React Native handles BLE through mature libraries, can render real-time data at 60fps with the right techniques, and supports native modules when a vendor SDK requires it. Many companion apps are mostly onboarding, dashboards, settings and commerce, which React Native handles very well.

How much does it cost to build an IoT companion app?

It depends on the connection model and features. Expect more than a standard app of similar size, because pairing, data sync, firmware updates and testing on real hardware add significant work. Budget explicitly for hardware testing and for a demo mode for app review.

How do I get a hardware companion app through App Store review?

Explain the device in the review notes, include a video showing pairing and core features, and offer a demo mode if possible, because reviewers usually don't have your hardware. Make sure in-app purchases follow Apple's rules, including the hardware-specific exception in guideline 3.1.4.

Next steps

If you're building a connected product and need the app side done properly, from pairing to firmware updates to commerce, I've built both kinds and can help. Get in touch, or see how I work as a React Native developer.

Sources

• react-native-ble-plx, GitHub
• App Review Guidelines (2.1, 3.1.4), Apple
• Bluetooth Low Energy overview, Android Developers
• Nordic Semiconductor: DFU, Nordic Semiconductor