Companion apps — the app for your connected product

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.

Why companion apps are their own discipline

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.

What we do

• 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.

What we've built

• 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.

How we work

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.