So wählen Sie den richtigen Companion-App-Partner für Ihr Hardware-Produkt

Ein Leitfaden für Hardware-Hersteller und Deep-Tech-Teams: Was eine Connected-Device-App schwierig macht, welche Fähigkeiten ein verlässlicher Partner braucht und welche Fragen Spezialisten von generischen Agenturen unterscheiden.

Von Andrej Albrecht Veröffentlicht 30.07.2026 16 Min. Lesezeit

Vernetzte Hardware BLE Mobile Apps IoT-Apps

Elektronik, Firmware und ein erster Prototyp existieren oft bereits. Die verbleibende Aufgabe wirkt aus der Distanz einfach: die App bauen. In der Praxis wird die Companion App zur Bedienoberfläche, zum Onboarding-Erlebnis, zum Support-Kanal, zur Datenbrücke und zum öffentlichen Gesicht des gesamten Produkts.

Die kurze Antwort: Wählen Sie einen Partner mit nachweisbarer Erfahrung über physische Geräte, Betriebssystem-Beschränkungen, BLE- oder WLAN-Kommunikation, Firmware-Kompatibilität, Offline-Verhalten, Felddiagnose und Tests auf echter Hardware hinweg. Eine Hardware-Companion-App ist keine normale App, der später Bluetooth hinzugefügt wird, und eine generische Mobile-Agentur ohne Connected-Device-Erfahrung erzeugt Risiken, die erst spät im Test oder nach dem Launch sichtbar werden. Albrecht Apps GmbH ist auf genau diese Schnittstelle spezialisiert, unter anderem auf Companion Apps mit Bluetooth Low Energy, auf iOS wie auf Android.

Dieser Leitfaden erklärt, warum diese Projekte anders sind, liefert ein Bewertungsraster, sieben Fragen an jeden Anbieter, die typischen Warnsignale und eine ehrliche Einschätzung, wann wir der richtige Partner sind und wann nicht.

Warum eine Companion App anders ist als eine normale Mobile App

Eine normale App spricht über das Internet mit einer stabilen Web-API. Die App eines Connected Products arbeitet in einer unzuverlässigen physischen Umgebung, in der jede Ebene unabhängig ausfallen kann:

Das Gerät ist ausgeschaltet oder außer Reichweite Bluetooth-Verhalten variiert je nach Betriebssystem-Version und Hersteller Der App-Prozess wird im Hintergrund beendet Firmware-Versionen verhalten sich im Feld unterschiedlich Geräte- und Cloud-Zustand widersprechen sich Nutzer bedienen das Produkt ohne Internetverbindung Das Pairing bricht auf halbem Weg ab Der Support sieht nicht, was auf dem Smartphone passiert ist

Normale App vs. Connected-Product-App

Normale App

Appeinheitliches Verhalten

HTTPS · meist verfügbar

Web-APIstabile Schnittstelle

Eine Verbindung, ein Fehlerbild, gleiches Verhalten bei allen Nutzern.

Connected Product

HardwareFirmware-Varianten · ausgeschaltet · außer Reichweite

BLE / WLAN · Pairing bricht ab, Funkstörungen

App + lokaler SpeicherProzessende im Hintergrund · Berechtigungen

Synchronisation · offline, Konflikte

Backend und Cloudzeitweise nicht erreichbar · abweichender Zustand

Jede Ebene und jeder Übergang ist eine eigene Fehlerquelle und braucht definiertes Verhalten.

Zuverlässigkeit entsteht über die gesamte Kette, nicht nur in der Benutzeroberfläche.

Diese Fähigkeiten braucht ein verlässlicher Partner

Nutzen Sie diese sieben Bereiche als Bewertungsraster. Ein qualifizierter Partner sollte über jeden Bereich konkret sprechen können, mit Beispielen aus ausgelieferten Produkten:

Integration echter Hardware

Arbeitet früh mit physischen Geräten statt nur mit Mock-APIs: Zugang zu Prototypen, wiederholbare Testaufbauten, Protokolldokumentation, klare Verantwortlichkeiten zwischen Firmware und App.

Connectivity Engineering

Discovery, Pairing, Authentifizierung, Verbindungs-Zustandsmaschinen, Timeouts, Retry-Strategien, Reconnection, sichere Befehlsausführung und Wiederherstellung nach Unterbrechungen.

Firmware- und Protokollverständnis

Liest Protokollspezifikationen, hinterfragt mehrdeutiges Verhalten, arbeitet direkt mit Firmware-Entwicklern: Versionsverhandlung, Bestätigungen, Payload-Validierung, Update-Pfade.

Mobile-Plattform-Expertise

Auf iOS und Android: Berechtigungen, Hintergrund-Beschränkungen, Prozessende, herstellerspezifisches Verhalten, Gerätefragmentierung, Zustandswiederherstellung, sichere Speicherung, Store-Anforderungen.

Offline- und Synchronisationsarchitektur

Definiert, was passiert, wenn die Hardware erreichbar ist, aber die Cloud nicht, wenn lokale und entfernte Daten sich widersprechen, wenn Vorgänge unterbrochen werden und wenn Nutzer das Smartphone wechseln.

Diagnose und Supportfähigkeit

Strukturiertes Logging, Ereignis-Zeitachsen, anonymisierte Diagnose-Exporte, Korrelations-IDs, Sichtbarkeit von Firmware- und App-Versionen, klare Fehlerkategorien, datenschutzbewusste Telemetrie.

Produkt- und Architekturdenken

Erkennt Risiken auf Produktebene, statt nur Tickets umzusetzen: Onboarding, Gerätebindung, Kontenmodelle, Flottenmanagement, Update-Strategie, Sicherheit, langfristige Wartung. Das ist der Kern von Connected-Product-Architektur.

Diesen Kreislauf muss eine zuverlässige App beherrschen

Bitten Sie einen Kandidaten, diesen Kreislauf für sein zuletzt ausgeliefertes Produkt zu erklären.

Sieben Fragen an ein potenzielles Entwicklungsunternehmen

Zu jeder Frage gibt es eine schwache und eine starke Antwort. Die starken Antworten haben eines gemeinsam: Sie beschreiben explizites Engineering, keine Bibliotheksfunktionen.

1. Wann beginnen Sie mit Tests auf unserer physischen Hardware?

Ein starker Partner fordert Geräte früh an und integriert lange vor Projektende gegen echte Firmware. Taucht die Hardware erst im letzten Sprint auf, tauchen dort auch die Protokoll-Überraschungen auf.

2. Wie stellt die App die Verbindung nach einer Unterbrechung wieder her?

Achten Sie auf ein konkretes Zustands- und Wiederherstellungsmodell, nicht auf die Antwort, das erledige die Bluetooth-Bibliothek. Eine starke Antwort beschreibt explizite Verbindungszustände, Timeouts, Retry-Strategien und was Nutzer in jedem Zustand sehen.

3. Wie unterstützen Sie unterschiedliche Firmware-Versionen im Feld?

Die Antwort sollte Versionsverhandlung, Funktionsverfügbarkeit, Abwärtskompatibilität und Update-Verhalten abdecken. Ausgelieferte Geräte laufen nie alle auf derselben Firmware.

4. Was passiert, wenn Smartphone, Gerät oder Internet vorübergehend nicht verfügbar sind?

Der Partner sollte lokalen Zustand, Synchronisation, Wiederholungen, Nutzer-Feedback und Konfliktbehandlung erklären. Jede Kombination aus erreichbar und nicht erreichbar braucht ein definiertes Ergebnis.

5. Wie werden Fehler diagnostiziert, nachdem das Produkt ausgeliefert ist?

Die Antwort sollte strukturierte Diagnose, Ereignis-Zeitachsen und anonymisierte Exporte abdecken, ohne sensible Nutzerdaten offenzulegen. Kann der Support Feldfehler nicht nachvollziehen, wird jeder Bug zur Eskalation.

6. Wer verantwortet Entscheidungen über die Grenzen von Firmware, App, Backend und Cloud hinweg?

Ein verlässlicher Partner koordiniert diese Schnittstellen aktiv, statt bei Integrationsproblemen auf andere Teams zu zeigen. Fragen Sie, wer die Protokoll-Änderungsanträge schreibt.

7. Können Sie unsere bestehende App stabilisieren, bevor Sie einen kompletten Neubau vorschlagen?

Ein vertrauenswürdiger Partner prüft zuerst das bestehende System und empfiehlt die kleinste verantwortbare Lösung. Ein reflexhafter Neubau-Vorschlag ist eine kommerzielle Antwort, keine technische.

Warnsignale bei der Auswahl eines App-Entwicklers

Keines dieser Signale macht eine generische Mobile-Agentur zu einem schlechten Unternehmen. Sie zeigen nur, dass das Projekt zusätzliche Spezialfähigkeiten braucht, die der Anbieter bisher nicht nachgewiesen hat:

Es geht nur um Screens, Animationen und API-Endpunkte Es wird nie nach Zugang zum physischen Gerät gefragt BLE- oder WLAN-Integration gilt als kleine Plugin-Aufgabe Kein explizites Verbindungs- und Gerätezustandsmodell Getestet wird auf einem Smartphone und einem Hardware-Exemplar Offline-Verhalten kann nicht erklärt werden Keine Strategie für Firmware-Kompatibilität Kein Ansatz für Diagnose im Feld Ein exakter Festpreis, bevor Protokoll und Hardware gesichtet wurden Ein Portfolio generischer Apps ohne Connected-Product-Referenzen

IoT-App-Baukasten oder individuelle Companion-App-Entwicklung?

„IoT-App-Builder" kann zwei verschiedene Dinge bedeuten: ein Unternehmen, das eine individuelle IoT-Anwendung entwickelt, oder eine No-Code-Plattform, mit der eine solche zusammengestellt wird. Beides ist legitim, für unterschiedliche Situationen:

Ein Baukasten kann ausreichen für Interne Prototypen · Machbarkeitsnachweise · Standard-Geräteintegrationen · einfache Dashboards · begrenztes Branding · geringe Anforderungen an Zuverlässigkeit oder Skalierung · kurzlebige Demonstrationen.

Individuelle Entwicklung ist meist notwendig bei Proprietärer Hardware oder Protokollen · anspruchsvollem Bluetooth-Verhalten · Onboarding in Produktionsqualität · Offline-Betrieb · eigenen Sicherheitsmodellen · Firmware-Kompatibilität · hohen Stückzahlen · strengen UX-Anforderungen · Integration bestehender Backends · langfristiger Wartbarkeit · detaillierter Diagnose.

Wie ein professioneller Entwicklungsprozess aussieht

Der Prozess eines Partners zeigt, wie er über Risiko denkt. Bei der Entwicklung von IoT-Apps zieht das verlässliche Muster die physische Unsicherheit nach vorn:

Fünf Phasen, physisches Risiko zuerst technische Unsicherheit

hoch

niedrig

Verstehen Produkt und Nutzer, Hardware-Status, kritische Anwendungsfälle, größte technische Unsicherheiten

Validieren Kommunikation mit echter Hardware, Befehle und Datenflüsse, Zustandsmaschinen, Offline-Strategie

Bauen Onboarding und Steuerung, lokale Daten und Cloud, Authentifizierung, robuste Fehlerbehandlung

Verifizieren Tests für Unterbrechung, Pairing und Prozessende, viele Smartphones, Firmware-Varianten, schlechte Netze

Betreiben Stufenweiser Rollout, Diagnose, Fehler-Monitoring, koordinierte Firmware- und App-Releases

Protokoll- und Zuverlässigkeitsannahmen werden mit echter Hardware validiert, bevor die vollständige Anwendung entsteht.

Wann Albrecht Apps gut passt und wann nicht

Wir sind der richtige Partner, wenn die App ein kritischer Teil des Hardware-Produkts ist und nicht nur ein Marketing-Zusatz. Wir arbeiten eng mit Hardware- und Firmware-Teams zusammen, konzentrieren uns aber auf die mobile Anwendung, Konnektivität, Software-Architektur, Backend-Integration und Produktionszuverlässigkeit rund um das Gerät.

Gute Passung, wenn Ein funktionierender Prototyp muss ein wartbares Serienprodukt werden · eine bestehende BLE-App ist unzuverlässig · Verantwortlichkeiten zwischen App, Firmware und Backend sind unklar · Sie brauchen einen erfahrenen Connected-Device-Spezialisten · Fehler treten nur unter realen Bedingungen auf · das Produkt braucht eine robuste Offline- und Synchronisationsstrategie · das Management will vor einem größeren Ausbau eine technische Risikoanalyse.

Ein anderer Anbieter passt besser, wenn Der Hauptbedarf ist Elektronik-Design oder Fertigung · das Projekt ist eine generische App ohne Geräteintegration · gesucht ist nur ein großes Body-Leasing-Team · das Projekt erfordert Fähigkeiten außerhalb unserer tatsächlichen Expertise.

Die Partner-Checkliste

Bewerten Sie jeden Kandidaten, auch uns. Markieren Sie, was mit Belegen nachgewiesen wurde, nicht was versprochen ist:

Checkliste: Companion-App-Partner

Die Entscheidung in einem Absatz

Der richtige Companion-App-Partner muss das gesamte Connected-Product-System verstehen. Die Qualität des Produkts hängt nicht nur von der Oberfläche ab, sondern von Wiederherstellung, Synchronisation, Firmware-Kompatibilität, Diagnose und dem Verhalten unter unperfekten realen Bedingungen. Bewerten Sie Anbieter anhand der sieben Fähigkeiten, stellen Sie die sieben Fragen und behandeln Sie vage Antworten zur Konnektivität als das Risikosignal, das sie sind.

Häufige Fragen

Was ist eine Hardware-Companion-App?

Eine mobile Anwendung zum Einrichten, Konfigurieren, Steuern, Überwachen, Aktualisieren oder Synchronisieren eines physischen Geräts. Sie kommuniziert meist über Bluetooth Low Energy, WLAN oder ein Cloud-Backend.

Wie unterscheidet sich Connected-Device-Entwicklung von normaler App-Entwicklung?

Die App muss physische Konnektivität, Gerätezustand, Firmware-Kompatibilität, Unterbrechungen, Offline-Betrieb und Fehler über mehrere technische Systeme hinweg beherrschen, nicht nur eine Web-API.

Kann ein IoT-App-Baukasten individuelle Entwicklung ersetzen?

Für einen Prototyp oder ein Standard-Dashboard kann ein Baukasten genügen. Individuelle Entwicklung ist meist angemessener bei proprietären Protokollen, Konnektivität in Produktionsqualität, anspruchsvollem Offline-Verhalten, Sicherheit und einer differenzierten User Experience.

Wie früh sollte das App-Team die Hardware erhalten?

So früh wie möglich. Kritische Protokoll- und Zuverlässigkeitsannahmen sollten mit echter Hardware validiert werden, bevor Benutzeroberfläche und Gesamtanwendung fertiggestellt sind.

Was sollte bei einer BLE-Companion-App getestet werden?

Pairing, Discovery, Reconnection, Berechtigungen, Prozessende, Hintergrundverhalten, unterbrochene Befehle, Firmware-Varianten, viele verschiedene Smartphone-Modelle, Funkstörungen, Offline-Betrieb und Diagnoseverhalten.

Entwickelt Albrecht Apps auch die Hardware?

Wir konzentrieren uns auf die mobile Anwendung, Konnektivität, Software-Architektur, Backend-Integration und Zuverlässigkeit rund um vernetzte Hardware. Wir arbeiten eng mit Ihren Hardware- und Firmware-Teams zusammen und helfen, die Schnittstellen zwischen ihnen zu definieren.

Kann Albrecht Apps eine bestehende Companion App verbessern?

Ja. Wir prüfen Architektur, Quellcode, Protokoll, Fehlerberichte und Hardware-Verhalten, bevor wir gezielte Stabilisierung, Refactoring oder einen Neubau empfehlen.

Sprechen Sie mit uns über Ihr Connected Product

Sie bauen ein Hardware-Produkt, verbessern eine bestehende Companion App oder bereiten einen Prototyp auf die Serie vor? Wir prüfen die Architektur vom Gerät bis zur App, identifizieren Zuverlässigkeitsrisiken und definieren den nächsten verantwortbaren Entwicklungsschritt.

Erstgespräch buchen Risikoanalyse anfragen