Intunio builds companion apps: mobile apps that are the interface to a physical product. Bluetooth LE, WiFi, Matter, and backend in one delivery, from pairing to the App Store.
Intunio is a design and development studio in Gothenburg. The companion app is one of our most common and most appreciated types of engagement: the app that belongs to a product. It might be a safety vest, an electric motorcycle, an energy meter, or an access control system. The hardware is the product, and the app is how the user experiences, interacts with, and meets it.
Companion apps are part of our app development, but with their own specific requirements. Pairing has to work on the first try, connections drop and must resume, firmware is updated over the air, and the user bought a product, not an app.

A regular app talks to an API. A companion app talks to a physical device, often over Bluetooth LE or local WiFi, and sometimes with no internet connection at all. That changes most things:
Onboarding is the moment of truth. The user has just unboxed the product. If pairing doesn't work immediately, the product gets the blame, not the app. That's why we treat the pairing flow as the most important part of the entire product, in both design and testing.
The connection is unstable by nature. Devices go out of range, batteries die, the OS throttles background processes. The app has to treat disconnection as the normal case, not an error case.
App and firmware evolve together. Protocols, versioning, and OTA updates require shared planning between the app team and the hardware team. We're used to working directly with our clients' firmware engineers.
The backend is often half the delivery. Data collection, user accounts, sharing, history, and notifications require a cloud backend that talks to both the app and the device. We build that too.
UX and design for connected products: onboarding, pairing, status views, and error handling designed for how the product is actually used
Bluetooth LE integration: pairing, GATT protocols, background communication, and the platform-specific pitfalls on iOS and Android
WiFi and local connectivity: devices that talk directly to the app over the local network, with or without a cloud
Matter and home automation: products headed for the smart home. Matter is the standard Apple, Google, and Amazon have agreed on, and we work with it
Backend and cloud: data collection, accounts, sharing, notifications, and third-party APIs
SDK integrations: maps, payments, chipset vendors' SDKs, and whatever else the product needs
Release and maintenance: App Store, Play Store, and follow-up after launch. The app lives as long as the product does
We choose the platform per product: Flutter when one codebase for iOS and Android matters most, native when the hardware integration demands it.
Swanholm Technology — companion app for a smart safety vest for construction and industrial workplaces. Bluetooth connectivity, AI-controlled alert features, and alarm configuration, built in Flutter for iOS and Android.
RGNT Motorcycles — companion app for Swedish electric motorcycles, with maps (HERE), battery status, pairing, and notifications.
Currently — app for a smart energy meter that makes household energy consumption tangible. We provided technical guidance, branding, and the app design.
Arena — access control for buildings where we went the other way: QR codes and smart locks straight in the browser, no app. The right solution isn't always an app, but the interface to the hardware is the same discipline.
What the projects share: the app isn't the product, but it is the experience of the product.
A companion app project follows the same setup as our app development: pre-study, design and technical foundation, sprint-based development, release and maintenance, with designers and engineers in the same team. We often start with a pre-study that lands the protocol choice, the platform choice, and how app, firmware, and backend fit together before a line of code is written.
A companion app is a mobile app that belongs to a physical product. It's used to configure, control, and visualize a connected device — for example the app for a fitness tracker, a robotic lawn mower, an EV charger, or a safety vest. It differs from standalone apps in that communication happens directly with the hardware, often over Bluetooth LE or local WiFi, and in that the app and firmware have to evolve in step.
It depends on the product. Bluetooth LE fits battery-powered devices close to the user. WiFi fits powered devices that need bandwidth or a direct cloud connection. Matter is right when the product needs to work in the smart home alongside Apple Home, Google Home, and Alexa. Many products combine several: Bluetooth LE for pairing and WiFi or Thread for operation. It's one of the first decisions we help you land in a pre-study.
Both. Most companion apps need a cloud backend for accounts, data collection, history, and notifications, and it needs to be designed together with the app and the device firmware, not afterwards. We build the app, the backend, and the integration between them.
Yes. We often step into existing apps for continued development or a rebuild, like when we rebuilt Swanholm's app in Flutter ahead of the iOS launch. We like to start with a product validation that maps the current state.
Yes. Intunio is based on Korsgatan 24 in central Gothenburg. For hardware companies, proximity is often genuinely practical: we need the device on the desk to be able to build the app for it. We also work with clients across Sweden, Europe, and North America.
Intunio is a design and development studio based in Gothenburg. We help companies create digital products, apps, and systems that are easy to use and built to last.






































Get in touch with us at Intunio, and we'll take it from there.