IoT is a Mess - Thoughts on How to Fix It

How come building apps for IoT feels so hard when compared to building a SwiftUI or JavaScript app? I can only distill it down to two major reasons:

There is no out of the box developer experience
IoT doesn't imply that there is a user interface or a screen

The developer experience

If you compared developing for an iPhone or Android device to developing for an IoT device, you'd notice that the developer experience is vastly different. For example, if you wanted to build an app for an iPhone, you'd need to download Xcode, install it, and then create a new project. You'd then be able to run your app on a simulator or a physical device.

For IoT, a developer (or worse team of developers) would need to do the following:

Pick a platform (e.g. Raspberry Pi, Arduino, etc.)
Pick an operating system (e.g. Linux, Android Things, etc.)
Pick a runtime (e.g. Node.js, Python, etc.)
Pick a developer kit (e.g. Raspberry Pi 4, Arduino Uno, etc.)
Pick a programming language (e.g. JavaScript, Python, etc.)
Pick a framework (e.g. Express, React, etc.)
Figure out how to create a developer experience with an IDE like VSCode, JetBrains, etc.

As you can see the friction is so high that it's no wonder that IoT hasn't taken off. It's not that there aren't any IoT devices out there, it's just that the developer experience is so fragmented that it's hard to build apps for them. And when you consider this level of fragmentation, it's no wonder that a developer community hasn't blossomed. Imagine creating an IoT developer meetup, some developers will show up with a Python app running on a Raspberry Pi, others will show up with a Node.js app running on an Arduino, and others will show up with a Java app running on a BeagleBone. It's a mess.

No screen, no UI

IoT devices are basically the cousin of mobile apps. They run on the edge, in the real world. But humans are visual creatures, and we like to see things. So when you build an app for an iPhone or Android device, you know that there will be a screen and a user interface. But when you build an app for an IoT device, you don't know if there will be a screen or a user interface. And if there is a screen, you don't know what the screen size will be, what the resolution will be, or what the aspect ratio will be.

This is quite a problem in production and debugging. Let's say we build a smart home garage door controller. If the device breaks, we have no way of knowing if it's the hardware, the software, or a connectivity problem. This is why most IoT applications need to outsource a user interface to either a mobile companion app or explicitly make internet calls to deliver a user interface to a web app. This is a huge problem because it means that the developer experience is even more fragmented. Now you have to build a mobile app, a web app, and an IoT app just to control, debug or configure the device!

Most of the IoT development teams are rather lazy, they make the IoT device require an internet connection to funnel data to a web configuration plane. In my opinion this makes for some of the most horrific user experiences. I've seen smart garage doors that can only work if it's properly configured to the internet. So if just one issue happens in the client-server communication, the garage door is rendered useless.

This is a bad problem in industrial and manufacturing sectors. A friend once told me that their manufacturing robots were all powered Raspberry Pis and if anything went wrong; even things as simple as a network outage, the entire manufacturing line would be shut down. So a line worker would have to run to the lockers, find a portable monitor, keyboard, and mouse, run to the robot and plug it in and navigate to the configuration page to fix the Wi-Fi connectivity issue. This is a terrible user experience. Pretty terrible right? If you have a web configuration system, connectivity would force you to debug the issue on the ground floor.

But I'm not going to lie, getting a Raspberry Pi to communicate with an iOS app is challenging. So I sympathize with the lazy web-client approach. If it was just easier to build IoT companion apps that could communicate and configure devices without even requiring an internet connection, I think we'd see a lot more successful IoT apps in the wild.

Android Things - A missed opportunity

One of the most interesting developments in the last decade could have been Android Things. Android Things was a platform that allowed developers to build apps for IoT devices. It was a great idea introduced in 2016 as a way to bring Android APIs and services to Raspberry Pi, Intel and NXPs devices.

In my opinion it was a significant step forward for creating a canonical way for IoT developers to build apps without having to shop for a platform, operating system, runtime or developer kit. In addition, because it was a variant of Android, it would have a major ecosystem of libraries that developers could tap into Sadly it was killed by Google in 2019. Sometimes the community will take 2 steps forward and 3 step back.

Conclusion

There is an opportunity for a player to create an accessible platform inspired by Android Things for the world of IoT to address the developer fragmentation problem.
I also think there is an opportunity to create a more accessible framework allowing mobile apps to communicate directly with IoT devices without requiring an internet connection.

The problem is super clear, but a lot of software development is required. But the market is big enough that it's worth it. The game development industry has largely solved the fragmentation problem with the rise of Unreal Engine and Unity. Previously, game engines were ungodly expensive to get a hold of, and every company created a game engine from scratch. But now, many large studios pick engines like Unreal Engine, which people like you and I can easily download and use. The same thing needs to happen for IoT.