IoT App Development: Devices, Cloud, Offline Sync

Building an app that talks to a physical device, a wearable, a sensor, a piece of equipment, a smart product, feels like building a normal app until it does not. Suddenly you are dealing with flaky connections, devices that sleep to save battery, firmware that needs updating in the field, and the uncomfortable reality that a hacked device is a hacked thing in someone's home or workplace. This article is the architecture that keeps an IoT product reliable and safe: how data gets from the device to the cloud, how the app stays useful when the network does not cooperate, how a device proves who it is, how you update a fleet without bricking it, and what the always-on connection everyone assumes actually costs.

The three layers, and the two hops between them

Every IoT system has the same shape: the device (the hardware and its firmware), the cloud (where data lands, is stored and acted on), and the app(where a person sees and controls it all). The design work lives in the two hops between them, because neither is a clean, always-on connection. The device-to-cloud hop is constrained by power and coverage; the cloud-to-app hop is an ordinary API until the person using it walks into a basement. Decide early which layer owns each decision: a thermostat should keep the house warm with the cloud unreachable, and a lock should open for an authorized phone with no signal at all. Local control for anything safety-related, cloud for history, coordination and anything that spans devices.

Device-to-cloud patterns

There are three common ways for a device to reach the internet, and the choice is mostly made by power budget and where the device lives.

For the network hop the common language is MQTT: a lightweight publish and subscribe protocol built for many small devices on unreliable links, which is why it dominates IoT where plain HTTP would be too heavy. A device publishes readings to a topic like site/42/device/7/telemetry and subscribes to a command topic; the broker (a managed IoT core or your own) fans messages out to whatever backend services care. Two MQTT features matter more than they look. Quality-of-service levels let you choose per message whether “fire and forget” is fine (a temperature reading) or delivery must be confirmed (a door-unlock command). And a last will message, which the broker publishes on the device's behalf if the connection dies, is how the cloud learns a device went dark without polling it. Our PulseAI concept uses the first pattern, a phone paired with a smartwatch over BLE; industrial equipment usually uses the second or third.

BLE for the phone-to-device hop up close; MQTT for the device-to-cloud stream at scale. Most products use both, and the app must be honest about which one is currently working.

Telemetry without drowning anyone

Telemetry is the firehose of readings flowing up: temperature, location, status, battery. The trick is sending enough to be useful without draining the battery or your backend. Devices should batch and back off, not chatter: sample often, transmit rarely, and send a change of state immediately while sending steady state on a slow heartbeat. Put a timestamp on every reading at the device, because it will arrive late, out of order, or in a burst after a reconnect, and the cloud must store it against when it happened rather than when it landed. The device shadow pattern (also called a digital twin) solves the mirror problem: the cloud holds a document with the device's last reported state and its desired state, the app reads and writes that document, and the device syncs with it when it can. The app then never waits on hardware: it sets “desired: locked” and shows a pending indicator until “reported: locked” catches up. The same server-streamed approach we use for the live map in Vexolis, trucks reporting up and dispatchers watching down, applies to any fleet of things; the transport choices are in our guide to real-time apps.

Offline-first sync in the app

Connectivity is never guaranteed, and the person holding the phone is often in the worst spot for it: a plant floor, a basement, a field, a truck cab. A good system assumes this. On the device side it means buffering readings locally and syncing when the link returns. On the app side it means the app is a client of its own local database first and the cloud second: every screen reads local data, every action writes locally and is queued for upload, and a sync engine reconciles in the background. That is exactly how Leak Survey Sidekick works, because the corners of a plant where compressed-air leaks hide are the corners where the signal dies, so a technician logs a leak on the device and it uploads when they walk back into coverage. The same pattern underlies our Stowly warehouse concept.

The details that separate a working offline mode from a demo:

• Client-generated ids. A record created offline needs an identity before the server has seen it, so the app mints a UUID and the server accepts it, which also makes every upload safe to retry.
• An outbox, not a retry loop. Queued changes live in a table, survive an app restart, and drain in order; a failure on one is stored with its error rather than blocking the rest.
• A conflict policy chosen per field. Last-write-wins is fine for a note and dangerous for a status; for the fields that matter, keep both versions and let the server or a human decide.
• Honest UI. Show “last synced 14 minutes ago” and “3 changes waiting” rather than pretending everything is live. Users forgive latency; they do not forgive a silent loss.

Provisioning and identity

Provisioning is the unglamorous first impression: getting a brand-new device onto the user's network and linked to their account. It is the moment most products feel either magical or broken, so it deserves real design attention and, quietly, it is also where security is decided. The common flows are BLE-assisted setup, where the app sends Wi-Fi credentials to the device over Bluetooth; a temporary access point the phone joins; and a QR code on the device that carries its identity so the app can claim it. Whichever you choose, the user should never type a Wi-Fi password into a tiny on-device keyboard, and the setup must survive being interrupted halfway.

The identity rule is absolute: every device gets its own credential, never a shared password baked into the firmware, because one leaked image then compromises the whole fleet. The strong version is a per-device certificate, ideally generated inside a secure element at the factory so the private key never exists anywhere else, with the cloud validating it on every connection and able to revoke one device without touching the rest. Claiming binds that device identity to a user account, and unclaiming on resale must wipe the association and the local data. The cloud then authorizes by identity, not by trust: a device may publish to its own topics only, and an app may command only the devices its account owns. This is the same least-privilege thinking we apply to any exposed server, with the difference that here a breach opens a door or turns off a pump.

Fleet updates without bricking anything

Over-the-air firmware updates are non-negotiable. You will ship bugs and find security holes, and a device you cannot update is a liability the day after it ships. Doing it safely is a checklist that mature products all converge on:

• Signed images. The device verifies a signature before installing anything, so it only ever accepts genuine firmware, even if the download channel is compromised.
• A/B partitions. The new image is written to a second slot and the device boots into it; if it fails to check in with the cloud after boot, the bootloader rolls back to the old slot automatically. Rollback that needs a human is not rollback.
• Staged rollout. One percent of the fleet, then ten, then everyone, with a health metric (check-in rate, crash reports, battery) gating each step. A bad image found at one percent is an incident; at one hundred it is a recall.
• Delta updates and scheduling. Send only the changed bytes, and let the device update when it is charged and idle, never mid-operation.
• A version floor. The cloud should know the minimum firmware it will talk to, so a device that has slept for a year updates before it does anything else.

The app needs its own version of this discipline: firmware, cloud API and app evolve at different speeds, and the app in someone's pocket may be a year old. Version every message, keep the API backward compatible, and never assume the three layers were released together.

The cost of always-on connectivity

“It is connected” is a feature on the box and a recurring bill everywhere else, and product owners regularly underestimate where the money goes. There is the obvious line: cellular data plans per device, and cloud messaging priced per message or per connection-minute, which rewards batching and punishes chattiness. Then the less obvious ones. Power: a persistent radio is the largest draw on a battery device, so an always-connected design can turn a year of battery life into weeks, and the fix is sleep cycles and wake-on-event, which the cloud and app must then tolerate. Storage: telemetry accumulates forever unless you downsample it, keeping seconds for a week, minutes for a year and hourly aggregates beyond. Support: every device that goes offline generates a ticket, so the app's honest “last seen” state is also a cost control. And the longest tail, the cloud service itself: the device on the shelf will still be trying to connect in five years, so the backend, its certificates and its protocol versions have to outlive the product cycle, and that has to be somebody's budget. Design connectivity as a resource to spend deliberately, not as a background assumption, and many products discover that an hourly check-in serves the user exactly as well as a live link.

A decision framework you can run in an afternoon

• Where does the device live and what powers it? Battery and a person nearby means BLE through the phone; mains and unattended means direct or via a hub.
• What must work with the cloud down? Anything safety-related is decided locally.
• How fresh must data be? Choose the check-in cadence before the protocol; it drives battery, cost and backend load.
• How does a device prove who it is? Per-device credentials, revocable one at a time, or the design is not finished.
• What happens when an update fails at 3 a.m.? Signed images, A/B slots, automatic rollback, staged rollout.
• What does the app show with no signal? Local data, queued changes, last-synced time, no pretending.
• Who pays for the backend in year five? Name the line item now.

The takeaway

IoT is normal app development plus the messy physics of the real world: intermittent connections, constrained devices, and stakes that are physical rather than digital. Design for offline from the start, choose the right protocol for each hop, make provisioning and OTA first-class, give every device its own identity, and treat connectivity as a cost you spend on purpose. Get those right and the product feels effortless to the user. Connected products sit at the intersection of the mobile apps and custom systems we build. If you are bridging hardware and software, tell us about it, or see what we have built.