“Gibt es davon eine App?” Gemeint sind damit meist die Dinger aus den App-Stores. Doch es gibt mindestens drei Kategorien an Apps, welche sich technisch grundlegend unterscheiden und bei weitem nicht alle aus den plattformspezifischen App-Stores geladen werden.
Apps im Vergleich
Ich unterscheide zwischen “nativen Apps”, “hybriden Apps” und “PWAs (Progressive Web Apps)”. Deren Aufbau habe ich in der folgenden Grafik skizziert:
Native App
Die native App wird explizit für das jeweilige Betriebssystem geschrieben (Windows, macOS, Android, iOS, iPad OS…). Entwicklung und Pflege einer nativen App sind Aufwändig und damit teuer, weil ein Grossteil der Arbeiten pro Betriebssystem neu gemacht werden müssen und nicht einfach übernommen werden können.
Daher sind native Apps vor allem im Einsatz, wo sie wegen ihrer Hardwarenähe benötigt werden. Meist aus Speed-Gründen oder – immer seltener – um auf bestimmte Hardware-Funktionen zugreifen zu können.
Hybride App
Bei der hybriden App werden Inhalt und “Runtime” getrennt. Stell dir das am einfachsten vor wie ein PDF. Du hast ein PDF und auf jeder Plattform gibt es Programme, um PDFs anzuzeigen. Stell dir diese Programme als “Runtime” vor: Der Inhalt (das PDF) ist immer der gleiche, die “Runtime” ist fürs jeweilige Betriebssystem geschrieben.
Vor bald zehn Jahren gab es im Publishing einen regelrechten Hype mit diesen hybriden Apps. Mit der Vorstellung des ersten iPads glaubten wir, gedruckte Magazine einfach auf ein digitales Gerät übertragen zu können. Mit pixelgenauem Layout, meist erstellt in Adobe InDesign. Die Zeit der starren Layouts auf mobilen Geräten ist vorbei, Adobes Lösung dafür (AEM Mobile, respektive die Digital Publishing Suite) gibt es nicht mal mehr.
Geblieben ist hingegen die Möglichkeit, Inhalt von Apps mit Standard-Webtechnologien wie HTML, CSS und JavaScript zu erstellen. Cordova von Apache ist ein beliebtes Framework dafür.
PWA (Progressive Web App)
Proprietäre Runtimes wie bei hybriden Apps bräuchte die Welt eigentlich nicht. Denn auf jedem heute verfügbaren Betriebssystem ist eh eine Runtime vorinstalliert: der Webbrowser. Ein Browser ist eine Runtime, um Web-Formate zu rendern (darzustellen). Genau das macht sich die PWA zunutze.
Leider zieht Apple bei den PWAs nicht kompromisslos mit. Vermutlich, weil eine PWA eine Website ist und daher keinen Store braucht und Apple sich Sorgen um Kontrolle, Sicherheit und nicht zuletzt die Provision der Apps aus dem App-Store macht.
Auf macOS (Desktop-System von Apple) ist es halb so wild. Man verzichtet einfach auf den Apple-Browser (Safari), holt sich Google Chrome als Browser und nutzt PWAs ohne Einschränkung.
Mobil sieht es bitter aus: Apple erlaubt nur Browser auf Basis von Webkit, dem Apple-eigenen Framework. Das heisst, alle Browser auf iOS oder iPad OS können nur, was Safari auch kann (auch Chrome & Co). Und das ist im Bereich PWA leider noch wenig. So fehlt der Empfang von Push-Nachrichten und das einfache Installieren der PWA über ein Pop-up. Eine PWA läuft trotzdem auf Webkit, weil eine echte PWA rückwärts kompatibel ist und nutzt, was vorhanden ist.
Alle anderen Plattformen unterstützen oder fördern PWAs – kann also gut sein, dass Apple unter Druck kommt und nachliefern muss.
Und welche App-Art ist nun die beste?
Wie immer, gibt es auch bei Apps nicht nur Schwarz und Weiss. Vielmehr muss abgeklärt werden, ob eine native App notwendig ist, oder ob es nicht auch eine hybride App oder eine PWA tut. Wenn es ums Publizieren von Inhalt geht und eh schon eine mobile Website vorhanden ist, ist die PWA der logische Schritt. Wo hingegen vom Zielmarkt eine App im Store erwartet wird, muss es eine hybride oder gar eine native App sein (unter Android gäbe es die Möglichkeit, auch eine PWA in den Google Play Store zu stellen).
Die App mit WordPress erstellen
In der Praxis haben wir als Agentur mit WordPress bereits PWAs und auch hybride Apps gebaut. Für die PWA nutzen wir das Plugin “Progressive WP“, für die hybride “WPMobile.App“.
