Von Slavko Tomcic, CTO der appsolute GmbH
Wenn ein Kunde zu uns kommt und sagt „Wir brauchen eine App für iOS und Android“, dann fällt intern fast immer dasselbe Wort: Flutter. Nicht weil wir nichts anderes können – wir entwickeln seit 2008 nativ mit Swift und Kotlin – sondern weil Flutter in den meisten Fällen die bessere Wahl ist. Aber eben nicht in allen.
Ich will hier keine Feature-Tabelle mit grünen Häkchen aufstellen. Davon gibt es genug im Netz. Stattdessen erkläre ich, wie wir bei appsolute die Entscheidung zwischen Flutter und React Native treffen, was dabei den Ausschlag gibt, und wann wir von beidem abraten.
Was Flutter und React Native gemeinsam haben
Beide Frameworks lösen dasselbe Problem: Sie ermöglichen Cross-Plattform-Entwicklung, also eine App für iOS und Android aus einer Codebasis. Das spart gegenüber zwei separaten nativen Apps erheblich Zeit und Geld – in der Praxis sehen wir 30–40% weniger Aufwand.
Beide Frameworks sind ausgereift, haben große Communities und werden von Tech-Giganten gepflegt: Flutter von Google, React Native von Meta. Beide können performante, gut aussehende Apps produzieren. Die Frage ist nicht, ob eines davon „schlecht“ ist – sondern welches besser zu einem konkreten Projekt passt.
Wo Flutter die Nase vorn hat
UI-Konsistenz: Flutter rendert alles selbst – es nutzt nicht die nativen UI-Komponenten des Betriebssystems, sondern zeichnet jeden Pixel mit der eigenen Rendering-Engine (Skia, seit Flutter 3 Impeller). Das klingt erstmal nach Nachteil, ist aber in der Praxis ein Riesenvorteil: Die App sieht auf iOS und Android identisch aus. Kein „das sieht auf dem iPhone anders aus als auf dem Samsung“. Für Kunden, denen ein einheitliches Markenerlebnis wichtig ist, ist das ein starkes Argument.
Performance: Flutter kompiliert zu nativem ARM-Code. React Native lief lange über eine JavaScript-Bridge, die bei komplexen UIs spürbar gebremst hat. Meta hat das mit der New Architecture (JSI, Fabric) deutlich verbessert – aber Flutters Ansatz ist architektonisch eleganter und in unseren Benchmarks konsistent schneller, besonders bei aufwendigen Animationen und Scroll-Verhalten.
Hot Reload: Beide haben Hot Reload, aber Flutters Version ist zuverlässiger. Ich kann den State einer laufenden App ändern, ohne sie neu starten zu müssen. Bei React Native musste ich in der Vergangenheit öfter einen kompletten Rebuild machen, weil der Hot Reload den State verloren hat. Klingt nach Kleinigkeit, summiert sich aber über Wochen Entwicklungszeit.
Custom Designs: Wenn ein Kunde ein individuelles UX/UI-Design will, das sich von Standard-Apps abheben soll, ist Flutter unschlagbar. Die Widget-Bibliothek ist so flexibel, dass wir praktisch jedes Design umsetzen können, ohne auf native Workarounds zurückgreifen zu müssen.
Wo React Native Stärken hat
Ich wäre kein guter CTO, wenn ich nicht auch die andere Seite beleuchten würde.
Bestehendes JavaScript-Team: Wenn ein Unternehmen bereits ein starkes Web-Team mit React-Erfahrung hat, ist React Native die naheliegende Wahl. Die Lernkurve ist deutlich flacher als bei Flutter mit Dart. Für Teams, die schnell produktiv sein müssen und React schon kennen, kann das entscheidend sein.
Web-Integration: React Native teilt sich die Codebasis leichter mit einer bestehenden React-Webanwendung. Wenn ein Unternehmen bereits eine React-basierte Webapp hat und diese um eine mobile App ergänzen will, ist React Native architektonisch im Vorteil.
Ökosystem: React Natives npm-Ökosystem ist riesig. Für fast jedes Problem gibt es ein Package. Flutters pub.dev wächst schnell, ist aber in manchen Nischenbereichen noch nicht so breit aufgestellt.
Warum wir uns für Flutter entschieden haben
Bei appsolute haben wir ab 2019 erste Projekte mit Flutter umgesetzt und dabei gemerkt, dass unsere Entwickler schneller produktiv waren als erwartet. Dart als Sprache liegt näher an Java und Swift als JavaScript – und das ist relevant, weil unser Team aus der nativen Entwicklung kommt, nicht aus der Web-Welt.
Was mich persönlich überzeugt hat: die Vorhersagbarkeit. Wenn ich in Flutter ein Widget baue, verhält es sich auf jedem Gerät gleich. Bei React Native hatten wir in der Vergangenheit immer wieder Situationen, wo etwas auf iOS funktioniert hat, aber auf einem bestimmten Android-Gerät nicht – weil die nativen Komponenten sich je nach Hersteller leicht unterschiedlich verhalten. Flutter umgeht das komplett.
Dazu kommt: Google investiert massiv in Flutter. Nicht nur für Mobile, sondern auch für Web und Desktop. Wir sehen Flutter als langfristige Plattform, nicht als Trend, der in drei Jahren wieder verschwunden ist.
Wann keines der beiden die richtige Wahl ist
Cross-Plattform ist nicht immer die Antwort. Es gibt Projekte, bei denen wir klar nativ mit Swift oder Kotlin empfehlen:
Wenn die App stark auf Hardware-Features angewiesen ist – Bluetooth Low Energy, NFC, spezielle Kamera-Funktionen, AR – dann sind native SDKs nach wie vor überlegen. Flutter kann das über Platform Channels anbinden, aber der Aufwand steigt, und man verliert den Vorteil der einheitlichen Codebasis teilweise wieder.
Wenn die App ausschließlich für eine Plattform gedacht ist, macht Cross-Plattform keinen Sinn. Eine reine iPad-App für den internen Gebrauch? Nativ mit Swift, ohne Umwege.
Und wenn maximale Performance bei grafikintensiven Anwendungen (Spiele, 3D-Rendering) gefragt ist, sind native Frameworks oder spezialisierte Engines wie Unity die bessere Wahl.
Die Entscheidung in der Praxis
Wenn Kunden zu uns kommen und fragen „Flutter oder React Native?“, stellen wir drei Gegenfragen:
Brauchen Sie iOS und Android? Wenn ja, lohnt sich Cross-Plattform. Wenn nur eine Plattform, dann nativ.
Hat Ihr Team bereits React-Erfahrung? Wenn ja und das Team die App selbst weiterentwickeln soll, kann React Native sinnvoller sein. Wenn wir entwickeln, setzen wir auf Flutter – weil wir damit schneller und vorhersagbarer arbeiten.
Wie individuell soll das Design sein? Je eigenständiger das Design, desto stärker spielt Flutter seinen Vorteil aus. Bei Standard-UI-Elementen ist der Unterschied geringer.
In 8 von 10 Fällen landen wir bei Flutter. Nicht weil wir es verkaufen wollen, sondern weil es für die meisten Projekte die effizienteste Lösung ist. Die anderen 2 Fälle sind nativ – und das ist auch gut so.
Wenn Sie gerade vor dieser Entscheidung stehen: Schreiben Sie uns. Ich nehme mir die Zeit, Ihr Projekt zu verstehen, bevor ich eine Empfehlung ausspreche. Manchmal reichen 15 Minuten, um Klarheit zu schaffen.