How should an app for a connected device be developed?
First prove the complete device lifecycle: discover, securely bind, issue a command, confirm its result, recover from failure, update, transfer, and unbind. Then choose native, cross-platform, or mini-program clients. Screen count is secondary. Without versioned firmware and protocol, unique device identity, actionable acknowledgements, recoverable OTA, and real samples, a UI estimate cannot promise provisioning, background Bluetooth, or update reliability.
Wavesteam treats samples, firmware, protocol ownership, and target networks as scheduling dependencies rather than discovering after the app is complete that the device cannot support the experience.
| Connection | Suitable device | Benefit | Constraint | Recommendation |
|---|---|---|---|---|
| Direct BLE | Low-power or local equipment without Wi-Fi | Operates nearby without cloud | Phone compatibility, permission, background scanning | Prove discovery, reconnect, transfer on target phones |
| Device-to-cloud | Appliances, cabinets, continuing online equipment | Remote control, alerts, fleet operations | Identity, message path, cloud state required | Preferred for formally operated connected fleets |
| Phone as temporary gateway | Wearables and mobile collectors | Lower device power and borrowed connectivity | Sync stops when app closes, phone leaves, or permission changes | Use only when delayed synchronization is acceptable |
| Edge gateway plus cloud | Industrial sites and protocol-rich subdevices | Local autonomy through weak networks | Extra hardware, versions, and remote operations | Use when a WAN outage cannot stop work |
Native development fits deep Bluetooth, media, background, and platform-specific work. Flutter or React Native can fit business-heavy apps after native boundaries are proven. A mini-program fits scanning, lookup, and light control but not a persistent background link. Apple's Core Bluetooth documentation illustrates permission and background constraints; cross-platform technology is not a universal percentage saving.
When separating device, connectivity, and platform responsibilities, also compare How should a remote device monitoring platform and mini-program be developed? and How should a smart pet collar app be developed?; the linked guidance adds context that should be considered in the same decision.
Treat a command as a transaction
“The user tapped open” is not “the door opened.” Generate an operation ID, authorize user and device, let the device apply local safety conditions, and record requested, accepted, executing, completed, failed, or unknown. Do not blindly retry a non-idempotent unlock or charging command after timeout. Define connectivity from heartbeat, last telemetry, network, and clock conditions rather than a socket alone.
BLE discovery does not prove binding authority. A serial number in a QR code is not secret. Locks, payments, and production controls need one-time possession evidence, relationship checks, key rotation, and final authorization at the device. Bluetooth Security Manager defines pairing, authentication, encryption, and key distribution, but the product must choose a secure method compatible with its input/output capability.
The first release covers sign-in, provisioning, binding and sharing, one core control, state and alerts, reconnect, transfer/unbind, and support diagnostics. Wavesteam tests production-candidate samples across supported OS versions and records step-level provisioning, command P95 and outcomes, reconnects, notification, OTA/rollback, and post-unbind access with firmware, app, network, sample, and window documented. MQTT can define message semantics, but business idempotency, authorization, and safe rollback remain application responsibilities.