Bluetooth LE IoT product architecture and development

A typical Bluetooth Low Energy system consists of several layers that need to work together. On the device side, there is hardware, either a custom PCB or a development kit used during the prototyping stage. The hardware runs a microcontroller or SoC with BLE support. On top of it, firmware is responsible for reading sensor data, controlling the device, managing power, handling product logic and managing radio communication.

The layer that usually connects firmware with the mobile application is BLE GATT. It is a communication model in which the device exposes services and characteristics. The mobile application can read values, write commands, subscribe to notifications and react to changes in the device state. A well-designed GATT structure is one of the most important elements of the entire system because it defines how the application and firmware communicate with each other.

On the phone side, there is a mobile application, for example written in Flutter, developed natively for Android and iOS or built with another cross-platform technology. The application is responsible for device discovery, onboarding, connection handling, configuration, diagnostics, data visualization and error handling. In more advanced products, the application also communicates with a backend, admin panel, database and external integrations.

This is why BLE projects are not just about designing a mobile application. Firmware, the GATT service structure, data format, security, OTA updates, connection error handling, background behavior, diagnostics and logging all need to be designed in parallel. If these decisions are made separately by different teams, the risk of integration issues, delays and costly changes at later stages increases.

Embedded software development services

Building a BLE product from hardware to mobile app? Our Poland-based team designs firmware, GATT, OTA, and companion apps—from architecture workshops to production.

Explore embedded software development services

Why GATT is so important

GATT can be treated as a contract between firmware and the mobile application. It defines what data is available, how the application can send commands, how the device reports changes and how communication works in different operating states. A well-designed GATT structure is simple, predictable, versioned and prepared for future product development.

In practice, it is worth separating configuration data, telemetry data, diagnostic information and control commands. The application should know which values it can read, which values it can write and which values will be delivered as notifications. Firmware, on the other hand, should clearly define how it reacts to invalid commands, connection errors, an older application version or an attempt to perform an operation while the device is in the wrong state.

Protocol versioning is also very important. A BLE product usually evolves over time. Firmware, the mobile application, hardware and business requirements all change. If the data format is not versioned, every update can become risky. That is why, even at the MVP stage, communication should be designed in a way that allows it to evolve safely.

OTA and DFU as a way to reduce product risk

In Bluetooth Low Energy products, firmware updates are critical. After being sold, an embedded device reaches the user, operates in different conditions, works with different phones and often remains in use for many months or years. If there is no way to update the firmware, every significant bug fix may require physical access to the device, a product return or service intervention. This creates a major business risk.

OTA, or over-the-air update, allows firmware to be updated wirelessly, most often through a mobile application. DFU, or device firmware update, is the process of safely installing new firmware on the device. In a well-designed product, the update process should include firmware signing, version control, handling interrupted connections, checking the battery level and the ability to recover the device after a failed update.

For an MVP, OTA updates may seem like an extra feature, but in practice they are one of the most important mechanisms for reducing risk. They make it possible to test the product faster, fix issues after a pilot deployment, develop new features and react to problems without replacing hardware. That is why, in BLE projects, OTA should be planned from the beginning, even if the first product version has a limited scope.