Companion-Apps: Warum die App zum Produkt gehört

Ein Gerät wird heute selten allein verkauft. Die Spülmaschine meldet ihren Betriebszustand, das Thermometer schickt den Messwert ans Telefon, die Maschine auf dem Feld zeigt ihre Daten auf einem Terminal. Die App ist dabei kein Zubehör, sondern der Teil des Produkts, mit dem der Kunde täglich umgeht.

Genau daraus entsteht ein Missverständnis, das wir immer wieder sehen: Die App wird organisatorisch beim Marketing geführt, budgetiert wie eine Kampagne und beauftragt wie eine Website. Das geht so lange gut, bis das erste Betriebssystem-Update kommt.

Der Kern in einem Satz: Eine Companion-App ist keine Projektleistung, sondern eine Betriebsaufgabe — sie muss so lange funktionieren, wie die Hardware im Feld steht, durch alle Betriebssystemwechsel und Store-Anforderungen hindurch. Daraus folgt fast alles Weitere: Architektur, Budget und die Frage nach der Zuständigkeit.

Die App erbt die Lebensdauer der Hardware

Das ist der Kern. Eine Maschine, die zehn oder fünfzehn Jahre im Feld steht, hat eine App, die zehn oder fünfzehn Jahre funktionieren muss. Nicht unverändert — sondern durch alle Betriebssystemwechsel, Store-Anforderungen und Gerätegenerationen hindurch, die in dieser Zeit anfallen.

Eine Website kann man in fünf Jahren neu bauen und niemand vermisst die alte. Eine Companion-App kann man nicht einfach abschalten, solange die Geräte laufen, zu denen sie gehört. Der Kunde hat die Hardware gekauft, und die App war Teil des Versprechens.

Das verändert die Rechnung von Anfang an: Die Frage ist nicht, was die Entwicklung kostet, sondern was die nächsten zehn Jahre kosten. Wer das erst nach dem Launch fragt, hat den teureren Weg gewählt.

Was regelmäßig unterschätzt wird

Bluetooth ist keine Funktion, sondern ein Fachgebiet

„Die App verbindet sich per Bluetooth mit dem Gerät” ist ein Satz aus einem Lastenheft. In der Umsetzung steckt darin: Gerätesuche, Kopplung, Wiederverbindung nach Abbruch, Verhalten bei schwachem Signal, Umgang mit mehreren Geräten in Reichweite, Unterschiede zwischen iOS und Android im Berechtigungsmodell — und die Frage, was die App tut, während der Nutzer wartet.

Unsere Erfahrung: Diese Anbindung gehört in ein eigenes, versioniertes Modul, nicht verstreut in den App-Code. Dann lässt sie sich getrennt testen, gegen echte Hardware verifizieren und austauschen, wenn eine neue Gerätegeneration kommt. Bei einem Basalthermometer-Projekt haben wir genau so gebaut — die Thermometer-Anbindung ist ein eigenes Package mit eigener Versionsnummer.

Offline ist der Normalfall, nicht die Ausnahme

Gemessen wird morgens im Bett. Gescannt wird in der Werkhalle. Gearbeitet wird auf dem Feld. Keiner dieser Orte ist dafür bekannt, gutes Netz zu haben.

Wenn die App eine Verbindung braucht, um eine Eingabe entgegenzunehmen, ist sie an genau den Orten unbrauchbar, an denen sie gebraucht wird. Die tragfähige Architektur dreht das um: Die lokale Datenbank ist die Wahrheit, der Server holt sich die Daten ab, sobald es geht. Verbindungsverlust ist dann kein Fehlerfall, sondern ein eingeplanter Zustand.

Das ist mehr Arbeit als ein Formular, das an eine API schickt. Es ist aber der Unterschied zwischen einer App, die im Alltag trägt, und einer, die im Alltag nervt.

Der Umbau im Nachhinein ist übrigens teuer. Eine App, die von Anfang an davon ausgeht, dass der Server erreichbar ist, hat diese Annahme an hundert Stellen im Code. Sie herauszuziehen bedeutet, die Datenhaltung neu zu denken — nicht ein Feature nachzurüsten.

Ein verlorener Messwert ist nicht wie ein verlorenes Formular

Bei einer Bestell-App kann der Nutzer den Vorgang wiederholen. Bei einer Messreihe geht das nicht: Der Wert von heute Morgen lässt sich nicht nachholen. Wer eine Zykluskurve, ein Wartungsprotokoll oder eine Betriebsstundenzählung führt, für den ist eine Lücke in den Daten ein echter Schaden.

Das hebt die Anforderungen an Speicherung und Synchronisation über das übliche Maß. Es verändert auch, was ein Absturz bedeutet: nicht Ärger, sondern Datenverlust.

Regulatorik kommt früher, als man denkt

Sobald eine App misst, auswertet oder Empfehlungen gibt, ist die Frage nach dem Medizinprodukt oder anderen regulatorischen Rahmen nicht mehr theoretisch. Das ändert die Arbeitsweise: Änderungen müssen nachvollziehbar sein, Releases dokumentiert, Verhalten reproduzierbar.

Wichtig ist der Zeitpunkt. Diese Anforderungen nachträglich in ein Projekt einzuziehen, ist deutlich teurer, als von Anfang an so zu arbeiten. Wer ahnt, dass es in diese Richtung geht, sollte es vor der ersten Zeile Code klären.

Firmware und App altern nicht im selben Takt

Die Hardware bekommt vielleicht alle zwei Jahre ein Firmware-Update, die App alle paar Wochen ein Store-Release. Daraus folgt eine Frage, die im Lastenheft fast nie steht: Welche App-Version muss mit welcher Firmware-Version zusammenarbeiten?

Im Feld stehen Geräte mit Firmware von 2021 neben welchen von heute. Die App muss mit beiden umgehen — und zwar in derselben Version, denn im Store gibt es nur eine. Wer das nicht von Beginn an einplant, steht später vor der Wahl, entweder Bestandsgeräte abzuhängen oder die App mit Fallunterscheidungen zu durchziehen, die niemand mehr überblickt.

Der saubere Weg ist eine Versionsaushandlung: Die App fragt das Gerät, was es kann, und verhält sich entsprechend. Das kostet in der ersten Version Aufwand und spart ihn ab der zweiten.

Die Sprachfrage ist eine Vertriebsfrage

Hardware wird exportiert. Die App muss mit. Acht oder fünfzehn Sprachen aus einer Codebasis sind machbar — aber nur, wenn Mehrsprachigkeit von Beginn an eingeplant ist. Nachträglich Texte aus dem Code zu ziehen, ist eine der undankbarsten Aufgaben in der App-Entwicklung.

Wer pflegt die App in drei Jahren?

Die meisten Ausschreibungen für Companion-Apps beschreiben sorgfältig, was die App können soll. Fast keine beschreibt, wer sie danach pflegt — die Frage, die im Lastenheft fehlt.

Dabei entscheidet genau das über die Gesamtkosten. Drei Modelle sind üblich:

Intern aufbauen. Sinnvoll, wenn die App zum Kerngeschäft gehört und dauerhaft Arbeit anfällt. Braucht mindestens zwei Personen — eine allein bedeutet Stillstand bei Urlaub und Totalausfall bei Kündigung.

Projektweise vergeben. Günstig in der Anschaffung, teuer im Unterhalt. Jeder neue Auftrag beginnt mit Einarbeitung, und zwischen den Aufträgen schaut niemand hin. Das ist das Modell, aus dem die Apps stammen, die wir später aus instabilem Zustand übernehmen — und bei denen sich dann die Frage stellt, ob man saniert oder neu baut.

Betreuung beauftragen. Feste Ansprechpartner, laufende Beobachtung, planbare Kosten. Rechnet sich, sobald die App über Jahre existieren soll — also bei fast jeder Companion-App.

Es gibt keine allgemein richtige Antwort. Es gibt nur die falsche: keine zu treffen und zu hoffen, dass sich das später klärt.

Eine Faustregel, die sich bei uns bewährt hat: Wenn die Hardware ein Produkt ist, das über Jahre verkauft und unterstützt wird, ist die App keine Projektleistung, sondern eine Betriebsaufgabe. Sie taucht dann sinnvollerweise nicht im Projektbudget auf, sondern in der Kalkulation des Produkts — so wie Ersatzteilversorgung und Support auch.

Woran du eine gut gebaute Companion-App erkennst

• Sie funktioniert ohne Netz vollständig, nicht nur lesend.
• Die Geräteanbindung ist ein eigenes Modul, kein verwobener Sonderfall.
• Es gibt eine Auslieferungskette, die regelmäßig benutzt wird — nicht einmal im Jahr.
• Abstürze landen in einem Monitoring, bevor sie in Bewertungen landen.
• Jemand ist namentlich zuständig.

Keiner dieser Punkte ist im Screenshot sichtbar. Alle fünf entscheiden darüber, ob die App in fünf Jahren noch trägt.

---

Passend dazu: Wie wir Apps für vernetzte Hardware bauen, steht unter App-Entwicklung. Für Apps, die schon im Feld sind, gibt es die App-Pflege — und ein paar der Fälle, um die es hier geht, findest du in unseren Referenzen.