Flutter, React Native oder nativ: Wahl nach Kriterien
Flutter, React Native und native Entwicklung im Vergleich nach Performance, Team, Wartung, Gerätefunktionen und Budget, damit Sie den passenden Weg wählen.
rabbitclip-TeamVeröffentlicht: 6 Min. Lesezeit
Kurz gesagt
Die Wahl zwischen Flutter, React Native und nativ ist die Entscheidung, ob die App aus einer Codebasis für beide Stores gebaut wird oder aus getrenntem Code für jede Plattform, und, falls es eine Codebasis ist, mit welchem Toolkit. Nativ bedeutet, getrennten Code für iOS und für Android zu schreiben und die eigenen Werkzeuge der jeweiligen Plattform zu nutzen. Flutter und React Native zielen beide mit weitgehend gemeinsamem Code auf die beiden Plattformen; jedes ist ein ausgereifter, weit verbreiteter Ansatz, der für genau diesen Zweck gebaut wurde. Die richtige Wahl ergibt sich nicht aus einer Rangliste. Sie ergibt sich aus den Anforderungen des Produkts, den Fähigkeiten des Teams und dem Plan für die Wartung.
Dieser Artikel lobt keine Seite. Er stellt die drei Ansätze an denselben Kriterien nebeneinander und erklärt, in welcher Situation jeder das geringere Risiko trägt. Auch unsere Artikel über den Bau einer mobilen App mit Flutter und über mobile App oder PWA berühren das Thema; hier geht es darum, wo die drei Entwicklungsansätze im Verhältnis zueinander stehen.
Wie unterscheiden sich die drei Ansätze?
Bei der nativen Entwicklung wird die iOS-App in der eigenen Sprache und mit den eigenen Werkzeugen der Plattform geschrieben und die Android-App in ihren eigenen. Am Ende haben Sie zwei Codebasen. Sie erhalten als Erste Zugriff auf neue Funktionen jeder Plattform und die direkteste Verbindung zu den Gerätefähigkeiten, aber die Arbeit wird doppelt erledigt.
Flutter ist ein Toolkit, das die Oberfläche mit einer eigenen Rendering-Engine selbst zeichnet und die Sprache Dart verwendet. React Native wird in JavaScript oder TypeScript geschrieben und zeigt die Oberfläche über die eigenen Komponenten der Plattform. Beide wollen mit einem Team in zwei Stores ausliefern; sie unterscheiden sich darin, wie die Oberfläche erzeugt wird und welche Sprache das Team kennt.
Nach welchen Kriterien sollten Sie vergleichen?
Damit die Wahl nicht zu einer Technologiedebatte wird, schreiben Sie zuerst die Kriterien auf und bewerten Sie jedes für Ihr eigenes Produkt. Ist ein Kriterium für Sie kritisch, entscheidet es die Sache, so gut die übrigen auch aussehen.
An jedes Kriterium wird dieselbe Frage gestellt: Wie wenig Risiko trägt dieser Ansatz dabei, die Anforderungen dieses Produkts zu erfüllen? Die Antworten fallen meist nicht als Zahlen aus, sondern als Unterscheidung wie «unproblematisch», «braucht Sorgfalt» und «schwierig».
- Team: Sprache und Erfahrung der Entwickler, die Sie haben oder finden können
- Gerätefunktionen: plattformnahe Anforderungen wie Kamera, Sensoren, Bluetooth und Hintergrundarbeit
- Oberfläche und Animation: markenspezifisch und visuell aufwendig oder das Standardaussehen der Plattform
- Wartung: wer die Versionsupdates und Bibliotheksänderungen beider Plattformen verfolgt und wie
- Zeit und Budget: ein Team oder zwei, und wie dringend die erste Veröffentlichung ist
In welcher Situation hat welcher Ansatz die Nase vorn?
Liegt das Produkt sehr nah an der Plattform, etwa bei intensiver Nutzung von Kamera und Sensoren, Arbeit, die dauerhaft im Hintergrund läuft, Erweiterungen für Uhr und Auto oder dem Bedarf an den neuesten Plattformfunktionen ab dem ersten Tag, bringt nativ meist die wenigsten Überraschungen. Der Preis ist die Pflege zweier Codebasen und meist zweier Teams.
Wenn die Oberfläche auf beiden Plattformen identisch und markenspezifisch aussehen soll und das Team offen ist, eine neue Sprache zu lernen, ist Flutter ein natürlicher Kandidat. Hat Ihr Team Webentwickler, die JavaScript oder TypeScript bereits kennen, ist React Native der kürzeste Weg, vorhandene Fähigkeiten zu nutzen, und auch der Austausch von Code und Wissen zwischen Web und Mobil kann leichter werden.
Diese Sätze beschreiben allgemeine Tendenzen, keine Regeln. Erfolgreiche, schnelle und ansprechende Apps werden mit allen drei Ansätzen geschrieben; Probleme entstehen meist durch ein Missverhältnis zwischen Produkt und Werkzeug, nicht durch das Werkzeug. Bevor Sie entscheiden, verkürzt deshalb ein kleiner Versuch die Debatte, in dem Sie den riskantesten Bildschirm oder die riskanteste Funktion des Produkts mit jedem Kandidaten testen.
Wie beeinflussen Team und Wartung die Wahl?
Mit der Veröffentlichung der App endet die Arbeit nicht. Jedes Jahr bringen beide Plattformen neue Versionen heraus, Bibliotheken ändern sich und Store-Regeln werden aktualisiert. Bei plattformübergreifenden Werkzeugen müssen diese Änderungen sowohl von der Plattform als auch vom Toolkit selbst aufgefangen werden. Bei nativ wird dieselbe Änderung zweimal in zwei getrennten Codebasen vorgenommen.
Auch die menschliche Seite zählt. Überlegen Sie, wer die Person ersetzen würde, die das gewählte Werkzeug kennt, falls sie geht, und wie lebendig die Community und die Dokumentation des Werkzeugs sind. Wägen Sie das nicht nach Gefühl ab, sondern an der tatsächlichen Lage auf Ihrem eigenen Markt, Entwickler in dieser Sprache zu finden.
- Wer die jährlichen Versionsupdates beider Plattformen verfolgt
- Wer eine Bibliotheksinkompatibilität im gewählten Werkzeug löst
- Wie leicht sich ein ausscheidendes Teammitglied ersetzen lässt
- Wie aktuell die Dokumentation und die Community des Werkzeugs sind
Welche Fehler passieren bei der Technologiewahl häufig?
Der häufigste Fehler ist, die Wahl der Beliebtheit oder Online-Argumenten zu überlassen. Ein Werkzeug, das in einem anderen Unternehmen funktioniert hat, liefert mit Ihrem Team und Ihrem Produkt vielleicht nicht dasselbe Ergebnis. Der zweite ist die Annahme, plattformübergreifend sei immer günstiger; eine Codebasis verringert den Entwicklungsaufwand, aber plattformspezifische Teile und die Wartung kosten dennoch Mühe.
Der dritte ist, bei der Entscheidung nur an die erste Veröffentlichung zu denken. Wer die App in drei Jahren pflegt, ist oft wichtiger als die Frage, wie schnell die erste Version erschien.
- Die Wahl der Beliebtheit oder Online-Debatten überlassen
- Annehmen, plattformübergreifend sei in jedem Fall günstiger
- Nur an die erste Veröffentlichung denken und die Wartung nicht einrechnen
- Entscheiden, ohne die riskanteste Funktion auszuprobieren
Wann ist dieser Vergleich die falsche Frage?
Zeigt Ihr Produkt überwiegend Inhalte, füllt Formulare aus und braucht kaum Funktionen wie Store-Präsenz oder Benachrichtigungen, lautet die eigentliche Frage, ob es eine mobile App oder eine PWA sein soll; einer der drei Entwicklungsansätze folgt aus dieser Frage. Prüfen Sie zuerst, ob das Produkt wirklich eine App braucht.
Stehen Sie noch im Ideenstadium, ist auch die Wahl einer Technologie verfrüht. Testen Sie die Idee zuerst mit einem Prototyp; die Wahl fällt gesünder aus, wenn klar ist, was wirklich gebaut wird. Es gibt weitere Optionen, aber wer die Überlegungen hinter diesen dreien versteht, hat auch eine gute Grundlage, sie zu beurteilen.
Für Flutter, React Native und nativ gibt es keine einzelne richtige Antwort. Die richtige Antwort ergibt sich aus den Anforderungen des Produkts, den Fähigkeiten Ihres Teams und Ihrem Plan für die Wartung. Schreiben Sie zuerst Ihre Kriterien auf, testen Sie die riskanteste Funktion in einem kleinen Versuch und rechnen Sie die Wartung über die erste Veröffentlichung hinaus mit ein. Wenn Sie die drei Ansätze für Ihr eigenes Produkt abwägen möchten, können Sie mit rabbitclip ein Erstgespräch vereinbaren.
Häufige Fragen
Ist Flutter oder React Native besser?
Im Allgemeinen ist keines besser als das andere; je nach Sprache des Teams, Anforderungen an die Oberfläche und Wartungsplan trägt das eine weniger Risiko. Teams, die Dart kennen oder lernen möchten und eine markenspezifische Oberfläche wollen, neigen zu Flutter, Teams, die JavaScript kennen, zu React Native.
Ist native Entwicklung noch notwendig?
Bei Produkten, die sehr nah an der Plattform liegen, etwa Apps mit intensiver Kamera-, Sensor- oder Hintergrundarbeit, und wenn Sie die neuesten Plattformfunktionen ab dem ersten Tag brauchen, bringt nativ die wenigsten Überraschungen. Für viele Business-Apps ist sie nicht erforderlich.
Ist eine plattformübergreifende App immer günstiger?
Nein. Eine Codebasis verringert meist den Entwicklungsaufwand, aber plattformspezifische Teile, Tests und Wartung kosten dennoch Mühe. Die Kosten bestimmen Umfang, Zahl der Integrationen und Wartungsplan, nicht der Name des Werkzeugs.
Kann man später von einem Ansatz zum anderen wechseln?
Man kann, aber es bedeutet, den größten Teil der App neu zu schreiben. Deshalb ist es günstiger, am Anfang sorgfältig zu wählen, indem Sie die riskanteste Funktion in einem kleinen Versuch testen und die Wartung einrechnen.
