Einmal schreiben, überall bereitstellen: Wann sollte man nativ werden?

Write Once, Deploy Everywhere (WODE) war das Versprechen vieler Entwicklungs-Frameworks in den letzten zehn Jahren, deren Ziel es ist, das Schreiben mehrerer nativer Anwendungen zu erleichtern. Die Entscheidung, welchen Weg man einschlagen soll, ist eine der wichtigsten Entscheidungen, die ein Projektmanager treffen muss, aufgrund der hohen Anlaufkosten, der Auswirkungen auf das Entwicklungsteam und der potenziellen Unmöglichkeit, sie rückgängig zu machen.

Hybridlösungen wie Ionic nutzen Webtechnologien, um Anwendungen plattformübergreifend zu rendern, aber oft bleibt das Endprodukt hinter den Erwartungen eines Benutzers an ein natives Erscheinungsbild zurück.

Allerdings wurde selbst der Begriff „nativ“ in letzter Zeit durch Frameworks verunreinigt, die zu nativem Code herunterkompiliert werden (z. B. React Native, Xamarin usw.).

Dieser Artikel schlüsselt die Vor- und Nachteile verschiedener mobiler Entwicklungspfade auf und wägt sie gegen die Zusammensetzung des Teams, die Kosten und die Benutzererfahrung ab, um Produktmanager in die Lage zu versetzen, fundiertere Entscheidungen zu treffen.

Einmal schreiben, überall einsetzen

Das Konzept „ Write Once, Deploy Everywhere “ bezieht sich auf die Fähigkeit eines Entwicklungsteams, eine Anwendung einmal zu schreiben – mit einem einzigen Entwicklungsstapel, einem Auszug aus den Plattformen, auf denen die Anwendung bereitgestellt wird – und dennoch die Fähigkeit zur Bereitstellung aufrechtzuerhalten die Anwendung auf allen gewünschten Plattformen, z. B. Android, iOS, Windows usw. Idealerweise geschieht dies ohne Einbußen bei der Wartbarkeit, Leistung oder Benutzererfahrung (UX).

Die alternative – und historische – Methode der Entwicklung mobiler Anwendungen umfasst den unkomplizierten Prozess, einfach eine separate Anwendung für jede Plattform zu schreiben, was natürlich seine eigenen potenziell hohen Zeit- und Ressourcenkosten mit sich bringt.

Zu den Faktoren, die bei der Auswahl eines Entwicklungspfads zu berücksichtigen sind, gehören im Allgemeinen:

• Alter des Projekts
• Zusammensetzung und Größe des Entwicklungsteams
• Gewünschte Plattform(en) für den Vertrieb
• Erforderlicher Zeitplan für die Markteinführung
• Verfügbare Bandbreite, um bei Bedarf auf einen anderen Pfad zu wechseln

Leider kann es ziemlich entmutigend sein, jeden dieser Faktoren auf jeden der verfügbaren Pfade anzuwenden und sich durch die unzähligen verfügbaren Meinungen zu diesem Thema zu wühlen. Darüber hinaus hinterlässt dieser Prozess beim Projektleiter oft ein Gefühl der Unsicherheit, welcher Weg der beste ist, um die Anforderungen der Anwendung zu erfüllen.

Auf hoher Ebene lassen sich die unterschiedlichen mobilen Entwicklungspfade in zwei Kategorien einteilen: nativ oder WODE, also nativ oder alles andere. Einfach ausgedrückt: Entweder man schreibt eine native Anwendung oder man tut es nicht. Die WODE-Kategorie ist weiter in zwei Gruppen unterteilt:

• Hybride Frameworks – solche, die Webtechnologien nutzen, um Anwendungen auf mehreren Plattformen zu rendern.
• Nicht-Hybrid-Frameworks – solche, die native UI-Komponenten (z. B. Schaltflächen, Textfelder und sogar Layout-Manager) verwenden, anstatt eine Webansicht innerhalb einer Anwendung zu rendern, wie es Hybrid-Frameworks tun.

Die Mehrheit der WODE-Frameworks sind hybrid ; Um jedoch sowohl die Leistung als auch die UX-Einschränkungen von Hybrid-Frameworks zu verbessern und gleichzeitig die Vorteile eines WODE-Frameworks bereitzustellen, geht der aktuelle Trend in Richtung Nicht-Hybrid . Aufgrund dieses Trends gewinnen Frameworks wie React Native, Xamarin und Appcelerator an Popularität.

Jeder dieser Pfade – nativ, hybrid und nicht-hybrid – hat unterschiedliche Stärken und Schwächen und hat daher unterschiedliche Anwendungsfälle, für die er am besten geeignet ist. Der Rest dieses Artikels schlüsselt die Vor- und Nachteile der einzelnen mobilen Entwicklungspfade auf, wenn konkurrierende Prioritäten wie Teamzusammenstellung, Projektkosten und UX berücksichtigt werden. Mit Ausnahme einiger spezieller Anwendungsfälle maximiert das Schreiben nativer Anwendungen die Benutzererfahrung zu etwas höheren Kosten.

Im Allgemeinen gilt das Sprichwort „ Sie bekommen, wofür Sie bezahlen “. Sobald UX jedoch unerlässlich wird, werden native Anwendungen zur klaren Wahl, da WODE-basierte Anwendungen zur Verbesserung der UX erhebliche Kosten in Form von Zeit oder nativem Fachwissen verursachen, was den Zweck der Auswahl eines Nicht-Natives zunichte macht Entwicklungsweg an erster Stelle.

Darüber hinaus liefert das WODE-basierte Endprodukt, selbst wenn diese Kosten bezahlt werden, im Vergleich zu seinem nativen Gegenstück immer eine schlechtere UX. Infolgedessen ist native für die meisten Entwicklungsteams und für die meisten Projekte fast immer die richtige Wahl.

Native Anwendungen

Native Anwendungen werden in der Kernsprache der jeweiligen Plattform geschrieben. Beispielsweise werden Android-Anwendungen in Java geschrieben, während iOS-Anwendungen entweder in Obj-C oder Swift geschrieben werden. Sie erfordern, dass der Entwicklungsingenieur die Sprache sowie die plattformspezifischen Nuancen versteht, zu denen beispielsweise die Paketintegration von Drittanbietern, die Layoutverwaltung, die Interaktion mit dem Betriebssystem (OS) usw. gehören.

Vorteile

Hochgradig anpassbar . Da jede Anwendung unter Verwendung nativer Komponenten geschrieben wird, ist die einzige Einschränkung für die Anpassung die Schnittstelle zu den zugrunde liegenden Frameworks, und manchmal nicht einmal dann. Wie die meisten nativen Entwicklungsingenieure bestätigen werden, gibt es oft eine Möglichkeit, eine bestimmte Aufgabe trotz einer begrenzten Schnittstelle zu erfüllen.

Ein einfacher Beweis für diese Idee kann gefunden werden, indem man die Support-Communities für eine bestimmte Plattform durchsucht. Man findet zahlreiche Beispiele dafür, wie man eine Aufgabe erledigen kann, die trotz der Einschränkungen der zugrunde liegenden Frameworks „außerhalb des Vorbehalts“ liegen könnte.

Ein konkretes iOS-Beispiel für solch eine scheinbar einfache Aufgabe könnte darin bestehen, ein Vollbild-Overlay anzuzeigen , über allen externen UI-Elementen, z normale UI-Schicht, die derzeit präsentiert wird. Um also ein Vollbild-Overlay zu haben, muss es der verborgenen Ebene über der Registerkartenleiste im Ansichtsstapel hinzugefügt werden. Diese Art der Anpassung ist normalerweise nur bei nativen Anwendungen möglich.

Höchste Leistung . Wie zu erwarten, setzt eine native Anwendung den Maßstab für die Leistung. Da die meisten anderen Framework-Typen eine oder mehrere Zwischenschichten hinzufügen, laufen sie von Natur aus langsamer als eine native Anwendung.

Am wartungsfreundlichsten . Betriebssysteme ändern sich ständig. Zeitraum. Wenn dies der Fall ist, muss eine Anwendung je nachdem, ob Breaking Changes vorgenommen wurden, rechtzeitig aktualisiert werden, um nicht den Teil der Benutzerbasis zu verlieren, der auf das neuere Betriebssystem aktualisiert. Je weniger Zeit zwischen der Bereitstellung der Änderung für die Benutzer und der Aktualisierung einer Anwendung vergeht, desto besser. Diese Zeit wird minimiert, wenn keine Abhängigkeiten aktualisiert werden müssen, um dieses neue Betriebssystem zu unterstützen, was bei der Arbeit an einer nativen Anwendung der Fall ist.

Nachteile

Zusätzliche Ressourcen . Beim Schreiben von Anwendungen für mehrere Plattformen besteht ein Entwicklungsteam normalerweise aus einem oder mehreren Entwicklern mobiler Software für jede unterstützte Plattform. Dies erhöht natürlich die Größe und die Kosten eines Entwicklungsteams. Es erfordert auch, dass das Team von Ingenieuren über eine Vielzahl von Fähigkeiten verfügt, im Gegensatz zu einer homogenen Qualifikationsbasis. Dies hat das Potenzial, ein Team in Bezug auf Unterstützung und Zusammenarbeit zu fragmentieren.

Langsamer Entwicklungszyklus . Native Apps haben das Potenzial, einen langsameren Entwicklungszyklus zu haben, einfach weil für jede gewünschte Plattform eine separate Anwendung geschrieben werden muss. Der Extremfall ist, wenn es im Team nur einen einzigen Mobile-Entwicklungsingenieur gibt, da jede Anwendung im Wesentlichen in Serie geschrieben wird.

Geringe Leistung . Es mag seltsam erscheinen, Leistung sowohl als Pro als auch als Contra zu haben. Einerseits geben native Anwendungen dem Entwickler genügend Spielraum, um eine fein abgestimmte, leistungsstarke Anwendung zu erstellen. Andererseits geben sie dem Entwickler aber auch genug Seil, um sich aufzuhängen. Wenn sie nicht wissen, was sie tun, landen sie am Ende bestenfalls bei einer unterdurchschnittlichen Bewerbung.

Hinweis: Im Allgemeinen gilt dies für alle Framework-Pfade (nativ, hybrid und nicht-hybrid). Wenn die Ingenieure, die eine Anwendung entwickeln, unzureichende Kenntnisse für das haben, was sie versuchen, wird die resultierende Anwendung wahrscheinlich weder die Designanforderungen erfüllen noch von den Benutzern gut angenommen werden.

Hybride Anwendungen

Hybridanwendungen werden typischerweise mit HTML/CSS/LESS geschrieben, um die Benutzeroberfläche zu entwerfen: das „V“ im MVC-Entwurfsmuster. Das „C“ oder der Controller wird dann typischerweise in JavaScript geschrieben – idealerweise unter Verwendung eines JavaScript-MVC-Frameworks wie AngularJS. Die Verwendung eines Frameworks wie AngularJS ermöglicht eine bessere Trennung von Klassen und Verantwortlichkeiten, als dies normalerweise nur mit jQuery möglich ist.

Ein Beispiel für diese Art von Hybrid-Framework-Stack wäre ein Ionic-View-Layer mit Unterstützung von AngularJS, der schließlich mithilfe von PhoneGap und Cordova in eine Webansicht auf der gewünschten Plattform konvertiert und gerendert wird. Offensichtlich geht diese Art von WODE-Framework auf Kosten zusätzlicher Komplexität.

Darüber hinaus bringt die Verwendung von JavaScript eigene designbasierte Einschränkungen und sprachbasierte Probleme mit sich. Das Ziel dieses Artikels ist es nicht, die Vorzüge oder Schwächen einer Sprache zu diskutieren; Als Projektmanager sollte man sich jedoch nicht leichtfertig für die Verwendung von JavaScript in seinem mobilen technischen Stack entscheiden. Im Folgenden finden Sie nur einige Beispiele für gut geschriebene Artikel, warum JavaScript möglichst vermieden werden sollte:

• Das JavaScript-Problem
  
• Warum ich kein React Native Developer bin

Vorteile

Minimales Entwicklungsteam . Hybrid-Frameworks ermöglichen es einem kleinen Entwicklungsteam – und insbesondere einem, dessen primäre Wissensbasis die Webentwicklung ist –, schnell einfache Anwendungen für mehrere Plattformen zu erstellen. Dies ermöglicht es einem Projektmanager, sein Team klein zu halten und sein Team nicht mehr die Muttersprachen und Frameworks für mehrere Plattformen lernen zu müssen.

Schnellerer Entwicklungszyklus . Neben einem kleineren Team bieten hybride Frameworks einen schnelleren Entwicklungszyklus bei der Bereitstellung auf mehreren Plattformen, da nur eine einzige Ansichtsebene mithilfe von Webtechnologien entworfen werden muss.

Nachteile

Potenziell schlechte UX . Der Nachteil, nur eine einzige Ansichtsebene schreiben zu müssen, besteht darin, dass nur eine einzige Ansichtsebene übrig bleibt. Dies kann zu einer schlechten UX führen, da ein einheitlicher Ansatz für das UI-Design der eigenen Anwendung kein Erscheinungsbild verleiht, das Benutzern auf allen Plattformen bequem und vertraut ist. Da es sich bei hybriden Anwendungen im Wesentlichen um eine in die Benutzeroberfläche eingebettete Webansicht handelt, können Benutzer außerdem den Eindruck erwecken, dass sie tatsächlich eine Webseite anzeigen, anstatt mit einer nativen Anwendung zu interagieren. Diese Erfahrung wirkt sich fast immer negativ auf die Benutzerzufriedenheit und letztendlich auf die Kundenbindung aus.

Kostspielig anzupassen . Die Verbesserung der UX durch das Entwerfen angepasster UIs für jede Plattform führt zu komplexen und einzigartigen UI-Frameworks, deren Erstellung kostspielig und im Laufe der Zeit schwierig zu warten sein kann. Um UI-Elemente zu erstellen, die dazu beitragen, die eigene Anwendung hervorzuheben (z. B. Animation, benutzerdefinierte Ansichten usw.), müssen außerdem angepasste Brückenkomponenten erstellt werden, um das UI-Design auf hoher Ebene in etwas zu übersetzen, das das Framework auf niedrigerer Ebene ist , wie Cordova, verstehen. Im Allgemeinen gilt: Je mehr man die UX einer Hybridanwendung anpasst und verbessert, desto mehr schmälert es den Vorteil eines schnellen und kostengünstigen Designzyklus.

Geringere Leistung . Da hybride Anwendungen die Ansichten der Anwendung innerhalb einer Webansicht wiedergeben, besteht ein großes Potenzial für Implementierungsfehler beim Umgang mit Betriebssystem-Frameworks (z. B. Netzwerk, Bluetooth, Kontakte auf dem Gerät usw.), was zu einer erheblichen Leistungseinbuße führt. Bemerkenswert ist auch, dass selbst bei größter Sorgfalt in Bezug auf die Leistung, da alles über eine Webansicht angezeigt wird, die maximale Leistung der hybriden Anwendungen immer etwas geringer sein wird als bei ihren nativen Pendants.

Nicht-triviale Plugin-Verwaltung . Erinnern Sie sich an die benutzerdefinierten Funktionen, an denen das Designteam wochenlang gefeilt hat, gefolgt von weiteren Wochen, in denen das Entwicklungsteam die erforderlichen Brückenkomponenten erstellt hat, damit Cordova damit arbeiten konnte? Nun, sie werden nicht funktionieren, es sei denn, es gibt ein unterstützendes Cordova-Plugin für das, was das Team zu erreichen versucht. Das bedeutet eines von zwei Dingen: Entweder das Team erstellt es selbst oder es muss ein geeignetes Plugin eines Drittanbieters gefunden werden, das die Arbeit erledigt. Leider gibt es Option zwei meistens nicht. Infolgedessen erfordert es zusätzliche Entwicklungszeit, um die benutzerdefinierten Plugins zu erstellen, gefolgt von Build-Support-Aufwand – im Laufe der Zeit – um die wachsende Bibliothek von Cordova-Plugins zu verwalten, die von der Anwendung benötigt werden. Wenn Cordova-Updates auftreten, besteht natürlich eine hohe Wahrscheinlichkeit, dass diese Plugins ebenfalls aktualisiert werden müssen.

Verzögerung der Betriebssystemunterstützung . Das zuvor erwähnte Problem der kaskadierenden Brückenkomponente/des Cordova-Plug-Ins wird weiter verschärft, wenn das Betriebssystem die Kernfunktionalität ändert. Sobald Cordova, PhoneGap und Ionic aktualisiert wurden, um die Änderungen zu unterstützen, ist es möglich, dass die benutzerdefinierten Plugins und Bridge-Komponenten ebenfalls aktualisiert werden müssen. Unabhängig von der Größenordnung, die diese Arbeit erfordern würde, führt dies zu zusätzlicher Zeit, während der die Anwendung Endbenutzer, die auf das neue Betriebssystem aktualisiert haben, nicht unterstützt. Dies ist natürlich ein Worst-Case-Szenario, in dem fehlerhafte, nicht abwärtskompatible Änderungen von Apple oder Google vorgenommen werden, was niemals passiert … richtig? Im Allgemeinen dient jedes Zwischenframework, das außerhalb der Kontrolle des Entwicklers liegt und zuerst aktualisiert werden muss, nur dazu, den Prozess zu verzögern. Schließlich kann es für Projektmanager schwierig sein, sich auf ein Zwischen-Framework zu verlassen, da das Timing dieser Frameworks so unbekannt ist.

Nicht-Hybrid-Anwendungen

Nicht-hybride Anwendungen beginnen ihr Leben genau wie ihre hybriden Gegenstücke – eine UI-Schicht, die in einer nicht-nativen Plattformsprache entworfen wurde: React Native verwendet HTML/CSS mit Unterstützung von JavaScript oder Xamarin, das aufgrund seiner .NET-Wurzeln auf C# basiert.

Hier endet jedoch die Ähnlichkeit. Nicht-Hybridanwendungen werden zu nativem Code herunterkompiliert und die Anwendung mithilfe von plattformeigenen Komponenten gerendert, anstatt über eine Webansicht zu rendern. Das Ergebnis ist ein WODE-Framework, das zumindest oberflächlich das Beste aus beiden Welten vereint.

Wie bereits erwähnt, sollte die Entscheidung für die Verwendung von JavaScript keine leichtfertige Entscheidung sein, und sie könnte ein Deal-Breaker für ein Entwicklungsteam sein, das nicht lernen möchte oder kein Interesse daran hat, JavaScript zu verwenden.

Vorteile

Höhere Leistung als Hybride . Wie zu erwarten, haben Nicht-Hybride von Natur aus eine höhere Leistung als Hybridanwendungen, da sie die Anwendung mithilfe nativer UI-Komponenten (Schaltflächen, Ansichten, Layout-Manager usw.) rendern können, anstatt sich auf eine eingebettete Webansicht zu verlassen. Natürlich steht es den Entwicklern immer noch frei, eine Anwendung zu schreiben, die entweder bemerkenswert oder schrecklich funktioniert. Der Vorteil von Nicht-Hybridanwendungen besteht einfach darin, dass sie im Vergleich zu ähnlichen Hybridanwendungen eine höhere Leistungsbasis haben.

Minimales Entwicklungsteam . Ähnlich wie hybride Frameworks ermöglichen Nicht-Hybride einem kleinen Entwicklungsteam – und insbesondere einem, dessen primäre Wissensbasis die Webentwicklung ist – schnell einfache Anwendungen für mehrere Plattformen zu erstellen. Auf diese Weise können Projektmanager ihr Team klein halten und verhindern, dass das Team die Muttersprachen und Frameworks für mehrere Plattformen lernt.

Schnellerer Entwicklungszyklus . Neben einem kleineren Team bieten nicht-hybride Frameworks einen schnelleren Entwicklungszyklus bei der Bereitstellung auf mehreren Plattformen, da nur eine einzige Ansichtsebene entworfen werden muss.

Schnellere Iterationen (Reagieren) . Das React-Framework bietet eine leistungsstarke Funktion, mit der Änderungen an der Anwendung in Echtzeit gerendert werden können: Es ist keine Neukompilierung, Neuerstellung usw. erforderlich. Daher ist der React-Emulator ein unglaublich leistungsstarkes Entwicklungstool, das die Dauer jeder Implementierung drastisch verkürzt Kreislauf.

Nachteile

Kostspielig anzupassen . Ähnlich wie bei seinem hybriden Gegenstück führt dies, wenn nicht-hybride Anwendungen eine Verbesserung der UX durch das Entwerfen angepasster UIs für jede Plattform erfordern, zu komplexen und einzigartigen UI-Komponenten, deren Erstellung kostspielig und im Laufe der Zeit schwierig zu warten sein kann. Das bedeutet auch, angepasste Bridge-Komponenten zu schreiben, um Lücken in der nativen Elementunterstützung des Frameworks zu schließen. Wie bei Hybriden verringern diese Kosten den Vorteil eines schnellen und kostengünstigen Designzyklus, aber im Gegensatz zu Hybridanwendungen werden Bridge-Komponenten für jede gewünschte Plattform in ihrer Muttersprache geschrieben . Anstatt dass nicht-hybride Anwendungen eine flexible Alternative zu einem Team sind, das hauptsächlich aus Webentwicklern besteht, müssen Teams, die den nicht-hybriden Weg wählen, nicht nur die spezielle Sprache des Frameworks (z. B. JSX oder C#) lernen, sondern auch auch die Muttersprache jeder Plattform (Java, Obj-C oder Swift).

Abhängigkeiten von Drittanbietern . Diese Begrenzung nimmt zwei unterschiedliche Formen an. Im Fall von React Native nimmt es die Form zahlreicher Abhängigkeiten an, dh ungefähr 650. Das Ergebnis ist, dass es zu einem bestimmten Zeitpunkt sehr wahrscheinlich ist, dass eine oder mehrere dieser Abhängigkeiten veraltet sind. Dies bedeutet auch, dass im Falle einer großen Änderung auf Betriebssystemebene eine hohe Wahrscheinlichkeit besteht, dass die meisten oder alle dieser Abhängigkeiten aktualisiert werden müssen. Die potenzielle Rettung ist, dass Facebook React verwendet, sodass man den 300-Pfund-Gorilla in seiner Ecke hat.

Im Fall von Xamarin besteht das Problem der Abhängigkeit von Drittanbietern einfach darin, dass es äußerst schwierig ist, sie überhaupt zu integrieren. Xamarin ist sich dieses Problems bewusst und stellt ein Dienstprogramm namens Sharpie bereit. Der Zweck des Tools besteht darin, bei einem Teil der Integration zu helfen, aber leider versucht Sharpie oft, falsche Ressourcen zu kompilieren und zu verknüpfen, was den Entwickler dazu zwingt, die mühsame und zeitaufwändige Aufgabe zu übernehmen, Low-Level-Kompilierungsparameter manuell zu ändern, um erfolgreich abzuschließen die Integration.

Verzögerung der Betriebssystemunterstützung . Nicht-Hybridanwendungen werden von demselben Problem geplagt wie Hybridanwendungen. Jedes zwischengeschaltete Framework, das außerhalb der Kontrolle des Entwicklers liegt und zuerst aktualisiert werden muss, dient nur dazu, den Prozess der Aktualisierung der eigenen Anwendung zu verzögern, um hochmoderne Benutzer zu unterstützen. Darüber hinaus kann es, wie bereits erwähnt, für Projektmanager schwierig sein, sich auf einen Zwischenrahmen zu verlassen, da das Timing dieser Rahmen so unbekannt ist.

Langfristige Unterstützung (React Native) . Dieses Problem ist spezifisch für React Native und bezieht sich auf die seltsame Tatsache, dass Facebook sich bis heute nicht zu einem langfristigen Supportplan für sein Framework verpflichtet hat. Es kann gesagt werden, dass dies ein geringes Risiko ist, da das Unternehmen ein eigenes Framework für seine mobilen Apps verwendet, aber es lohnt sich für jeden Projektmanager, darüber nachzudenken, warum Facebook sich geweigert hat, sich zu diesem Thema zu äußern.

Die Wahl des richtigen Ansatzes

Wenn die Kosten keine primäre Überlegung sind, zeigt Abbildung 2 , dass das Schreiben nativer Anwendungen fast immer die beste Wahl ist, wenn es darum geht, die Zusammensetzung des Entwicklungsteams gegen die Anforderungen der Anwendung einzusetzen. Wenn es weniger Entwicklungsingenieure als gewünschte Plattformen gibt, wird es etwas interessanter. In diesem Fall ist die Verwendung von React die richtige Wahl, wenn das Team einen sehr engen Release-Zeitplan hat; Andernfalls ist es immer noch die beste Option, nativ zu werden.

Wenn das Team in erster Linie ein Webentwicklungsteam ist und eine angepasste UX erforderlich ist, ist es besser, einige Teammitglieder den Hut wechseln zu lassen oder einige Teammitglieder hinzuzufügen, um die eigenen Anwendungen nativ zu machen. Es gibt wirklich keine realisierbare, wartbare Framework-Option, wenn eine Anwendung benutzerdefinierte Elemente erfordert, was bei vielen Anwendungen der Fall ist.

Wenn jedoch keine benutzerdefinierte UX erforderlich ist, ist es je nach Veröffentlichungsplan möglicherweise besser, sich für Ionic oder React zu entscheiden. Wenn das eigene Team keine Zeit hat, JSX zu lernen, ist Ionic die richtige Wahl. Andernfalls ist es besser, React zu wählen, da es bereits viele Abhängigkeiten von Drittanbietern erfordert und das Hinzufügen weiterer den eigenen Entwicklungszyklus nicht beeinträchtigt.

Sobald die Kosten des Projekts ein vorrangiges Anliegen sind, wird die bestehende Teamzusammensetzung in der Regel weniger wichtig, da der erste Schritt darin besteht, das richtige Team einzusetzen, um den Projektplan für die prognostizierten Kosten auszuführen. Wie in Abbildung 3 gezeigt, haben native Anwendungen höhere Anfangskosten als ihre WODE-Pendants, aber auch ein höheres potenzielles UX. Darüber hinaus werden WODE-Anwendungen immer in ihrer UX begrenzt sein, unabhängig davon, wie viel Geld und Ressourcen für das Projekt aufgewendet werden.

Ich hoffe, dass dieser Artikel etwas Licht in die Vor- und Nachteile verschiedener mobiler Entwicklungspfade geworfen hat und dabei geholfen hat, die Zusammensetzung des Teams sowohl gegen die Anwendungsanforderungen als auch gegen die Kosten des Projekts abzuwägen. Seine Botschaft sollte nicht vermitteln, dass WODE-Frameworks minderwertig sind und niemals gesucht werden sollten, sondern dass man, obwohl es gültige Anwendungsfälle dafür gibt, nicht nativ zu werden, die Auswirkungen vollständig verstehen sollte.