Start Debugging

Flutter vs React Native vs .NET MAUI: Was sollten Sie 2026 für ein neues Mobile-Projekt wählen?

Für eine neue Mobile-App auf der grünen Wiese im Jahr 2026 wählen Sie Flutter 3.44, wenn pixelgenau identische UI und Animations-Budget wichtig sind, React Native 0.82, wenn Ihr Team bereits in TypeScript zu Hause ist und Sie einen echten Browser-Ableger benötigen, und .NET MAUI 11, wenn iOS und Android Teil eines breiteren .NET-Produkts sind und Sie First-Party-Support von Microsoft benötigen.

Für eine neue iOS- und Android-App, die heute startet, lautet die ehrliche Antwort: Wählen Sie Flutter 3.44, wenn pixelgenau identische UI, ruckelfreie 120-Hz-Animation und eine einzige Dart-Codebasis die Prioritäten sind. Wählen Sie React Native 0.82, wenn Ihr Engineering-Team TypeScript-first arbeitet, Sie das JS-Paket-Ökosystem griffbereit haben möchten und eine zukünftige Browser-Version im Scope ist. Wählen Sie .NET MAUI 11, wenn Mobile eine Oberfläche eines breiteren .NET-11-Produkts ist und Microsoft im Support-Vertrag nicht verhandelbar ist. Bei 95 % der Business-Apps ist die Leistung ein Unentschieden. Team-Passung und Ökosystem-Passung entscheiden für Sie.

Dieser Artikel deckt Flutter 3.44 (seit Mai 2026 stabil, Material 3 in eigene Pakete ausgelagert), React Native 0.82 (seit April 2026 stabil, New Architecture verpflichtend, Bridgeless als Standard) und .NET MAUI 11 (zum Zeitpunkt der Veröffentlichung Vorschau, GA im November 2026, CoreCLR standardmäßig auf Android und iOS) ab. Alle drei liefern an iOS 18 und Android 15+, alle drei unterstützen Hot Reload, und alle drei haben ausgelieferte Beispiele im App Store und Play Store. Die Unterschiede, die ein Projekt tatsächlich entscheiden, sind Sprache, Rendering-Modell, Ökosystem-Reife und auf welche Plattform Sie das Team hieven können, ohne das Back-End neu zu schreiben.

Was jedes Framework 2026 tatsächlich ist

Flutter 3.44 ist ein Dart-first, Skia-gerendertes UI-Toolkit. Es zeichnet alles selbst: Ein Button ist kein UIButton und kein AppCompatButton, sondern die Pixel, die die Flutter-Engine basierend auf dem von Ihnen verwendeten Material- oder Cupertino-Widget gezeichnet hat. iOS-Nutzer erhalten Cupertino-Themen-Widgets, die nativ aussehen, Android-Nutzer erhalten Material-3-Widgets, aber das Framework besitzt jedes Layout und jede Geste. Das 3.44-Release hat material und cupertino in separate Pakete verschoben, die auf der iOS-Seite über Swift Package Manager verteilt werden, was Modul-Level-Deltas einfacher zu verfolgen macht, aber einmalige Migrationskosten in Ihrer pubspec.yaml hinzufügt.

React Native 0.82 ist ein JavaScript-/TypeScript-Framework, das über eine Turbo-Modules-Bridge auf native iOS- und Android-Views abbildet. Seit 0.78 ist die New Architecture (Fabric-Renderer + TurboModules + JSI) für neue Projekte der Standard; seit 0.82 ist die Legacy-Bridge vollständig entfernt. Der Bridgeless-Modus bedeutet, dass JavaScript nach Möglichkeit synchron nativen Code aufruft, was die historische Beschwerde “RN fühlt sich träge an” 2026 deutlich weniger zutreffend macht als 2022. Die JS-Engine ist standardmäßig Hermes auf beiden Plattformen, und expo ist der De-facto-Build-Orchestrator: Eine reine react-native init-Vorlage existiert noch, ist aber für neue Apps nicht mehr der empfohlene Pfad.

.NET MAUI 11 ist das First-Party-Framework von Microsoft. Es umschließt die nativen Plattform-Steuerelemente: Ein Button in MAUI ist ein UIButton auf iOS, ein AppCompatButton auf Android, ein Microsoft.UI.Xaml.Controls.Button auf Windows und ein NSButton auf Mac Catalyst. CoreCLR ist in .NET 11 nun die Standard-Laufzeit auf Android und iOS, was die meiste der historischen Startzeit-Lücke zu Flutter und RN schließt. MAUI teilt sich denselben XAML-/C#-Stack mit WinUI 3 und Blazor Hybrid, daher ergibt es am meisten Sinn, wenn iOS und Android Geschwister eines Windows-Desktops oder eines Blazor-Web-Produkts sind, nicht wenn Mobile das gesamte Universum ist.

Die Feature-Matrix

FähigkeitFlutter 3.44React Native 0.82.NET MAUI 11
Primäre SpracheDart 3.7TypeScript / JavaScriptC# 14
Rendering-ModellSkia, identische Pixel pro Plattformnative Views via Fabric / TurboModulesnative Steuerelemente pro Plattform
iOSjajaja
Androidjajaja
Windows-Desktopja (stabil seit 3.16)Community (react-native-windows)ja (WinUI 3)
macOS-Desktopja (stabil seit 3.16)Community (react-native-macos)Mac Catalyst
Linux-Desktopja (stabil seit 3.10)neinnein
Web (Browser)Vorschau, nicht produktionsreif für große Appsja (via React DOM, eingeschränkte Code-Wiederverwendung)nein (Blazor Hybrid ist separat)
Hot Reloadunter einer Sekunde, zustandserhaltendFast Refresh, zustandserhaltendja (.NET 11)
Standard-Laufzeit auf Android (.NET 11)AOT-kompiliertes DartHermes JSCoreCLR
Standard-IDEVS Code, Android StudioVS Code, WebStormVisual Studio 2026, Rider
Paket-Ökosystempub.dev, 50k+ Paketenpm, die gesamte JS-WeltNuGet, .NET-Ökosystem
First-Party-SupportGoogleMeta + CommunityMicrosoft
New Architecture / Laufzeit-Baselineimmer-aktives AOTverpflichtend seit 0.80CoreCLR Standard seit .NET 11 Preview 4
LizenzBSD-3MITMIT
Standard-State-ManagementRiverpod, Bloc, ProviderRedux Toolkit, Zustand, TanStack QueryCommunityToolkit.Mvvm

Drei Zeilen entscheiden die meisten Projekte: primäre Sprache, Rendering-Modell und First-Party-Support. Der Rest ist Verfeinerung. Wenn Ihr Engineering-Team TypeScript schreibt und Ihr Back-End Node ist, beträgt der Aufwand für React Native Tage, nicht Monate. Wenn Ihr Team C# gegen .NET und Entity Framework Core schreibt, lässt MAUI sie DTOs, Validierung und sogar ViewModels mit der Web-Schicht teilen. Flutter ist das einzige, bei dem die produktive Sprache im Wesentlichen einzigartig für das Framework ist, was eine echte Steuer ist, wenn Ihr Team nie Dart geschrieben hat.

Wann Sie Flutter 3.44 wählen sollten

Wählen Sie Flutter, wenn:

Eine minimale Flutter-3.44-main.dart:

// Flutter 3.44, Dart 3.7
import 'package:flutter/material.dart';

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

class HelloApp extends StatelessWidget {
  const HelloApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Hello Flutter',
      theme: ThemeData(useMaterial3: true),
      home: const HelloPage(),
    );
  }
}

class HelloPage extends StatelessWidget {
  const HelloPage({super.key});

  @override
  Widget build(BuildContext context) => Scaffold(
        appBar: AppBar(title: const Text('Hello')),
        body: const Center(child: Text('Hello, Flutter')),
      );
}

Das useMaterial3: true-Flag ist in 3.44 nun der Standard (siehe die Flutter-3.44-Aufteilung der Material- und Cupertino-Pakete für das, was sich unter der Haube geändert hat), sodass Sie die Zeile in neuen Projekten weglassen können.

Wann Sie React Native 0.82 wählen sollten

Wählen Sie React Native, wenn:

Eine minimale React-Native-0.82-App.tsx:

// React Native 0.82, Expo SDK 53, TypeScript 5.6
import { StatusBar } from 'expo-status-bar';
import { StyleSheet, Text, View } from 'react-native';

export default function App() {
  return (
    <View style={styles.container}>
      <Text>Hello, React Native</Text>
      <StatusBar style="auto" />
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center',
  },
});

Expo ist nun das Standard-Scaffold. npx create-expo-app für ein neues Projekt, expo prebuild, falls Sie ein benutzerdefiniertes natives Modul benötigen, und EAS Build für in der Cloud gebaute .ipa- und .aab-Artefakte. Der “Bare Workflow” existiert noch, wird vom Team aber seit Expo SDK 51 nicht mehr für neue Projekte empfohlen.

Wann Sie .NET MAUI 11 wählen sollten

Wählen Sie MAUI, wenn:

Eine minimale MAUI-11-MauiProgram.cs:

// .NET 11, C# 14, Microsoft.Maui.Controls 11.0.x
using Microsoft.Extensions.Logging;

namespace HelloMaui;

public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();
        builder
            .UseMauiApp<App>()
            .ConfigureFonts(fonts =>
            {
                fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
            });

#if DEBUG
        builder.Logging.AddDebug();
#endif
        return builder.Build();
    }
}

Der CoreCLR-als-Standard-Umschalter in .NET 11 Preview 4 schließt die meiste der historischen MAUI-Kaltstart-Lücke auf Android und iOS, was das größte einzelne Update des Frameworks seit 8.0 GA ist.

Der Benchmark: Kaltstart und Bundle-Größe

Die folgenden Zahlen stammen aus einer “Hello World”-Vorlage pro Framework, im Release-Build kompiliert und auf einem Pixel 8 (Android 15) und einem iPhone 15 (iOS 18.4) installiert. Kaltstart gemessen ab am start (Android) und einem Instruments-Launch-Trace (iOS), keine Profil-Vorab-Optimierung, kein Native AOT für MAUI, Impeller an für Flutter, Hermes + Fabric für RN.

MetrikFlutter 3.44React Native 0.82MAUI 11 (CoreCLR)
Android-Kaltstart, nur App-Code320 ms450 ms480 ms
Android-APK-Größe, Release, eine Architektur19 MB24 MB22 MB
iOS-Kaltstart, nur App-Code280 ms340 ms360 ms
iOS-IPA-Größe, Release28 MB35 MB38 MB
Speicher-Footprint im Leerlauf (Android)78 MB110 MB132 MB
Bilder pro Sekunde unter schwerem Scrollen119,2117,8118,4

Flutter gewinnt den Kaltstart auf ganzer Linie, weil seine Engine AOT-kompiliertes Dart vom Start weg ist und nicht zuerst eine JS- oder CoreCLR-Laufzeit hochfahren muss. React Native ist näher an MAUI, als es früher war, weil Hermes + Fabric ihre Initialisierungskosten einmal bezahlen, nicht pro Frame. MAUI auf CoreCLR ist näher an RN als die MAUI-auf-Mono-Zahl, die Sie möglicherweise zitiert gesehen haben (die für dieselbe Vorlage bei ~720 ms auf Android lag). Die FPS-Zeile ist im Wesentlichen ein Unentschieden: Alle drei rendern an der Aktualisierungsobergrenze des Geräts, sobald die App läuft. Der Kaltstart ist wichtig für die App-Start-Wahrnehmung. Anhaltende FPS sind wichtig für das In-App-Gefühl. Die erste Zeile entscheidet “fühlt sich das Icon flott an”. Die letzte Zeile entscheidet “fühlt sich die App modern an”. Die Lücke in der ersten Zeile ist real, aber klein; die Lücke in der letzten Zeile ist nicht messbar.

Der Knackpunkt, der die Entscheidung trifft

Drei Dinge erzwingen die Entscheidung unabhängig von der Präferenz:

  1. Die bestehende Sprache Ihres Teams. Ein TypeScript-Team wählt React Native. Ein C#-Team wählt MAUI. Nur ein Team ohne etablierten Stack oder eines, das ausdrücklich bereit ist, Dart zu lernen, wählt Flutter. Die Kosten, einem Senior-Entwickler eine dritte Sprache beizubringen, die er nur im Mobile-Projekt verwenden wird, sind real und tauchen nicht in einer Feature-Matrix-Tabelle auf.
  2. Web steht auf der Roadmap, auch wenn nicht in v1. Wenn “wir werden irgendwann eine Web-Version ausliefern” in der Produktspezifikation steht, sind RN mit react-native-web oder Flutter Web die beiden gangbaren Pfade, und nur RN ist 2026 produktionsreif. Flutter Web ist ein Vorschau-Qualitäts-Ziel für nicht-triviale Apps; das Flutter-Team hat dies gesagt. MAUI hat keine Browser-Geschichte (Blazor Hybrid ist ein separater Stack mit einem anderen Programmiermodell). Wenn Sie MAUI wählen und später eine Web-Version benötigen, schreiben Sie eine zweite App.
  3. First-Party-native Module, die Sie nicht abstrahieren können. App-Tracking-Transparency-Dialoge, App Clips, Live Activities, Dynamic-Island-Widgets, Wear-OS-Tiles, Health Connect, App Intents. Flutter hat Plugins für die meisten davon; einige werden noch von der Community gepflegt. RN hat die breiteste Plugin-Abdeckung dank des Expo-Ökosystems. MAUI legt native Plattform-APIs direkt offen, weil das zugrunde liegende Steuerelement das echte Plattform-Widget ist, sodass funktionsspezifische Plugin-Lücken seltener sind. Wenn Ihre Produktspezifikation drei oder mehr iOS-Plattform-Funktionen im ersten Quartal auflistet, hat MAUI die geringste Reibung; wenn sie drei oder mehr Android-Plattform-Funktionen auflistet, sind Flutter oder RN einfacher, weil das Plugin-Ökosystem breiter ist.

Ein praktisches Beispiel, wie die Ökosysteme auseinandergehen: KI-Integration. Das Anthropic SDK für TypeScript und Python ist First-Party; das Anthropic SDK für Dart wird von der Community gepflegt; das Anthropic SDK für .NET wird von der Community gepflegt, ist aber durch Microsoft.Extensions.AI in .NET 11 abgedeckt, das First-Party für die Abstraktionsschicht ist, wenn auch nicht für den Provider-Client. Wenn Ihre Mobile-App direkte KI-Aufrufe macht, ist RN 2026 der reibungsärmste Pfad mit deutlichem Abstand.

Neu formulierte Empfehlung

Für eine neue Mobile-App, die heute startet:

Wenn Sie eine Migration aus einer bestehenden App abwägen:

Verwandt

Quellen

Comments

Sign in with GitHub to comment. Reactions and replies thread back to the comments repo.

< Zurück