Fünfzehn Jahre eine App am Leben halten

Die meisten Apps, die 2011 im App Store standen, gibt es nicht mehr.

Eine unserer ältesten läuft noch. Sie heißt heute Neon Home, hieß früher PLC Smart Home, und sie steuert keine Cloud und keinen Server. Sondern eine speicherprogrammierbare Steuerung im Keller.

Im Sommer 2026 haben wir sie von Grund auf modernisiert. Das ist ein guter Moment, um zu erzählen, was in fünfzehn Jahren aus so einem Produkt wird.

2011: Ein Rollladen soll aufs Handy

Angefangen hat es mit Vorprogrammieren, unserem Partner für SPS-Programmierung und Gebäudeautomation. Die Ausgangslage war einfach zu beschreiben und alles andere als einfach zu bauen: In den Häusern liefen fertig programmierte Steuerungen für Rollladen, Licht, Dimmer und Heizung. Bedient wurden sie über Taster an der Wand. Der Wunsch war, dieselben Anlagen vom iPhone aus zu bedienen.

Kein Gateway, keine Hersteller-Cloud, kein Abo. Die App sollte im lokalen Netz direkt mit der Steuerung sprechen.

Ein Hinweis zur Zeitrechnung: Die App ist älter als die Firma. Die spiritdev Softwareentwicklung GmbH gibt es seit 2017, PLC Smart Home seit 2011. Entwickelt haben wir sie von Grund auf selbst, und ich habe sie bei der Gründung mit in die Firma gebracht. Seitdem wird sie bei spiritdev weiterentwickelt.

Daraus wurde PLC Smart Home. Über die Jahre haben wir die App für iOS und Android ausgebaut, Funktion um Funktion: Räume, Gerätegruppen, Szenen, Zeitschaltprogramme, Sensorübersicht, Widget für den Sperrbildschirm, Backup und Übertragung der Konfiguration zwischen Geräten. Später ist aus dem Produkt Neon Home geworden.

Drei Hardware-Generationen unter einer Oberfläche

Das eigentlich Interessante an diesem Produkt liegt unter der Oberfläche. Eine App für SPS-Anlagen ist keine App mit einer API. Jede Steuerungsfamilie hat ihr eigenes Protokoll, ihre eigene Adressarithmetik und ihre eigenen Eigenheiten beim Antwortverhalten.

Wir haben diesen Weg über drei Generationen mitgemacht:

• Mitsubishi. Die erste unterstützte Familie. Eigenes Frame-Format, eigene Adressberechnung.
• Millenium. Kam später dazu, inklusive der programmierbaren Funktionen und Systemwerte, die diese Steuerungen bereitstellen.
• Modbus. Mit den Modbus-fähigen Steuerungen kam der Bruch. Statt für jeden Hersteller ein eigenes Protokoll zu pflegen, arbeiten wir seither auf einem Industriestandard. Heute sprechen unsere Apps unter anderem mit em4-Stationen, Wago-Controllern und Siemens LOGO!.

Auf Modbus haben wir uns dann bewusst spezialisiert. Nicht, weil es das bequemste Protokoll ist. Sondern weil es das ist, was in der Praxis in den Schaltschränken steht, und weil es uns erlaubt, neue Anlagen anzubinden, ohne jedes Mal von vorn anzufangen.

Das Kommunikationsmodul ist der eigentliche Wert

Fünfzehn Jahre Arbeit an einer Sache haben einen konkreten Ertrag. In unserem Fall ist es ein Modul, das die gesamte Kommunikation zwischen App und Steuerung übernimmt: Verbindungsaufbau, Frame-Erzeugung, Timeouts, Wiederholversuch bei besetzter Leitung, Auswertung der Antwort und saubere Fehlermeldung nach oben.

Das klingt unspektakulär. Es ist der Unterschied zwischen einer App, die sich anfühlt wie ein Wandtaster, und einer App, die man nach dem dritten Versuch wieder zuschiebt. Wer eine Steuerung bedient, wartet nicht gern. Ein Rollladen, der eine Sekunde nach dem Tippen losfährt, ist ein anderes Produkt als einer, der drei Sekunden braucht.

Dieses Modul steckt inzwischen nicht mehr nur in Neon Home. Es ist die Grundlage weiterer Apps, die mit realer Hardware sprechen, zum Beispiel in Lift Gate Control, der von uns im Auftrag von RMP-Tec entwickelten App für die Hubtorsteuerung in Melkanlagen. Dort läuft die gleiche Klasse von Kommunikation gegen Siemens LOGO! Controller, nur in einem völlig anderen Anwendungsfall.

Genau das ist der Punkt, den wir Kunden gern erklären: Die Domäne wechselt. Rollladen, Hubtor, Lüftung, Pumpe. Die Kommunikationsschicht bleibt.

2026: Version 3.0.0

Software, die fünfzehn Jahre läuft, sammelt Altlasten. Neon Home lief zuletzt auf einem Fundament aus einer anderen Zeit. Diesen Sommer haben wir es ersetzt.

• Mindestanforderung von iOS 9.3 auf iOS 15 gezogen, Build auf das aktuelle SDK mit Xcode 26.
• Swift-Sprachversion angehoben und die daraus folgenden API-Umbenennungen im gesamten Bestand nachgezogen.
• Das Widget für die Kurzsteuerung auf WidgetKit migriert, weil Apple die alte Technik abgekündigt hat.
• Zentrale Screens nach SwiftUI portiert: Räume, Raumdetail inklusive Raumfoto, Gerätegruppen und Geräteliste mit Wischgeste.
• Dark Mode wieder durchgehend korrekt, nachdem der SDK-Sprung an Navigations- und Tab-Bar Regressionen erzeugt hatte.
• Privacy-Manifest ergänzt, sauber aus dem Code abgeleitet. Neon Home sammelt keine Daten und trackt nicht. Die App redet ausschließlich lokal mit der Steuerung.
• Ballast entfernt: eine nicht mehr benötigte Lizenzverwaltung, ein toter Produkt-Flavor, der abgekündigte Mitsubishi-Stationstyp.

Und wir haben echte Fehler gefunden, die jahrelang unauffällig mitgelaufen waren. Darunter ein Zeigerfehler bei der Erzeugung der Modbus-Frames, ein Absturz beim Import einer Konfiguration aus einer Mail und ein Ladeindikator in der Raumansicht, der unter bestimmten Bedingungen nie verschwand. Solche Dinge findet man nicht durch Draufschauen. Man findet sie, wenn man ein Altsystem systematisch durcharbeitet.

Was wir daraus mitnehmen

Ein Modernisierungsdurchlauf wie dieser ist kein Neuschreiben. Er ist Bestandspflege mit klarem Ziel: Die App muss die nächsten Jahre wieder abgabefähig, wartbar und für ihre Nutzer unauffällig gut sein. Alles, was am Verhalten der Kommunikation zur Hardware hängt, haben wir dabei nur nach Prüfung angefasst und den Rest dokumentiert statt blind zu ändern. Bei Software, die eine physische Anlage bewegt, ist das keine Vorsicht. Das ist Handwerk.

Und es zeigt, was möglich ist. Eine App aus 2011 muss nicht ersetzt werden, nur weil sie alt ist. Sie muss jemanden haben, der sie versteht.

Sie haben eine Anlage, die aufs Smartphone soll?

Wir bauen Apps, die mit echter Hardware sprechen. Steuerungen, Maschinen, Sensoren. Nativ für iOS und Android, direkt über Modbus/TCP, ohne Umweg über eine Hersteller-Cloud.

Typische Ausgangslagen, die wir kennen:

• Eine bestehende SPS-Anlage soll mobil bedienbar werden.
• Eine vorhandene Steuerungs-App ist technisch veraltet und fliegt bald aus dem Store.
• Ein Maschinenbauer will seinen Kunden eine eigene App mitgeben, statt ein Fremdprodukt zu empfehlen.

Sprechen Sie uns an. Ein erstes Gespräch kostet nichts und klärt meist schon, ob der Weg über eine eigene App der richtige ist.