Warum CodeFlügel auf React Native setzt

Das Cross-platform Framework React Native von Facebook hat sich in der Entwicklerszene in den letzten Jahren einen sehr großen Namen gemacht. So setzen viele sehr bekannte und oft genutzte Apps im Hintergrund bereits auf React Native – zum Beispiel die Facebook App, der Facebook Messenger, Discord, Walmart, Instagram, SoundCloud und noch einige mehr. Wieso du dir die Mühe machen solltest, ein kleines Projekt mit diesem Framework zu starten, um auf den Geschmack zu kommen, und wieso CodeFlügel nach zwei Jahren noch immer nicht genug davon hat, erfährst du nur hier.

Falls du dir mit den Begrifflichkeiten React, ReactJS oder React Native noch nicht ganz sicher bist, kann ich dir vorab noch einen meiner früheren Blogposts empfehlen. So, da wir nun alle wissen was React Native ist und wofür es verwendet wird, möchte ich kurz auf die Handhabung dieser Technologie bei CodeFlügel eingehen. Alle verwendeten Technologien und essentiellen Frameworks werden in einer Liste namens „Technology Stack“ zusammengetragen. Somit weiß jeder was zu verwenden ist und worin wir Experten sind. Wenn man sich einmal in die Firma eingelebt hat und jeden beim Vornamen kennt, wirkt es vielleicht beim schnellen Hinblicken unnötig, jedoch zu Beginn oder bei Nicht-Entwicklern ist ein Technology Stack Gold wert. Jede Änderung im Technology Stack wird dann wieder firmenweit bekanntgegeben und neue Technologien werden mit Ansprechpartnern aus dem Entwicklerteam versehen.

Das Kennenlernen mit React Native

Im Mai 2017 war ein ganztägiger Hackathon für alle Mobile- und Webentwickler (+ alle Interessierten aus anderen Bereichen) verpflichtend angesetzt. Im Vorfeld haben sich zwei Entwickler mit Hilfe von Online Kursen und Tutorials einen Überblick über die Technologie verschafft. Am Tag des Hackathons wurden dann noch zwei externe Experten ins Team geholt, um den Einstieg für das ganze Team zu erleichtern. Direkt nach den Basics wurden zwei Gruppen gebildet, die versuchten den gleichen Task individuell umzusetzen. Am Ende des Tages hatte sich das gesamte Team einen groben Überblick über die Technologie und wie man sie verwendet verschafft. In der darauffolgenden Zeit wurden dann intern im kleineren Kreise Projekte umgesetzt, wodurch verschiedenste Scenarios durchgespielt und ausgetestet wurden.

Wann ist React Native die Wahl #1 bei CodeFlügel?

Zurück im Jahr 2019 haben wir unsere Erfahrung mit React Native nicht nur bereits in einigen Kundenprojekten angewandt, sondern auch Wissen in ReactJS für das Webfrontend aufgebaut. Wie man in dieser Branche schnell merkt, bringt jede Technologieentscheidung seine Vor- und Nachteile mit sich, weshalb auch jedes Problem separat analysiert werden muss. Aus diesem Grund wird bei uns Individualsoftware nicht nur auf die Homepage geschrieben sondern auch gelebt. Bei dem einen Projekt bietet sich React Native an, beim nächsten vielleicht nicht mehr – entschieden wird immer pro Projekt. Um diesen Entscheidungsprozess so effizient wie möglich zu gestalten, haben wir ein paar Grundpfeiler für die App-Entwicklung definiert, die uns entweder Richtung native Entwicklung oder React Native lotsen:

React Native

  • – Businesslogik geteilt mit Desktop oder Web
  • – Updates ohne App-Update im Store (Graubereich)
  • – Budget nicht ausreichend für Entwicklung und Wartung von 2 oder mehr Plattformen

Native

  • – AR, VR Anwendungen mit 3D Engine als Basis
  • – Separates Tablet Design
  • – Große Downloads und Datenübertragungen
  • – Viele plattformspezifische Extras (Erweiterungen, Design, UX)

Damit der Blogeintrag nicht den Rahmen sprengt, gehe ich jetzt nicht auf alle Punkte ein, jedoch möchte ich die nicht so offensichtlichen Punkte kurz erklären:

Updates ohne App-Update im Store

Da React Native den gesamten JS-Code und alle Assets bündelt und beim Appstart von einem definierten Ort ausliest, kann diese Datei nachträglich heruntergeladen und ausgetauscht werden. Solange keine nativen Elemente verändert, gelöscht oder erweitert werden, ist dies kein Problem und die Technologie lässt sich somit ideal für Quick Fixes verwenden. Grundsätzlich rate ich aber davon ab, komplette Updates über diese Funktion zu übertragen. Zum einem ist, je nach Änderung des Inhalts der App, dies teilweise von Apple oder Google verboten und zum anderen ist das ganze Ökosystem drumherum und in den zu verwendenden Stores nicht dafür ausgelegt. Wenn Personen mit der gleichen Store-Version dann unterschiedliche Apps mit unterschiedlichen Funktionen vorliegen haben, führt das meist schnell zu Verwirrung und Misstrauen.

Budget

Viel zu häufig wird React Native als cross-plattform Framework falsch interpretiert und somit mit falschen Erwartungen eingesetzt. Klar kann man Zeit (und in weiterer Folge auch Geld) sparen, indem man einmal Code schreibt der auf zwei Plattformen angezeigt wird. Die Krux dabei ist jedoch, dass es immer wieder plattformspezifische Eigenschaften gibt, die separat entwickelt werden müssen bzw. dass manche Feature mehr Zeit beanspruchen als wenn sie jemand native entwickeln würde. Somit geht die Faustregel „Abschätzung zweier native Apps durch 2“ nicht wirklich auf und das sollte jedem Beteiligten bewusst sein. Die wirklichen Einsparungen kommen häufig erst bei Langzeitprojekten zu tragen, da die Wartung und Erweiterung einer Codebasis wesentlich einfacher und effizienter ist als die von zweien. Mein Tipp also: Ein wenig mehr Zeit in die Klärung der Vor- und Nachteile investieren um bösen Überraschungen vorzubeugen.

Große Downloads und Datenübertagungen

Jeder der sich schon näher mit dem Framework beschäftigt hat, weiß, dass ein Worker (thread) für die UI und einer für die Businesslogik (JavaScript) zuständig ist. In den meisten Fällen, wenn die App kurz (oder auch länger ;-)) nicht reagiert, blockiert gerade der JavaScript-Worker und kann somit keine weiteren Befehle abarbeiten. Der Grund dafür ist unter anderem die Schnittstelle zwischen UI und JavaScript Code, welche rein text-basiert arbeitet. JSONs werden über die Bridge an die native Seite geschickt, was bei großen Daten umso länger dauert. Die Funktionen rund um JSON arbeiten nämlich nicht asynchron, so auch nicht die Serialisierung. Nativ hingegen werden wie in React Native zuvor auch die Daten asynchron heruntergeladen. Danach befinden sie sich dort jedoch im Arbeitsspeicher, auf den direkt zugegriffen werden kann.

Fazit

React Native hat sich in den letzten Jahren sehr stark weiterentwickelt und es kommen ständig Neuerungen, die das Arbeiten in diesem Setup leichter oder angenehmer machen. Bei CodeFlügel ist React Native definitiv im Technology Stack, auch wenn die nativen Lösungen der Technologie sehr souverän die Stirn bieten. Somit bleibt die Technologieentscheidung bei jedem Projekt aufs Neue spannend – so wie es sein soll 😉

Stefan

Über den Autor

Stefan

Trotz jahrelanger Abneigung gegenüber Apple Produkten hat es Stefan schlussendlich doch in die IOS Abteilung verschlagen. Nachdem er sich einiges von Freunden und Familie anhören hat müssen, von wegen „ich steige nie auf Apple um“, ist er jetzt sehr zufrieden mit seiner Entscheidung und will alles über Swift und Co. erfahren. Wenn gerade nichts bei Arbeit oder Uni ansteht, geht Stefan gern zum Kraftsport oder hört Musik.