Einen pauschalen Gewinner gibt es 2026 nicht, und wer euch einen verkauft, will euch meist etwas anderes verkaufen. Flutter und React Native sind beide ausgereift und liefern beide produktionsreife Apps für iOS und Android aus einer Codebasis. Was den Ausschlag gibt: was euer Team schon kann, wie wichtig euch identische Optik auf allen Plattformen ist, und ob dieselbe Codebasis auch Web und Desktop bedienen soll. Wir entwickeln unsere Apps mit Flutter — warum, steht unten. Genauso wie die Fälle, in denen wir trotzdem zu React Native oder nativer Entwicklung raten.
Warum wir bei Flutter gelandet sind
Der Unterschied, der im Alltag am meisten zählt, klingt zunächst wie ein Implementierungsdetail: Flutter zeichnet seine Oberfläche selbst, statt die nativen UI-Bausteine der Plattform zu verwenden. In der Praxis heißt das: Die App sieht auf jedem Gerät und jeder OS-Version gleich aus, und ein iOS-Update im Herbst verschiebt euch keine Buttons. Wer schon einmal nach einem OS-Update durch drei Bildschirme voller kaputter Abstände debuggt hat, weiß, was dieses Detail wert ist. Pixelgenaues Corporate Design gibt es so deutlich günstiger als mit nativen Komponenten, die auf jeder Plattform anders ausfallen.
Der zweite Grund ist Reichweite. Eine Codebasis für iOS, Android, Web und Desktop bedeutet für die typische Business-App — Außendienst, internes Tool, Kundenportal —, dass die Fachlogik genau einmal existiert und genau einmal getestet wird. Dart lernt ein Entwickler mit Java- oder TypeScript-Hintergrund in wenigen Tagen, und das Tooling drumherum — Hot Reload, strenge Typisierung, eingebaute Tests — gehört zum Angenehmsten, was es in der Cross-Platform-Welt gerade gibt.
Wann React Native trotzdem die bessere Antwort ist
Es gibt eine Konstellation, in der wir gar nicht erst diskutieren: ein eingespieltes React-Team im Haus. Wer täglich TypeScript schreibt, nimmt die Mobile-App im vertrauten Ökosystem mit — npm-Pakete, bekannte Patterns, geteiltes Wissen mit dem Web-Frontend. Der Umweg über Dart würde dieses Team langsamer machen, nicht schneller.
Auch Expo ist inzwischen ein echtes Argument: Builds, Store-Deployments und Updates laufen weitgehend automatisiert, und Over-the-Air-Updates bringen Fehlerkorrekturen an der App-Store-Prüfung vorbei auf die Geräte. Dazu kommt, dass React Native native UI-Komponenten verwendet — Apps fühlen sich von Haus aus etwas mehr nach iOS beziehungsweise Android an. Wenn plattformtypisches Verhalten wichtiger ist als identische Optik, spricht das für React Native, nicht gegen es.
Die Grenzen von Cross-Platform
Beide Frameworks haben dieselbe Achillesferse: die Brücke zur Plattform. Wer tief in Plattform-APIs muss — aufwendige Hintergrundverarbeitung, spezielle Hardware, AR, anspruchsvolle Audio- und Video-Pipelines —, schreibt an diesen Stellen ohnehin nativen Code. Ab einem gewissen Anteil davon spart die Brücke keine Arbeit mehr, sie erzeugt welche. Und eine reine iOS-App mit aufwendigen Animationen fährt mit Swift schlicht besser.
Diese Einschätzung gehört an den Anfang des Projekts, nicht in den Rückspiegel. Es ist der Punkt, an dem sich eine Stunde unabhängige Beratung mehr rechnet als jede Zeile Code danach.
Die Kostenfrage, ohne Ausflüchte
Cross-Platform spart die zweite Codebasis — aber nicht die Hälfte des Budgets. Konzept, Design, Backend, Schnittstellen und Tests fallen genauso an. Den Preis einer App bestimmt ihr Funktionsumfang: Anzahl der Screens, Anbindungen, Offline-Fähigkeit, Login-Verfahren. Das Framework-Logo steht auf der Rechnung ganz unten.
Der Posten, der dagegen regelmäßig fehlt, sind die Jahre nach dem Launch. Jährliche Framework-Upgrades, neue OS-Versionen, Abhängigkeiten mit Sicherheitsupdates — eine App ohne laufende Wartung ist nach zwei Jahren ein Sanierungsfall, egal womit sie gebaut wurde. Wer das von Anfang an einplant, erlebt keine Überraschungen. Wer nicht, zahlt die Ersparnis der einen Codebasis später mit Zins zurück.
Ihr plant eine App und wollt wissen, ob Flutter, React Native oder nativ zu eurem Fall passt? Schreib mir — ihr bekommt eine ehrliche Empfehlung, auch wenn sie „nicht wir“ lautet.