In meinem letzten Artikel dieser Blogreihe habe ich Ihnen die nativen Apps vorgestellt. Falls Sie den Artikel noch nicht gelesen haben, sollten Sie dies unbedingt tun, da dieser Artikel über „native Apps mit nicht-nativen Framework" daran anknüpft.
Wie auch im vorangegangenen Artikel schauen wir uns zunächst Vor- und Nachteile der Technologie an. Anschließend wägen wir Risiken und Abhängigkeiten während der Entwicklung ab und werfen einen Blick auf das Know-How am Markt. Zum Schluss betrachten wir noch die Entwicklungskosten und den Entwicklungsaufwand, bevor ich Ihnen schließlich die Ergebnisse meiner Beispiel-App vorstelle.
Die Blogreihe „Technologien mobiler Anwendungen"
Hier finden Sie die Auflistung der einzelnen Blogartikel die zur Blogreihe gehören. Diese Agenda wird mit jedem neu veröffentlichtem Artikel erweitert.
Native Apps mit nicht-nativen Framework
Wirtschaftlicher Vergleich der Technologien
Überblick: Native Apps mit nicht-nativen Framework
Eine native App mit nicht-nativen Framework bezeichnet eine App, die mit einem Framework entwickelt wird, welches nicht die Systemsprache verwendet, aber so übersetzt wird, dass die Anwendung die nativen Komponenten verwendet. Unter der Haube wird das so realisiert, dass die Anwendung selbst in einer Runtime läuft und mit Hilfe einer Bridge mit den nativen Elementen kommuniziert.
Die Anwendung wird, ähnlich wie bei den nativen Apps, für genau eine Plattform entwickelt, allerdings können einige Teile der Anwendung für die andere Plattform wiederverwendet werden. Dadurch spart man sich im Vergleich zu nativen Apps etwas Arbeitsaufwand. Anwendungen können bzw. müssen teilweise in dem nativen Code geschrieben werden, um beispielsweise weitere Komponenten zu schreiben, die das Framework nicht besitzt oder um Sensoren anzusteuern, für die das Framework noch keine eingebaute Kompatibilität hat.
Vor- und Nachteile von nativen Apps mit nicht-nativem Framework
Wohl der größte Vorteil, den nicht-native Frameworks im Vergleich zu nativen Apps bieten, ist die Wiederverwendbarkeit des Quellcodes. Dadurch sparen Sie sich Zeit und Geld in der Entwicklung. Die Wiederverwendbarkeit resultiert auch aus der „learn once, write everywhere“ Philosophie, welche die Frameworks verfolgen. Egal für welche Plattform entwickelt wird, die Programmiersprache ist dieselbe; meistens JavaScript.
Ein weiterer Vorteil ist, dass Sie das gleiche Look & Feel wie das von nativen Apps erreichen können. Dadurch sehen die App Komponenten genauso aus wie bei nativen Apps und die Nutzer sind vertraut mit den UI-Komponenten.
Ein großer Nachteil der nicht-nativen Frameworks ist allerdings die fehlende Sensorunterstützung. Das Verwenden von Sensoren des Handys ist mit nicht-nativen Frameworks nur über Plugins möglich, die entweder schon von anderen entwickelt wurden oder selbst entwickelt werden müssen. Die Plugins selbst werden in der nativen Programmiersprache geschrieben, wodurch für die Entwicklung weiteres Know-How benötigt würde. Da die App in einer Runtime läuft und nur über eine Bridge mit den nativen Komponenten kommuniziert, kann die Anwendung nur Single-Threaded laufen. Es ist also nicht möglich mit solchen Anwendungen mehrere parallellaufende Threads zu benutzen.
Dabei geht es allerdings nur um die physischen Threads. Asynchrone Aufgaben mit sogenannten Promises sind in der JavaScript Runtime von beispielsweise ReactNative durchaus möglich.
Bei der Entwicklung einer App mit nicht-nativen Framework ist es auf Grund der Runtime auch möglich, ein hot reloading zu benutzten. Hot reloading ist ein Feature, welches dazu führt, dass geänderter Code sofort in der Applikation angezeigt wird, ohne, dass diese neugestartet werden muss.
Apps mit nicht-nativen Frameworks werden genauso wie native Apps auf Google Play und im App Store zur Verfügung gestellt.
Risiken und Abhängigkeiten von nativen Apps mit nicht-nativem Framework
Bei der Entwicklung von Apps mit nicht-nativen Framework ist man stark abhängig von Third-Party Modulen, welche die Nutzung von Sensoren möglich machen. Da diese Module nicht von den Framework Entwicklern selbst geschrieben wurden, könnte es passieren, dass ein Modul bei neueren Versionen nicht aktualisiert wird oder sich die Geräteschnittstelle ändert und das Modul dadurch unbrauchbar wird.
Ein großes Risiko bei der Entwicklung ist die Tatsache, dass die Module in nativen Code geschrieben werden müssen. Wenn es noch kein entsprechendes Modul gibt, braucht man native Entwickler, um ein entsprechendes Modul anzufertigen.
Technologien und Markt Know-how
Große Beispiele für nicht-native Frameworks sind React Native und NativeScript. Beide Frameworks basieren auf der Programmiersprache JavaScript.
React Native ist ein von Facebook entwickeltes Open-Source Framework, welches die gleiche Syntax verwendet wie das ebenfalls von Facebook entwickelte JavaScript Framework React, welches in der Web-Entwicklung verwendet wird.
NativeScript ist ebenfalls ein Open-Source Projekt, das von Progress ins Leben gerufen wurde. NativeScript unterstützt ebenfalls die Entwicklung mit den gängigen großen JavaScript Frameworks (Angular, Vue, React, Svelte)
Aus einer Statista Umfrage geht hervor, dass React Native deutlich beliebter ist, öfters verwendet wird und mehr Mitarbeitende dafür gesucht werden, als es bei NativeScript der Fall ist. Auf Github sind die Projekte in den letzten Jahren noch bekannter geworden und konnten einen Anstieg auf ca. 119.000 Sterne (React Native) bzw. 24.200 (NativeScript) Sterne verzeichnen.(Quelle: Statista)
Entwicklungsaufwand und -kosten
Der Entwicklungsaufwand einer App mit nicht-nativen Framework ist geringer als bei der nativen Entwicklung. Das liegt daran, dass für sowohl Android als auch iOS mit nur einem Development-Team entwickelt werden kann, da mit nur einer Sprache für beide Plattformen geschrieben wird.
Auch die Wiederverwendbarkeit von Code-Teilen führt zu einer Reduzierung der Entwicklungsdauer. Wenn Sie eine Anwendung mit vielen nativen Features planen, benötigen Sie sehr wahrscheinlich trotzdem noch weitere Entwickler, die nativ entwickeln können, da die Module wie bereits im vorherigen Kapitel beschrieben in nativem Code geschrieben werden.
Dadurch, dass für beide Plattformen mit einer Sprache geschrieben werden kann, kommen Sie theoretisch mit einem Entwicklerteam aus. Die Entwicklungszeit pro Anwendung ist in der Regel zwar kürzer, allerdings wird man für beide Apps mehr Zeit benötigen, als wenn man zwei native Entwicklerteams parallel entwickeln lässt.
Da beide hier vorgestellten Frameworks auf JavaScript basieren, kann man auch die Gehälter von JavaScript Entwicklern mit den Gehältern von nativen Entwicklern vergleichen. Aufgrund der gemeinsamen Codebasis sind auch die Wartungskosten entsprechend geringer als bei nativen Apps.
Beispiel-App
Für die Beispiel-App wurde das Framework ReactNative gewählt. Die App wurde ebenfalls wie die native App für die Zielplattform Android entwickelt. Bei der Entwicklung traten allerdings mehr Probleme auf als bei der nativen Entwicklung.
Das initiale Projekt wurde mittels der Projekterstellung von IntelliJ aufgesetzt. Die Verwendung eines physischen Gerätes zum Debuggen und Previewen der App war deutlich komplizierter als bei der nativen Entwicklung und hat dementsprechend mehr Zeit gekostet. Die Dokumentation des Frameworks und auch von Third-Party-Modulen sind sehr mager gewesen, wodurch die Verwendung von Third-Party-Modulen deutlich erschwert wurde.
Auffällig war bei der Entwicklung auch, dass sehr viele Standard-Komponenten, wie sie bei der nativen Entwicklung zu finden waren, nicht vorhanden waren oder nur durch weitere Third-Party-Libraries implementiert wurden. Angenehm war bei der Entwicklung im Kontrast zu der nativen Entwicklung allerdings das hot reloading der App. Dadurch musste die App nicht immer wieder neugestartet werden, wenn Änderungen gemacht wurden, sondern diese waren beinahe sofort sichtbar.
Aufgrund der recht großen Hürden musste die Entwicklung nach den geplanten sechs Stunden abgebrochen werden, weil ein erfolgreicher Abschluss des Projektes innerhalb einer annehmbaren Zeit nicht realistisch schien. Grund dafür waren vor allem fehlende Komponenten, deren Erstellung zu lange gedauert hätte. Der Eindruck dieser Beispielentwicklung ist, dass ReactNative für kleine Projekte einen zu großen Aufwand bietet, aber vor allem durch die Wiederverwendbarkeit einzelner Komponenten bei größeren Projekten wahrscheinlich einen besseren Eindruck hinterlassen würde.
Hier nochmal der Erfüllungsgrad der einzelnen Features in einer Tabelle.
++: Feature ist vollständig umgesetzt
+-: Feature ist nur teilweise umgesetzt
--: Feature ist gar nicht umgesetzt
| Anforderung | Erfüllt | Anmerkung |
|---|---|---|
| Uhr | +- | Logik fehlt |
| Runde Progressbar | +- | Logik fehlt |
| Picker für die Zeit | +- | Dialog mit 3 Textfeldern, weil NumberPicker nicht verfügbar sind |
| Play-Button | +- | Logik fehlt |
| Reset-Button | +- | Logik fehlt |
| Vibration | -- | |
| Wecker-Ton | -- |
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 schauen wir uns an, wie man mobile Apps mit Cross Compile Frameworks schreibt.
Sie haben eine Produktidee für eine App und sind sich unsicher, welcher Technologie für Sie die Beste ist? Dann kontaktieren Sie uns gerne für ein unverbindliches Erstgespräch.
