Die falsche Frage, zweimal pro Woche
“Sollen wir in Flutter oder in React Native bauen?”
Diese Frage bekommen wir fast jeden Montag von Kunden. Die ehrliche Antwort lautet “kommt darauf an, und wahrscheinlich nicht aus den Gründen, die Sie vermuten”. Der eigentliche Fehler ist aber, das Gespräch überhaupt mit dieser Frage zu beginnen.
Der richtige Startpunkt: Was tut diese App wirklich, wer pflegt sie in drei Jahren, und passt das Team, das Sie heute haben, zu dem Framework, das Sie gleich auswählen?
Wenn Sie das beantwortet haben, wird die Flutter-vs.-RN-Entscheidung leichter. Manchmal ist es Flutter. Manchmal React Native. Manchmal keines, weil Sie eigentlich zwei native Apps oder eine gut gebaute Progressive Web App brauchen.
So treffen wir die Entscheidung.
Wofür jedes Framework wirklich gut ist
Flutter und React Native lösen dasselbe Geschäftsproblem (eine Codebase, zwei App Stores) mit gegensätzlichen technischen Strategien.
Flutter bringt seine eigene Rendering-Engine mit. Der Dart-Code spricht mit Impeller (Flutters moderner Renderer, mittlerweile Standard auf iOS und Android, mit Skia nur noch als OpenGL-Fallback auf älteren Geräten), das jeden Pixel zeichnet. Sie nutzen keine nativen UI-Komponenten, sondern Flutter-Widgets, die nativ aussehen, weil jemand bei Google die Arbeit gemacht hat, Material 3 und Cupertino-Stile nachzubauen.
React Native setzte früher auf eine asynchrone JavaScript-Brücke. Die New Architecture (JSI + Fabric + TurboModules + bridgeless mode, Standard seit RN 0.76 und Expo SDK 52) hat sie durch synchrone native Aufrufe ersetzt. Ihr TextInput rendert auf iOS als UITextField und auf Android als Android-View (mit zunehmender Jetpack-Compose-Interop), und das Modell bleibt “JS beschreibt einen Baum, das Native rendert ihn”, nur ohne die Brückensteuer zu zahlen.
Beide funktionieren in Produktion. Beide haben Apps mit Millionen Nutzern ausgeliefert. Die Trade-offs sind real und ziehen in unterschiedliche Richtungen.
In der Praxis treffen wir die Wahl seltener als gedacht auf Basis eines technischen Benchmarks. Viel häufiger entscheidet, wer den Code in zwei Jahren pflegt und welche Sprache dieses Team am besten beherrscht. Das ist langweilig, aber ehrlich.
Wann wir Flutter wählen
Wir greifen zu Flutter, wenn:
Die UI plattformübergreifend identisch aussehen soll. Wenn Markenkonsistenz wichtiger ist, als sich perfekt nativ anzufühlen, gewinnt Flutter. Ihre Buttons, Animationen und Übergänge sehen auf einem iPhone und einem fünf Jahre alten Android gleich aus. Pixel für Pixel. Versuchen Sie das mit React Native, und Sie verbringen ein Drittel Ihrer Zeit damit, Plattform-Inkonsistenzen zu bekämpfen.
Die App animationslastig ist. Eigene Übergänge, gestengetriebene Oberflächen, alles, wo 60-120fps Bewegung Teil des Produkts sind. Flutters Render-alles-selbst-Modell gibt Ihnen direkte Kontrolle über jeden Frame.
Das Team kein JavaScript kennt. Oder das Team klein ist und lieber eine Sprache gut lernt, statt JS-Konventionen über Mobile, Web und Backend zu jonglieren.
Sie Desktop und Embedded als günstige Nebenprodukte wollen. Flutter liefert aus derselben Codebase nach macOS, Windows, Linux und Embedded-Geräten aus. Echte Teams nutzen das für Kiosk-Software, Fahrzeug-Displays und B2B-Desktop-Tools. React Native hat macOS- und Windows-Ports, aber Microsoft pflegt sie und das Erlebnis ist rauer.
Performance bei rechen- oder grafiklastiger Arbeit zählt. Skia / Impeller rendert schnell. Dart kompiliert AOT zu nativem Code. Für Datenvisualisierung, eigene Karten und komplexe Listen mit tausenden Elementen hat Flutter messbar weniger Jank als RN.
Die Praxisverbreitung ist solide. ByteDance, BMW, Toyota (In-Vehicle-Infotainment über die Flutter-Embedder-API), eBay Motors und Alibaba liefern Flutter in Produktion für Dinge, die Kundinnen und Kunden tatsächlich nutzen. Statistas Mobile-Developer-Survey 2025 verortet Flutter bei rund 46 % unter Cross-Platform-Entwicklern, vor React Native.
Wann wir React Native wählen
Wir greifen zu React Native, wenn:
Das Team bereits in React lebt. Wenn Ihre Web-App React ist, Ihre Entwicklerinnen in JSX denken und Ihre geteilten Utilities in TypeScript leben, kann eine Frontend-Person mit React Native eine Mobile-App ausliefern, ohne die Sprache zu wechseln. Dieser Hiring- und Onboarding-Vorteil ist real.
Sie deutlich Code mit Ihrer Web-App teilen wollen. Nicht die UI (es bleiben zwei Bäume), aber Geschäftslogik, Validierung, Typen und API-Client-Schicht. Universal React Server Components in Expo Router sind Mitte 2026 noch in der Developer-Preview, aber die Grenze zwischen Web und Mobile wird zunehmend dünner.
Die App sich am besten nativ anfühlt. Ein Fintech-Überweisungsbildschirm, eine Systemeinstellungs-Seite, ein Dateneingabeformular. UIKit und Jetpack Compose liefern diese Interaktionen frei Haus, einschließlich der kleinen plattformspezifischen Verhaltensweisen (Haptik, System-Sheets, Share-Dialoge), die Endnutzer unbewusst registrieren.
Hot Reload und Over-the-Air-Updates operativ wichtig sind. Expo Application Services lässt Sie JS-Bundle-Änderungen ohne Store-Review ausrollen. Für eine interne B2B-App oder ein Produkt, das wöchentlich kleine Fixes ausliefert, ist das ein echter Produktivitätsgewinn.
Sie eine ausgereifte Bibliothek für eine spezielle Sache brauchen. React Native hat breitere Drittanbieter-Abdeckung als Flutter für Nischenanforderungen (BLE, fortgeschrittene Kamera, AR). Flutter holt auf, aber für ein Projekt 2026 zählt das immer noch.
Wir haben das größere Bild in unserem Beitrag zu Native vs. Cross-Platform Mobile 2026 beschrieben, aber speziell für Cross-Platform landet die Entscheidung meist auf einem dieser Team-Fit-Argumente und nicht auf einem technischen Benchmark.
Wenn keiner gewinnt
Es gibt einen dritten Pfad, der zu schnell verworfen wird. Manchmal lautet die Antwort: zwei native Apps oder gar keine App.
Native (Swift + Kotlin) ist die richtige Wahl, wenn:
- Die App tief mit plattformspezifischen APIs integriert (HealthKit, CarPlay, Wear OS, Apple Watch).
- Sie nur iOS oder nur Android brauchen und das Team das Budget für eine Plattform jetzt hat.
- Sie etwas bauen, bei dem 1 % Performanceunterschied für Nutzer sichtbar wird (High-End-Spiele, Echtzeit-Kollaboration mit eigenem Rendering).
- Sie ein 50+-Personen-Team sind, in dem die Wartung zweier nativer Codebases nicht mehr der Engpass ist.
Eine gut gebaute PWA ist die richtige Wahl, wenn:
- Die App hauptsächlich Inhalt und Formulare ist.
- Ihre Zielnutzer ohnehin im Web sind und nichts wirklich installieren müssen.
- Sie App-Store-Gatekeeping vermeiden und Updates sofort ausrollen wollen.
- iOS hat seit 16.4 Web Push und Badging API ausgeliefert, das alte “iOS kann eigentlich keine PWAs” als Ausrede ist 2026 deutlich schwächer (das Add-to-Home-Screen bleibt manuell über Teilen, und die EU-DMA-Lage rund um installierte PWAs sollten Sie prüfen, bevor Sie darauf wetten).
Rund ein Drittel der “Wir brauchen eine Mobile-App”-Gespräche enden bei uns mit “eigentlich brauchen Sie eine bessere mobile Web-Erfahrung und eine Notification-Strategie”. Das ist nicht die Antwort, die Kunden hören wollen. Es ist oft die richtige, vor allem für KMU mit knappem Engineering-Budget, das in zwei Plattformen sonst zerrieben wird.
Was wir für Kunden ausliefern
Für Consumer-Produkte mit starker Markenidentität und Animation: Flutter. Wir kombinieren es mit Riverpod für State, Drift für lokale Persistenz und Firebase oder Supabase als Backend, je nach Team-Vertrautheit. Für komplexe Bildschirme mit Diagrammen oder eigenen Karten setzen wir zusätzlich auf fl_chart oder MapLibre, ohne die UI-Konsistenz aufzugeben.
Für B2B-Mobile, das eine bestehende React-Web-App ergänzt: React Native mit Expo. Dieselbe TypeScript-Codebase wie das Web-Produkt, geteilte API-Schicht, EAS Build für die Deploy-Pipeline. Wir haben gesehen, wie vierköpfige Teams auf diesem Weg in acht Wochen eine polierte Mobile-Begleit-App ausgeliefert haben.
Für einen Single-Plattform-Launch mit plattformspezifischen Features: nativ. SwiftUI auf iOS, Compose auf Android, je nachdem, womit Sie starten. Die Kosten von “nativ gehen” liegen heute hauptsächlich im Hiring, nicht im Tooling.
Das Framework, das Sie wählen, zählt weniger, als Sie denken. Das Team, das Sie darauf setzen, zählt mehr. Die architektonischen Entscheidungen aus unserem Blick auf die wahren Kosten technischer Schulden gelten hier genauso wie im Backend.
Das richtige Framework ist das, in dem Ihre konkreten Entwicklerinnen ohne Frust ausliefern können.
Das ist es. Das ist das ganze Geheimnis. Jeder Framework-Vergleichsbeitrag tut so, als wäre es komplizierter. Ist es nicht, sobald Sie Team und Produkt ehrlich vor die Entscheidung stellen.
Sie überlegen zwischen Flutter, React Native, nativ oder PWA für Ihr nächstes Mobile-Projekt? Lassen Sie uns darüber sprechen. Wir schauen uns Ihr Team, Ihre Nutzer und Ihr tatsächliches Produkt an und sagen ehrlich, welcher Pfad Sie über drei Jahre am wenigsten kostet.
