Faktencheck zu Progressive Web Apps, Teil 4: Grenzen & Auswege

Im vorigen Teil dieser Serie rund um häufig gestellte Fragen zu Progressive Web Apps rückten die Themen Offenheit und Abwärtskompatibilität moderner Webschnittstellen in den Vordergrund. In diesem vorerst letzten Teil geht es um die Grenzen des PWA-Anwendungsmodells und mögliche Auswege, falls Entwickler an eine solche stoßen sollten.

In Pocket speichern vorlesen Druckansicht 2 Kommentare lesen
Lesezeit: 3 Min.
Von
  • Christian Liebel

Im vorigen Teil dieser Serie rund um häufig gestellte Fragen zu Progressive Web Apps rückten die Themen Offenheit und Abwärtskompatibilität moderner Webschnittstellen in den Vordergrund. In diesem vorerst letzten Teil geht es um die Grenzen des PWA-Anwendungsmodells und mögliche Auswege, falls Entwickler an eine solche stoßen sollten.

Nein. PWA können (nur) auf Funktionen zurückgreifen, für die es auch eine passende Webschnittstelle gibt. Das sind schon jede Menge, wie Clientdatenbanken (IndexedDB), die Steuerung per Gamepad (Gamepad API) oder die bequeme Bezahlung von Artikeln (Payment Request API, hier auf ÜberKreuz vorgestellt). Und es werden zunehmend mehr: So wird derzeit die Web Share API in den ersten Browsern ausgerollt, die das Aufrufen des nativen Teilendialogs erlaubt, über die Generic Sensor API sollen Webanwendungen Zugriff auf Gerätesensoren erhalten und die WebXR API soll Cross-Reality-Inhalte ins Web bringen. In Line-of-Business-Apps häufig benötigte Funktionen wie Formulare, hardwarebeschleunigte 2-D- oder 3-D-Visualisierungen lassen sich selbst in älteren Browserausgaben problemlos abbilden.

Es stimmt aber auch, dass auf bestimmten Plattformen manche Schnittstellen nicht zur Verfügung stehen, etwa können PWA unter iOS keine nativen Push-Benachrichtigungen empfangen. Andere Schnittstellen werden durch den Browserhersteller möglicherweise eingeschränkt und manche APIs (zum Beispiel zur Abfrage der installierten Netzhardware) wird es vielleicht nie geben. Innovationen dürften sich auch zukünftig erst im Bereich nativer Anwendungen abspielen, ehe eine plattformübergreifend einsetzbare Webschnittstelle verfügbar sein wird.

Teilweise lässt sich das Fehlen einer Schnittstelle umgehen, indem eine alternative oder ergänzende Implementierung gewählt wird. So können PWA unter iOS über WebSockets wenigstens zur Laufzeit Push-Nachrichten entgegennehmen und dem Anwender darstellen.

Mit Apache Cordova und GitHub Electron stehen Tools zur Verfügung, um Webanwendungen in ein natives Anwendungsbündel für Mobil- beziehungsweise Desktopgeräte zu verpacken. Damit können Entwickler eine Webanwendung über gängige App-Stores oder als ausführbare Datei vertreiben. Beide Technologien stellen eine Kommunikationsschicht zur Verfügung, über die solche verpackte Webanwendung beliebige native APIs aufrufen kann. Damit stehen diese Anwendungen ihren nativen Gegenstücken in nichts mehr nach. Apps wie Visual Studio Code oder Skype setzen auf genau diese Lösung.

Investitionen in Webanwendungen dürften sich daher in den meisten Fällen bezahlt machen: Ist eine Schnittstelle nicht verfügbar, kann man seine Web-App zusätzlich zu oder anstatt einer PWA als verpackte native Anwendung bereitstellen. Wird die gewünschte Schnittstelle eines Tages auch im Web verfügbar, so kann der Wrapper einfach entfallen. ()