Building apps that control hardware: lessons from a 20-electrode EMS suit

Apps that drive physical devices fail differently from normal apps. A dropped connection isn’t a spinner, it’s a workout that stops halfway.

OHM Fitness ran its EMS training only in studios. To grow beyond them, it needed a consumer app that could safely control the emPower Suit, a wearable with 20 electrodes, and keep members engaged at home. These are the lessons from building it.

What we learned building OHM at Home

• Pairing must be one tap, with clear recovery when it fails.
• Control commands need acknowledgements and timeouts, never fire-and-forget.
• Safety limits live in both firmware and app, never just one.
• Test on real devices across dozens of phone models.

Pairing people can recover from

Pairing is the first experience every user has, and the first place a connected product can fail. One tap is the goal, but recovery matters more: Bluetooth switched off, a permission denied, a suit that is not charged, or a phone that remembers an old connection. Each needs a plain message and a single next step, not a generic error.

Real-time control needs acknowledgements

A command to change intensity is not done when the app sends it; it is done when the device confirms it. Every command should expect an acknowledgement and have a timeout, and the interface should reflect what the device reports, not what the app requested. When a connection drops mid-session, the app has to decide quickly and predictably what happens next, and the device has to be safe even if the app never reconnects.

Safety limits live in two places

With wearable hardware, the firmware is the last line of defense: it enforces hard limits whatever the app sends. The app enforces the same limits in the interface, adds session rules and guidance, and never offers a setting the device would refuse. In the OHM app, session limits and intensity guardrails are built into every workout.

Permissions and platform rules

Each platform adds its own rules. On Android 12 and later, apps must declare and request the BLUETOOTH_SCAN and BLUETOOTH_CONNECT permissions, and Android’s documentation warns that once devices pair over Bluetooth Low Energy, the data they exchange is accessible to all apps on the phone, so sensitive data needs its own app-layer protection. Design the permission screens early; a denied permission is a pairing failure the user caused without knowing it.

Test on real devices

Emulators cannot test Bluetooth properly. Build a device lab covering the phone models and operating system versions your users actually own, and test pairing, reconnection, background behavior and long sessions on each.

“With hardware, reliability is the user experience.”

The result: guided 25-minute EMS sessions that work at home as well as in the studio.

The OHM at Home app is live on the App Store and Google Play, with sessions across Strength, Fat Burn, Cardio and Recovery, and a new remote membership line for the business. If you are building a companion app for connected hardware, our IoT and BLE app development and mobile app development teams can help, and our guide to native or cross-platform covers the framework decision.