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. At AESTECHNO, we design these apps as technical tools, not marketing collateral. Flutter for a single iOS/Android codebase, Bluetooth BLE robust and tested on 5+ devices, MQTT 5.0 to cloud backend with automatic reconnect.
Expertise led by Hugues Orgitello, electronic-design engineer and founder of AESTECHNO Montpellier (10+ years of experience, certified CAP'TRONIC instructor).
- 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. At AESTECHNO, we've developed several Flutter apps for custom IoT products.
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. We apply our CI/CD pipelines that auto-deploy to the Play Store if all tests pass, which secures deliveries by minimizing regressions.
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.
At AESTECHNO, we've developed several Bluetooth sensors for custom IoT projects. 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). We test every app with our custom Bluetooth 5.4 PAwR protocols to guarantee reliability. 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. At AESTECHNO, we routinely use Mosquitto self-hosted, EMQX managed, or AWS IoT Core depending on client constraints. We've designed a top-tier high-availability database cluster (HA) dedicated to IoT, capable of continuous sensor-fleet data ingestion.
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). See also our article on IoT cybersecurity to secure MQTT channels with TLS 1.3.
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.
At AESTECHNO, 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 (we've designed numerous products integrating batteries and BMS systems), 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.
Très bonne collaboration avec AESTECHNO ! Une équipe à la fois sympathique, efficace, flexible et réactive. Leur expertise, aussi bien en conception électronique, qu'en développement logiciel et mise au point système, a été un véritable atout pour la réussite du projet. Je recommande sans réserve.
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 delivered by us is a PCB you can manufacture at scale, certify without rework, and assemble in the factory without surprises. EMC, IPC standards and DFM are built into the schematic, not added after the prototype smokes.
Industrialization
The classic trap: a working prototype that needs six months and a re-spin to hold up in series production. At AESTECHNO, our technical signature is the opposite. DFM, IPC standards and testability are integrated into the initial schematic. The prototype is already a manufacturable board. Our designs reach series production with no industrialization rework phase: 100% CE/FCC first-pass success on 65 projects since 2022.