Mobile apps for IoT products — gateways, configuration, telemetry.
An industrial IoT product almost always needs a mobile app: initial configuration, field supervision, operator troubleshooting, telemetry uplink. We design these apps as technical tools, not marketing collateral — Flutter, robust BLE, MQTT to backend.
- Bluetooth 5.4
- MQTT 5.0
- TLS 1.3
- Material Design 3
- Apple HIG
- GDPR
Flutter — the right tool for product apps
For a product app (configuration, supervision, telemetry of a sensor or machine), Flutter is currently the best choice: a single codebase for Android and iOS, near-native performance, a mature ecosystem for BLE and MQTT, simple deployment in-house or on the stores.
Our Flutter apps are written with Riverpod or Bloc for state management, with a clear UI / business logic separation, and unit + widget tests on critical functions. Long-term maintenance (OS updates, feature additions) stays smooth.
BLE — robust, for real
Bluetooth Low Energy is notoriously temperamental: connections that time out, services that change UUID after an update, sensor-side energy management that interrupts the session. A BLE app that works on the bench and breaks in the field is a classic.
Our approach: explicit BLE state machine (not implicit), handling of every transition (connect, disconnect, automatic reconnect, service loss), tests on 5+ different Android devices and 3+ iPhones (iOS and Android have different BLE bugs — both must pass). For cold-chain products where the BLE connection can last weeks, robustness isn't negotiable.
MQTT 5.0 to backend
MQTT 5.0 (the current version) adds important features for industrial IoT: Reason Codes (structured diagnostics), User Properties (extensible metadata), Shared Subscriptions (load balancing across backend instances), Session Expiry. We routinely use Mosquitto self-hosted, EMQX managed, or AWS IoT Core depending on client constraints.
On the mobile side, the MQTT client supports automatic reconnect, QoS 1/2 for critical messages, and offline buffering for connectivity dead zones (worksites, warehouses in coverage holes).
Industrial Android gateways — cold-chain and fleet
Typical use case: an operator on patrol scans BLE sensors as they pass nearby, the app collects the data and forwards it to an MQTT backend in the background. The phone is a gateway.
We've developed industrial Android apps dedicated to cold-chain (temperature sensors placed in refrigerated trucks, real-time cold-chain verification) and fleet management. Typical constraints: Android foreground service for continuous BLE collection, local SQLite store (outbox pattern) to withstand connectivity loss, fine-grained battery management, GDPR compliance for collected data.
FAQ
- Flutter or React Native?
For a product app with intensive BLE and client-side computation, Flutter has an edge in performance and stability. React Native is still relevant if the client team already has React skills. For a mostly UI-bound app without heavy constraints, both are fine. We avoid older frameworks (Cordova, Ionic) that have BLE limitations.
- Can you publish on the App Store and Play Store?
Yes — full handling: signing, Apple profiles, store listing, version management, crash tracking (Sentry, Firebase Crashlytics). For internal apps (enterprise deployment), we also handle MDM (Mobile Device Management) and B2B signing. Count 2 to 4 weeks between final candidate and first published version.
- What's the typical duration of an IoT app project?
For a complete product app (provisioning + supervision + telemetry), count 4 to 8 months depending on complexity. UX specification phase takes 2-4 weeks. Initial development 3-5 months. Real-device testing and BLE stabilization 1-2 months. Evolutionary maintenance is a separate item that can stretch over several years.
Firmware
Industrial firmware isn't a script that works on delivery day. It's a system that has to keep running after ten years of series production, support secure OTA updates, and withstand a regulatory environment that keeps moving (CRA, IEC 62443).
Hardware
A PCB we deliver is a PCB you can manufacture in series, certify without rework, and assemble in the factory without surprises. EMC, IPC standards and DFM are baked into the schematic — not bolted on after the prototype goes up in smoke.
Industrialization
The classic trap: a working prototype that needs six months and a re-spin to hold up in series production. Our technical signature is the opposite — DFM, IPC standards and testability are integrated into the initial schematic. The prototype is already a manufacturable board.