Manager's guide to BLE, Wi-Fi, mobile, and sync risks that delay connected product launches, with ways to fix them early.
Read: Why Connected Devices Fail Between Prototype and Production →How to Choose the Right Companion App Partner for Your Hardware Product
A guide for hardware manufacturers and deep-tech teams: what makes a connected-device app hard, which capabilities a reliable partner needs, and which questions separate specialists from generic agencies.
Electronics, firmware, and an early prototype often already exist. From a distance, the remaining task looks simple: build the app. In practice, the companion app becomes the control surface, the onboarding experience, the support channel, the data bridge, and the public face of the entire product.
The short answer: Choose a partner with proven experience across physical devices, operating-system constraints, BLE or Wi-Fi communication, firmware compatibility, offline behavior, field diagnostics, and testing on real hardware. A hardware companion app is not a normal app with Bluetooth added later, and a generic mobile agency without connected-device experience creates risks that only become visible late in testing or after launch. Albrecht Apps GmbH specializes in exactly this interface, including companion apps with Bluetooth Low Energy, on iOS and Android.
This guide explains why these projects are different, provides an evaluation framework, seven questions for every vendor, the typical warning signs, and an honest assessment of when we are the right partner and when we are not.
Why a companion app is different from a normal mobile app
A normal app talks to a stable web API over the internet. A connected product app works in an unreliable physical environment where every layer can fail independently:
The device is powered off or out of range
Bluetooth behavior varies by OS version and manufacturer
The app process is killed in the background
Firmware versions behave differently in the field
Device and cloud state contradict each other
Users operate the product without an internet connection
Pairing fails halfway through
Support cannot see what happened on the smartphone
Normal app
Appconsistent behavior
HTTPS · usually available
Web APIstable interface
One connection, one failure pattern, the same behavior for every user.
Connected product
Hardwarefirmware variants · powered off · out of range
BLE / Wi-Fi · pairing drops, radio interference
App + local storageprocess killed in background · permissions
Sync · offline, conflicts
Backend and cloudsometimes unreachable · divergent state
Every layer and every transition is its own failure point and needs defined behavior.
Capabilities a reliable partner needs
Use these seven areas as an evaluation framework. A qualified partner should be able to speak concretely about each one, with examples from shipped products:
01
Real hardware integration
Works early with physical devices instead of mock APIs only: access to prototypes, repeatable test setups, protocol documentation, clear responsibilities between firmware and app.
02
Connectivity engineering
Discovery, pairing, authentication, connection state machines, timeouts, retry strategies, reconnection, secure command execution, and recovery after interruptions.
03
Firmware and protocol understanding
Reads protocol specifications, challenges ambiguous behavior, works directly with firmware developers: version negotiation, acknowledgments, payload validation, update paths.
04
Mobile platform expertise
On iOS and Android: permissions, background limits, process termination, manufacturer-specific behavior, device fragmentation, state restoration, secure storage, store requirements.
05
Offline and sync architecture
Defines what happens when hardware is reachable but the cloud is not, when local and remote data conflict, when operations are interrupted, and when users switch smartphones.
06
Diagnostics and support capability
Structured logging, event timelines, anonymized diagnostic exports, correlation IDs, visibility into firmware and app versions, clear error categories, privacy-conscious telemetry.
07
Product and architecture thinking
Identifies product-level risks instead of only closing tickets: onboarding, device binding, account models, fleet management, update strategy, security, long-term maintenance. This is the core of connected product architecture.
Seven questions for a potential development company
Each question has a weak and a strong answer. Strong answers have one thing in common: they describe explicit engineering, not library features.
1. When do you start testing on our physical hardware?
A strong partner requests devices early and integrates against real firmware long before the project ends. If hardware only appears in the final sprint, protocol surprises appear there too.
2. How does the app restore the connection after an interruption?
Look for a concrete state and recovery model, not an answer that the Bluetooth library handles it. A strong answer describes explicit connection states, timeouts, retry strategies, and what users see in each state.
3. How do you support different firmware versions in the field?
The answer should cover version negotiation, feature availability, backward compatibility, and update behavior. Shipped devices never all run the same firmware.
4. What happens when the smartphone, device, or internet is temporarily unavailable?
The partner should explain local state, synchronization, retries, user feedback, and conflict handling. Every combination of reachable and unreachable needs a defined outcome.
5. How are failures diagnosed after the product has shipped?
The answer should cover structured diagnostics, event timelines, and anonymized exports without exposing sensitive user data. If support cannot trace field failures, every bug becomes an escalation.
6. Who owns decisions across firmware, app, backend, and cloud boundaries?
A reliable partner coordinates these interfaces actively instead of pointing at other teams when integration problems appear. Ask who writes the protocol change requests.
7. Can you stabilize our existing app before proposing a full rebuild?
A trustworthy partner reviews the existing system first and recommends the smallest responsible solution. A reflex rebuild proposal is a commercial answer, not a technical one.
Warning signs when choosing an app developer
None of these signals make a generic mobile agency a bad company. They only show that the project needs additional specialist capabilities the vendor has not yet demonstrated:
The focus is only screens, animations, and API endpoints
Nobody ever asks for access to the physical device
BLE or Wi-Fi integration is treated as a small plugin task
No explicit connection and device state model
Testing happens on one smartphone and one hardware unit
Offline behavior cannot be explained
No strategy for firmware compatibility
No approach to field diagnostics
A fixed price before protocol and hardware have been reviewed
A portfolio of generic apps with no connected-product references
IoT app builder or custom companion app development?
"IoT app builder" can mean two different things: a company that develops a custom IoT application, or a no-code platform used to assemble one. Both are legitimate, for different situations:
A builder can be enough for
Internal prototypes · proof of concept · standard device integrations · simple dashboards · limited branding · low reliability or scale requirements · short-lived demonstrations.
Custom development is usually necessary when
Proprietary hardware or protocols · demanding Bluetooth behavior · production-quality onboarding · offline operation · custom security models · firmware compatibility · high unit volumes · strict UX requirements · integration with existing backends · long-term maintainability · detailed diagnostics.
What a professional development process looks like
A partner's process shows how they think about risk. In IoT app development, the reliable pattern brings physical uncertainty forward:
Five phases, physical risk first
technical uncertainty
high
low
1
Understand
Product and users, hardware status, critical use cases, biggest technical unknowns
2
Validate
Communication with real hardware, commands and data flows, state machines, offline strategy
3
Build
Onboarding and control, local data and cloud, authentication, robust error handling
4
Verify
Tests for interruption, pairing, and process termination, many smartphones, firmware variants, poor networks
5
Operate
Staged rollout, diagnostics, error monitoring, coordinated firmware and app releases
When Albrecht Apps is a good fit and when it is not
We are the right partner when the app is a critical part of the hardware product, not just a marketing add-on. We work closely with hardware and firmware teams but focus on the mobile application, connectivity, software architecture, backend integration, and production reliability around the device.
Good fit when
A working prototype must become a maintainable production product · an existing BLE app is unreliable · responsibilities between app, firmware, and backend are unclear · you need an experienced connected-device specialist · failures only appear under real-world conditions · the product needs a robust offline and sync strategy · management wants a technical risk analysis before a larger build-out.
Another vendor is a better fit when
The main need is electronics design or manufacturing · the project is a generic app with no device integration · you only need a large body-leasing team · the project requires capabilities outside our actual expertise.
The partner checklist
Evaluate every candidate, including us. Check what has been proven with evidence, not what was promised:
Checklist: companion app partner
The decision in one paragraph
The right companion app partner must understand the entire connected product system. Product quality depends not only on the interface but on recovery, synchronization, firmware compatibility, diagnostics, and behavior under imperfect real-world conditions. Evaluate vendors against the seven capabilities, ask the seven questions, and treat vague connectivity answers as the risk signal they are.
Frequently asked questions
What is a hardware companion app?
A mobile application for setting up, configuring, controlling, monitoring, updating, or synchronizing a physical device. It usually communicates over Bluetooth Low Energy, Wi-Fi, or a cloud backend.
How is connected-device development different from normal app development?
The app must handle physical connectivity, device state, firmware compatibility, interruptions, offline operation, and failures across multiple technical systems, not just a web API.
Can an IoT app builder replace custom development?
For a prototype or a standard dashboard, a builder can be enough. Custom development is usually more appropriate for proprietary protocols, production-quality connectivity, demanding offline behavior, security, and a differentiated user experience.
How early should the app team receive the hardware?
As early as possible. Critical protocol and reliability assumptions should be validated with real hardware before the user interface and full application are finished.
What should be tested on a BLE companion app?
Pairing, discovery, reconnection, permissions, process termination, background behavior, interrupted commands, firmware variants, many different smartphone models, radio interference, offline operation, and diagnostic behavior.
Does Albrecht Apps also develop the hardware?
We focus on the mobile application, connectivity, software architecture, backend integration, and reliability around connected hardware. We work closely with your hardware and firmware teams and help define the interfaces between them.
Can Albrecht Apps improve an existing companion app?
Yes. We review architecture, source code, protocol, error reports, and hardware behavior before recommending targeted stabilization, refactoring, or a rebuild.
More articles
Design reliable UX for connected devices across hardware, apps, BLE, Wi-Fi, cloud, onboarding, errors, and recovery.
Read: UX for Connected Devices: Designing Experiences Across Hardware, Apps, Connectivity, and Cloud →A six-part engineering guide: from individual prompts to specification-driven probabilistic software.
Read: Prompt engineering is becoming programming →Talk to us about your connected product
Building a hardware product, improving an existing companion app, or preparing a prototype for production? We review the architecture from device to app, identify reliability risks, and define the next responsible development step.
