Mobile App Development for Hardware Products

Mobile app development for hardware products is a different job

A companion app is not a standalone app with a Bluetooth icon on it. It is half of a distributed system: the phone is the device's screen, its setup wizard, its update channel and its support desk. Every flow that matters crosses the boundary between app and firmware; pairing, setup and updates each depend on what the device does on the other side. When two vendors own the two sides, each flow is designed twice, debugged twice and blamed on the other side once.

We build the app together with the firmware and the back end, from one senior team, so the protocol, the onboarding flow and the update path are decided once and implemented on both ends. We also build standalone mobile and web apps for product companies with no device in the loop. This page is about the app in the user's hand; the SaaS platform or admin dashboard behind it is our software development service, and the device-facing cloud of identity, telemetry and fleet updates is cloud and IoT back ends. We are not an agency that discovered hardware last year: inteRFace R&D runs software of its own, including ArduinoStudio, which generates the logic, the app and the wiring for real Arduino hardware.

Companion app development, designed with the firmware

Pairing and first-run onboarding

The first five minutes decide whether a product gets returned. A typical onboarding asks for Bluetooth permission when it is needed, scans, lets the user pick the right device among several, bonds, and hands over Wi-Fi credentials. Each step has a platform trap: Android versions before 12 required location permission to scan for BLE devices, which looks alarming for a lamp; iOS caches device names and hides unpairing in the Settings app; many low-cost Wi-Fi modules join only 2.4 GHz networks while the phone sits on 5 GHz. We design around those facts and test on the Android phones your customers actually own.

The BLE command protocol

The command protocol is the contract between the app and the device, and it outlives both. We define it before either side is written: services and characteristics, a versioned command set, how the device reports state, how large a payload can be after MTU negotiation, and how the app recovers when the connection drops mid-command. The reasoning is in BLE command protocol design for connected devices; the same discipline applies to Wi-Fi and cellular devices.

Firmware updates from the phone

Without Wi-Fi on the device, the phone is the update channel. The app fetches a signed image, streams it over BLE at a rate that turns a one-megabyte update into minutes rather than seconds, survives the user walking out of range, and resumes instead of restarting. The device verifies the signature and keeps the old image until the new one has booted and reported in, so a failed update costs a retry, not a returned unit. The device side is in OTA firmware updates: architecture, security and rollback.

Offline behavior and telemetry

A companion app has to control the device with no internet at all; the cloud is for remote access, history and sharing, never for the on/off button. We build offline-first: local state, a queue for settings changes and telemetry, and a sync that resolves conflicts predictably when the connection returns. Telemetry is designed once with the device team, so every event carries the firmware version, the app version and the phone OS, and a support ticket can actually be answered.

Native, Flutter or React Native: an honest platform choice

There is no universally right answer, and a company that always gives the same one is selling what it knows rather than what you need. Our default for a companion app is Flutter: one codebase, consistent rendering on both platforms, mature Bluetooth plugins, and a cost that lets a startup launch on iOS and Android together, with the Bluetooth and update logic isolated behind a layer the UI never touches. We build web apps in React. The alternatives earn their place:

• Native Swift and Kotlin when the product leans on platform behavior that cross-platform frameworks reach late or poorly: background BLE under strict iOS lifecycle rules, HomeKit or Matter, CarPlay or Android Auto, watch apps. It costs two codebases.
• React Native when your team already writes React for the web and will maintain the app in-house after handover. A shared language beats any framework benchmark.
• Flutter for most of the rest: consumer, installer and technician apps, and screens that must match a design system on both platforms.

Release, analytics, accessibility and maintenance

App Store and Google Play release

Reviewers at both stores will not have your hardware. Apple's review guidelines ask for demo hardware or a demo video when an app depends on a device, so a demo mode or a recorded walkthrough is planned from the first sprint. We prepare the listings, the technical half of Apple's privacy labels and Google's data safety form from what the app actually collects, TestFlight and internal testing tracks, and a staged rollout so a bad build reaches a fraction of customers rather than all of them.

Crash reporting and analytics

Crash reporting goes in before the first beta, with the Bluetooth connection state attached to every report, because a crash during pairing is the most common and least reproducible bug in this category. Analytics are a small, documented event set that answers the questions you will actually ask: how many users finish onboarding, and how many devices run the latest firmware.

Accessibility

A device app that shows status only as a color fails users with color vision deficiency, and text that cannot scale fails many more. We build with VoiceOver and TalkBack labels, readable contrast, text that scales, and haptic and audible feedback for device events. The screens come from our UX/UI design service when a product needs more than a developer's layout.

Maintenance after launch

An app is never done. iOS and Android ship a major release every year, Google Play raises its required target API level on a schedule, and libraries get deprecated. We offer maintenance as a monthly block of engineering hours, agreed in writing before it starts, covering OS updates, store compliance, dependencies and the firmware changes that ripple into the app.

What you receive from an app development engagement

• The app source code, build configuration and signing setup, in your repositories and under your store accounts.
• A written, versioned command protocol specification, BLE or API, that your firmware and cloud teams build against.
• The pairing, provisioning and update flows, implemented and documented, with every error state listed.
• A test plan for the connection edge cases: out of range, device reboot mid-command, two phones, app killed during an update.
• Store listings, privacy and data safety declarations, review notes, and crash reporting and analytics configured and documented.

You own all of it: code, protocol, designs and store listings. You keep 100% of the IP, we never take equity, and a mutual NDA is signed before any technical detail is exchanged.

How an app development engagement is priced

Everything is priced in engineering hours; you get a written quote with phases before any work starts. The ranges on our engineering services page apply here: a companion-app MVP with the core flows is roughly 150 to 350 engineering hours, and a full product with accounts, payments and polish is 300 to 650. BLE pairing, Wi-Fi provisioning and updates from the phone each add real hours. The free project cost estimator gives a range of hours in minutes, and the AI estimator on the homepage, built from our real delivered quotes, does the same from a paragraph about your product.

How a first engagement starts, and where we work

It starts with a free 30-minute call with a senior engineer. Bring the device or just the sketch. The first paid step is bounded and quoted up front: an app and protocol plan that settles the platform choice, defines the command set, maps the pairing, provisioning and update flows, and ends in a written quote with phases for the build. You can stop there and keep the documents.

We are based in Silicon Valley and work with teams across the United States, mostly remotely: the app is built in your repositories, reviews run on video with the device on camera, and prototype hardware ships by carrier. How a nationwide engagement runs is on our United States page.

If you are choosing a partner for mobile app development for hardware products, the quickest way to find out is to book the free 30-minute call. If you would rather start with numbers, run your project through the free project cost estimator and bring the result.