Nur Vergleich zeigen

Einführung

Die Mobile App Framework Matrix zeigt Technologien auf, mit denen sich iOS-/Android-Apps durch eine zentrale JavaScript-Codebasis entwickeln lassen: Dies wird dank bestimmter Frameworks möglich, die Cross-Plattform-Support durch HTML oder eine dynamische Runtime ermöglichen. An dieser Stelle sei erwähnt, dass Windows Phone-Apps nicht betrachtet wurden, da sie von aktuellen Lösungen nicht oder nur teilweise unterstützt werden.
Webentwickler sollen sich ein Bild von den derzeitigen Technologien und ihren Kehrseiten machen können. Da mobile Cross-Plattform-Apps unterschiedliche Anforderungen haben, eignet sich nicht jede Lösung für jedes Szenario. Wenn es um Erweiterbarkeit, Leistung und Skalierbarkeit geht, variieren die Frameworks in verschiedenen Bereichen.

Funktionsweisen

Die hier beleuchteten Frameworks unterscheiden sich in bestimmten Punkten. Wie bereits erwähnt, hängt die Wahl der passenden Technologie stark von den Anforderungen des Projekts ab. Es sollte zudem klar sein, dass bei JavaScript-Lösungen immer Kompromisse eingegangen werden müssen. Entwickler müssen daher eine passende Balance zwischen Leistung und Anpassbarkeit finden. Zudem soll auch gesagt sein, dass die Entwicklung mit einer zentralen JavaScript-Codebasis immer Nachteile oder Einschränkungen gegenüber der nativen Entwicklung mit Objective-C/Swift oder Java aufweist.

Nun folgt eine grobe Übersicht der verschiedenen Technologien. Grundsätzlich gibt es zwei Konzepte, mit denen sich native iOS- und Android-Apps auf Basis eines zentralen JavaScript-Codes realisieren lassen: Mit einem WebView-Wrapper und einer JavaScript-Bridge oder dem Ansatz einer dynamischen Runtime. In beiden Fällen fungiert JavaScript als Abstraktionsebene, über die sich native Funktionalitäten und Geräte-Features ansprechen lassen.

WebView-Wrapper

Die Idee eines WebView-Wrappers ist ein hybrider Ansatz, bei dem Web- und native Technologien zusammen genutzt werden. Die WebView-Komponente (UIWebView unter iOS, WebView unter Android) ist eine rahmenlose Browser-Ansicht ohne Bedienelemente, die eine HTML-Layout-Engine (WebKit/Blink) zur Darstellung einer HTML/CSS-Benutzeroberfläche nutzt. Zusätzlich macht dieser Ansatz Gebrauch von einer JavaScript-Native-Bridge, um zwischen der WebView-Ebene und der nativen Plattform zu kommunizieren. Daher können native APIs sowie Geräte-Features (wie die Kamera) innerhalb des WebViews durch JavaScript genutzt werden.

Den bekanntesten Vertreter dieses Ansatzes stellt PhoneGap/Cordova dar. An dieser Stelle soll klargestellt werden, dass die beiden Frameworks mehr oder weniger gleich sind, aber dennoch als separate Lösungen existieren. Dies kann etwas verwirrend sein, doch wenn man einen Blick auf die Dokumentationen wirft, wird man keine oder nur geringe Unterschiede feststellen: Einige Konventionen und CLI-Commands variieren und so ist es lediglich Geschmackssache, welches Framework verwendet wird. Da die Frameworks von unterschiedlichen Entwicklern (Apache und Adobe) gewartet werden, werden sie auch zukünftig nebeneinander bestehen bleiben.

Dynamische Runtime

Auf der anderen Seite gibt es WORA-Ansatz (Write Once Run Anywhere): JavaScript-Code wird zur Laufzeit evaluiert und füllt die Lücke zu plattformspezifischen Aufrufen. Eine dynamische Runtime (Laufzeitumgebung), die in der nativen Sprache (Objective-C oder Java) entwickelt wurde, agiert als Brücke zwischen nativen Methoden und JavaScript. Derartige Technologien bieten eine einheitliche JavaScript-API, um auf die nativen Funktionalitäten zuzugreifen.

Der Vorteil bei dieser Idee begründet sich darin, dass native Bedienelemente genutzt werden können. Gleichzeitig stellt es einen Nachteil dar, keine HTML-Komponenten verwenden zu können. Allerdings muss hier auch nicht auf eine HTML-Layout-Engine zurückgegriffen werden, um das User Interface darzustellen und so gibt es einen Bereich weniger, der zur Verringerung der App-Leistung führen könnte.

Frameworks

Aktuell gibt es 7 nennenswerte Frameworks und Technologien, die entweder das Konzept eines WebView-Wrappers oder das einer dynamischen Runtime verfolgen. An dieser Stelle sei erwähnt, dass PhoneGap/Cordova in den folgenden Auswertungen nicht betrachtet wurden. Es gibt mittlerweile erweiterte Lösungen, die bereits mit einem MV*-Framework sowie UI-Komponenten ausgestattet sind. Die folgende Liste enthält Links zu den Frameworks sowie eine grobe Beschreibung.

Basierend auf PhoneGap/Cordova

Ionic Ein quelloffenes HTML5-Framework, das auf AngularJS basiert. Es enthält HTML-, CSS- und JavaScript-Komponenten sowie ein auf Node.js basierendes CLI, Live Reload und andere interessante Features.
Telerik AppBuilder Eine Lösung für hybride Apps, die auf jQuery und Kendo UI Mobile basiert und mit vielen UI-Widgets sowie einem optionalem MVVM-Framework kommt. Das visuelle Erscheinungsbild kann durch Themes angepasst werden.
Supersonic Ein hybrides App-Framework, das auf Ionic setzt und erweiterte Funktionen (Cordova-Promises) bietet. Es integriert teilweise native UI-Komponenten und basiert auf einem PhoneGap-kompatiblen WebView-Wrapper, dem AppGyver Wrapper.

Dynamische Runtime

React Native Ein natives Mobile-App-Framework, basierend auf der React-JavaScript-Bibliothek. Es bietet direkten Zugriff auf native UI-Komponenten, erlaubt eine asynchrone Ausführung und kann in verschiedenen JavaScript-Umgebungen ausgeführt werden (Unterstützung für ES5, ES6 und ES7).
Appcelerator Titanium Ein Framework für native Mobile-Apps, das mit einem integrierten MVC-Framework, einer eigenen IDE sowie einem Framework zum Erstellen von APIs kommt. Appcelerator verspricht eine Code-Wiederverwendung zwischen den Plattformen von 60-90%. Auf Appcelerator.org gibt es das quelloffene Titanium-Mobile-Framework.
Tabris.js Ein Cross-Plattform-Mobile-Framework mit Unterstützung für native Widgets. JavaScript-Code wird in Modulen entwickelt und ein Page-Stack-Konzept kommt für das User Interface zum Einsatz. Tabris.js hat ein Subset von W3C-Standards implementiert und unterstützt Cordova-Plugins.
NativeScript Ein quelloffenes Cross-Plattform-Entwicklungssystem, das mit UI-Abstraktionen, einem CSS-Subset, ES5-Features und Support für Third-Party-JavaScript-Bibliotheken kommt. Der gesamte Entwicklungsprozess basiert auf einem Node.js-gestützten CLI.

Vergleich

Die unten stehende Tabelle zeigt einen direkten Vergleich der genannten Frameworks auf dieser Seite. Einige Zellen enthalten zusätzliche Informationen, die durch das Bewegen des Mauszeigers über diese Zelle angezeigt werden können.

Basierend auf PhoneGap/Cordova Ionic Telerik AppBuilder Supersonic React Native Appcelerator Titanium Tabris.js NativeScript
XML-gestützte Views/Komponenten Ionic Telerik AppBuilder Supersonic React Native Appcelerator Titanium Tabris.js NativeScript
UI-Framework enthalten Ionic Telerik AppBuilder Supersonic React Native Appcelerator Titanium Tabris.js NativeScript
UI-Anpassungen via CSS Ionic Telerik AppBuilder Supersonic React Native Appcelerator Titanium Tabris.js NativeScript
Benutzung nativer UI-Komponenten Ionic Telerik AppBuilder Supersonic React Native Appcelerator Titanium Tabris.js NativeScript
Verwendung anderer JavaScript-MV*-Frameworks Ionic Telerik AppBuilder Supersonic React Native Appcelerator Titanium Tabris.js NativeScript
Repository mit Community-Plugins/-Modulen Ionic Telerik AppBuilder Supersonic React Native Appcelerator Titanium Tabris.js NativeScript
Node.js-gestützter Workflow Ionic Telerik AppBuilder Supersonic React Native Appcelerator Titanium Tabris.js NativeScript
Verwendung von CommonJS-Modulen Ionic Telerik AppBuilder Supersonic React Native Appcelerator Titanium Tabris.js NativeScript
Unterstützung von iOS und Android Ionic Telerik AppBuilder Supersonic React Native Appcelerator Titanium Tabris.js NativeScript
Umwandlung nativer Apps in mobile Web-Apps Ionic Telerik AppBuilder Supersonic React Native Appcelerator Titanium Tabris.js NativeScript
Erfordert Online-Registrierung Ionic Telerik AppBuilder Supersonic React Native Appcelerator Titanium Tabris.js NativeScript
Kostenlos Ionic Telerik AppBuilder Supersonic React Native Appcelerator Titanium Tabris.js NativeScript
Teilweise
Einschränkung

Pro und Contra

Obwohl die oben genannten Technologien einen guten Weg zur Umsetzung mobiler Cross-Plattform-Anwendungen darstellen, gibt es dennoch einige Nachteile. Wie bereits erwähnt, hängt die Wahl des Frameworks von den Anforderungen des Projekts ab. Die Frameworks sind an JavaScript-Entwickler gerichtet: Es sollte klar sein, dass iOS- und Android-Entwickler jede Aufgabe in ihrer nativen Sprache umsetzen können. Hier sind einige Fakten, die ein grobes Bild über die Verwendung einer JavaScript-Lösung vermitteln sollen.

Pro JavaScript-Frameworks

  • Kenntnisse in Objective-C/Swift und Java sind nicht oder nur kaum erforderlich
  • die Verwendung nativer IDEs (XCode, Eclipse, etc.) wird nicht oder nur selten benötigt
  • plattformspezifische Anpassungen können leicht implementiert werden
  • Hardware-Features können direkt verwendet werden (API)
  • Prototypen und kleine Anwendungen können schnell umgesetzt werden
  • bestehende native Plugins können komplexe Aufgabe erledigen
  • ein Node.js-gestützter Workflow sorgt für ein schnelles Entwickeln und Testen
  • User Interface-Layouts können für beide Plattformen schneller umgesetzt werden

Contra JavaScript-Frameworks

  • starke Abhängigkeit von Frameworks und deren Wartung/Support
  • native UI-Reaktionszeiten/Performance sind nicht erreichbar mit WebView-Ansätzen
  • erweiterte Hardware-Programmierung erfordert Kenntnisse in einer nativen Sprache
  • App-Leistung und Speicherverwendung können nur gering optimiert werden
  • neue OS/SDK-Features können nicht direkt verwendet werden
  • mögliche Abhängigkeit von Community-Plugins und deren Wartung
  • Performance-Leaks und UI-Fehlverhalten in WebView-Lösungen

Fazit

Die bestehenden JavaScript-Lösungen für das Erstellen nativer iOS- und Android-Apps sind leistungsstark und können die Zeit der Entwicklung erheblich reduzieren. Gleichzeitig muss klar sein, dass es zu Einschränkungen kommen kann und Nachteile entstehen können. Es hängt von den Projektanforderungen und nicht zuletzt von den Fähigkeiten und Neigungen des Entwicklers ab.

App-Leistung und UI-Reaktionszeiten sind die primären Aspekte, wenn es darum geht, eine JavaScript-Lösung zu verwenden oder nicht (native Apps mit zentraler C#-Code-Basis sind mit Xamarin möglich). Es sollte klar sein, dass WebView-Wrapper-Ansätze nie die Qualität nativer UI-Performance erreichen werden. Daher sollten Entwickler mit einem Proof of Concept beginnen, wenn eine HTML-gestützte WebView-Technologie in Betracht gezogen wird: Die Verarbeitung von dynamischen Daten sowie die Optimierung von Formularelementen sind keine trivialen Aufgaben.

Schließlich sei noch erwähnt, dass auch JavaScript-Lösungen ein tiefergehendes Wissen über Paradigmen der Programmierung sowie erweiterte JavaScript-Syntax erfordern. Auch wenn vereinfachte APIs und gute Dokumentationen bereitgestellt werden, kann es einen erheblichen Zeitaufwand bedeuten, um alle Konzepte eines Frameworks zu verstehen und anzuwenden.