Flutter vs. React Native 2026: Der ultimative Vergleich für Entwickler, CTOs und Entscheider

Der mit Abstand umfangreichste deutschsprachige Vergleich zwischen Flutter und React Native — Architektur, Performance, Ökosystem, Kosten, Hiring, Code-Beispiele, reale Case Studies, Sicherheit, Wartung, AI-Integration, Zukunftsausblick und konkrete Entscheidungsmatrix. Stand: Juni 2026.

Lesezeit: ca. 55 Minuten · Wörter: ~12.500 · Aktualisiert: Juni 2026

---

Inhaltsverzeichnis

1. TL;DR — Die wichtigsten Erkenntnisse auf einen Blick
2. Warum Cross-Platform überhaupt? Die Marktlage 2026
3. Geschichte und Herkunft beider Frameworks
4. Architektur im Detail — was unter der Haube passiert
5. Programmiersprachen: Dart vs. JavaScript/TypeScript
6. Rendering-Pipeline: Skia/Impeller vs. Native Bridge/JSI/Fabric
7. Performance-Benchmarks 2026 (Startzeit, FPS, Speicher, App-Größe)
8. UI & Design-System: Material 3, Cupertino, native Feel
9. Developer Experience (DX): Hot Reload, Tooling, Debugging
10. Ökosystem, Pakete und Community-Größe
11. Native-Module, Plattform-APIs und Plugin-Entwicklung
12. State-Management — von Provider/Riverpod bis Redux/Zustand
13. Navigation und Routing
14. Testing-Strategien (Unit, Widget, Integration, E2E)
15. CI/CD, Build-Pipelines und App-Distribution
16. Sicherheit und Compliance
17. Web-Support, Desktop-Support und Embedded
18. Accessibility & Internationalisierung
19. Update-Strategien: OTA, CodePush, Play-Feature-Delivery
20. Kosten, Time-to-Market und TCO-Modell
21. Hiring, Gehälter und Verfügbarkeit von Entwicklern in DACH
22. Reale Case Studies: BMW, Alibaba, Discord, Shopify, Tesla
23. Wann React Native gewinnt — und wann Flutter
24. AI- und ML-Integration: On-Device-Inferenz mit beiden Frameworks
25. Migrationspfade und Rewrite-Strategien
26. Häufige Anti-Patterns und Stolperfallen
27. Code-Beispiele Side-by-Side
28. Entscheidungsmatrix: 25 Kriterien, gewichtet
29. Zukunftsausblick 2027–2030
30. FAQ — die 40 häufigsten Fragen
31. Glossar
32. Weiterführende Quellen

---

1. TL;DR — Die wichtigsten Erkenntnisse auf einen Blick

Wer 2026 keine Lust auf 30 Minuten Lesezeit hat, bekommt hier in zwei Minuten die destillierte Wahrheit:

Flutter ist die richtige Wahl, wenn du eine pixel-perfekte, hochperformante App willst, die auf iOS, Android, Web, Windows, macOS und Linux exakt gleich aussieht — und wenn dein Team bereit ist, Dart zu lernen oder bereits beherrscht. Flutter glänzt bei UI-intensiven Apps, Animationen mit 120 fps, komplexen Custom-Designs, Spielen, Embedded-Systemen und Apps, bei denen visuelle Konsistenz ein Verkaufsargument ist. Google steht voll dahinter, die Engine (Impeller) ist 2026 in einem ausgereiften Zustand, und das Tooling rund um Hot Reload und DevTools ist branchenführend.

React Native ist die richtige Wahl, wenn du bereits ein React/Web-Team hast, JavaScript/TypeScript-Code wiederverwenden willst, ein riesiges npm-Ökosystem nutzen möchtest, native iOS/Android-Look-and-Feel mit echten UIKit/Material-Komponenten brauchst, oder wenn du auf Plattformen wie Expo EAS setzt, um Build- und OTA-Updates radikal zu vereinfachen. Mit der neuen Architektur (Fabric + JSI + TurboModules + Hermes), die seit 0.76 standardmäßig aktiv ist, hat React Native den größten Performance-Sprung seiner Geschichte hinter sich.

Die ehrliche Kurzempfehlung 2026:

• B2C-App mit starker Marken-UI, viel Animation, langer Lebenszeit → Flutter
• Content-, Commerce- oder Social-App mit Backend-Wiederverwendung von einem React-Web → React Native
• MVP in 6 Wochen mit kleinem Team, das JavaScript spricht → React Native (mit Expo)
• Multi-Plattform inklusive Web/Desktop aus einer Codebasis → Flutter
• Hochfrequente Animationen, 120-Hz-Smoothness, Custom-Painting → Flutter
• Tiefe Integration in eine bestehende native iOS/Android-App → React Native (Brownfield)
• Apps mit viel On-Device-AI/ML, die nahtlos zu Web skalieren sollen → React Native + ONNX/TF Lite

Beide Frameworks sind 2026 produktionsreif, beide werden von Milliardenkonzernen in Apps mit hunderten Millionen Nutzern eingesetzt, und beide werden auch 2030 noch relevant sein. Die "falsche" Entscheidung gibt es kaum noch — nur die jeweils bessere für dein Team, deine Domäne und deine Roadmap.

---

2. Warum Cross-Platform überhaupt? Die Marktlage 2026

Bevor wir die beiden Schwergewichte gegeneinander antreten lassen, ein kurzer Blick auf den Markt: Warum sollte ein Unternehmen 2026 überhaupt cross-platform entwickeln, statt zwei separate Teams für Swift/SwiftUI und Kotlin/Jetpack Compose zu unterhalten?

Die Antwort ist eine Mischung aus Wirtschaftlichkeit, Geschwindigkeit und Realität. Native Entwicklung liefert zwar maximale Plattform-Treue, kostet aber typischerweise das Anderthalb- bis Doppelte an Personal- und Wartungskosten. Wer pro Feature in zwei Codebasen Tickets schreibt, doppelt testet und doppelt deployed, verliert nicht nur Geld, sondern auch Innovationsgeschwindigkeit. Studien von Forrester (2025) und IDC (Q1 2026) belegen, dass Cross-Platform-Teams Features im Durchschnitt 35–55 % schneller in beide Stores bringen als parallele native Teams. Bei MVPs und in der frühen Wachstumsphase ist dieser Vorsprung oft überlebenswichtig.

Gleichzeitig ist Cross-Platform 2026 nicht mehr der "Kompromiss" von 2017. Die beiden marktführenden Frameworks Flutter (Google) und React Native (Meta) liefern Performance auf nativem Niveau für 95 % aller App-Klassen. Selbst Konzerne wie BMW (My BMW App, Flutter), Discord (React Native + native), Shopify (Shop App, React Native) und Alibaba (Xianyu, Flutter) setzen produktiv auf Cross-Platform — nicht trotz, sondern wegen ihrer Größe.

Der Markt hat sich faktisch konsolidiert: Während Xamarin/MAUI eher in Enterprise-Nischen verbleibt, Ionic/Capacitor primär als Web-Wrapper genutzt wird und KMP (Kotlin Multiplatform) hauptsächlich shared business logic liefert, dominieren Flutter und React Native den Markt für vollwertige UI-Cross-Platform-Apps. Laut Stack Overflow Developer Survey 2025 nutzen 9,1 % aller professionellen Entwickler React Native und 9,8 % Flutter — beide haben sich gegenüber 2020 etwa verdoppelt.

In DACH ist die Tendenz klar: Mittelständische Software-Häuser, Konzerne mit Inhouse-Mobile-Teams und schnelle Startups gehen verstärkt zu Flutter, weil Dart schnell zu lernen ist und das Tooling weniger "Magic" enthält. Agenturen mit React-Web-Hintergrund bleiben oft bei React Native, weil Wissens- und Code-Wiederverwendung den Ausschlag geben. Beide Lager wachsen, beide Lager sind nachhaltig — und keines der beiden Frameworks "stirbt" auch nur ansatzweise.

---

3. Geschichte und Herkunft beider Frameworks

Um die heutigen Stärken und Schwächen zu verstehen, lohnt sich ein Blick auf die Genese.

React Native wurde 2013 intern bei Facebook geboren, im Rahmen eines Hackathon-Projekts von Jordan Walke. 2015 wurde es auf der React.js Conf öffentlich vorgestellt. Die Grundidee: Das mentale Modell von React (deklarative Komponenten, unidirektionaler Datenfluss, JSX) auf native Mobile-Plattformen übertragen. Anfangs nur für iOS, kurze Zeit später auch für Android. Die Architektur basierte auf einer asynchronen JSON-Bridge zwischen JavaScript-Thread und nativen Threads — eine elegante Idee, die jedoch jahrelang als Performance-Achillesferse galt. 2018 startete das große Architektur-Re-Write, das mit JSI (JavaScript Interface), TurboModules, Fabric (neuer Renderer) und Hermes (optimierte JS-Engine) Ende 2024 mit React Native 0.76 endgültig produktionsreif wurde und in den Folgeversionen bis 0.86 (Juni 2026) weiter verfeinert wurde. Heute (Juni 2026) ist die "New Architecture" Standard und liefert die Performance, die viele Skeptiker dem Framework lange absprachen.

Flutter ist jünger. Erste Prototypen ("Sky") liefen 2015 als Experiment innerhalb von Google. Auf der Dart Developer Summit 2015 wurde das Konzept skizziert. 2017 erschien die erste Alpha, im Dezember 2018 das offizielle 1.0-Release. Flutter wurde von Anfang an radikal anders gedacht: Statt auf native UI-Komponenten setzt Flutter auf eine eigene Rendering-Engine (zuerst Skia, ab Flutter 3.10/3.13 schrittweise abgelöst von Impeller, der ab Flutter 3.27 für iOS und Android Default ist; aktuelle stabile Version ist Flutter 3.44, Stand Juni 2026). Jeder Pixel wird von Flutter selbst gezeichnet — die Plattform liefert nur das Surface. Das Versprechen: identische UI, deterministische Performance, freie Hand beim Custom-Design. Die Wahl der Sprache fiel auf Dart — eine ebenfalls von Google entwickelte, statisch typisierte Sprache, die sowohl AOT (für Production) als auch JIT (für Hot Reload in der Entwicklung) kompilieren kann.

Die jeweiligen Mutterkonzerne stehen voll hinter ihren Frameworks: Meta nutzt React Native in Facebook, Instagram (Teile), WhatsApp Desktop, Marketplace und vielen internen Tools. Google setzt Flutter unter anderem in Google Pay (Migration 2020/21 abgeschlossen), Google Classroom Tools, Stadia-Companion und Teilen von Google Earth ein. Beide Konzerne haben strategisches Interesse, dass ihr Framework wächst — und das spiegelt sich in der Investitionsbereitschaft.

Wichtig zu wissen: Beide Projekte sind Open Source (MIT-Lizenz für React Native, BSD-3 für Flutter). Es gibt keine Lizenzgebühren, keine Vendor-Lock-in-Klauseln. Selbst wenn Meta oder Google morgen die Investitionen einstellten — die Communities, Forks und kommerzielle Wartungsverträge (z. B. von Bitrise, Microsoft, Invertase) wären groß genug, um beide Frameworks am Leben zu halten.

---

4. Architektur im Detail — was unter der Haube passiert

Hier wird es technisch. Wer Architektur-Entscheidungen für ein Team trifft, sollte die Mechanik verstehen.

4.1 Die Architektur von Flutter

Flutter besteht im Wesentlichen aus drei Schichten:

Die Framework-Schicht ist in Dart geschrieben und stellt das bereit, was Entwickler täglich sehen: Widgets (Material, Cupertino, einfache RenderObjects), das Rendering-Subsystem, Animation, Gestures, Painting, Foundation. Das Widget-Tree ist konzeptionell ähnlich zu Reacts virtuellem DOM, aber granularer und immutable per Konvention. Bei jedem Frame wird ein neues Widget-Tree erzeugt, mit dem alten verglichen, und nur die tatsächlichen RenderObjects in der nächsten Schicht werden mutiert.

Die Engine ist in C++ geschrieben und liefert das Low-Level-Fundament: Skia bzw. Impeller für 2D-Grafik, Dart-Runtime, Text-Layout (HarfBuzz, ICU), Plattform-Channels für Native-Calls, Plugin-System. Die Engine wird mit jeder Flutter-Version mitgeliefert und ist plattform-spezifisch kompiliert.

Die Embedder-Schicht verbindet die Engine mit dem jeweiligen Betriebssystem: Auf iOS ist das ein UIView, auf Android eine SurfaceView/TextureView, auf Web ein Canvas/WebGL/Wasm-Backend, auf Desktop entsprechende OS-spezifische Surfaces. Der Embedder kümmert sich um Lifecycle, Input-Events, Threading und das Rendern des finalen Frame-Buffers.

Der entscheidende Punkt: Flutter zeichnet alles selbst. Ein Button ist kein UIButton oder Material-Button im OS-Sinne — er ist eine pixelgenaue Nachbildung, die exakt so aussieht. Vorteil: 100 % Konsistenz zwischen Geräten, keine bösen Überraschungen bei OS-Updates, freie Hand beim Custom-Design. Nachteil: Wenn Apple morgen iOS-Buttons neu designt, sieht deine App weiter wie iOS 17 aus, bis du die Flutter-Version aktualisierst, die das nachzieht.

4.2 Die (alte und neue) Architektur von React Native

Die alte Architektur (bis ca. RN 0.67, lange Zeit Default) bestand aus drei Threads: dem JS-Thread (führt deine JavaScript-/TypeScript-Logik aus), dem Shadow-Thread (berechnet Layout via Yoga, ein C++-Port von CSS Flexbox) und dem Main/UI-Thread (rendert echte native Views). Die drei Threads kommunizierten über die berühmt-berüchtigte Bridge: Eine asynchrone, batched, JSON-serialisierte Message-Queue. Das war einerseits robust und gut entkoppelt, andererseits Quelle vieler Performance-Probleme bei großen Listen, Animationen und schnellen UI-Updates.

Die neue Architektur (Standard ab RN 0.76 / Ende 2024) räumt damit auf:

• JSI (JavaScript Interface): Ein C++-Layer, der direkt zwischen JS-Engine (Hermes/JSC/V8) und nativem Code Brücken schlägt — synchron, ohne JSON-Serialisierung. Damit fallen viele Bridge-Latenzen weg.
• TurboModules: Native Module werden lazy geladen und über JSI aufgerufen. Statt beim App-Start alle Module zu initialisieren, lädt RN nur, was gebraucht wird.
• Fabric: Ein neuer Renderer, der das Shadow-Tree in C++ verwaltet und synchrone Rendering-Pfade ermöglicht. Layout wird weiterhin von Yoga berechnet, aber das gesamte System ist deutlich enger gekoppelt und latenzärmer.
• Hermes: Eine schlanke, AOT-bytecode-fähige JS-Engine, die speziell für mobile React-Native-Apps optimiert ist. Schnellerer Cold-Start, geringerer Speicherverbrauch.
• Codegen: Generiert Type-safe Brücken zwischen TypeScript und nativem Code, sodass viele Bridge-Bugs zur Compile-Zeit auffallen.

Wichtig: React Native rendert weiterhin echte native Views (UIView auf iOS, android.view.View auf Android). Eine Touchable-Komponente ist ein UIControl. Das hat den großen Vorteil, dass Plattform-Updates (iOS 19, Android 17) UI-Komponenten sofort anpassen — und den Nachteil, dass Custom-UI mehr Aufwand bedeutet.

4.3 Was bedeutet das praktisch?

Stell dir eine simple ListView mit 10.000 Items, Bilder, Pull-to-Refresh, sticky Headers vor.

• In Flutter rendert die ListView.builder jedes Item als Widget, das vom Skia/Impeller-Renderer gezeichnet wird. Das Scrolling ist auf 60/120 fps stabil, weil Layout, Paint und Composite alle im Engine-Thread passieren — kein JS dazwischen.
• In React Native (neue Architektur) rendert eine FlashList (Shopify) oder LegendList jedes Item als echten UIView/Cell. Mit Fabric ist das Scrolling fast gleich smooth wie nativ — und in Listen sogar leicht effizienter als Flutter, weil das OS Cell-Recycling, Lazy-Loading und Memory-Management hochoptimiert handhabt.

In der Praxis kommen beide auf "60 fps fühlt sich smooth an", die Unterschiede liegen in den Edge Cases: Custom-Painting, Animationen mit vielen gleichzeitig animierten Elementen, sehr lange Listen mit komplexen Items, oder Inhalte, die direkt mit OS-spezifischen UI-Frameworks (iOS Live Activities, Android Material You Dynamic Color) interagieren.

---

5. Programmiersprachen: Dart vs. JavaScript/TypeScript

Die Sprachenwahl ist oft das emotionalste Entscheidungskriterium — und gleichzeitig das am stärksten überschätzte. Beide Sprachen lassen sich in zwei bis drei Wochen produktiv lernen, beide haben moderne Features, beide sind für mobile App-Entwicklung absolut geeignet.

5.1 Dart

Dart ist eine objektorientierte, klassenbasierte, statisch typisierte Sprache mit Sound-Null-Safety (seit Dart 2.12), Mixins, Extensions, Records (Dart 3), Pattern Matching und Sealed Classes (Dart 3+). Die Syntax ist Java/Kotlin/C#-ähnlich und für jeden Entwickler mit OO-Hintergrund sofort lesbar. Dart kann zu nativem ARM/x86-Code (AOT) für Production-Builds und zu Bytecode für JIT (Hot Reload während der Entwicklung) kompiliert werden — eine Eigenschaft, die für Flutters legendären Hot-Reload entscheidend ist.

Vorteile von Dart:

• Statische Typisierung von Geburt an — keine ESLint-Roulette wie bei JS/TS-Migrationen
• Sound Null Safety: Wenn der Compiler sagt, ein Wert ist nicht null, dann ist er garantiert nicht null
• Async/await, Streams, Isolates (echte Parallelität via Worker, kein "Web-Worker-Workaround")
• Records und Pattern Matching machen Domain-Modellierung elegant
• Klare, eine "official way" Mentalität — weniger Streit über Stilfragen

Nachteile von Dart:

• Außerhalb von Flutter ein Nischen-Ökosystem (Backend mit Dart Frog, Serverpod, etc. existiert, ist aber klein)
• Die Reichweite an verfügbaren Entwicklern in DACH ist kleiner als bei JS/TS (auch wenn sie wächst)
• Die Library-Landschaft (pub.dev) ist deutlich kleiner als npm

5.2 JavaScript / TypeScript

JavaScript ist die meistverbreitete Programmiersprache der Welt, TypeScript hat sich seit ca. 2018 als De-facto-Standard für ernsthafte JS-Entwicklung etabliert. React Native unterstützt beides nativ; in der Praxis schreiben 2026 mehr als 90 % aller neuen RN-Projekte in TypeScript.

Vorteile von TypeScript:

• Riesiges Ökosystem: npm hat über 3,5 Millionen Packages, viele davon mobile-tauglich
• Code-Sharing mit Web-Frontends (React, Next.js), Backend (Node.js, Bun, Deno) und sogar Server-Side-Rendering
• Hervorragende IDE-Unterstützung (VS Code, WebStorm, Cursor, Zed)
• Massive Community, riesiger Talent-Pool
• Pattern wie React Hooks, Suspense, Concurrent Features sind direkt anwendbar

Nachteile von TypeScript:

• "Strict Mode" muss disziplinärt durchgehalten werden, sonst sammelt sich any-Schmutz an
• Asynchrone Code-Komplexität (Promises, Generators, Async-Iteratoren, Schedulers) kann übergroß werden
• Bundle-Größen müssen aktiv gemanagt werden (Tree-Shaking, dynamische Imports)
• Build-Tooling-Vielfalt (Metro, Babel, SWC, esbuild) kann verwirrend sein

5.3 Lern-Aufwand für ein DACH-Team

Ein Java- oder C#-Backend-Team lernt Dart typischerweise in einer Woche bis zur produktiven Geschwindigkeit. Ein React-Web-Team kann nach drei bis fünf Tagen produktiv React Native schreiben — die mentale Brücke ist minimal. Für ein Team ohne mobile Vorerfahrung, aber mit JavaScript-Background, ist React Native der schnellere Onboarding-Pfad. Für ein Team mit Java/Kotlin/C#-Background ist Dart syntaktisch näher und Flutter daher oft die natürlichere Wahl.

---

6. Rendering-Pipeline: Skia/Impeller vs. Native Bridge/JSI/Fabric

Wer wirklich verstehen will, warum eine Liste smooth scrollt oder eine Animation ruckelt, muss die Pipeline kennen.

6.1 Flutter-Pipeline mit Impeller

Wenn ein Frame in Flutter gerendert wird, läuft folgende Sequenz ab:

1. Build: Das Widget-Tree wird (re)konstruiert. Das geschieht in Dart, ist aber mit AOT-Code extrem schnell.
2. Layout: Jedes RenderObject berechnet seine Größe und Position. Das Layout-System ist single-pass und konzeptionell elegant.
3. Paint: Jedes RenderObject erzeugt eine Liste von Paint-Befehlen (z. B. "zeichne ein Rechteck mit Farbe X an Position Y").
4. Composite & Raster: Impeller (oder Skia, je nach Plattform/Version) übersetzt die Paint-Befehle in GPU-Operationen. Auf iOS nutzt Impeller Metal, auf Android Vulkan (mit OpenGL ES als Fallback).
5. Submit: Der fertige Frame-Buffer wird ans OS übergeben, das ihn auf dem Display anzeigt.

Impeller wurde 2023 eingeführt, um Skia abzulösen — Hauptmotivation war das Eliminieren von Shader-Compilation-Jank (kurze Hänger beim erstmaligen Verwenden eines Shaders). Impeller pre-kompiliert alle Shader und liefert dadurch deterministisch smooth Frames. Stand Juni 2026 ist Impeller auf iOS produktionsreif (seit Flutter 3.10), auf Android Default seit Flutter 3.27 (Vulkan-Backend), und auch auf Desktop/Web in Vorbereitung.

6.2 React Native New-Architecture-Pipeline

In der neuen Architektur sieht der Frame-Pfad so aus:

1. JS rendert: React erzeugt ein Element-Tree (JSX → React-Elemente).
2. Reconciler: Vergleicht neues und altes Tree, entscheidet, was geändert werden muss.
3. Fabric Shadow Tree (C++): Mutationen werden synchron via JSI an den C++-Shadow-Tree weitergereicht.
4. Yoga-Layout: Berechnet Layout via CSS-Flexbox-Engine.
5. Mounting Layer: Übersetzt das Shadow-Tree in echte UIView/View-Mutationen auf dem UI-Thread.
6. OS-Composite: Das OS rendert die finalen native Views auf den Bildschirm — exakt wie bei einer "echten" Swift-/Kotlin-App.

Der entscheidende Unterschied zur alten Architektur: Es gibt keine asynchrone JSON-Bridge mehr. Die JSI-Verbindung ist synchron, type-safe und C++-optimiert. Animationen, die früher zwingend über react-native-reanimated (das die Bridge umging) realisiert werden mussten, laufen jetzt auch mit "vanilla" Animated-API smooth — wobei Reanimated 3+ weiterhin der Goldstandard für komplexe Worklet-basierte UI-Thread-Animationen ist.

6.3 Was heißt das für Animationen?

In Flutter sind 120-fps-Animationen mit Custom-Painting (Hero-Animationen, Liquid-Pull-to-Refresh, custom transitions) trivial und liefern deterministische Performance — weil alles im Engine-Thread passiert und Dart-Code AOT-kompiliert ist. In React Native erreicht man das gleiche Niveau mit Reanimated 3+ und Worklets, die direkt auf dem UI-Thread laufen. Der Unterschied: Bei Flutter ist es eingebauter Standard, bei React Native musst du dich mit dem Worklet-Modell vertraut machen und ggf. manuell optimieren.

---

7. Performance-Benchmarks 2026 (Startzeit, FPS, Speicher, App-Größe)

Performance-Vergleiche sind notorisch schwer, weil sie stark von Hardware, Build-Konfiguration, Code-Qualität und Workload abhängen. Trotzdem gibt es einige Trends, die sich aus dem Schnitt zahlreicher 2025/26er Benchmarks (u. a. von Bitrise, Notjust.dev, Reddit-Communities, sowie internen Vergleichen großer Konzerne) destillieren lassen.

7.1 Cold-Start-Zeit

Auf einem mittleren Android-Gerät (Pixel 7a, 8 GB RAM, Android 15) für eine Standard-Demo-App (Login + Home + Liste mit 50 Items, ohne Splash-Bild gemessen):

• Native Kotlin/Compose: ~0,75 s
• Flutter (AOT, Impeller): ~0,95 s
• React Native (Hermes, New Arch): ~1,15 s
• React Native (alte Arch + JSC): ~1,55 s

Auf iPhone 13 (iOS 18):

• Native Swift/SwiftUI: ~0,55 s
• Flutter (AOT, Impeller): ~0,65 s
• React Native (Hermes, New Arch): ~0,80 s

Flutter ist bei Cold-Start im Schnitt 15–25 % schneller als React Native, hauptsächlich, weil weniger Initialisierung notwendig ist (kein JS-Bundle parsen, keine Engine bootstrappen — alles ist AOT-Code).

7.2 Frame-Rate bei Listen mit 1.000 Items

• Flutter ListView.builder: stabil 119 fps auf 120-Hz-Display, Drops <0,5 %
• React Native FlashList (Shopify): 117–120 fps, vereinzelte Drops auf 90 fps
• React Native FlatList (legacy): 90–115 fps, regelmäßige Drops

Mit FlashList oder LegendList ist React Native faktisch gleichauf mit Flutter; mit der alten FlatList und schweren Items (Bilder, Schatten, Custom-Animation) liegt Flutter merklich vorn.

7.3 Speicherverbrauch (Resident Set, idle nach Cold-Start)

• Flutter: ~60–90 MB
• React Native (Hermes, New Arch): ~75–110 MB
• Native Android: ~45–70 MB

React Native braucht etwas mehr Speicher, weil zusätzlich die JS-Engine und das geparste Bundle resident sind. In der Praxis fällt das nur auf Low-End-Geräten unter 4 GB RAM ins Gewicht.

7.4 App-Bundle-Größe

• Flutter (release, ARM64): ~12–18 MB Core-Footprint plus Assets
• React Native (release, ARM64, Hermes): ~7–10 MB Core-Footprint plus JS-Bundle (1–4 MB) plus Assets
• Native (release, ARM64): ~3–8 MB Core plus Assets

React Native produziert leicht kleinere Bundles, weil die Flutter-Engine als statische Library mitgeliefert wird. Mit Code-Splitting und dynamischen Features (Play Feature Delivery, App Thinning) lässt sich das reduzieren.

7.5 Praxisrelevanz

In den allermeisten realen Apps ist der Performance-Unterschied nicht spürbar — User merken den Unterschied zwischen 0,8 s und 1,1 s Cold-Start kaum, und 117 fps "fühlen sich" wie 120 fps an. Performance-relevant wird die Wahl erst bei:

• Apps mit komplexen Animationen (z. B. sportbezogene Apps mit 3D-Visualisierungen)
• Apps mit sehr großen Listen / Datentabellen (ETF-Tracking, Tradingplattformen, Wettkampf-Statistiken)
• Apps, die viele OS-Ressourcen mit nativem Code teilen müssen (Kamera-Apps, AR-Anwendungen, Audio-Tools)

Für eine durchschnittliche B2C-App mit Login, Listen, Detail-Screens, Push, Settings ist beides gleichermaßen ausreichend.

---

8. UI & Design-System: Material 3, Cupertino, native Feel

Hier prallen zwei Philosophien aufeinander.

Flutter liefert mit dem material- und cupertino-Package zwei vollständige, pixel-genau nachgebaute Design-Systeme. Material 3 (auch "Material You" genannt) ist seit Flutter 3.16 vollständig integriert, inklusive Dynamic Color (Android 12+), Color Schemes aus einem Seed, und allen 100+ Komponenten. Cupertino (iOS-Look) deckt die wichtigsten Komponenten ab, ist aber traditionell ein paar Versionen hinter den neuesten iOS-UI-Trends. Wer eine App mit "iOS sieht aus wie iOS, Android sieht aus wie Android" bauen will, braucht in Flutter zwei Code-Pfade — was machbar, aber Aufwand ist.

React Native rendert echte native Komponenten. Wenn iOS 19 morgen einen neuen Button-Style einführt, übernimmt deine RN-App diesen Style nach einem Recompile. Das ist ein massiver Vorteil für Apps, deren USP "fühlt sich echt iOS an" ist — etwa Banking, ÖPNV, Behörden-Apps. Allerdings bedeutet das auch, dass Custom-UI in RN aufwendiger ist: Wer einen pixelgenauen Glassmorphism-Look mit animierten Blur-Layern und Custom-Schatten will, schreibt entweder native Code oder nutzt Bibliotheken wie react-native-skia (Shopify) — die Flutter-Skia-Pipeline auf RN bringt.

8.1 Themen-Systeme

Beide Frameworks haben ausgereifte Theme-Systeme mit Light/Dark-Mode, dynamischen Farben, Typografie-Tokens. Flutter's ThemeData ist ein einzelnes Objekt, das durch den Widget-Tree fließt; React Natives Theme-Lösungen sind stärker fragmentiert (Tamagui, NativeWind, gluestack, restyle, oder einfach Context+Hook-Pattern).

8.2 Design-Systeme im Unternehmenskontext

Wer ein corporate Design-System hat (z. B. Allianz, Telekom, Deutsche Bank), wird in Flutter typischerweise das ganze Design-System einmal als ThemeData+Custom-Widgets bauen und auf beiden Plattformen identisch ausliefern. In React Native baut man oft auf einer Shared-Library mit einer headless UI-Lib (Tamagui, restyle) auf, die plattform-adaptiv rendert.

8.3 Komponenten-Bibliotheken (Auswahl, Stand 2026)

Flutter: Material 3 (built-in), Cupertino (built-in), Forui (Vercel-style), shadcn-flutter, Flutter Bootstrap, Velocity X, GetWidget.

React Native: Tamagui (Performance-Champion), NativeWind (Tailwind für RN), gluestack-ui v2, React Native Paper (Material), React Native Elements, NativeBase (mittlerweile auf Tamagui-Modus umgestellt).

---

9. Developer Experience (DX): Hot Reload, Tooling, Debugging

Die DX entscheidet oft mehr über die Produktivität eines Teams als die nominelle Performance des Frameworks.

9.1 Hot Reload / Fast Refresh

Beide Frameworks bieten Hot Reload — die Fähigkeit, Code-Änderungen in <1 s in der laufenden App zu sehen, ohne State zu verlieren. Flutter's Implementierung ist legendär stabil und schnell, weil die Dart-VM dafür gebaut ist. React Native's Fast Refresh (basierend auf Metro Bundler) ist ähnlich gut, aber leidet gelegentlich an Edge Cases (z. B. State-Verlust bei Hooks-Änderungen, Cache-Invalidierung). Subjektiv geben viele Entwickler Flutter hier den leichten Vorteil.

9.2 IDE-Unterstützung

Flutter: Erstklassige Unterstützung in VS Code (Flutter-Extension von Google) und Android Studio / IntelliJ. JetBrains' Flutter-Plugin ist besonders mächtig (Refactoring, Widget-Inspector, Performance-Overlay).

React Native: VS Code (mit React Native Tools), WebStorm, Cursor, Zed. Da TS/JS, profitiert RN von der gesamten Web-Tooling-Vielfalt — TypeScript-Server, ESLint, Prettier, Biome, all das funktioniert.

9.3 DevTools

Flutter DevTools (im Browser oder integriert in VS Code/IntelliJ) bietet: Widget-Inspector, Layout-Explorer, Memory-Profiler, CPU-Profiler, Network-Inspector, Logging, Performance-Overlay. Das ist ein extrem ausgereiftes Werkzeug.

React Native bietet seit Ende 2024 die "React Native DevTools" als Standard-Debugger (basierend auf Chrome DevTools), plus die React DevTools (Komponentenbaum, Profiler). Das ist 2026 deutlich besser als der "alte" Remote-JS-Debugger, aber nicht ganz auf Flutter-DevTools-Niveau.

9.4 Build-Zeiten

• Flutter (Cold Build, Release, Android): 60–180 s je nach Projektgröße
• React Native (Cold Build, Release, Android): 90–240 s je nach Projektgröße
• Inkrementelle Rebuilds: beide unter 10 s

Mit EAS Build (Expo-Cloud), Fastlane, Gradle-Caches und Xcode-Build-Caches lassen sich beide Frameworks in CI/CD auf 5–10 Minuten pro Plattform optimieren.

---

10. Ökosystem, Pakete und Community-Größe

Quantitativ (Juni 2026):

• npm (JavaScript/TypeScript): ~3,7 Millionen Packages, davon ~28.000 mit "react-native"-Tag
• pub.dev (Dart): ~50.000 Packages, davon ~30.000 Flutter-spezifisch

Die schiere Zahl täuscht: npm hat eine extreme Long-Tail-Verteilung mit viel veraltetem Code. pub.dev ist kleiner, aber kuratierter — Google bewertet Packages mit einem Pub Score, was die Suche nach qualitativ guten Paketen erleichtert.

10.1 Welche Pakete sind unverzichtbar?

Flutter (essential 2026):

• flutter_riverpod oder bloc — State Management
• go_router — Navigation (offiziell empfohlen)
• dio — HTTP-Client
• freezed + json_serializable — Code-Generierung für Models
• flutter_secure_storage — Credentials
• firebase_core und Firebase-Suite
• cached_network_image — Bilder mit Cache
• intl und flutter_localizations — i18n
• flutter_native_splash, flutter_launcher_icons — Asset-Generierung

React Native (essential 2026):

• Expo SDK 53+ — der Goldstandard für neue Projekte
• expo-router oder react-navigation v7 — Routing
• zustand, jotai, redux-toolkit, oder tanstack/query — State / Server State
• react-native-reanimated v3 — Animationen
• react-native-gesture-handler — Touch / Gestures
• nativewind oder tamagui — Styling
• @shopify/flash-list oder legend-list — Listen
• react-hook-form + zod — Forms / Validierung
• react-native-mmkv — Performant Storage
• react-native-skia — 2D-Grafik / Custom Painting

10.2 Community-Aktivität

GitHub-Stars (Juni 2026, gerundet):

• flutter/flutter: ~175.000 Stars
• facebook/react-native: ~125.000 Stars

Reddit:

• r/FlutterDev: ~210.000 Mitglieder
• r/reactnative: ~190.000 Mitglieder

Stack Overflow Tags (Fragen):

• [flutter]: ~190.000 Fragen
• [react-native]: ~170.000 Fragen

Konferenzen 2026: Flutter Forward, Fluttercon (Berlin und New York), Flutter Heroes, FlutterVikings; App.js Conf, Chain React, React Native EU, React Universe Conf. Beide Communities sind extrem aktiv, beide haben starke Maintainer und Sponsoren.

---

11. Native-Module, Plattform-APIs und Plugin-Entwicklung

Wenn du auf Plattform-APIs zugreifen musst, die das Framework nicht direkt abdeckt (z. B. ein BLE-Headset, Live Activities, App Clips, Foreground Services, Deep-OS-Integrationen), brauchst du Native-Module.

11.1 Flutter Plattform-Channels

Flutter kommuniziert mit nativem Code über Platform Channels — typed asynchronous messaging zwischen Dart und Java/Kotlin (Android) bzw. Swift/Objective-C (iOS). Es gibt drei Varianten: MethodChannel (RPC-Stil), EventChannel (Streams, z. B. für Sensor-Events), BasicMessageChannel (low-level).

Seit Flutter 3.7 gibt es zusätzlich Pigeon — ein Codegen-Tool, das aus einer Dart-Spec native Bindings generiert (Java/Kotlin/Swift/Objective-C, type-safe). Pigeon ist 2026 der empfohlene Standard für eigene Plugins.

Außerdem FFI (Foreign Function Interface) — Dart kann direkt in C/C++-Bibliotheken aufrufen, ohne Plattform-Channel-Overhead. Praktisch für CPU-intensive Workloads (Image-Processing, Krypto, Audio-DSP).

11.2 React Native TurboModules / Fabric Native Components

Mit der neuen Architektur sind Native-Module sauberer als je zuvor: Du beschreibst die TS-API, Codegen erzeugt die Brücken-Definitionen, du implementierst sie nativ in Swift/Kotlin/C++. Synchrone Calls über JSI sind möglich, was für viele Use Cases (Krypto-Operationen, Inline-Image-Verarbeitung) ein Game-Changer ist.

Fabric Native Components erlauben es, eigene native Views zu schreiben, die wie eingebaute Komponenten in React-Trees funktionieren — wichtig für komplexe Widgets wie Maps, Camera, Charts.

11.3 Bestehende Plugin-Landschaft

Beide Frameworks haben für die meisten gängigen Anforderungen ausgereifte Plugins: Kamera (image_picker, react-native-vision-camera), Karten (google_maps_flutter, react-native-maps), Push (firebase_messaging, expo-notifications, react-native-notifications), Bluetooth, NFC, Biometrie, In-App-Purchases, App-Tracking-Transparency, etc.

Für extrem spezielle Anforderungen (z. B. CarPlay/Android Auto, Apple Watch / Wear OS Companions, Live Activities) hat React Native oft den leichten Vorteil, weil Brownfield-Integration (RN in eine bestehende native App einbetten) gut etabliert ist und du einzelne Screens nativ behalten kannst. Flutter unterstützt Brownfield ebenfalls, aber traditionell mit etwas mehr Konfigurations-Overhead.

---

12. State-Management — von Provider/Riverpod bis Redux/Zustand

State Management ist in beiden Welten ein Glaubenskrieg.

Flutter: Die offizielle Empfehlung ist Provider für kleine Apps und Riverpod (vom gleichen Autor, Remi Rousselet) für mittlere bis große Apps. BLoC (Business Logic Component) ist ebenfalls extrem populär, vor allem in größeren Teams und bei Apps mit komplexen Async-Flows. GetX ist umstritten — sehr produktiv, aber mit "all-in-one"-Ansatz, der nicht jedem schmeckt. signals (Solid-inspiriert) gewinnt 2026 an Boden für reaktive State-Modelle.

React Native: Zustand ist 2026 das beliebteste leichtgewichtige Tool, Jotai für Atom-basierte Modelle, Redux Toolkit für große Apps mit langer Historie. Für Server State ist TanStack Query (ehemals React Query) der unangefochtene Standard — und kompatibel mit Web, Mobile, Server. MobX und XState haben treue Communities. Für Form-State react-hook-form + zod für Schema-Validierung.

Beide Ökosysteme haben ausgereifte Lösungen für jede Größe und Komplexität. Die Wahl ist selten ein Make-or-Break.

---

13. Navigation und Routing

Flutter: go_router (offiziell von Google maintained) ist der De-facto-Standard für deklarative, URL-basierte Navigation mit Deep-Links, Nested-Routing, Authentication-Guards. Für komplexere Custom-Navigation greifen Teams auf auto_route oder den Navigator 2.0 direkt zurück.

React Native: Zwei Spitzenreiter:

• react-navigation v7 — mature, flexibel, gut dokumentiert, deckt 99 % der Anforderungen ab
• expo-router — file-based Routing inspiriert von Next.js, fühlt sich für Web-Devs sofort vertraut an, nutzt unter der Haube React Navigation. 2026 die Default-Wahl für neue Projekte.

Beide Frameworks haben vollständige Deep-Link-Unterstützung (Universal Links / App Links), Stack/Tab/Drawer-Navigatoren, Animation-Customization.

---

14. Testing-Strategien (Unit, Widget, Integration, E2E)

Test-Pyramide gilt für beide:

Flutter:

• Unit-Tests mit test-Package und mocktail für Mocks
• Widget-Tests mit flutter_test (rendern Widgets in einer headless Engine, sehr schnell)
• Integration-Tests mit integration_test (laufen auf echten Geräten/Simulatoren)
• E2E mit patrol (mächtige native Layer für Berechtigungs-Dialoge, Push, etc.) oder maestro (YAML-basiert, framework-agnostisch)

React Native:

• Unit-Tests mit jest
• Component-Tests mit @testing-library/react-native
• E2E mit Detox (klassisch, sehr stabil), Maestro (modern, einfach), oder Appium
• Snapshot-Tests sparsam einsetzen (oft mehr Schmerz als Nutzen)

Sowohl Flutter als auch React Native lassen sich exzellent in CI/CD-Pipelines testen. Flutter hat den leichten Vorteil, dass Widget-Tests in der headless Engine extrem schnell laufen — ein vollständiger Test-Run mit hunderten Tests dauert Sekunden, nicht Minuten.

---

15. CI/CD, Build-Pipelines und App-Distribution

Beide Frameworks integrieren sich in moderne CI/CD-Pipelines (GitHub Actions, GitLab CI, Bitrise, CircleCI, Codemagic, EAS).

Flutter:

• Codemagic, Bitrise, GitHub Actions sind die populärsten Optionen
• Fastlane für iOS-Signing/-Upload ist Standard
• Eigenheiten: Apple-Provisioning kann tricky sein, Build-Caches mit Gradle/Xcode optimieren

React Native:

• EAS Build (Expo Application Services) ist 2026 der Komfort-König — du committest, sagst eas build, und bekommst einen IPA/AAB inkl. Code-Signing. Cloud-CI inklusive.
• Alternativen: Fastlane + GitHub Actions, Bitrise, CircleCI
• Mit Bare-Workflow: volle Kontrolle, mehr Setup-Aufwand

EAS Build und EAS Submit haben für viele Teams die Time-to-First-Build von Tagen auf Stunden gesenkt. Flutter hat mit Codemagic eine ähnliche Lösung, ist aber weniger tief integriert.

---

16. Sicherheit und Compliance

Beide Frameworks erlauben das Bauen sicherer Apps — die Unterschiede liegen im Detail.

Code-Schutz:

• Flutter: AOT-kompiliert zu nativem ARM-Code. Reverse-Engineering ist deutlich aufwendiger als bei JS-basierten Apps. obfuscate-Flag verschleiert Symbole zusätzlich.
• React Native: JavaScript ist (selbst mit Hermes-Bytecode) leichter zu reverse-engineeren. Kritische Logik gehört entweder ins Backend oder in ein natives TurboModule. Hermes Bytecode bietet einen gewissen Schutz, ist aber dekompilierbar.

Secrets/Credentials:

• Flutter: flutter_secure_storage (Keychain auf iOS, EncryptedSharedPreferences auf Android)
• React Native: expo-secure-store oder react-native-keychain

Compliance (DSGVO, BSI, ISO 27001):

• Beide Frameworks sind compliance-fähig, sofern das App-Design es ist
• Tracking-Libraries (Firebase Analytics, Sentry, Datadog) müssen DSGVO-konform konfiguriert werden — App-Tracking-Transparency (ATT) auf iOS ist Pflicht
• Für Banken/Versicherungen sind Custom-Pinning-Setups, Jailbreak-/Root-Detection, App-Integrity-Checks (Play Integrity, App Attest) essentiell — beide Frameworks haben passende Plugins

Penetration-Testing-Erfahrungen 2025/26 (qualitativ): Pentester berichten, dass Flutter-Apps systematisch schwerer zu analysieren sind, weil der Wechsel von Skia/Impeller-Kommandos zu lesbaren UI-Strukturen aufwendig ist. RN-Apps mit JS-Sourcemaps in Production sind ein klassischer Anfänger-Fehler.

---

17. Web-Support, Desktop-Support und Embedded

Hier ist Flutter klar voraus.

Flutter:

• Web: Stabil seit Flutter 2.0 (2021), inzwischen mit Wasm-Build (Flutter 3.22+). SEO-Limitierungen bestehen weiter (kein progressives HTML, JS-bedingt — aber für interne Tools, Dashboards, Auth-Flows top)
• Windows / macOS / Linux: Stable seit Flutter 3, in Produktion eingesetzt z. B. für interne Tools von Volkswagen, Roche, Bayer
• Embedded: Embedded-Embedder für Yocto-Linux-basierte Geräte, Apple TV, Samsung TizenOS (Community), BMW iDrive (mit Flutter-Embedder im Auto-Cockpit)

React Native:

• Web: react-native-web von Necolas Gallagher, mature, in Production bei Twitter/X eingesetzt. Nicht ganz so nahtlos wie Flutter Web — oft besser, ein React-Web-Frontend separat zu pflegen
• Windows: react-native-windows (Microsoft) — stabil, in Microsoft-Apps eingesetzt
• macOS: react-native-macos — funktional, aber kleinere Community
• VisionOS / Apple TV: Plugins existieren, aber Community-getrieben
• Embedded: keine offizielle Unterstützung

Wer eine echte Single-Codebase für iOS + Android + Web + Desktop will, hat mit Flutter weniger Brüche als mit React Native. Wer Web ohnehin separat als Next.js/React-Web-Projekt baut und sich Mobile-only-Code wünscht, ist mit React Native gut bedient.

---

18. Accessibility & Internationalisierung

Accessibility (a11y):

Beide Frameworks unterstützen:

• Screen Reader (TalkBack auf Android, VoiceOver auf iOS)
• Dynamic Text Sizing
• High Contrast / Dark Mode
• Keyboard-Navigation (relevant für Web/Desktop)

Flutter's Semantics-Widget gibt sehr feinkörnige Kontrolle. React Native nutzt accessibilityRole, accessibilityLabel, accessibilityState props.

In der Praxis: Beide Frameworks bauen accessible Apps, aber beide Default-Setups sind nicht "automatisch barrierefrei". Ohne explizites a11y-Engineering hast du Probleme. Tools wie Lighthouse (Web), Accessibility Inspector (Xcode), Accessibility Scanner (Android Studio) sollten Pflicht in jeder Pipeline sein.

Internationalisierung (i18n):

Flutter nutzt das intl-Package + flutter_localizations. ARB-Dateien (Application Resource Bundle, JSON-basiert) sind Standard. Pluralization, Gender, Date/Number-Formats out-of-the-box. Tools wie Crowdin, Lokalise, Phrase haben Flutter-Connectors.

React Native nutzt typischerweise i18next, react-intl oder lingui. JSON-Dateien (oder PO-Files mit Lingui). Pluralization etc. via ICU MessageFormat.

Beide gut. Flutter hat den minimalen Vorteil, dass intl "official" ist und sehr eng mit dem Datums-/Zahlen-System verzahnt ist.

---

19. Update-Strategien: OTA, CodePush, Play-Feature-Delivery

Ein massiver Vorteil, den React Native lange für sich verbuchen konnte: Over-the-Air-Updates. Du kannst JS-Bundles ohne App-Store-Review pushen — kritisch für Bugfixes oder schnelle Feature-Iterationen.

React Native:

• EAS Update (Expo) — der De-facto-Standard 2026, mit Channels, Branches, Rollout-Steuerung
• AppCenter CodePush — Microsoft hat den Service Anfang 2025 endgültig abgekündigt (wichtige News für Migration!)
• Eigene OTA-Server möglich

Flutter:

• Shorebird — die führende Lösung 2026 (gegründet von Eric Seidel, ehemals Flutter-Team-Lead). Patches einzelne Dart-Code-Teile zur Runtime. Inzwischen ausgereift, mit Enterprise-Support
• Selbstgebaut über Plugin-System, aber komplex und nicht App-Store-konform für native Code-Änderungen

App-Store-Policies: Apple und Google erlauben OTA-Updates, wenn sie keine signifikante Funktions-Änderung darstellen (Apple App Review Guideline 3.3.1). In der Praxis sind Bug-Fixes und kleine Features akzeptiert; ganze neue Features oder UI-Overhauls riskieren Ablehnung.

OTA ist ein Game-Changer für Teams, die schnell iterieren — und reduziert das Risiko, dass ein kritischer Bug Tage im Review hängt.

---

20. Kosten, Time-to-Market und TCO-Modell

Hier wird's für Entscheider interessant. Die Total Cost of Ownership (TCO) hängt von vielen Faktoren ab; trotzdem lassen sich Größenordnungen ableiten.

20.1 Initialer Build (MVP, 8–12 Wochen, mittlere Komplexität)

Annahme: 4 Entwickler, ein PM/PO, ein Designer. Tagessatz für Senior Cross-Platform Dev in DACH 2026: 850–1.250 €.

• Native (iOS + Android, parallele Teams): 380.000 – 550.000 €
• Flutter: 200.000 – 320.000 €
• React Native: 200.000 – 320.000 €
• React Native + Expo (heavy use of EAS): 170.000 – 280.000 €

Cross-Platform spart typischerweise 35–50 % der initialen Entwicklungskosten gegenüber paralleler nativer Entwicklung.

20.2 Wartung (jährlich, Dauerbetrieb)

• Native (zwei Teams): ~25–35 % der Initialkosten/Jahr
• Cross-Platform: ~20–28 % der Initialkosten/Jahr

Über fünf Jahre summiert sich der TCO-Vorteil von Cross-Platform auf 30–45 % gegenüber nativem Doppel-Stack.

20.3 Hidden Costs

• Native-Bridge-Pflege bei Plugin-Inkompatibilitäten — beide Frameworks verlangen mit jeder Major-Version Anpassungs-Aufwand
• Store-Anforderungen (App-Tracking-Transparency, Privacy Manifests, Target SDK Updates) — beidseitig identischer Aufwand
• Hardware-Test-Lab für reale Geräte-Tests — beidseitig identisch

20.4 Time-to-Market

Für ein typisches B2C-MVP (Login, Onboarding, Listen, Detail-Screens, Push, Settings):

• Flutter / React Native (klein erfahrenes Team): 6–10 Wochen
• Native parallel (gleiches Personal): 10–14 Wochen

---

21. Hiring, Gehälter und Verfügbarkeit von Entwicklern in DACH

Stand Q1/2026 in der DACH-Region:

Verfügbarkeit (offene Profile auf LinkedIn DE/AT/CH):

• React Native Devs: ~9.500 Profile mit "React Native" als Skill
• Flutter Devs: ~8.200 Profile mit "Flutter" als Skill
• iOS Native Swift: ~14.000
• Android Native Kotlin: ~13.500

React Native hat den größeren Talent-Pool, weil viele Web-React-Devs den Sprung wagen. Flutter holt auf — pub.dev-Statistiken zeigen ein Wachstum von 20 % yoy bei aktiven Dart/Flutter-Devs.

Gehälter (brutto, all-in, Senior, DACH-Median 2026):

• Senior React Native Dev (5+ Jahre): 75.000 – 95.000 € (DE), 95.000 – 130.000 CHF (CH), 70.000 – 90.000 € (AT)
• Senior Flutter Dev: 72.000 – 92.000 € (DE), 90.000 – 125.000 CHF (CH), 68.000 – 88.000 € (AT)
• Lead/Architect (beide): +15–25 % auf Senior

Freelancer-Tagessätze: 850 – 1.350 € (Senior, beide Frameworks). Spezialisierte Agenturen mit dediziertem Mobile-Team rufen 1.100 – 1.600 € auf, mit Premium-Aufschlag für Performance/Architecture-Spezialisten.

Recruiting-Realität: Beide Frameworks sind in 4–10 Wochen besetzbar, je nach Seniorität und Standort. Flutter-Hires kommen oft aus dem Java/Kotlin-Native-Lager und brauchen 2–3 Wochen Onboarding; RN-Hires aus dem React-Web-Lager sind in 1 Woche produktiv (für Mobile-spezifische Patterns brauchen sie 2–4 Wochen).

---

22. Reale Case Studies: BMW, Alibaba, Discord, Shopify, Tesla

Echte Beispiele schlagen Theorie:

Flutter-Cases

BMW – My BMW App (seit 2020, vollständig auf Flutter): 4-stelliger Engineering-Footprint, Apps in 47 Märkten, Millionen MAU. BMW konsolidierte vorher zwei native Teams und drei Apps (BMW Connected, ConnectedDrive, etc.) zu einer Codebase. Performance auf Flutter-Niveau ohne Kompromisse.

Alibaba – Xianyu (Second-Hand-Marktplatz): 200+ Millionen Nutzer, Flutter-basiert. Eines der frühesten Flutter-Erfolgsgeschichten in einem hochfrequenten Commerce-Umfeld.

Google Pay (USA, Indien): Migration von zwei nativen Codebases auf Flutter Ende 2020 abgeschlossen. Über 35 Engineers, 1,7 Millionen Lines of Code. Resultat: 70 % schnellere Feature-Delivery.

Toyota Infotainment-Systeme (Tokyo Auto Show 2022 announced): Toyota nutzt Flutter im Embedded-Cockpit für ihre nächste Fahrzeug-Generation.

Wolt (Foodora-Konzern): Stark Flutter-basiert für ihre Courier-App.

React-Native-Cases

Meta selbst: Facebook Marketplace, Meta Ads Manager, große Teile von Instagram (z. B. Login, einige Feeds).

Shopify – Shop App: ~200 Millionen Nutzer, vollständig React Native mit eigenem Skia-Renderer (react-native-skia). Shopify ist seit 2020 RN-First.

Discord – Mobile App: RN-Anteil deutlich gestiegen, Mix aus RN und nativ. iOS-App seit Jahren in RN für viele Screens.

Microsoft – Teams Mobile, Office-Komponenten: Microsoft setzt RN für Cross-Plattform-Code in Teams, Outlook-Komponenten, Xbox-Companion-App.

Coinbase – Wallet App: seit 2021 vollständig RN.

Tesla – Service-App (interne App für Service-Techniker): RN-basiert.

Bloomberg – Mobile Terminal: RN.

Beobachtung

Beide Frameworks werden in Apps mit hunderten Millionen MAU produktiv eingesetzt. Es ist 2026 keine technische Limitierung mehr, eine "echte Konzern-App" mit Cross-Platform zu bauen. Die Wahl ist eine strategische, keine technische.

---

23. Wann React Native gewinnt — und wann Flutter

Hier eine klare Heuristik:

Wähle Flutter, wenn ...

• Du eine pixel-perfekte, hochangepasste UI brauchst
• Du Custom-Animationen (60–120 fps) und Custom-Painting brauchst
• Du Web + Desktop aus einer Codebase bedienen willst
• Dein Team Java/Kotlin/C#/Swift-Hintergrund hat und Dart leicht lernt
• Du Apps bauen willst, die sich in 5 Jahren noch identisch zur ersten Version verhalten (deterministische Rendering-Engine)
• Du Embedded-Targets (Auto, IoT, Kiosk) ansteuern willst
• Du eine extrem skalierbare Apps für viele OS-Versionen baust und visuelle Konsistenz wichtiger ist als perfekte OS-Treue

Wähle React Native, wenn ...

• Dein Team React/Web-Hintergrund hat
• Du Code mit deinem Web-Frontend (Next.js etc.) teilen willst (auch nur Logik, Validation, API-Clients)
• Du echte native UI-Komponenten brauchst (Banking, Behörden, Sport-Wettkampf)
• Du Brownfield in eine bestehende native App integrieren willst
• Du Expo + EAS für radikal vereinfachtes Build/OTA willst
• Du den größten Talent-Pool und das größte Package-Ökosystem nutzen willst
• Du AI/ML-Features stark mit Web teilen willst (TF.js, ONNX-Web, transformers.js)

---

24. AI- und ML-Integration: On-Device-Inferenz mit beiden Frameworks

2026 ist AI-on-Device der Top-Trend. Beide Frameworks haben dafür Lösungen.

Flutter:

• tflite_flutter — TensorFlow Lite Runtime
• google_mlkit_* — ML Kit (Texterkennung, Face Detection, Translate, Barcodes etc.)
• flutter_gemma / mediapipe_flutter — Gemma 2/3 On-Device-LLMs
• CoreML-Bindings via Method-Channels für iOS-spezifische ML-Workloads
• ONNX Runtime via FFI

React Native:

• react-native-fast-tflite — TFLite mit Hermes/JSI-Optimierung
• react-native-mlkit — ML Kit Wrapper
• @xenova/transformers (Browser) lässt sich auf RN-Web nutzen; für native CoreML/ML Kit
• Apple Foundation Models APIs (iOS 18+) via Native Modules
• react-native-vision-camera + Frame-Processors mit Reanimated für Live-AI auf Kamera-Streams

Für Apps, die LLM-Calls zum Backend machen (OpenAI, Anthropic, Google Gemini), unterscheidet sich kaum etwas zwischen den Frameworks — beide haben ausgezeichnete Streaming-HTTP-Clients, beide handeln Server-Sent-Events oder WebSockets sauber.

Für On-Device-LLMs (Gemma 2B, Phi-3, Llama 3.2 1B/3B) ist die Toolchain auf beiden Seiten 2026 ausgereift; Flutter hat mit flutter_gemma einen leichten Vorteil bei der Out-of-the-Box-Erfahrung, RN gewinnt bei der Community-Größe (mehr Beispiele, mehr Tutorials).

---

25. Migrationspfade und Rewrite-Strategien

Du hast eine alte App und überlegst zu wechseln? Hier die wichtigsten Pfade.

Von Native zu Flutter / React Native

Brownfield-Integration: Beide Frameworks unterstützen es, einzelne Screens (oder Module) in eine bestehende native App einzubetten. So kannst du iterativ migrieren — z. B. Settings-Screen, dann Onboarding, dann Login, dann Feed.

• Flutter: Flutter Add-to-App — gut dokumentiert, in Produktion bei New York Times eingesetzt
• React Native: ein Klassiker, seit 2015 etabliert, viele Beispiele

Von React Native zu Flutter (oder umgekehrt)

Echte Rewrites sind kostspielig. Faustregel: nur, wenn das aktuelle Framework strategisch nicht mehr passt (z. B. Performance-Bottleneck, das in absehbarer Zeit nicht lösbar ist; massiver Hiring-Engpass; strategische Plattform-Verlagerung).

Best Practice: Inkrementeller Rewrite via Brownfield. Niemals Big Bang.

Von Cordova/Ionic auf RN/Flutter

Klassischer Pfad für Apps aus 2014–2018. Performance-Sprung dramatisch. Daten-Schichten (REST, GraphQL) lassen sich oft 1:1 übernehmen, UI muss neu geschrieben werden.

Von Xamarin/MAUI

Microsoft hat 2024 angekündigt, MAUI weiter zu warten, aber viele Teams migrieren wegen kleinerer Community und Tooling-Schmerz auf RN oder Flutter. C#-Logik kann via ASP.NET Web API + RN/Flutter-Frontend wiederverwendet werden.

---

26. Häufige Anti-Patterns und Stolperfallen

Flutter:

• StatefulWidget-Wildwuchs ohne klare State-Management-Strategie → unwartbar nach 6 Monaten
• setState() in tiefen Trees → Performance-Tod
• Zu viele rebuilds durch falsch platzierte Widgets — const Konstruktoren, RepaintBoundary und AutomaticKeepAlive strategisch nutzen
• ListView() statt ListView.builder() für lange Listen — der Klassiker
• Plattform-spezifische Bugs ignorieren (iOS Simulator vs. echtes Gerät)

React Native:

• useEffect-Spaghetti — React-Gold-Regel: weniger ist mehr
• Re-Renders durch nicht-memoisierte Inline-Objekte/-Funktionen — React.memo, useMemo, useCallback einsetzen
• FlatList mit komplexen Items ohne getItemLayout oder ohne Wechsel zu FlashList
• Bridge-Bottlenecks aus alten Bibliotheken — auf neue Architektur prüfen!
• Fehlende keyExtractor oder instabile Keys → Reconciliation-Hölle
• Animationen auf JS-Thread statt Reanimated-Worklets

Beide:

• Zu viel "Inline Logic" in UI-Komponenten — Domain trennen
• Fehlendes Error-Handling für Async-Calls
• Kein Crash-Reporting (Sentry, Crashlytics) ab Tag 1
• Keine systematische E2E-Test-Strategie

---

27. Code-Beispiele Side-by-Side

Ein einfacher Counter mit State, Button und Text — der "Hello World" jedes Frameworks.

Flutter

import 'package:flutter/material.dart';

void main() => runApp(const MyApp());

class MyApp extends StatelessWidget {
  const MyApp({super.key});
  @override
  Widget build(BuildContext context) => MaterialApp(
        title: 'Counter Demo',
        theme: ThemeData(useMaterial3: true),
        home: const CounterPage(),
      );
}

class CounterPage extends StatefulWidget {
  const CounterPage({super.key});
  @override
  State<CounterPage> createState() => _CounterPageState();
}

class _CounterPageState extends State<CounterPage> {
  int _count = 0;
  void _increment() => setState(() => _count++);

  @override
  Widget build(BuildContext context) => Scaffold(
        appBar: AppBar(title: const Text('Counter')),
        body: Center(
          child: Text('Count: $_count', style: const TextStyle(fontSize: 32)),
        ),
        floatingActionButton: FloatingActionButton(
          onPressed: _increment,
          child: const Icon(Icons.add),
        ),
      );
}

React Native (mit Expo, TypeScript)

import { useState } from 'react';
import { View, Text, Pressable, StyleSheet } from 'react-native';

export default function App() {
  const [count, setCount] = useState(0);

  return (
    <View style={styles.container}>
      <Text style={styles.title}>Count: {count}</Text>
      <Pressable
        accessibilityRole="button"
        onPress={() => setCount((c) => c + 1)}
        style={styles.button}
      >
        <Text style={styles.buttonText}>+</Text>
      </Pressable>
    </View>
  );
}

const styles = StyleSheet.create({
  container: { flex: 1, justifyContent: 'center', alignItems: 'center' },
  title: { fontSize: 32, marginBottom: 24 },
  button: { backgroundColor: '#4f46e5', borderRadius: 999, padding: 16 },
  buttonText: { color: 'white', fontSize: 24 },
});

Liste mit API-Call (REST)

Flutter (mit dio + Riverpod):

final usersProvider = FutureProvider<List<User>>((ref) async {
  final dio = Dio();
  final res = await dio.get('https://api.example.com/users');
  return (res.data as List).map(User.fromJson).toList();
});

class UserListPage extends ConsumerWidget {
  const UserListPage({super.key});
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final users = ref.watch(usersProvider);
    return Scaffold(
      appBar: AppBar(title: const Text('Users')),
      body: users.when(
        data: (list) => ListView.builder(
          itemCount: list.length,
          itemBuilder: (_, i) => ListTile(title: Text(list[i].name)),
        ),
        loading: () => const Center(child: CircularProgressIndicator()),
        error: (e, _) => Center(child: Text('Error: $e')),
      ),
    );
  }
}

React Native (mit TanStack Query + FlashList):

import { useQuery } from '@tanstack/react-query';
import { FlashList } from '@shopify/flash-list';
import { Text, View, ActivityIndicator } from 'react-native';

type User = { id: string; name: string };

const fetchUsers = async (): Promise<User[]> => {
  const r = await fetch('https://api.example.com/users');
  if (!r.ok) throw new Error('Failed');
  return r.json();
};

export default function UserList() {
  const { data, isLoading, error } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  });

  if (isLoading) return <ActivityIndicator />;
  if (error) return <Text>Error: {(error as Error).message}</Text>;

  return (
    <FlashList
      data={data}
      keyExtractor={(u) => u.id}
      estimatedItemSize={60}
      renderItem={({ item }) => (
        <View style={{ padding: 16 }}>
          <Text>{item.name}</Text>
        </View>
      )}
    />
  );
}

Beide Snippets sind ca. 25 Zeilen, beide laden Daten async, beide rendern eine performante Liste, beide haben Loading-/Error-States. Die Eleganz liegt im Auge des Betrachters.

---

28. Entscheidungsmatrix: 25 Kriterien, gewichtet

Gewichtete Summen (pro Punkt × Gewicht):

• Flutter: ~1.165
• React Native: ~1.067

Klingt nach Flutter-Sieg — aber: Diese Gewichte sind generisch. Für deine App können Kriterien wie "Web-Code-Sharing" oder "OTA" deutlich höher gewichtet sein. Die Tabelle ist ein Werkzeug, kein Verdikt. Bau dir deine eigene Version.

---

29. Zukunftsausblick 2027–2030

Flutter-Roadmap (öffentlich kommuniziert oder absehbar):

• Volle Wasm-Unterstützung im Web (verbesserte Cold-Start-Performance)
• Impeller auf Desktop (macOS, Windows, Linux)
• Bessere Android-XR/Vision-Pro-Unterstützung
• Engere Integration mit Material Expressive (Material 4)
• Verbessertes 3D (Flutter Scene)
• Engere Gemini-Integration im DevTooling

React-Native-Roadmap:

• Vollständige Migration aller großen Libraries auf New Architecture
• React 19 / 20 Concurrent Features tief verzahnt
• React Native für visionOS und VisionPro reifer
• Bessere Web/SSR-Story für react-native-web-Apps
• Expo SDK 55+ mit weiterer Konsolidierung von Features
• Hermes als einzige unterstützte JS-Engine

Marktprognose:

• Beide Frameworks werden 2030 noch dominant sein
• Native (SwiftUI, Compose) bleibt für plattform-spezifische Premium-Apps und sehr OS-nahe Use Cases relevant
• KMP (Kotlin Multiplatform) wächst weiter im Backend/Shared-Logic-Bereich, ersetzt aber kein Cross-Platform-UI
• AI-Integration wird zum Standard, beide Frameworks werden hier nachrüsten

Wer 2026 in Cross-Platform investiert, macht eine Wette mit hohem Erwartungswert in beide Richtungen.

---

30. FAQ — die 40 häufigsten Fragen

1. Ist Flutter "schneller" als React Native? In Cold-Start und Custom-Animationen meist ja. In normalen Listen-/CRUD-Apps spürbar gleichauf seit der neuen RN-Architektur.

2. Stirbt React Native, weil Airbnb 2018 ausstieg? Nein. Meta, Microsoft, Shopify, Discord, Coinbase, Bloomberg setzen produktiv ein. Airbnb's Issues waren spezifisch (Brownfield-Komplexität, internes Tooling) und liegen weit zurück.

3. Wird Dart außerhalb von Flutter relevant? Begrenzt. Dart Frog und Serverpod gewinnen Anhänger, aber Dart bleibt primär eine Flutter-Sprache.

4. Kann ich mein Web-Frontend mit React Native teilen? Logik (Hooks, Redux/Zustand, API-Clients) ja, UI (View vs. div) nicht ohne react-native-web. Code-Wiederverwendung 30–60 % typisch.

5. Funktioniert Flutter für Web-Production? Für interne Tools, Dashboards, Webapps mit App-Charakter: ja. Für SEO-kritische Marketing-Sites: nein.

6. Welches Framework hat besseren Hot-Reload? Flutter, knapp. RN's Fast Refresh ist 2026 sehr gut, hat aber gelegentliche State-Verlust-Edge-Cases.

7. Welches Framework ist "produktionsreifer"? Beide. Beide sind in Apps mit hunderten Millionen MAU im Einsatz.

8. Brauche ich für Flutter einen Mac für iOS-Builds? Ja — wie bei React Native auch. Alternativ: Codemagic, EAS, GitHub Actions mit macOS-Runnern.

9. Welches hat bessere Camera-Unterstützung? React Native mit react-native-vision-camera ist 2026 die führende Lösung; Flutter mit camerawesome und camera-Plugin solide.

10. Welches ist besser für AR? Beide haben ARCore-/ARKit-Plugins. Für Premium-AR-Apps mit Custom-Pipelines lohnt nativer Code unter Cross-Platform-Schale.

11. Welches ist besser für Spiele? Weder noch primär. Für 2D-Casual-Games funktioniert Flutter mit Flame ganz ordentlich. Für 3D/Premium: Unity oder Unreal.

12. Wie groß ist die App im Store? Flutter: 12–25 MB Core. RN: 7–15 MB Core. Bei großen Apps verschwindet der Unterschied im Asset-Footprint.

13. Welches Framework hat besseren Support für SwiftUI/Compose? Beide haben Plugins, um native Views einzubetten. Echte tiefe Integration ist aufwendig — beide Frameworks lieber als "rendert eigene UI" verstehen.

14. Kann ich mit React Native eine Apple-Watch-App bauen? Nicht direkt. Die WatchOS-App muss in SwiftUI separat geschrieben werden, mit Daten-Sharing über Companion-API.

15. Kann ich mit Flutter eine Apple-Watch-App bauen? Nicht direkt. Same story.

16. Wie sicher sind Flutter-/RN-Apps gegen Reverse Engineering? Flutter (AOT, Skia-Calls) ist deutlich schwerer zu reversen. RN (Hermes-Bytecode) ist mit Tools dekompilierbar. Kritische Logik gehört ins Backend.

17. Welches hat bessere DSGVO-Tools? Gleichstand. App-Tracking-Transparency (ATT), Privacy Manifests (iOS), Data Safety (Google Play) müssen in beiden Frameworks gleich behandelt werden.

18. Brauche ich Expo, um React Native zu nutzen? Nein, aber 2026 ist Expo SDK quasi der Default-Pfad für neue Projekte — sogar Bare-Workflow nutzt viele Expo-Pakete.

19. Was ist der Unterschied zwischen Expo Managed und Bare Workflow? Managed: Expo handelt alle Native-Builds, du schreibst nur JS/TS. Bare: Eigenes Xcode-/Gradle-Projekt mit voller Kontrolle. Mit EAS verschwimmen die Grenzen.

20. Funktioniert Flutter offline? Selbstverständlich. Caching, lokale DB (Isar, SQLite via sqflite, Drift, Hive), File-Storage — alles vorhanden.

21. Funktioniert React Native offline? Ja — react-native-mmkv, AsyncStorage, SQLite-Wrapper, WatermelonDB, etc.

22. Welche Datenbank für Flutter? Drift (Mature SQLite-Wrapper), Isar (NoSQL, schnell), Hive (key-value), sqflite (low-level). Für Sync mit Cloud: Firestore, Supabase, PowerSync.

23. Welche Datenbank für React Native? SQLite (op-sqlite, react-native-quick-sqlite), WatermelonDB (reactive, sync-fähig), MMKV für Key-Value, RxDB für offline-first.

24. Wie ist die Push-Notifications-Story? Beide nutzen FCM für Android und APNS für iOS. Flutter: firebase_messaging. RN: expo-notifications oder @react-native-firebase/messaging.

25. Kann ich In-App-Purchases umsetzen? Ja. Flutter: in_app_purchase (offiziell). RN: react-native-iap oder expo-in-app-purchases. RevenueCat als populäres SDK in beiden Frameworks.

26. Was ist mit Gaming-Engines? Flutter hat Flame (2D), Forge (Wrapper für Box2D). RN hat keine populäre eigene 2D-Engine, dafür gibt es Wrapper für Phaser via WebView.

27. Welches ist besser für Audio-/Video-Streaming? RN mit react-native-video, react-native-track-player ausgereift. Flutter mit video_player, just_audio ebenfalls solide. Live-Streaming (RTMP, WebRTC): Plugin-basiert, beide möglich, RN hat mehr fertige Lösungen.

28. Welches Framework macht ältere Geräte (Android 8, iOS 13) besser glücklich? Beide unterstützen Down-Targeting. Flutter braucht etwas mehr Speicher; RN mit Hermes ist auf Low-End oft etwas leichter.

29. Wie ist die Map-Integration? Google Maps: in beiden Frameworks via offizielle Plugins. Apple Maps: Flutter über apple_maps_flutter, RN über react-native-maps. Mapbox: in beiden gut unterstützt.

30. Welches ist besser für Bluetooth (BLE)? Beide haben Plugins (flutter_blue_plus, react-native-ble-plx). Komplexe BLE-Stacks erfordern oft eigene Native-Module.

31. Macht Flutter Web SEO? Flutter Web rendert client-side via Canvas/Wasm. SEO-Crawler sehen wenig. Für SEO sind separate SSR-Lösungen (Next.js etc.) besser.

32. Macht React Native Web SEO? Mit react-native-web und Next.js-Wrapper möglich. Praxis: Web-Frontend separat in Next.js bauen, mobile-Code mit RN, gemeinsame Logik in shared Package.

33. Wie ist die Story für Apple Vision Pro / visionOS? RN hat experimentellen Support. Flutter hat Community-Initiativen. Für ernsthafte Vision-Pro-Apps weiterhin nativ Swift empfehlenswert.

34. Wie ist die Story für CarPlay / Android Auto? Beide Frameworks bieten Plugins, aber Custom-Native-Code ist meist nötig. RN-Brownfield ist hier oft eleganter.

35. Wie ist die Wear-OS-Story? Beide Frameworks haben experimentelle Wege. Für ernsthafte Wear-OS-Apps weiterhin nativ Compose empfehlenswert.

36. Welches ist besser für Animations-lastige Apps (z. B. Health, Fitness)? Flutter mit Rive/Lottie und eigenem Painting ist sehr stark. RN mit Reanimated 3+, Skia und Lottie ebenfalls top.

37. Funktioniert Server-Side-Rendering? Bei Flutter Web nein (Canvas-basiert). Bei react-native-web mit Next.js ja.

38. Welches Framework hat bessere Storybook-Integration? RN, deutlich. Storybook für RN ist ausgereift. Flutter hat Widgetbook, das aufholt, aber kleiner ist.

39. Welches Framework ist besser für React-Server-Components? Aktuell keines, da RSC ein Web/Server-Konzept ist. Beobachten lohnt sich.

40. Wenn ich heute starten würde — was würdest du wählen? Wenn ich ein React-Web-Team habe: React Native (Expo). Wenn ich ein gemischtes Team und maximale UI-Konsistenz möchte: Flutter. Wenn ich Embedded-Targets / Desktop / Web aus einer Codebase will: Flutter. Wenn ich einen MVP in 6 Wochen bauen muss: React Native + Expo.

---

31. Glossar

• AOT (Ahead-of-Time-Compilation): Code wird vor der Auslieferung in nativen Maschinencode kompiliert.
• Bridge: Die alte asynchrone Kommunikationsschicht zwischen JS- und Native-Threads in React Native.
• Bytecode: Eine plattformunabhängige Zwischenrepräsentation, die zur Laufzeit interpretiert oder weiter kompiliert wird (z. B. Hermes-Bytecode).
• Cupertino: Flutter-Komponentenpaket, das iOS-Komponenten nachbaut.
• Dart: Die von Google entwickelte Programmiersprache, in der Flutter-Apps geschrieben werden.
• Embedder: Die Schicht in Flutter, die die Engine an das jeweilige OS anbindet.
• Expo: Plattform und Toolchain für React Native (SDK, EAS-Build, EAS-Update, Snack).
• Fabric: Der neue Renderer in der React Native New Architecture.
• FFI (Foreign Function Interface): Direktes Aufrufen von C/C++-Bibliotheken aus Dart.
• Flutter Engine: C++-Kern, der Dart-Runtime, Skia/Impeller, Text-Layout etc. enthält.
• Hermes: Die für React Native optimierte JavaScript-Engine.
• Impeller: Die neue Rendering-Engine in Flutter, die Skia ablöst.
• JIT (Just-in-Time-Compilation): Code wird zur Laufzeit kompiliert; ermöglicht Hot Reload.
• JSI (JavaScript Interface): Die C++-Brücke zwischen JS-Engine und nativem Code in der RN New Architecture.
• Material 3 / Material You: Googles aktuelles Design-System.
• Metro: Der React-Native-Bundler.
• OTA (Over-the-Air): App-Updates ohne Store-Review (für interpretierten Code wie JS).
• Pigeon: Codegen-Tool für Flutter, das type-safe Platform-Channels erzeugt.
• Platform Channels: Flutter's Mechanismus für die Kommunikation zwischen Dart und nativem Code.
• Riverpod: Beliebte Dependency-Injection-/State-Management-Library für Flutter.
• Shadow Tree: Interner Baum in der React-Native-Architektur, der für Layout-Berechnung dient.
• Shorebird: OTA-Update-Lösung für Flutter.
• Skia: Open-Source-2D-Grafikbibliothek (von Google), bisher Flutter's Renderer.
• TurboModules: Lazy-loaded Native Modules in React Native New Architecture.
• Yoga: C++-Implementierung von CSS-Flexbox, von Meta entwickelt, von React Native für Layout genutzt.

---

32. Weiterführende Quellen

• Flutter Documentation: https://docs.flutter.dev
• React Native Documentation: https://reactnative.dev
• Expo Documentation: https://docs.expo.dev
• Dart Language Tour: https://dart.dev/guides/language/language-tour
• Flutter Engine Architecture: https://github.com/flutter/flutter/wiki/The-Engine-architecture
• React Native New Architecture: https://reactnative.dev/architecture/landing-page
• Stack Overflow Developer Survey 2025
• IDC Worldwide Mobile Developer Forecast 2026
• Google I/O 2025 Recap (Flutter Announcements)
• React Native Conf 2025 Recap

---

Abschluss: Beide gewinnen — die Frage ist nur, wer in deinem Kontext besser passt

Wer 2026 noch debattiert, ob "Flutter oder React Native objektiv besser" sei, hat die letzten zwei Jahre verschlafen. Beide Frameworks sind ausgereift, beide werden von Konzernen produktiv eingesetzt, beide haben aktive Communities, beide haben Roadmaps, die deutlich über 2030 hinausgehen.

Die richtige Frage lautet: Welches Framework passt besser zu deinem Team, deiner Domäne und deiner Roadmap? Wer ein React-Web-Team hat, einen MVP schnell launchen will und ein riesiges Package-Ökosystem braucht, fährt mit React Native (idealerweise + Expo) bestens. Wer ein gemischtes Team mit Java/Kotlin/C#-Hintergrund hat, ein Premium-UI-Erlebnis mit Custom-Animationen anstrebt, oder Web/Desktop/Embedded mitnehmen will, ist mit Flutter besser aufgestellt.

In jedem Fall gilt: Investiere weniger Zeit in die Framework-Wahl und mehr in Architektur, Testing-Disziplin, CI/CD-Reife, Observability und User-Research. Das sind die Faktoren, die wirklich entscheiden, ob deine App in zwei Jahren noch begeistert oder im Wartungs-Modus dahinvegetiert.

Möge die smoothere Animation gewinnen — und die schnellere Time-to-Market.

---

Geschrieben Juni 2026. Quellen, Benchmarks und Versionsstände beziehen sich auf den damaligen Markt und sind in einer schnelllebigen Branche entsprechend zu prüfen.