A companion app that stays connected
even when the device goes offline for a minute
An IoT companion app's hardest job is handling a device that drops its connection constantly. Bluetooth range, Wi-Fi hiccups, a battery saver killing a background process. The app still has to avoid confusing the user about whether the device is actually working. We have written native Kotlin and Swift modules for exactly this kind of flaky, OS-throttled background behavior.
The part that actually breaks
An IoT companion app pairs with a connected device: pairing it, showing live status and telemetry, pushing alerts, handling firmware updates. It is built specifically for the thing every IoT app eventually struggles with. A connection drops constantly, and a user needs to trust the app’s read on whether the device is actually fine. It is for a hardware brand that needs a reliable mobile companion for a connected product, or a product team adding smart-device control to an existing app.
The part that separates a working IoT app from a frustrating one is rarely the UI. It is correct handling of Bluetooth range, OS background throttling, and battery optimization that the platform imposes whether the app wants it or not.
What’s in the build
Device pairing covers Bluetooth, Wi-Fi provisioning, or both, built to fail gracefully and retry sensibly, rather than leaving a user stuck on a spinner. Live status and telemetry get shown with honest handling of a dropped connection. The app tells the user clearly when it last heard from the device, rather than showing a stale reading as if it were current. Alerts tie to real device events, a threshold crossed, an error state, not constant pings that train users to ignore notifications.
Firmware updates ship with rollback safety, since a failed update on a connected device can be far worse than a failed app update. Where the platform’s Bluetooth or background APIs require it, which is often, we write native Kotlin and Swift modules. We do not force a cross-platform abstraction to do something it genuinely cannot do reliably. This is the same approach behind native wallpaper and widget modules we have shipped and had independently reviewed for race conditions.
We also build in the detail that determines whether an IoT companion app stays usable past the first weeks of ownership. A device-health history lets a user see whether a connection problem is new or recurring. A clear onboarding flow handles re-pairing a device after a factory reset or a phone change. Remote diagnostics let your support team see a device’s recent status without asking the user to describe a blinking light over a support ticket. Where multiple family members or coworkers share access to the same device, permission levels control who can change settings versus who can only view status.
How we build it
- Understand the device’s actual communication protocol. Bluetooth, Wi-Fi, or a vendor SDK, before assuming a cross-platform library covers it.
- Build pairing and reconnection logic to fail gracefully. Retries and clear status, not a stuck spinner.
- Write native modules where the platform genuinely requires them. Background behavior and Bluetooth are the usual trigger for this.
- Build firmware updates with rollback safety. A failed update should never leave a device bricked.
- Review native code specifically for race conditions. Background and connection-state bugs are the category’s most common silent failure.
Timeline and price
| Tier | Price | What’s included | Timeline |
|---|---|---|---|
| MVP | from $8,000 | Device pairing, live status, basic alerts | 7 to 12 weeks |
| Production | from $14,000 | MVP plus firmware update flow, multi-device support, native module hardening | 12 to 16 weeks |
| Full control, handover-ready | from $15,000 | Everything in Production plus full handover documentation for your own team or hardware partner | 12 to 16 weeks |
What you own at the end
The app, its native Kotlin and Swift modules, and the device-pairing and telemetry logic all sit under your own developer accounts. Documentation means your own team or a hardware partner can maintain it without us.
Related
See the setup and integrations service page for how we connect apps to hardware and external systems. See the internal field-staff app and inspection and checklist app pages for adjacent field-hardware builds. For infrastructure, see push notifications infrastructure. For the native-module discipline behind this build, see TaskWall’s native Kotlin wallpaper module and iOS widgets.
Shipping a connected device and need a companion app that handles dropped connections honestly? Get in touch and we will scope the native work your device actually needs.
FAQ
How much does an IoT companion app cost?
From $8,000 for device pairing, live status and basic alerts on one platform's native requirements. Firmware update flows, fleet-level admin views and multi-device support typically add $4,000 to $8,000.
How long does it take?
7 to 12 weeks depending heavily on how much native (Kotlin/Swift) work the device's Bluetooth or background behavior actually requires. We scope this honestly after seeing your device's SDK or communication protocol.
Why does this need native code instead of just React Native?
Bluetooth background behavior, battery-optimization exemptions and certain sensor APIs are platform-specific in ways React Native's cross-platform layer cannot fully abstract. We use React Native for the bulk of the UI and write native Kotlin or Swift modules specifically where the platform requires it. Skipping this step is where most IoT companion apps start failing silently.
Who owns the app and the device-communication code?
You. The app, its native modules, and the pairing and telemetry logic are yours, under your own developer accounts. Documentation lets your own team or hardware partner maintain it.
Can this show a fleet of devices, not just one user's device?
Yes. If your product needs an admin or fleet view across many deployed devices, we scope that as part of the build. It typically runs as a web dashboard alongside the mobile companion app.