Native oder hybride Anwendung

Nachteile von Hybridanwendungen

Sobald eine Hybrid-App entwickelt ist, kann sie sowohl auf Android als auch auf dem iPhone laufen. Um beide Systeme bedienen zu können, wird eine zusätzliche „Übersetzungsschicht“ verwendet, die den beiden Apps vorschreibt, was sie tun können und was nicht. Dadurch wird eine zusätzliche, unnötige Abhängigkeit in die App aufgenommen, die sowohl kurz- als auch langfristig zu Problemen bei der Entwicklung, dem künftigen Betrieb und der Wartung der App führen kann.

Aus diesem Grund wird eine hybride App nicht so gut funktionieren wie eine native App und es gibt Einschränkungen beim Zugriff auf die Gerätehardware. Da eine hybride App eine Übersetzungsschicht enthält, die von einem Drittanbieter (z. B. Microsoft, Facebook oder Adobe) bereitgestellt wird, besteht eine unangemessene Abhängigkeit von dem Anbieter der Software, die diesen Übersetzer erstellt. Dies kann zu Unannehmlichkeiten führen, wenn die App läuft und wenn Apple und Android ihre Betriebssysteme aktualisieren.

Darüber hinaus werden hybride Entwicklungssprachen in großen Organisationen entwickelt, die in erster Linie darauf abzielen, Anwendungen für ihre eigenen Produkte zu entwickeln. Aus demselben Grund besteht nur ein begrenztes Interesse an der Entwicklung von Funktionen, die nicht für ihre eigene Plattform bestimmt sind. Beispiele hierfür sind:

React Native wird von Facebook für seine eigene Plattform entwickelt

Xamarin wird von Microsoft für seine eigene Plattform entwickelt

Flutter wird von Google für seine eigene Plattform entwickelt

Außerdem basieren hybride Tools, obwohl React „nativ“ im Namen trägt, auf Webtechnologie und nicht auf App-Technologie. Wenn die App eine Funktion nutzen muss, die von der Hybrid-Plattform noch nicht unterstützt wird, muss nativer iOS- und Android-Code entwickelt werden, und hier kommt der Hybrid-Entwickler schnell ins Hintertreffen.

Das Gleiche gilt für die Integration mit Diensten von Drittanbietern. Die überwiegende Mehrheit der Dienste von Drittanbietern entwickelt nur SDKs (Entwicklungskits/-tools) für iOS und Android. Daher können Sie deren SDKs erst dann verwenden, wenn ein Übersetzer für die gewählte Hybridsprache entwickelt wurde.

Oft muss ohnehin ein einheimischer Entwickler hinzugezogen werden.

Grundsätzlich sollten Sie eine reine Hybridlösung immer als die Möglichkeit sehen, den kleinsten gemeinsamen Nenner auf den beiden Plattformen zu nutzen, d. h., wenn etwas nur auf einer Plattform verfügbar ist, wie z. B. NFC-Lesen oder Ähnliches, können Sie dies nicht in einer Hybridlösung nutzen, da es auf beiden Plattformen verfügbar sein muss.

Sie können sich jedoch dafür entscheiden, einen Teil der nativen Entwicklung als „Skin“ auf Ihre hybride Lösung aufzusetzen, um bestimmte Plattformmöglichkeiten zu erschließen. In diesem Fall muss ein nativer Entwickler hinzugezogen werden, was die Einsparungen, die die hybride Entwicklung mit sich bringt, verringert. Außerdem erhöht sich dadurch die Komplexität, was sich auf die Zuverlässigkeit auswirkt.

Vorteile von Hybridanwendungen

Hybride Lösungen sind in der Regel billiger als native Lösungen. Zumindest auf kurze Sicht. Außerdem können Sie ein kleineres Team/eine kleinere Person mit der Aufgabe betrauen, da dieselbe(n) Ressource(n) die Aufgabe für beide Plattformen übernimmt/übernehmen – sofern keine nativen Elemente in die hybride App entwickelt werden müssen, was bei den meisten Hybridlösungen früher oder später der Fall ist. Natürlich kann es als Vorteil angesehen werden, dass die Option, native Module zu verbinden, überhaupt vorhanden ist.

Hybride Lösungen sind ideal für kleinere Projekte und Prototypen mit geringeren Anforderungen an die App-Leistung