
Do you know those famous Christmas family dinners?
The ones straight out of a movie, full of relatives you might have seen just once during the year, maybe by chance at the shopping mall. Uncles and aunts who sit next to you and try to understand what you do with “computers” (and inevitably ask if you can fix something on their phone or laptop too).
Yes, I know, itās a clichĆ© from the 2000s and might not mean much to the younger crowd, but for those whoāve been there, well, itās an unmistakable emotional mix. Weāre in 2024, true, and everyone seems to be a “computer expert” now (even that aunt/uncle!), but thereās still a moment when that old feeling of “why me?” resurfaces. Itās when I have to explain what it means to work in IoT development.
The acronym is familiar: the famous Internet of Things.
But often, the magic word smart is just added to the name of a device, transforming a passive, silent object into something alive and able to communicate. Itās like giving a digital soul to the objects around us.
So, with Christmas around the corner and all the relatives getting ready to ask me what I really do with “computers,” I thought Iād practice a little and share my experience with the Codemotion community, explaining what developing for IoT really means. Or at least try to…
A few examples
Perhaps the simplest way to introduce the topic is to better define its scope. IoT might seem like a niche field, and in some ways, it is, but it has infinite facets. Itās a vast system, reminiscent of the “long tail” in the SEO world: you start with a simple flower pot, and you end up with a push notification on your phone that says: “Hey, remember to water me!”

The process covers every type of object: anything can become āsmartā and start providing data of any kind. A watch, beyond telling the time, could monitor our oxygen levels, body temperature, and the number of steps we take each day. A refrigerator could inform us about the internal temperature, the state of the food, and even remind us when itās time to toss out the milk.
A sensor next to a cluster of grapes could gather detailed data to produce the perfect Prosecco, while a bike in a ride-sharing service might have so much telemetry that a Formula 1 team would envy itāperhaps even with bidirectional communication!
As I was saying, there are endless domains and perspectives in which an object can become smart. In this sea of possibilities, itās my job to guide you through what it means to develop an IoT device, going through all the phasesāfrom prototyping to integration, and finally to managing the data that, in the end, is the true soul of every connected object.
From prototype to production
The creation of an IoT device, or āsmart device,ā begins by distilling the requirements and defining the final data it will need to provide. This preliminary analysis helps identify, broadly, the necessary sensors, required physical ports, and whether an electrical outlet or a battery will power the device.

Bill of materials
This initial phase allows us to define the Bill of Materials (BOM), which is the list of components required to create the final product. Choosing the right components is crucial: you need to consider market availability, compatibility, technical specifications, and cost. Efficient BOM management is essential to optimise production costs and ensure the device can be produced on a large scale without issues. For example, a microcontroller with multiple integrated connectivity options (Wi-Fi, Bluetooth, etc.) can simplify development but increase the per-unit cost.
The prototype
Often, an initial iteration involves creating a hardware prototype to physically validate the project and identify potential limits or issues before moving on to optimisation and scaling. Rapid prototyping platforms like Arduino, ESP32, or Raspberry Pi are commonly used to reduce initial time and costs, allowing us to test and validate concepts before transitioning to more specific and customised solutions.
Another critical aspect is the design of the enclosure, or the deviceās casing. This must be not only aesthetically pleasing but also functional and resistant to the expected usage conditions. For example, a device intended for underwater use will require certified waterproofing (e.g., IP68 standard), while one for winter sports must withstand extreme temperatures and shocks. At this stage, ergonomic and industrial design studies come into play, considering even the user interface of the device (display, buttons, visual or auditory feedback, etc.).
Cost studies
In parallel, we conduct cost studies and market analysis. Itās crucial to accurately estimate production and development costs to establish a final price and evaluate the product’s economic viability. This phase often requires assessing the expected production volumes and economies of scale. The analysis must also consider different production scenarios, including certification costs, especially for products intended for regulated industries like medical or automotive sectors.
Architecture
When it comes to communication methods, IoT devices can use different technologies, each with specific advantages and limitations:
- USB: for wired connections and power supply;
- Bluetooth Low Energy (BLE): ideal for low-power devices and short-range communication;
- Wi-Fi: for high-speed connections and local coverage;
- LoRaWAN: for devices that require long-range and low-power consumption, like sensors in agricultural or remote environments;
- IR: in some contexts, for transmitting information to dedicated optical readers (e.g., energy meters).
The choice of technology depends on the use case, the type of data the device needs to transmit, and the power supply method. Properly designing the communication architecture is essential to ensure device reliability and its ability to integrate into an existing IoT network. Additionally, itās important to consider the possibility of OTA (Over-The-Air) updates to ensure longevity and maintenance, allowing software updates and bug fixes remotely.
Communication and Data
Once my colleagues have completed the prototype and the hardware is tested, itās my turn: mobile app development. To put it simply (and maybe explain it to my uncle!), this is where we connect the physical world to the digital, translating raw data from the device into a tangible and intuitive user experience.
After validating the first prototype (even though the hardware might not be fully available at this stage), we begin verifying that what was discussed during the planning phase is being followed. However, verification is not a final process; it happens continuously, in every sprint, with periodic demos from the firmware team. This is a crucial moment: itās the equivalent of a Formula 1 “shake down,” where we test the complete system to ensure everything works correctly and identify potential issues before they become critical.

Mobile development
Our role as mobile developers for smart devices is to bridge the physical world (the device and its sensors) and the digital experience (the app). To do so, we collaborate with a range of professionals: firmware and embedded engineers, UI/UX specialists, backend engineers, AI/ML experts, mobile engineers, and QA teams. This multidisciplinary team works in synergy to create a coherent and integrated experience that perfectly connects the real world with the digital one.
Often, the interaction between the app and the device doesnāt happen through a classic RESTful API but through dedicated communication protocols that establish a direct, one-to-one connection between the smartphone and the peripheral device. Team synergy is essential, and using methodologies like fail-fast (FF) allows us to quickly identify and resolve critical points efficiently. For instance, if we notice that data isnāt arriving with the required granularity, hardware modifications might be necessary, impacting production timelines and BOM costs, requiring re-planning.
Our task as the mobile team is to connect the WHAT (data provided by firmware, backend, or calculated through AI/ML) with the HOW (the user experience designed by UX/UI teams). Although some aspects of development may resemble those of a traditional app connecting to a backend, there are unique and challenging aspects. For example, onboarding an IoT device goes far beyond the classic informational “carousel”; it requires intense user interaction through a process called provisioning.

Provisioning
During provisioning, the smart device becomes part of the userās ecosystem. Various operational modes are used for this integration, including:
- Selecting a BLE device from a list detected by the smartphone, where the user chooses the correct device;
- Temporarily connecting to a Wi-Fi Access Point (AP) to transmit network credentials and configure the device;
- Using an NFC bump to start the pairing process.
In some cases, these methods can be combined to ensure a secure and stable connection. Once provisioning is complete, the device is ready to transmit its data. If the connection is through Wi-Fi, the data is often sent to a backend that collects, analyzes, and makes it available through the app. Conversely, if the communication happens via BLE or NFC, much of the data management work is done by the smartphone, acting as a direct bridge between the device and the app.
This phase is particularly delicate because synch and updating data, especially with low-power protocols like BLE, requires special attention to transmission speed (MTU) and the amount of data to transfer. This is why we often see āsyncingā screens in apps, with duration depending on these factors.
Thereās no fixed rule on how to manage data: in some cases, data is saved directly to the smartphoneās native services, such as HealthKit for iOS or equivalent services on Android, while in other cases, a backend is needed to process and analyse the data, especially when the collected data is complex and requires deeper processing.
OTA updates
A crucial aspect of IoT development is managing Over-The-Air (OTA) updates, essential for fixing bugs, improving functionalities, and ensuring product longevity. However, OTA also represents one of the most critical phases because if something goes wrong, thereās a risk of “bricking” the device, rendering it unusable. Therefore, itās essential to design a secure and reliable infrastructure for distributing updates, minimising the associated risks.

To minimise the risk of bricking, devices must have rollback mechanisms that allow reverting to the previous firmware in case of an error during an update. Furthermore, itās crucial to implement a firmware integrity verification system, using certificates and cryptographic keys, for example, to ensure that only authorised and secure firmware can be installed.
Coordination with the QA team is vital at this stage, as a fail-fast approach allows us to quickly identify issues during the update distribution and intervene before the devices reach the users. Testing techniques include simulating updates on a large number of devices, monitoring errors, and providing immediate feedback in case of malfunctions.
TLDR;
Mobile development for IoT devices is a multidisciplinary challenge that combines hardware, software, UI, UX, and QA in a complex ecosystem.
From initial setup and provisioning to managing OTA updates, every step requires attention to detail, team synch, and a deep understanding of the technologies involved.
In the end, seeing a device come to life and work as expected, seamlessly integrating into the userās daily life, is the reward for a job well done.
Images designed by Freepik.