Real-Time Data: What "Live" Actually Costs in Mobile

Real-time is one of the most overloaded terms in IoT product specs. To a user, live data means the number on screen reflects what the sensor is measuring right now. Architecturally, what that means depends entirely on the update frequency, and the frequency determines the cost.

• Sensor data updating every 500ms or faster: WebSocket or MQTT with QoS 0. Acknowledgment overhead at this frequency is not worth the latency it adds.

• Data updating every 1 to 10 seconds: MQTT with QoS 1, or SSE from the cloud. Reliable, lightweight, scales without infrastructure complexity.

• Data updating every 30 seconds or slower: HTTP polling. Simple to build, easy to debug, zero persistent connection overhead.

The UX question matters as much as the technical one. Users reading a temperature sensor do not need 500ms updates. A surgeon monitoring a patient's oxygen saturation does. The polling interval should match the actual decision speed of the user, not the capability of the device.

Displaying raw sensor values is also rarely the right design. A number changing 20 times per second is noise, not information. The mobile layer should smooth, aggregate, or threshold the data before rendering it. This is a product decision, not a performance optimization.

For apps that need to display historical data alongside live values, a time-series backend such as InfluxDB, TimescaleDB, or Amazon Timestream is the correct call. Storing sensor events in a relational database produces query performance problems the moment a user asks to see the last 30 days at high resolution.

Offline Behavior: The Decision Most Teams Make Too Late

Every IoT mobile app will be used somewhere with unreliable connectivity. Warehouses, construction sites, hospital floors, rural areas, and subway cars are all common deployment environments. The question is not whether the app should handle offline scenarios. The question is what it should do while it cannot reach the backend.

Three viable strategies exist, and the choice depends on what data the user needs to act:

• Read-only cache. The app stores the last known device state locally and displays it with a clear timestamp when offline. Writes are blocked or queued with explicit user notification. This is the correct default for most consumer IoT apps.

• Offline-first with a sync queue. All user actions are written locally first, queued for sync, and pushed to the backend when connectivity returns. Conflicts are resolved by timestamp or surfaced to the user. This is the correct pattern for field service apps, medical devices, and any app where the user must continue working regardless of connectivity.

• Offline-aware UI. The app detects connectivity loss and degrades its interface explicitly: disabling real-time charts and cloud-dependent commands, but keeping the user informed and functional. This is appropriate when the device itself remains accessible via BLE even when cloud connectivity drops.

In Flutter, the offline-first pattern requires a local database (SQLite via sqflite or Drift, or Hive for simpler schemas), a connectivity listener via connectivity_plus, and a sync engine that processes a queue of pending writes. The conflict resolution strategy must be decided before implementation. Adding it later is a major refactor, not a feature. Timestamp-based last-write-wins works for most consumer apps. For collaborative or safety-critical data, merge strategies or user-facing conflict UI are required.

The detail most teams miss: the sync queue must survive app restarts. Writing pending actions only to memory is not offline-first. It is offline-fragile.