Nachdem mit den Hybrid Apps jetzt alle fünf Technologien dieser Blogreihe vorgestellt wurden, werden in den nächsten zwei Artikeln nochmal alle Technologien miteinander verglichen. In diesem Artikel werden zunächst die technischen Kriterien: Performance Nutzeroberfläche, Native Features, Abhängigkeit von anderen Technologien oder Herstellern und Komplexität miteinander verglichen. Dabei erhalten die einzelnen Technologien in jeder Kategorie eine Punktzahl von 1 - 5, wobei eine hohe Punktzahl gut bedeutet. Am Ende der Blogreihe werden die Rankings verwendet um eine Entscheidungsmatrix zu erstellen, mit der die Entscheidung zu einer Technologie möglichst einfach gemacht werden soll.
Blogreihe
Hier finden Sie die Auflistung der einzelnen Blogartikel, die zur Blogreihe gehören. Diese Agenda wird mit jedem neu veröffentlichten Artikel erweitert.
Technischer Vergleich der Technologien
Performance
Die Performance einer App kann durch mehrere Faktoren beeinflusst werden. Zum einen fühlt sich eine App für Nutzer langsam an, wenn die Oberfläche lange braucht, um zu laden und nicht sofort verfügbar ist. So fühlen sich zum Beispiel Webseiten sehr langsam an, wenn sie viele Bilder laden müssen. Verwendet eine App die nativen UI-Komponenten des Betriebssystems, ist die Nutzeroberfläche häufig schneller aufgebaut, weil die Komponenten bereits vorgeladen sind.
Anhand dieser Tatsache lässt sich schnell sagen, dass Technologien, welche eine WebView nutzen in der Regel langsamer sind bzw. wirken als Apps, die die nativen Komponenten nutzen. Die WebView läuft in einem anderen Thread als die native Schicht. Die Threads an sich sind schnell, aber die Kommunikation zwischen den Schichten kann die Performance drosseln. Zudem kommt die nur eingeschränkte Möglichkeit mehrere Threads innerhalb einer WebView zu nutzen. Es ist zwar über einen WebWorker möglich weitere Threads zu nutzen, allerdings sind diese in ihren Möglichkeiten eingeschränkt.
Bei der Performance sollte aber beachtet werden, dass es um geringfügige Unterschiede geht. Auch eine App mit WebView läuft auf den heutigen Geräten sehr flüssig. Die Performance spielt erst eine wichtige Rolle, wenn man Apps, wie z.B. Spiele entwickeln möchte, die sehr viel Rechen- bzw. Grafikleistung fordern. Bei einer simplen App, wie z.B. einer Shop-App macht die Performance kaum einen Unterschied. Daher liegen die nativen Apps in der Performance Kategorie vorn, gefolgt von den gleich zu bewertenden Cross Compile Frameworks und nicht-nativen Frameworks. Auch Progressive Web Apps und Hybrid Apps lassen sich von der Performance her gleich bewerten und liegen gemeinsam auf Platz 3.
| Technologie | Punkte |
|---|---|
| Native App | 5 |
| nicht-natives Framework | 4 |
| Cross Compile Framework | 4 |
| Progressive Web App | 3 |
| Hybrid App | 3 |
Nutzeroberfläche
Bei der Nutzeroberfläche gibt es drei verschiedene Ansätze. Erstens das Darstellen einer Oberfläche mit den nativen Komponenten des Betriebssystems, zweitens die Darstellung mit Web Komponenten oder drittens das Zeichnen eigener Komponenten auf einem eigenen Canvas, wie zum Beispiel Flutter die Nutzeroberfläche realisiert. Das Nutzen der nativen Komponenten hat den Vorteil, dass die Nutzer die Komponenten bereits kennen und sich die Nutzeroberfläche genauso anfühlt wie bei anderen nativen Apps.
Durch das Verwenden von Web Komponenten in Web Views sehen zwar die Apps auf jeder Plattform gleich aus, so dass sich Nutzer nicht von Plattform zu Plattform umstellen müssen, allerdings stehen sie dann meistens im Kontrast zu den gewohnten anderen Komponenten vom Betriebssystem. Der Ansatz eine Nutzeroberfläche selbst zu Zeichnen ist hat ein ähnliches Problem, wie die Nutzung von Web Komponenten. Der Unterschied dazu hingegen ist, dass die Komponenten von Plattform zu Plattform wieder verschieden dargestellt werden können, aber den nativen Komponenten nur ähneln und nicht zu 100% übereinstimmen.
Ein anderer Aspekt ist das Design einer App. Bei der Nutzung von nativen Komponenten ist der Entwickler eingeschränkter was das Design der App angeht, als zum Beispiel bei der Verwendung selbst designter Web Komponenten. Technologien, die die nativen Komponenten verwenden, sind von daher am besten zu bewerten, was die Nutzererfahrung an geht. Darauffolgend kommen die Cross Compile Frameworks, welche ihre Komponenten selber zeichnen oder auch die nativen Komponenten übersetzen. Bei Web Komponenten überwiegen die Nachteile nativen Nutzeroberfläche den Vorteilen einer Plattformübergreifend gleichen Oberfläche.
| Technologie | Punkte |
|---|---|
| Native App | 5 |
| nicht-natives Framework | 5 |
| Cross Compile Framework | 4 |
| Progressive Web App | 2 |
| Hybrid App | 2 |
Native Features
Bei mobilen Anwendungen spielen die nativen Features eines Gerätes häufig eine große Rolle. Die nativen Features eines Gerätes umfassen unter anderem die verbauten Sensoren, wie z.B. das GPS oder Accelerometer, die Kamera, das Mikrofon oder auch die Benachrichtigungstöne oder auch die Kontaktliste. Um diese Features zu nutzen, benötigt die Anwendung eine Möglichkeit mit den Schnittstellen des Betriebssystems zu kommunizieren um so die gewünschte Funktion ansteuern bzw. auslesen zu können.
Bei der Entwicklung von nativen Apps kann eine solche Schnittstelle einfach angefragt werden, ohne dass es einer Brücke bedarf.
Bei Cross Compile Frameworks und nicht-nativen Frameworks benötigt man für viele Features Third-Party-Plugins bzw. schon im Framework enthaltene Plugins. Diese sind in der Regel wieder in nativem Code geschrieben. Je nach Framework gibt es schon mehr oder weniger viele Plugins, so dass man zumindest alle Standard Funktionen in der Regel nutzen kann.
Bei Hybrid Apps ist das Prinzip ein ähnliches. Dort werden der WebView auch mit Hilfe von Plugins die nativen Features nutzbar gemacht. Die Plugins von Hybrid Apps sind in der Regel auch in nativem Code geschrieben. Der Wrapper einer Hybrid App funktioniert also wie eine Brücke zwischen den nativen Features und der WebView. Bei Progressive Web Apps ist der Zugriff auf native Features abhängig von dem Browser in dem die WebView läuft. Die meisten modernen Browser unterstützen allerdings schon sehr viele native Features, welche man mit Hilfe der Webseite whatwebcando.today für den gerade verwendeten Browser heraus finden kann.
Native Apps haben in Hinsicht native Features einen offensichtlichen Vorteil gegenüber anderen Technologien. Bei PWAs ist man vollständig davon abhängig, welche Features der Browser kann. Bei allen anderen Technologien hat man hingegen noch die Möglichkeit selbst Plugins für die nativen Features zu schreiben. Die Punktevergabe erfolgt so, dass viele Punkte bedeuten, dass die Technologie besonders gut für viele native Features ist
| Technologie | Punkte |
|---|---|
| Native App | 5 |
| nicht-natives Framework | 3 |
| Cross Compile Framework | 3 |
| Hybrid App | 3 |
| Progressive Web App | 2 |
Abhängigkeit von anderen Technologien oder Herstellern
Bei der Entwicklung mit Frameworks ist die Abhängigkeit zu anderen Technologien bzw. Herstellern am stärksten. Bei allen vorgestellten Technologien mit einem Framework, also Cross Compile Frameworks, nicht-native Frameworks und Hybrid Apps, kommt man als Entwickler nicht drum herum, Third-Party-Plugins zu benutzen. Diese Plugins werden meist von anderen Entwicklern geschrieben. Benutzt man ein Plugin, ist man davon abhängig, dass der Entwickler des Plugins, dieses für neue Versionen des Frameworks updatet. Diese Abhängigkeit kann natürlich auch bei Progressive Web Apps und nativen Apps entstehen, allerdings ist man dort nicht so dazu gezwungen Plugins zu verwenden wie bei den Frameworks.
Alle Frameworks haben auch zum Teil nativen Code, bzw. sind viele Plugins für die nativen Features in nativem Code geschrieben. Dadurch entsteht über Umwege auch eine Abhängigkeit von der nativen Sprache selber. Wenn Sprachfeatures entfernt werden, die in diesen Plugins genutzt werden gehen die Plugins kaputt und damit auch die eigene Anwendung.
Bei der Entwicklung von Progressive Web Apps und Hybriden Apps ist man auch immer abhängig vom verwendeten Browser, weil die WebView im Hintergrund vom Browser betrieben wird. Dadurch entsteht vor allem das zuvor behandelte Problem mit nativen Features im Falle der Progressive Web App.
Für alle Technologien besteht allerdings eine gemeinsame Abhängigkeit zum Geräte-Hersteller bzw. auch zum Betriebssystem-Hersteller. So ist eine Anwendung darauf angewiesen, dass sich die Schnittstellen zu den Sensoren nicht ändern. Alle Technologien außer der Progressive Web Apps sind zudem vom App Store abhängig, über den die App heruntergeladen werden kann. So muss die App erst durch eine Prüfung kommen, um zu dem App Store zugelassen zu werden. Außerdem hat der App Store Besitzer die Kontrolle darüber, ob eine App im App Store bleibt, nachdem sie bereits aufgenommen wurde und auch über das Bezahlsystem hat der Entwickler selber keine Kontrolle.
Native Apps haben prinzipiell am wenigsten Abhängigkeiten, dicht gefolgt von den Progressive Web Apps, die abhängig vom Browser sind. Nicht-native Frameworks und Cross Compile Frameworks haben viele unterschiedliche nicht gut beeinflussbare Abhängigkeiten und Hybrid Apps haben zusätzlich zu diesen Abhängigkeiten auch noch die Abhängigkeit zum Browser.
| Technologie | Punkte |
|---|---|
| Native App | 4 |
| Progressive Web App | 3 |
| Cross Compile Framework | 2 |
| nicht-natives Framework | 2 |
| Hybrid App | 1 |
Komplexität
Die Komplexität einer Technologie beschreibt, wie schwierig die Entwicklung mit dieser Technologie ist. Der Aspekt der Komplexität lässt sich innerhalb dieses Projekts nur auf die verwendeten Frameworks bzw. Sprachen der einzelnen Technologien zurückführen und ist daher als Kategorie für die Entscheidungsmatrix eher ungeeignet.
Um dennoch einen Vergleich der Technologien durchführen zu können wurden die Beispiel-Apps entwickelt. Vor dem Hintergrund der nur teilweise vorhandenen Vorkenntnisse lässt sich besonders gut vergleichen, wie schwierig es ist die Sprache oder das Framework zu lernen. Die Einlese-Zeit in die jeweilige Sprache oder das Framework ist in der Gesamtentwicklungszeit inbegriffen. Hierbei stechen die Cross Compile Anwendung und die native Anwendung besonders hervor, da hier keine Vorkenntnisse vorhanden waren und dennoch die komplette Beispiel-App entwickelt werden konnte.
Bei der Anwendung mit nicht-nativen Framework waren bereits Vorkenntnisse vorhanden, da bereits mit JavaScript gearbeitet wurde und auch das sehr ähnliche React Framework bereits verwendet wurde. Die Entwicklung an sich war vor allem mit den Vorkenntnissen nicht besonders komplex. Bei der Entwicklung der PWA verhält es sich ähnlich wie bei der Anwendung mit nicht-nativen Framework. Vorkenntnisse mit dem React Framework, welches verwendet wurde, waren bereits vorhanden, wodurch die Entwicklung recht einfach war.
Bei der hybriden App allerdings gab es einige Probleme, da die Dokumentation des verwendeten Frameworks sehr mager war und man viel suchen musste bis man eine Lösung für sein eigentlich einfaches Problem gefunden hat. Zusammenfassend lässt sich zur Komplexität sagen, dass die Technologien generell nicht schwer zu erlernen sind und deshalb im Rahmen der kleinen Beispiel App kaum einen Unterschied gemacht hat.
Wenn Sie die nächsten Artikel der Blogreihe "Technologien mobiler Anwendungen" nicht verpassen wollen, dann folgen Sie newcubator auf den Social Media Kanälen und schauen Sie regelmäßig auf unserer Blogseite vorbei. Im nächsten Artikel vergleichen wir alle bisher vorgestellten Technologien im wirtschaftlichen Vergleich der Technologien.
