IoT app development: Architecture, protocols & build guide

This guide breaks down what senior engineering teams need to ship a production-grade IoT app.

What is IoT app development?

IoT app development means building mobile and backend software that talks directly to physical hardware in real time, not just to a server sitting behind a REST API. That single difference changes the architecture, the protocol choice, and the failure modes compared with a standard app build.

Standard mobile development assumes one client talking to one backend. IoT app development has to handle hundreds or thousands of devices streaming data concurrently, usually through an IoT gateway that filters, batches, and forwards telemetry before it hits the cloud. Teams that skip the gateway layer and connect devices straight to their backend tend to rebuild that piece within the first year, once message volume outgrows what a single ingestion endpoint can absorb.

Protocol choice follows the same pattern. Most teams start with HTTP because it is familiar, then hit battery drain and connection-overhead limits once device counts climb. The MQTT protocol, the lightweight publish-subscribe standard maintained by the Eclipse Foundation, is the usual replacement because it keeps a persistent low-overhead session open instead of re-negotiating a connection per request.

In our work with connected-device fleets, the gateway design and the messaging protocol are the two decisions teams end up revisiting first once a pilot moves to production.

Number of connected IoT devices projected to reach 39 billion worldwide by 2030 (IoT Analytics, 2025), architecture that consumer app teams rarely plan for on day one. This piece covers the layers, protocol tradeoffs, vendor selection, and cost tiers behind that shift.

IoT architecture: Device, connectivity, cloud, and app layers

IoT architecture splits into four layers: device, connectivity, cloud, and application, each solving a different problem and each capable of breaking a build if the boundaries blur. Treat them as separate concerns with separate failure domains, not as one monolithic stack.

The device layer is where most cost overruns start, since device provisioning and OTA update tooling rarely ship as an afterthought without turning into a support burden six months post-launch.

Connectivity is where protocol choice matters most.

An IoT gateway aggregates dozens or hundreds of device connections onto one upstream link, and edge computing on that gateway trims raw sensor noise before it hits the network, cutting both bandwidth cost and round-trip latency. Eclipse Foundation's MQTT specification defines the publish/subscribe model most fleets standardize on, over raw REST, precisely because it tolerates flaky connections.

Cloud is where a digital twin lives: a live software model of each physical device, backed by a time-series database tuned for high-write, timestamped telemetry rather than relational lookups. AWS IoT Core and Azure IoT Hub both ship managed twin services, which is often the deciding factor in a vendor selection call.

Gartner forecasts 1.8 billion IoT-enabled consumer machine customers by 2026, growing 25% annually (Gartner, 2026)

The app layer is the only piece end users see, but it fails without the other three built correctly first.

MQTT vs CoAP vs zigbee vs BLE vs LoRaWAN: Choosing a protocol

MQTT protocol wins the fanout question for most IoT app development builds that need reliable pub/sub messaging back to a mobile app or cloud service. CoAP fits the opposite case: a constrained device on a lossy network that can't hold a persistent broker connection open.

Zigbee, Bluetooth Low Energy, and LoRaWAN sit a layer below both, they decide the radio hop, not the message contract, so the real decision tree has two levels, not one.

MQTT runs over TCP, keeps a persistent session, and supports QoS 0-2 for guaranteed delivery. The Eclipse Foundation defines exactly how a broker should handle retained messages and session state across reconnects, which is why nearly every AWS IoT Core and Azure IoT Hub reference architecture defaults to it.

CoAP skips the broker entirely, using a REST-like GET/PUT model over UDP, lighter, but with weaker delivery guarantees, which matters once a device fleet grows past a pilot.

Protocol choice also sets the cost tier. A BLE app that pairs with one smart device is the simplest build; an MQTT-based fleet wired into AWS IoT Core or Azure IoT Hub adds broker configuration, device shadows, and over-the-air update orchestration, which pushes both budget and timeline up a tier.

LoRaWAN projects spanning thousands of remote sensors sit highest, driven by gateway and network-server costs rather than the mobile application layer.

BLE remains the default when a companion app talks to a single physical device rather than an IoT application managing a whole fleet.

We recommend picking the protocol before selecting an IoT gateway or cloud partner, not after, reversing that order is how teams end up with protocol islands that a vendor selection framework should catch during the architecture review, well before any code is written.

AWS IoT core vs azure IoT hub vs Google Cloud IoT

AWS IoT Core and Azure IoT Hub are the two managed platforms actually worth shortlisting in 2026.

Google retired Cloud IoT Core in August 2023, pointing customers toward partners like EMQX and HiveMQ instead: a detail plenty of comparison posts still miss, and one that matters if you're scoping a build against outdated vendor pages.

Both surviving platforms support the MQTT protocol as the primary transport, handle device provisioning at scale, and expose digital twin state through a device shadow (AWS) or device twin (Azure) model. The differences show up in integration depth and pricing structure, not core capability.

Cost tiers scale with device count and message volume more than with feature checklist. A pilot fleet under 1,000 devices typically runs on either platform's free or entry tier; production fleets in the tens of thousands push teams toward reserved throughput pricing, where AWS and Azure diverge sharply depending on message frequency per IoT gateway.

Our vendor selection framework weighs three things before locking a platform: existing cloud commitment, in-house MQTT protocol and edge computing skills, and how the platform's OTA update tooling matches your mobile release cadence. Netguru works across both AWS IoT Core and Azure IoT Hub as an implementation partner rather than a platform vendor, which keeps the architecture decision protocol-first instead of locked to a single vendor's roadmap.

How to build an IoT app: Step-by-step process

Building an IoT app runs seven steps in sequence, from connectivity requirements through firmware to fleet-wide maintenance.

Skipping the provisioning step to save time is the single most common reason pilots stall before rollout.

1. Scope connectivity and data requirements. Decide what each device reports, how often, and over what protocol. This decision sets the ceiling on every architecture choice downstream, so treat it as a spec, not a guess: write down the message size, the send frequency, and the tolerable delay before picking a stack.

A hospital wearable sending vitals every second needs MQTT's persistent connection; a monthly meter reading tolerates REST polling.

2. Choose your architecture. Pick edge computing versus cloud-only processing, an IoT gateway topology if devices can't reach the internet directly, and a managed platform (AWS IoT Core or Azure IoT Hub) to anchor device identity and telemetry. Map each decision back to the connectivity spec from step 1 — a cloud-only architecture chosen for a fleet that turns out to need sub-second local control is the single most expensive rework in this list.

3. Build device provisioning and firmware. Device provisioning issues each unit a unique certificate and registers it against your device registry before it ships. Firmware handles the local read/write loop and exposes an update hook; retrofitting this after launch means a truck roll to every unit in the field. Build the provisioning flow to run unattended at manufacturing time, since a step that requires a human to configure each device by hand doesn't scale past a few hundred units.

4. Develop the mobile app. iOS and Android background execution limits (BLE scanning windows, doze mode) shape how often the app can sync with devices, so design the sync interval around the platform's constraints, not the ideal case. Build the sync logic to degrade gracefully when the OS suspends background access rather than assuming a live connection: queue writes locally and reconcile on the next foreground open. If this expertise isn't in-house, our mobile app development team can help navigate these platform-specific tradeoffs.

5. Test across the real device fleet, not a handful of dev boards: weak signal, battery drain, and firmware version drift only surface at scale. Include at least one device on each hardware revision and OS version in the test matrix — a fix validated on this quarter's board doesn't guarantee anything about units shipped a year earlier.

6. Deploy with staged over-the-air updates. Roll firmware and app updates to 1-5% of the fleet first, watch crash and reconnection rates, then expand (Memfault OTA Update Checklist & OTA for IoT; Arshon). According to AWS IoT Core device management documentation, staged job rollouts let teams halt a bad update before it reaches the full fleet.

7. Maintain with fleet monitoring and digital twin state. A digital twin per device catches drift between expected and reported state before it becomes a support ticket. Treat this step as ongoing rather than a launch checkbox: pairing failure rate, battery health, and firmware version distribution are the three metrics worth alerting on from day one, since they're the earliest signal of a fleet-wide problem before support tickets start arriving.

Cost tiers track this list directly: a single-protocol pilot (steps 1-4, under 50 devices) runs weeks; a production build with staged OTA and fleet monitoring across thousands of devices is a multi-quarter engagement. Vendor selection matters most at step 2, shortlist partners who've shipped provisioning and OTA at your target device count, not just a demo.

Android and iOS considerations for IoT Apps

Android and iOS handle background execution differently, and that difference drives most of the architecture decisions for iot applications that talk to devices over Bluetooth Low Energy. iOS suspends background BLE scanning aggressively. Per Apple's Core Bluetooth background execution guidance, an app can only scan for specific service UUIDs once backgrounded, not scan freely.

Developers building iot mobile applications on iOS should register known service UUIDs at launch, restore central manager state via CBCentralManagerRestoredStatePeripheralsKey, and never rely on continuous scan callbacks firing once the app is suspended.

Android gives more latitude but varies by OEM battery-management policy, so a pairing flow validated on a Pixel can silently fail on a Samsung device three OEM updates later. Any development company shipping iot application development at scale needs to test against a real device matrix, not just emulators.

BLE pairing flow design matters as much as the protocol choice. We recommend building a bonding state machine that survives app kill and OS restart, with a clear fallback to Wi-Fi provisioning when BLE handshake retries exceed a fixed threshold.

A few practical defaults for iot developers building this state machine:

• Cap BLE handshake retries at three attempts for consumer products, tighter for medical devices requiring guaranteed connection.
• Persist bonding state to local storage so reconnection survives a force-quit, not just a backgrounding event.
• Trigger Wi-Fi provisioning fallback automatically once the retry threshold is hit, rather than leaving the user stuck on a spinner.

For device fleet monitoring, log pairing success and drop-off rate per OS version and device model from day one. That data set is what separates a debugging guess from an evidence-based fix once the application development effort is live across thousands of devices and users.

Device provisioning and security: TLS/DTLS and OTA updates

Device provisioning is the weak point most IoT app development teams underestimate: the process of assigning identity, credentials, and initial configuration to a device before it ever talks to your backend. Get it wrong and you have thousands of devices with hardcoded certificates that can't be rotated without a truck roll.

X.509 certificates issued at manufacturing time, paired with a provisioning service like AWS IoT Core's Just-in-Time Registration or Azure IoT Hub's Device Provisioning Service, let a fleet bootstrap its own identity on first boot.

Neither service should be treated as optional for anything shipping past a pilot.

Transport security follows the same logic as protocol choice. TLS secures MQTT and REST traffic over TCP; DTLS covers the CoAP and UDP paths common on constrained, battery-powered devices where a full TLS handshake costs too much power. Per Eclipse Foundation, TLS on port 8883 is the baseline expectation for any production deployment, not an add-on.

Firmware update mechanics decide whether your fleet is manageable at scale. Over-the-air updates need atomic, resumable delivery with rollback: a partial flash on a device in the field, with no physical access, turns into a paperweight rather than a bug.

We recommend staging OTA rollouts in cohorts of 5-10% of the fleet, watching device health telemetry for 24-48 hours before expanding, and always shipping a signed delta update rather than a full image to cut bandwidth and radio-on time. This is where digital twin state comparison earns its keep: a mismatch between expected and reported firmware version after a rollout is the first sign of a failed batch, well before support tickets start arriving.

Cost-wise, provisioning and OTA infrastructure is usually the line item that separates a mid-tier IoT build from an enterprise-grade one.

How much does an IoT app cost?

Cost breaks into three tiers, and the biggest swing factor is where you put the processing: cloud-only, or split with edge computing.

Most IoT application development quotes hide this variable inside a lump-sum number, so it pays to ask upfront.

These figures track closely with market benchmarks for IoT MVP and enterprise IoT platform builds.

Edge computing is the tier boundary most teams underestimate. Pushing data processing onto the gateway or device itself cuts cloud transmission volume and cloud spend, but it adds firmware complexity and testing surface that a cloud-only architecture never touches.

Budget for both, not one.

When picking an IoT development company, weigh four things: MQTT and protocol expertise, provisioning and OTA track record, mobile background-execution experience on iOS and Android, and whether they have shipped a comparable device count. Experienced IoT developers treat these as one connected system, not isolated line items.

A development company that has only built consumer applications will treat your fleet as isolated islands of data rather than a single connected product. That gap shows up fastest in IoT mobile apps, where background execution and offline sync separate seasoned iot developers from generalists.

Fleet monitoring adds a recurring line item most quotes omit. Dashboards, alerting, and device health scoring scale with device count, not app screens, and every user-facing dashboard needs a data pipeline behind it.

Ask any vendor to quote monitoring separately from the initial application build, so the number doesn't hide inside a lump-sum estimate. This single request separates realistic IoT applications proposals from padded ones, and it's the fastest way to compare products across development company shortlists.

How to choose an IoT development partner

Choosing an IoT development company comes down to one test: can they show a device fleet running in production, not a proof of concept that stalled after the demo. Most application development vendors can wire a mobile app to a single sensor. Few can run a digital twin across thousands of connected devices, handle device provisioning at scale, and push over-the-air updates without bricking a percentage of the fleet.

Use a structured vendor evaluation checklist for IoT app development rather than judging on a sales deck alone. A workable checklist looks like this:

• Protocol depth: can they justify MQTT over REST for your telemetry pattern, not just build whichever protocol they already know
• Cloud IoT platform experience: hands-on delivery on AWS IoT Core or Azure IoT Hub, not slide-deck familiarity
• Mobile constraints expertise: background execution limits on iOS and Android, and how the user-facing application degrades when connectivity drops
• OTA and fleet monitoring: a documented rollout process with staged deployment and rollback, not a manual push to every device at once
• End-to-end delivery: developers who have shipped both the device-facing firmware and the consumer-facing product, since most IoT applications fail at that handoff

These five criteria exist because they map directly onto where IoT projects actually stall between proof-of-concept and production — not protocol religion or platform brand preference, but whether the vendor has solved offline resilience and cross-layer coordination before, on a fleet your size.

About 72% of IoT initiatives never progress beyond the pilot (PoC) phase into full production (EmbedThis (citing industry surveys/Gartner-related 2024).

That failure rate is exactly why the checklist matters more than the pitch.

Differentiation among IoT developers rarely shows up in a sales conversation. It shows in whether the team has actually shipped iot mobile applications where edge data collected from sensors turns into a decision a business can act on, at scale, in production.

Ask any prospective partner for one reference architecture running live, with a real device count attached, rather than ten case studies that stop at the demo stage.

IoT use cases: Smart Home, healthcare, industrial, retail

Four verticals dominate IoT app development today: smart home, healthcare, industrial, and retail. Each pushes a different split between edge computing and cloud processing, so the architecture decision starts with the use case, not the platform.

Smart home apps tolerate a few hundred milliseconds of latency, which is why most run happily on MQTT over Wi-Fi with commands routed through AWS IoT Core or Azure IoT Hub.

Healthcare devices flip that trade-off: telemetry from a patient monitor needs local pre-processing on an IoT gateway before it ever reaches the cloud, both for latency and for HIPAA-grade data handling.

Industrial deployments are where edge computing stops being optional. A digital twin of a production line needs sensor data arriving fast enough to mirror real machine state, which means inference has to happen on-site rather than round-tripping to a data center. We've built fleets where moving control logic to the gateway cut round-trip latency from seconds to under 200ms after switching off a REST polling pattern in favor of MQTT.

Retail sits closer to a data problem than a devices problem: shelf sensors, POS systems, and mobile apps each generate their own data islands, and the application layer exists mainly to stitch them into one inventory view.

The common thread across all four is AIoT: pairing edge computing with on-device or gateway-level machine learning so a digital twin doesn't just mirror equipment state but predicts failure before it happens. By 2026-60% of IoT-enabled predictive maintenance solutions will be delivered as part of enterprise reliability programs That shift, from monitoring to prediction, is what separates a mature IoT application from a dashboard.

Frequently asked questions

Build your IoT app with an experienced partner

Selecting an IoT app development partner comes down to one question: has the team shipped device fleets at scale, not just prototypes?

Look for developers who have handled provisioning, OTA rollouts, and edge computing pipelines across multiple industries.

These are the architecture decisions your roadmap probably hinges on right now.

Strong IoT development teams understand how users interact with connected products in the field, not just how the backend performs in a lab. Netguru engineers have built on AWS IoT Core and Azure IoT Hub across retail, robotics, and industrial deployments, work that mirrors the tradeoffs most iot mobile teams face today.

We saw this in practice with Żabka: a 24/7 shopping experience delivered at scale through a connected backend. If your team needs a partner to design and manage that kind of infrastructure, our IoT infrastructure development services team can help you weigh the options.

Whether your roadmap centers on a single smart sensor or a multi-thousand-device rollout, the vendor selection framework matters more than any single tech stack. Evaluate protocol choice, data transmission needs, and long-term maintenance cost before writing a line of code. Ask any development company to show proof that its IoT developers have solved similar problems for comparable applications, such as case studies, reference clients, or measurable results.

Get an estimate for your project and compare how different approaches to application development would shape the IoT applications you're planning to build.