Progressive Web App: die installierbare Webanwendung als zweiter Kanal

Eine Progressive Web App ist eine Webanwendung, die sich auf dem Gerät installieren lässt, in einem eigenen Fenster startet und einen Teil ihrer Aufgaben ohne Netz erledigt. Sie wird über den Browser ausgeliefert, nicht über einen Store, und bleibt technisch eine Website mit zusätzlichen Fähigkeiten. Für Unternehmen ist das vor allem ein Weg zu einem mobilen Kanal.

Progressive Web App: was sie technisch ausmacht

Drei Bausteine trennen eine solche Anwendung von einer gewöhnlichen Website. Das Web-App-Manifest beschreibt Name, Symbol, Startadresse und Anzeigemodus, damit das Betriebssystem ein Symbol auf dem Startbildschirm anlegen und die Anwendung ohne Adressleiste öffnen kann. Ein Service Worker liegt als kleines Programm zwischen Anwendung und Netz: Er beantwortet Anfragen aus einem lokalen Zwischenspeicher und macht damit den Start und einen Teil der Nutzung ohne Verbindung möglich. Ausgeliefert wird über HTTPS, sonst gibt der Browser diese Fähigkeiten nicht frei.

Alles Weitere bleibt Web: eine Codebasis, ein Deployment, keine getrennten Fassungen für zwei Betriebssysteme. Eine Aktualisierung ist im Kern ein neuer Stand auf dem Server, den der Service Worker beim nächsten Start übernimmt. Das ist der eigentliche Unterschied im Betrieb – nicht das Symbol auf dem Startbildschirm.

Unterschied zur nativen App und zur gewöhnlichen Website

Gegenüber der gewöhnlichen Website gewinnt eine PWA drei Dinge: den Start aus einem eigenen Symbol, einen definierten Zustand ohne Netz und – je nach Plattform – Benachrichtigungen. Gegenüber der nativen App verliert sie Tiefe im Gerät und Sichtbarkeit im Store.

Die native App wird je Plattform gebaut, signiert und über den Store verteilt; jede Fassung geht durch die App-Store-Veröffentlichung und die Prüfung des Store-Betreibers. Dafür darf sie tiefer ins Gerät greifen und arbeitet im Hintergrund verlässlicher. Die PWA umgeht den Store vollständig: Der Weg zur Installation ist ein Link, die Verteilung im eigenen Haus damit eine Frage von Zugängen statt von Konten.

Was eine PWA kann und wo sie an Grenzen stößt

Offline heißt nicht „läuft ohne Netz“, sondern „läuft mit dem, was vorher geladen wurde“. Der Service Worker legt Dateien und ausgewählte Datensätze lokal ab, alles andere fehlt. Wer im Lager, in der Werkstatt oder auf der Baustelle arbeitet, braucht deshalb eine bewusste Entscheidung: Welche Daten liegen auf dem Gerät, wie lange gelten sie, und was geschieht mit Eingaben, die im Funkloch entstehen?

Am Gerät gilt: Kamera, Standort, Dateien und Bewegungssensoren sind über Browser-Schnittstellen erreichbar; Bluetooth-Peripherie, NFC, herstellereigene Handscanner und dauerhafte Hintergrundprozesse in der Regel nicht oder nur eingeschränkt. Benachrichtigungen verhalten sich je nach Plattform verschieden und setzen auf Apple-Geräten die Installation auf dem Startbildschirm voraus. Und was nicht im Store steht, findet dort auch niemand: Wer über die Store-Suche gefunden werden will, kommt an einer nativen Fassung nicht vorbei.

Wann eine Progressive Web App der richtige zweite Kanal ist

Die Entscheidung fällt an vier Fragen, nicht an der Technik:

• Wer benutzt die Anwendung? Bekannte Personen – eigene Leute, angemeldete Kunden – erreicht ein Link. Anonyme Endkunden suchen im Store.
• Wie lange ist das Gerät ohne Empfang? Minuten im Aufzug sind etwas anderes als eine Schicht im Funkloch.
• Was muss die Anwendung am Gerät anfassen? Foto und Standort sind Web; Handscanner, Etikettendrucker oder NFC sind es meist nicht.
• Wie wird verteilt? Eine zentrale Geräteverwaltung rollt Store-Apps aus; ein Lesezeichen im Browser lässt sich schlechter steuern.

In der Praxis wird die installierbare Webanwendung damit eher zum ersten Schritt als zum Gegenentwurf: ein schmaler zweiter Kanal auf die vorhandene Fachanwendung, der ohne Store-Konten in den Alltag kommt. Zeigt sich dort, dass Hardware am Gerät oder verlässlicher Hintergrundbetrieb gebraucht werden, folgt die native Fassung mit einem belegten Anlass statt aus Gewohnheit.

Typische Fehler bei der Einführung

• Website mit Symbol. Manifest gesetzt, Service Worker leer – die Anwendung startet im eigenen Fenster und steht ohne Netz vor einer Fehlerseite.
• Zu viel zwischengespeichert. Bestände, Preise und Termine aus dem Zwischenspeicher sind falsch, sobald jemand anders sie ändert. Was aktuell sein muss, gehört nicht in den Cache oder zumindest mit sichtbarem Stand auf den Bildschirm.
• Eingaben ohne Rückweg. Offline erfasste Aufträge brauchen eine Warteschlange, eine Wiederholung und eine Regel für den Fall, dass der Datensatz im Kernsystem inzwischen verändert wurde.
• Anmeldung übersehen. Sitzungen laufen ab, während das Gerät ohne Verbindung ist; ohne Plan dafür steht der Monteur beim Kunden vor der Anmeldemaske.
• Nur am Schreibtisch geprüft. Geprüft wird auf dem Gerät, das im Betrieb benutzt wird – mit Handschuhen, in der Sonne, am Rand der Funkabdeckung.

Hinzu kommt ein Punkt, der oft erst spät auffällt: Die Oberfläche läuft im Browser, also gelten für sie dieselben Anforderungen an die Barrierefreiheit wie für jede andere Webanwendung – Tastaturbedienung, Kontrast und beschriftete Felder inklusive.

Wie wir den zweiten Kanal bauen

Wir setzen den zweiten Kanal auf die vorhandene Fachanwendung: dieselbe Datenbasis, dieselbe Rollenverteilung, derselbe Releasezyklus. Der erste Ausschnitt ist meist lesend – Aufträge, Bestände, Stammdaten auf dem Gerät –, danach kommen Eingaben mit Warteschlange und Konfliktregel dazu. Welche Sätze am Ende geprüft werden, steht vor dem Start im Angebot; ob die Oberfläche im Browser bleibt oder eine native Fassung bekommt, entscheiden wir an den vier Fragen oben. Wie wir dabei vorgehen, steht auf der Seite App-Entwicklung als zweiter Kanal zur Fachanwendung.