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, without 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.
What it is and who needs it
An IoT companion app pairs with a connected device, pairing it, showing live status and telemetry, pushing alerts and handling firmware updates, built specifically to handle the thing every IoT app eventually struggles with: a connection that drops constantly and a user who 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 is inside
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 are 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 are tied 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 rather than forcing a cross-platform abstraction to do something it genuinely cannot do reliably, the same approach behind native wallpaper and widget modules we have shipped and had independently reviewed for race conditions.
We also build in the operational detail that determines whether an IoT companion app stays usable past the first weeks of ownership: a device-health history so a user can see whether a connection problem is new or recurring, a clear onboarding flow for re-pairing a device after a factory reset or a phone change, and remote diagnostics that 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 $23,800 | 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 under your own developer accounts, documented so 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, and 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, which is where most IoT companion apps that skip this step 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, documented so your own team or hardware partner can 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, typically with a web dashboard alongside the mobile companion app.