What do app developers need to know about the future of the IoT?

Connected devices are no longer a niche category. Smart speakers, fitness trackers, baby monitors, thermostats, and sleep sensors are all ordinary parts of people's lives, and the apps that sit alongside them have become the primary interface for all of that hardware. The app is where the experience actually lives. The device collects. The app makes sense of what it collected, surfaces it in a way the user can act on, and holds the relationship together over time. That is a fundamentally different job from building a standalone mobile product, and it asks different things of the people building it.

The app is where the experience lives, not where the data is collected.

We have been working on connected product design for long enough to know that the technical complexity is rarely what trips teams up. What trips them up is the gap between how they imagine the hardware-software relationship will work and how it actually works once real devices and real users get involved. That gap tends to reveal itself late, under pressure, and in places that are expensive to fix.

There are now over 21 billion connected IoT devices worldwide, according to SumatoSoft, 2026. For app developers, that scale means the category is no longer optional to understand. If you are building anything in wellness, fitness, home, or lifestyle, the likelihood that it touches connected hardware is high and getting higher.

How the IoT is changing what users expect from apps

When a user pairs their fitness tracker or smart sleep sensor with an app, their expectations shift immediately. They are no longer just expecting the app to be useful. They are expecting it to know things about them that they did not have to type in. They expect it to respond to their current state, to update in real time, and to remember everything across sessions. The app is no longer a tool they use. It is a system they live inside.

This matters because the bar for what feels broken is much lower. A standalone app that is slow to load feels slow. A connected app that fails to reflect what the device just measured feels wrong in a more personal way, because the device was measuring something about the person. When the app does not reflect that, users feel unheard, not just inconvenienced. The emotional weight of that failure is heavier than the technical cause would suggest.

Approximately 75% of fitness app revenue now comes from subscription models that rely heavily on IoT-powered features such as real-time biometric feedback and adaptive coaching, according to Business of Apps. Users are paying for the integration. They are paying because the connected experience is more valuable than the app alone. That means the connected features are no longer a bonus, they are what the product actually is.

The hardware-software contract: defining how app and device communicate

The relationship between a companion app and its hardware is not automatic. It has to be designed explicitly, which is something teams often underestimate when they begin. The assumption is that Bluetooth or Wi-Fi will handle communication in a fairly standard way, and that the main work is on the app side. In practice, the communication layer between device and software is where projects run into the most serious technical problems.

We worked on a baby monitor product where the client was building both the physical hardware and the companion app simultaneously. The original plan was to use off-the-shelf Bluetooth protocols, which sounded straightforward at the outset. As the project developed, the integration turned out to be far more complex than anticipated. We ended up defining a formal contract between the software and the hardware that specified exactly how the app would communicate with the device. That covered turning things on and off, retrieving sensor data, and accessing camera feeds, all structured in a format the app could actually consume.

Without that formal definition, both teams would have been building towards their own assumptions about what the other side would produce. The hardware team would have made choices about data formats, connection handshakes, and error states that the app team could not predict. Defining the contract early forced both sides to agree on the interface before either side built too far in a direction the other could not support.

Define the hardware-software contract as a written specification before either team writes production code. It should cover connection protocols, data formats, error states, and expected latency. Review it jointly with both the hardware and software teams so disagreements surface on paper rather than in integration.

Testing IoT integrations before the hardware exists

One of the practical challenges in connected product development is that the hardware and the software are often being built at the same time. The app team cannot wait for finished devices to start testing. If they do, integration happens under pressure, at the end of the schedule, with no room to fix what is wrong.

On the baby monitor project, we built a prototype that simulated the hardware by running a web server from the device. This let us connect to it, inspect its internal state, verify that settings being applied in the app were correctly reflected in the device, and control the device through the app simultaneously. It was effectively a simulation of the full communication loop between hardware and software, built before the final hardware existed in its finished form.

You can simulate the full communication loop long before the hardware is finished.

This approach lets the app team test real logic rather than hypothetical logic. They can see what the app does when a connection drops mid-stream, when a sensor returns an unexpected value, or when a command does not receive a confirmation. Finding these edge cases in a simulated environment costs a fraction of what it costs to find them after final hardware has shipped.

The discipline required is front-loading the integration work rather than treating it as something that gets sorted out at the end. Teams that build the simulation early find the problems early, and that is a straightforward time and cost advantage.

Build a hardware simulation as early as possible in the project, even a simple one. A device that runs a local server and returns predictable responses is enough to begin meaningful app-side integration testing without waiting for finished hardware.

Data, sensors, and real-time state: what apps need to handle differently

A standard mobile app manages user input and stored data. A connected app manages all of that plus a continuous stream of data arriving from external sensors it does not control. The device might send readings every second, or it might send them in bursts, or it might stop sending entirely because of a connection problem. The app has to handle all three of those situations gracefully, without confusing the user about what is happening.

Real-time state introduces a category of problem that does not exist in offline or server-driven apps. The app has to decide what to display when the latest reading has not arrived yet. It has to decide how to handle a reading that looks anomalous. It has to decide how long a cached value can be treated as current before it becomes misleading. These are design decisions with real emotional consequences for users, because the data is often about their body or their home or their child.

• Define a clear freshness window for each data type, so the app knows when to show a reading as current versus stale.
• Handle partial data explicitly, show what is known rather than waiting for a complete picture that never arrives.
• Log sensor anomalies and distinguish between a bad reading and a lost connection, so error states are accurate.
• Test the app under realistic latency conditions, not just ideal ones.

The sensor data is only useful if the app surfaces it at the right moment and in a form the user can act on. Raw numbers rarely mean anything. The design work is in the interpretation layer, translating what the sensor measured into something the person using the app can understand and respond to.

Context-aware logic: using device data to drive smarter app behaviour

One of the things connected devices make possible is an app that responds to the user's actual situation rather than just their actions. The device knows where the user is, what their heart rate is doing, how long they have been asleep, or what the temperature in the room is. The app can use that information to change what it shows, when it shows it, and what it suggests.

We used this kind of contextual reasoning on a concierge app for a premium property development. Rather than sending all new residents the same onboarding notifications on the same schedule, we designed a dynamic timing system based on focus group research into how people actually behave when moving home. Someone who arrived in the morning was likely to begin unpacking that day. Someone arriving in the evening probably would not unpack until the following morning. A single person moving in alone would take longer to settle than a household of two or three. The notification timing adjusted based on arrival time and the number of occupants, so the messages arrived when they were actually relevant rather than when a fixed timer said to send them.

That is what context-aware logic looks like in practice. The underlying data points are simple. The reasoning about what they mean for the user's current state is where the experience gets genuinely useful. The device or the onboarding data provides the signal. The app decides what to do with it in a way that feels personal rather than automated.

Map out the contextual states your device data creates before you design the notification or content logic. A user in a specific state should receive a different response from the app than a user in a different state, even if they would otherwise be at the same point in the product flow.

Security and privacy in connected app design

Connected apps handle data that is more personal than almost anything else a mobile product collects. Location, biometrics, sleep patterns, home occupancy, and health readings are all categories of information that require careful handling for compliance reasons and because users feel the exposure even when they cannot articulate exactly why.

We encountered a clear version of this on a fitness social app that was originally designed to show users' real-time locations on a map so they could find workout partners nearby. Once research revealed that a high proportion of users would be female, precise location sharing became a significant safety concern. We redesigned the feature around randomised location offsets so users could see only the general area where a potential workout partner was located. Users could then review profiles and have a conversation before choosing to share their exact location. The opt-in approach preserved the core value, enough proximity information to judge whether a meetup was realistic, without removing the safety layer that made the feature acceptable to use.

The lesson is not just about location. Any connected app that collects sensor data needs to think through what that data could reveal, who can access it, and what happens if it is intercepted or misused. These questions belong in the design process, not in the compliance review at the end.

Designing for failure: connectivity loss, latency, and edge cases

Connected apps are only as reliable as their connections, and connections fail. Bluetooth drops. Wi-Fi drops. The device loses power. The server times out. An app that only works when everything is working is not reliable enough for users who have come to depend on it. Approximately 20% of mobile app crashes are correlated with network problems, according to Appwrk. For connected apps, where the network relationship includes the device as well as the server, that number is likely higher in practice.

Designing for failure means deciding in advance what the app should do in each degraded state. Some decisions are technical, cache the last known value, queue commands and retry, display a connection status indicator. Some are design decisions about what the user should understand when something is not working, and how alarmed they should be. A baby monitor app that shows nothing when the connection drops is worse than one that shows the last recorded state with a clear timestamp.

1. Identify every state where connectivity between the app and device can be absent or degraded.
2. Decide what to show the user in each of those states, cached data, a status message, or both.
3. Test those states deliberately during development, not just as an afterthought.
4. Make reconnection smooth and automatic, so users do not have to intervene to restore the session.

The 78% of enterprise developers who consider offline functionality very important when choosing a development platform, as reported by LinkedIn Pulse, understand this intuitively. Offline and degraded-connectivity handling is core product work, not an edge case to address after launch.

Platform fragmentation and protocol decisions

Connected apps operate across a wide range of hardware platforms, operating systems, and communication protocols. A device that works reliably on Android 13 and Bluetooth 5.0 may behave differently on an older iOS version or a different chipset. Protocols that are well-suited to low-power sensors, such as Zigbee or Z-Wave, behave differently to protocols optimised for bandwidth, such as Wi-Fi. The choice of protocol is not just a technical decision, it shapes what the app can do, how often it can do it, and how much power the device consumes doing it.

Protocol decisions made early in a project are difficult to reverse, which is why app architecture design needs to account for them from the outset. Testing across the full range of devices and OS versions that your users will actually have is the only way to know whether the protocol choice holds up in practice. Building in protocol abstraction, where the app communicates with a middleware layer rather than directly with device-specific implementations, makes later changes less expensive.

Where emotional and environmental design intersect

The user's emotional state when they open a connected app is shaped by what happened just before they opened it. They have just woken up and looked at their sleep data. They have just finished a workout and their tracker recorded something. They have just heard an alert from a sensor in their home. The emotional context arriving at the app is not neutral, and the design has to account for that.

This is something we think about carefully across connected product work. The user journey begins before the app opens. What the device measured, and what the user understands about that measurement, defines the emotional state they bring to every interaction inside the app. If the sleep data was bad, they may feel anxious or frustrated before they have tapped anything. If the baby monitor flagged something overnight, they arrive in the app under stress. Designing as though users arrive in a calm, neutral state is designing for the wrong user.

The emotional dimension also extends to how the app handles data that might worry users. A reading that looks unusual needs careful framing, enough information to be useful, not so much alarm that it sends someone into a spiral at six in the morning. The app's tone, the language it uses to describe sensor readings, and the visual weight it gives to different data points are all decisions with emotional consequences.

Connected design is also environmental in the literal sense. The user might be checking the app in bed, in the gym, in the kitchen. The context of use shapes what information is most useful, how much cognitive load is reasonable, and what the interaction model should look like. An app designed purely for a seated, focused user will feel clumsy when someone is checking their fitness data mid-workout with one hand free.

Conclusion

Building a companion app for a connected device is a different discipline from building a standalone mobile product. The hardware relationship introduces complexity at every layer, communication protocols, real-time state, failure modes, security, and the emotional weight of personal data, and the teams that handle it well are the ones who engage with that complexity early rather than deferring it.

The consistent lesson across the connected product work we have done is that the gaps between expectation and reality show up at integration. Between the hardware team and the software team. Between what the prototype does and what the finished device does. Between how the team imagined failure states would work and how they actually present to users. Closing those gaps is a process that starts with defining the contract, building simulation tools, and designing for degraded states, all before a line of production code is written.

The emotional dimension matters as much as the technical one. Users arrive at connected apps carrying the context of what their devices just measured, and they leave with feelings shaped by how the app handled that data. The design has to be built for the emotional state the user is actually in, and the experience has to hold up when the connection drops, the reading looks wrong, or the notification arrives at the wrong moment.

If you are working on a connected product and want to think through where the design and integration risks actually sit, let's talk about your connected app.

Frequently Asked Questions