1    Im Web, als App: Geschichte und Einstieg

Google sagt: Die Zukunft gehört den Progressive Web Apps. Bevor Sie sich mit diesem Anwendungsmodell ausführlich auseinandersetzen, lohnt sich ein Blick auf die Geschichte mobiler Apps sowie auf hilfreiche Tools, die die App-Entwicklung zum Kinderspiel machen.

Wir schreiben den 1. April 2004. Die Ankündigung eines neuen E-Mail-Dienstes sorgt für Aufsehen: Wegen seines für damalige Verhältnisse sehr großzügigen E-Mail-Speicherplatzes von einem Gigabyte (üblich waren damals nur wenige Megabytes) halten manche die Ankündigung zunächst für einen Aprilscherz. Und nicht nur der Speicherplatz ist bemerkenswert, sondern auch die besondere Schnelligkeit des zugehörigen webbasierten E-Mail-Clients. Die Rede ist von Gmail, dem bekannten Freemail-Dienst von Google und zugleich einem der ersten Produkte, mit denen der Suchmaschinenanbieter sein klassisches Kerngeschäft verließ. Google etablierte mit diesem E-Mail-Dienst einen der ersten großen Vertreter einer Single-Page Web Application (SPA). Darunter versteht man eine als Fat Client realisierte Webanwendung, die Interaktionen durch clientseitige Dynamik umsetzt, anstatt einen serverseitigen Seitenwechsel durchzuführen. Nach dem initialen Laden der Quelldateien nimmt dieser Typ Anwendung lediglich zur Abfrage oder Manipulation von Daten Kontakt zu einem entfernten Server auf, etwa mithilfe von Asynchronous JavaScript and XML (AJAX). Diese Technologie stellt wiederum einen Baustein des Web 2.0 dar, das ungefähr zeitgleich Fahrt aufnahm. Im weiteren Verlauf wurden Webanwendungen salonfähig und zunehmend mehr Anwendungen auf der SPA-Architektur aufgesetzt. Heute sind GitHub, Google Maps oder Facebook weitere bekannte Vertreter dieses Typs Webanwendung.

Etwas mehr als zehn Jahre nach der Veröffentlichung von Gmail will es Google erneut wissen und postuliert mit den Progressive Web Apps (PWA) das Anwendungsmodell der Zukunft. Mit dem mobilen Betriebssystem Android und dem Webbrowser Chrome hat Google zwei mächtige und weitverbreitete Anwendungsplattformen im Portfolio, die in ihren jeweiligen Segmenten zu Marktführern avanciert sind. Progressive Web Apps möchten das Beste aus diesen beiden Welten vereinen: den Funktionsreichtum nativer Anwendungen und die plattformübergreifende Ausführbarkeit von Webanwendungen. Zwar wurden über die vergangenen Jahre viele neue Schnittstellen mit wichtigen Features im Web eingeführt, doch blieben die Installierbarkeit von Anwendungen auf den Homebildschirm, Pushbenachrichtigungen, vollumfängliche Offlinefähigkeit sowie die Abwicklung von In-App-Käufen bislang nur nativen Anwendungen vorbehalten. Unter anderem mit dem Service Worker, dem Web App Manifest und der Payment Request API wurden nun Schnittstellen für das Web geschaffen, die diese Lücken schließen. Außerdem können Progressive Web Apps auf alle weiteren Funktionen zurückgreifen, für die es eine Webschnittstelle gibt und die vom jeweiligen Webbrowser auf der jeweiligen Plattform zur Verfügung gestellt werden. Mit den Progressive Web Apps wird ein gravierendes Problem der Anwendungsentwicklung ein für alle Mal aus der Welt geschafft: die Plattformabhängigkeit. Denn diese Apps können auf jedem Gerät ausgeführt werden, auf dem ein halbwegs moderner Browser läuft: vom Smartphone mit Android bis hin zum Desktopcomputer mit Microsoft Windows.

Insgesamt haben Progressive Web Apps kein geringeres Ziel, als die altbekannten App Stores abzuschaffen. Diese Anwendungen werden nicht über eine zentrale Vertriebsplattform installiert, sondern zunächst im Browser ausgeführt. Dabei sind Progressive Web Apps aber keine funktional reduzierten Webclients, die ihr Leben nur in einer Browserregisterkarte fristen – wünscht der Benutzer einen schnelleren Zugang zur Anwendung, kann er eine Verknüpfung zur App auf dem Homebildschirm respektive dem Desktop hinterlegen. Von dort startet die Anwendung auf Wunsch ohne Menüleisten und Statuszeilen, auf Mobilgeräten als vollflächige App oder auf dem Desktop in einem eigenen Fenster mit nativer Fensterdekoration. Auch im App-Switcher oder der Taskleiste erhält die Anwendung einen Platz, womit sie von nativen Anwendungen kaum mehr zu unterscheiden ist (siehe Abbildung 1.1). Die Anwendung verlässt den Browser schrittweise, unter anderem darauf weist der Namensbestandteil Progressive hin. Unter der Haube tickt jedoch weiterhin der Browser und darin die Progressive Web App: Eine Progressive Web App, die über eine Verknüpfung in einem eigenen Fenster gestartet wird, unterscheidet sich funktional nicht von der im Webbrowser ausgeführten Variante. Insgesamt begegnen Progressive Web Apps ihren nativen Gegenstücken also auf Augenhöhe. Native Anwendungen und App Stores könnten damit in weiten Teilen bald überflüssig werden.

Abbildung 1.1    Hätten Sie es geahnt? Hier läuft die Progressive Web App Twitter Lite, von nativen Anwendungen nicht zu unterscheiden.

1.1    Wie Apps auf unser Handy kamen – eine kleine Zeitreise

Mit den Progressive Web Apps geht es für Anwender, Entwickler und Plattformbetreiber also zurück in eine Zeit vor dem App Store. Eine Zeit, die es schon einmal gab, denn Anwendungen für mobile Endgeräte wie Smartphones und Tablets sind natürlich keine Neuerfindung: Bereits die ersten Handys waren mit solchen Minianwendungen für einen abgegrenzten, dedizierten Zweck ausgestattet. Später kam die Möglichkeit hinzu, beliebige von Drittanbietern bereitgestellte Anwendungen auf den Geräten zu installieren. Der Weg, auf dem Apps auf die mobilen Endgeräte kommen, änderte sich aber im Laufe der Zeit. Blicken wir daher kurz zurück auf die Entwicklung mobiler Anwendungen.

1.1.1    Der PC für die Hosentasche

Microsoft Windows CE ist ein früher Vertreter eines potenten Betriebssystems für mobile Geräte. Manche davon wurden zwischenzeitlich als Pocket PC bezeichnet, also als PC für die Hosentasche. Während sich der Unterbau dieses Systems zwar grundsätzlich vom Desktopbetriebssystem Windows unterscheidet, wurden diesem dennoch viele Konzepte entnommen: So hat Windows CE etwa eine Startschaltfläche, eine Taskleiste und Menüzeilen. Alle Steuerelemente sind so klein, dass der Anwender zur Bedienung auf einen Stylus, einen kleinen Plastikstift, angewiesen ist.

Auch das Anwendungskonzept wurde vom Desktopbetriebssystem übernommen: Programmdateien (Executables) können, wie es unter Windows nach wie vor üblich ist, aus beliebigen Quellen (etwa aus dem Internet oder über einen angeschlossenen Rechner) bezogen und direkt ausgeführt werden. Abbildung 1.2 zeigt die Installation einer Drittanbieteranwendung unter Windows Mobile 2003: Führt man die Installationsdatei (hier tcmdpocketarm.cab) aus, werden die Programmdateien im Programme-Verzeichnis des Geräts hinterlegt. Danach erscheint eine Verknüpfung zur Anwendung in der Programmliste. Was heute auf Desktopbetriebssystemen noch immer üblich ist, erschien auch auf mobilen Plattformen in den Anfangsjahren als passables Konzept. Das Betriebssystem vertraute den darauf ausgeführten Anwendungen noch und stellte ihnen eine Vielzahl von Schnittstellen zur Verfügung, eine Sandbox oder ein Berechtigungskonzept gab es nicht.

Abbildung 1.2    Apps installieren auf die klassische Art, hier unter Windows Mobile 2003

1.1.2    Der Browser als Anwendungsplattform

Dann kam Apple und änderte wieder einmal alles: Am 9. Januar 2007 stellte Steve Jobs das iPhone auf der Macworld in San Francisco vor. Dieses Smartphone setzte sich von der seinerzeit vorherrschenden Konkurrenz durch seinen vollflächigen Multi-Touch-Bildschirm, die intuitive und auch mit Fingern gut bedienbare Benutzeroberfläche sowie seinen Webbrowser Safari ab. Auf dem iPhone stand die Safari-Engine mit dem vollen aus der Desktopvariante bekannten Funktionsumfang zur Verfügung. Für damalige Verhältnisse war diese Ausgabe eines mobilen Browsers herausragend leistungsstark.

Über das Anwendungsmodell des iPhone wurde bei der Keynote noch nicht gesprochen. Informationen dazu lieferte Jobs bei der hauseigenen Entwicklerkonferenz WWDC am 11. Juli 2007 nach, nur 18 Tage vor der Auslieferung der ersten iPhones. Der Weg, auf dem Apps von Drittanbietern auf das iPhone kommen sollten, wurde als innovativ und besonders sicher beschrieben: Als Anwendungsplattform sollte Safari zum Einsatz kommen – und damit ein Webbrowser. Jobs dazu:

And so, you can write amazing Web 2.0 and AJAX apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services. They can make a call, they can send an email, they can look up a location on Google Maps.

Als weitere Vorteile dieses webbasierten Anwendungsmodells nannte Jobs, dass Apps durch die Bereitstellung auf einem eigenen Server besonders einfach verteilt und durch eine simple Änderung an den Quelldateien auch aktualisiert werden könnten, ganz ohne komplizierte Prozesse. Durch die Ausführung von Webinhalten in einer Sandbox wäre dieses Modell auch...