Die Frage, ob native oder cross-platform entwickelt werden soll, war 2016 eine ideologisch besetzte Frage. 2021 wurde sie pragmatisch beantwortet — meistens mit „kommt drauf an”. 2026 ist sie konzeptionell weitgehend geklärt: Cross-Platform-Frameworks haben sich in einem Spektrum etabliert, das je nach Anforderungsprofil unterschiedliche Optima kennt. Diese Differenzierung lohnt einen sorgfältigen Blick — gerade weil die Marketingsprache der jeweiligen Framework-Hersteller die Unterschiede tendenziell verwischt.

Vier Frameworks teilen sich im Mai 2026 den Großteil des produktiven Cross-Platform-Einsatzes: Flutter (entwickelt bei Google), React Native (entwickelt bei Meta), Kotlin Multiplatform (entwickelt bei JetBrains, in Teilen unter dem Namen Compose Multiplatform) und .NET MAUI (entwickelt bei Microsoft). Ein nüchterner Vergleich entlang Performance, Library-Ökosystem, Hiring-Pool und Plattform-Spezifika ergibt das folgende Bild.

Flutter: vom Rendering-Engine-Experiment zum Material-3-Standard

Flutter ist das einzige der vier Frameworks, das eine eigene Rendering-Engine mitbringt: Statt auf die nativen UIKit- beziehungsweise Android-View-Komponenten zurückzugreifen, zeichnet Flutter über die Skia-Engine (mittlerweile in Teilen durch Impeller ersetzt) direkt auf einen Canvas. Diese Architektur-Entscheidung — getroffen in den frühen Flutter-Tagen 2016/17 — hat lange für ein eigentümliches Spannungsfeld gesorgt: Flutter-UIs sahen pixelgenau über alle Plattformen identisch aus, fühlten sich aber genau deshalb auf keiner Plattform vollständig nativ an.

Diese Spannung hat sich seit 2024 deutlich entschärft. Die in Material 3 (Google) standardisierten UI-Tokens werden in Flutter ab Version 3.16 (November 2023) konsequent durchgereicht; die Cupertino-Komponenten-Bibliothek hat in den Versionen 3.22 (Mai 2024) und 3.27 (November 2024) substanzielle Renovierungen erfahren und kommt im Mai 2026 dem Look-and-Feel von SwiftUI-Komponenten visuell sehr nahe. Die Impeller-Engine ist seit Flutter 3.24 (August 2024) der Default-Renderer auf iOS und seit 3.27 auf Android — was die historisch beklagten Frame-Drops in komplexen Scroll-Listen praktisch beseitigt hat.

Dart als Sprache ist ein Spezialfall: außerhalb der Flutter-Welt kaum verbreitet, innerhalb davon mittlerweile eine ausgereifte Sprache mit Sound Null Safety, Records, Patterns und einer ordentlichen Tooling-Schicht in IntelliJ und VS Code. Wer Flutter wählt, wählt Dart mit — eine Bindung, die im Hiring eine eigene Bedeutung hat (dazu unten mehr).

Die Library-Ökonomie ist robust: pub.dev verzeichnet im Mai 2026 rund 50.000 Pakete, von denen ein signifikanter Teil aktiv gepflegt wird. Riverpod (State Management), Drift (lokale Datenbank), go_router (Navigation), Dio (HTTP) sind die De-facto-Standards. Die Firebase-Integration ist eng — was wirtschaftlich logisch ist, technisch aber gelegentlich zu Lock-in-Fragen führt.

React Native: New Architecture als Konsolidierungs-Schritt

React Native hat den möglicherweise turbulentesten Reifeprozess der vier Frameworks hinter sich. Die in 2018 erstmals angekündigte „New Architecture” — bestehend aus dem Fabric-Renderer, der TurboModules-Schicht und der JavaScript Interface (JSI) — hat von der Ankündigung bis zur Default-Aktivierung sieben Jahre gebraucht; mit Version 0.74 (April 2024) wurde sie zum Opt-in-Standard, mit Version 0.78 (Februar 2026) zum Default für neue Projekte.

Die zentrale Konsolidierungsentscheidung der React-Native-Welt war 2022 die Festlegung auf Hermes als Default-JavaScript-Engine. Hermes — Metas eigene, für React Native optimierte Engine — hat den vorher verwendeten JavaScriptCore (auf iOS) beziehungsweise V8 (auf Android) abgelöst. Die operative Folge: deutlich kürzere Startup-Zeiten, kleinere Bundle-Größen, eine eigentümliche Stack-Trace-Sprache, die noch immer nicht jedem Entwickler:innen-Team auf Anhieb vertraut ist.

Die Library-Ökonomie ist die größte unter den vier Frameworks: NPM-Pakete mit React-Native-Bezug zählen weit über 100.000, die Expo-Plattform bündelt einen relevanten Teil davon in einer kuratierten, getesteten und über Expo Application Services (EAS) gebauten Distribution. Wer React Native heute neu beginnt, beginnt mit Expo — die Argumente für ein „bare” React-Native-Setup haben sich in den letzten zwei Jahren deutlich reduziert.

Die Plattform-Spezifika sind durch JSI und TurboModules pragmatisch lösbar geworden: Plattform-spezifische APIs lassen sich in Swift / Kotlin schreiben und über typsichere TurboModule-Brücken aus dem JavaScript-Code aufrufen. Was 2018 noch eine asynchrone Bridge-Operation war, ist 2026 ein synchroner JSI-Call — was die Performance-Charakteristik vieler nativer Integrationen substanziell verbessert hat.

Kotlin Multiplatform: die KMP-1.0-Stabilisierung und die iOS-UI-Frage

Kotlin Multiplatform — kurz KMP — ist konzeptionell das andersartigste der vier Frameworks. KMP ist keine UI-Plattform, sondern ein Shared-Code-Mechanismus: Geschäftslogik, Datenmodelle, Netzwerk- und Persistenz-Schichten werden in Kotlin geschrieben und in plattformspezifische Targets kompiliert — JVM-Bytecode für Android, LLVM/Objective-C-Interop für iOS, JavaScript / WebAssembly für Web. Die UI-Schicht bleibt nativ.

JetBrains hat KMP im November 2023 mit Version 1.0 als stabil markiert; die zugehörige UI-Schicht Compose Multiplatform ist im Mai 2024 für Desktop und Android als stabil eingestuft worden, für iOS im Februar 2025. Compose Multiplatform erlaubt es, die aus dem Android-Jetpack-Compose vertraute UI-Beschreibungssprache auch für iOS-Builds zu verwenden — eine Option, die KMP näher an die Flutter-Charakteristik rückt, ohne die Möglichkeit der nativen UI-Schicht aufzugeben.

Die operativ relevante Wahl liegt im Mai 2026 zwischen drei KMP-Konfigurationen:

KMP mit nativen UIs (SwiftUI auf iOS, Compose auf Android). Das ist die ursprüngliche und konzeptionell sauberste Variante: Shared Business Logic, vollständig native UIs. Die UI-Code-Duplizierung ist substanziell, das Look-and-Feel auf jeder Plattform einwandfrei. Diese Variante hat sich bei Banken, Fintechs und größeren E-Commerce-Anbietern etabliert.

KMP mit Compose Multiplatform für beide UIs. Die direkte Flutter-Konkurrenz: Eine UI-Beschreibungssprache, beide Plattformen. Die iOS-Variante von Compose hat in den letzten zwölf Monaten substanzielle Reife gewonnen; die Skia-basierte Rendering-Schicht zeigt auf hochfrequentierten iOS-Geräten weiterhin gelegentliche Frame-Drops, die aber im Mai 2026 für die meisten Anwendungsfälle akzeptabel sind.

KMP mit SwiftUI-Compose-Interop. Eine 2025 von JetBrains adressierte Möglichkeit: Compose-Komponenten lassen sich punktuell in eine SwiftUI-Hülle einbetten und umgekehrt. Diese Variante eignet sich für Migrations-Szenarien.

Die Library-Ökonomie ist die schmalste unter den vier Frameworks: Kotlinx.Serialization, Ktor, SQLDelight, Koin sind die wichtigsten KMP-fähigen Bibliotheken; der Rest der Android-Library-Welt muss in Teilen plattformspezifisch implementiert oder über die Expect/Actual-Mechanik gebrückt werden.

.NET MAUI: Microsofts Antwort und ihre Performance-Trade-offs

.NET MAUI (Multi-platform App UI) ist 2022 als Nachfolger von Xamarin.Forms eingeführt worden und hat seitdem eine eigene, leicht abseitige Position in der Cross-Platform-Landschaft eingenommen. Die Sprache ist C# (mit .NET 9 im Mai 2026 als aktuelle LTS-Version), die UI-Schicht ist eine Abstraktion über UIKit und Android-Views — keine eigene Rendering-Engine wie bei Flutter.

Die Performance-Charakteristik von MAUI ist 2026 deutlich besser als die der späten Xamarin.Forms-Jahre, bleibt aber unter Flutter und gut konfiguriertem React Native: Startup-Zeiten auf iOS liegen im 1,5-bis-2-Sekunden-Bereich (vs. 0,8 bis 1,2 Sekunden bei Flutter); der Memory-Footprint ist signifikant größer.

Die Library-Ökonomie ist gespalten: Wer im NuGet-Ökosystem bereits unterwegs ist, findet eine umfangreiche Toolchain; wer von außen kommt, findet eine spezifisch C#-orientierte Welt vor, deren Mobile-Slice deutlich schmaler ausfällt als das Backend-orientierte Hauptgeschäft.

Die operativ relevante Frage zu MAUI 2026 lautet: Für wen ist es die richtige Wahl? Die Antwort ist in der Praxis spezifisch — für Unternehmen mit etablierten .NET-Backends, mit ASP.NET-Web-Frontends und mit einem überwiegend C#-orientierten Engineering-Team kann MAUI eine kohärente Tech-Stack-Wahl sein. Außerhalb dieser Konstellation steht MAUI im direkten Performance-Vergleich gegenüber Flutter und React Native im Nachteil.

Vergleichs-Tabelle

Kriterium	Flutter	React Native	KMP	.NET MAUI
Sprache	Dart	TS/JS	Kotlin	C#
UI-Schicht	Eigene Engine (Impeller)	Native + Fabric	Native oder Compose	Native (UIKit/Android-Views)
Build-Größe iOS (typisch)	18–25 MB	12–18 MB	8–14 MB	25–35 MB
Startup-Zeit iOS (typisch)	0,8–1,2 s	1,0–1,5 s	0,6–1,0 s	1,5–2,0 s
Hiring-Pool (relativ)	mittel	groß	mittel-klein	klein
Library-Reife	hoch	sehr hoch	mittel	mittel
Plattform-Native-Integration	mittel	hoch (JSI)	sehr hoch (Native Interop)	hoch
Hauptunterstützer	Google	Meta	JetBrains	Microsoft

Hiring-Pool: die unsichtbare Kosten-Achse

Die Wahl eines Cross-Platform-Frameworks ist eine Hiring-Entscheidung. Dart-Entwickler:innen sind im Mai 2026 deutlich seltener als React-Entwickler:innen; Kotlin-Entwickler:innen mit KMP-Erfahrung sind nochmals seltener; C#-MAUI-Entwickler:innen sind die schmalste Gruppe.

Die Konsequenzen lassen sich beobachten: React-Native-Stellen werden im DACH-Raum typischerweise binnen sechs Wochen besetzt, Flutter-Stellen im Mittel binnen acht bis zwölf Wochen, KMP-Stellen mit relevanter iOS-Erfahrung benötigen häufig drei bis vier Monate. Diese Zahlen sind Schätzungen aus der laufenden Hiring-Praxis und sollten nicht als belastbare Marktstatistik missverstanden werden, sind aber als Größenordnung tragfähig.

Die Cross-Platform-Diskussion 2026 ist kein „Welches Framework ist objektiv besser?”, sondern ein „Welches Framework passt zu unserer Team-Topologie, unserer Plattform-Roadmap und unserem Hiring-Markt?”.

Plattform-Spezifika: die unvermeidliche native Schicht

Wer 2026 cross-platform entwickelt, kommt um eine native Schicht nicht vollständig herum. Die Liste der Anforderungen, die in jedem Framework eine plattformspezifische Implementierung verlangen, ist im Mai 2026 weitgehend stabil:

• App-Intents und Shortcuts auf iOS, App Actions auf Android
• Live Activities und Dynamic Island auf iOS, Always-On-Display-Komponenten auf Android
• Health Kit / Health Connect
• Apple Watch und Wear OS Companion Apps
• CarPlay und Android Auto
• App Clips und Instant Apps
• Widget-Schichten (WidgetKit auf iOS, App Widget Provider auf Android)

Für diese Schicht stellen alle vier Frameworks Bridge-Mechanismen bereit (Flutter Platform Channels, React Native TurboModules, KMP expect/actual mit nativer Platform-Schicht, MAUI Handlers). Die Effizienz dieser Bridges ist im Mai 2026 hoch genug, dass die plattformspezifische Schicht nicht mehr als systemischer Performance-Engpass auftritt — was 2018 anders aussah.

Empfehlung nach Anwendungsprofil

Eine knappe Heuristik für die Framework-Wahl im Mai 2026:

• App mit hoher UI-Eigenständigkeit und visuell konsistentem Design über beide Plattformen: Flutter.
• App im Anschluss an eine bestehende React-Web-Codebasis: React Native mit Expo.
• App mit komplexer Geschäftslogik, hohen iOS-Native-Anforderungen und einem etablierten Android-Kotlin-Team: Kotlin Multiplatform mit nativen UIs.
• App im Anschluss an eine bestehende .NET-Backend-Welt: MAUI.

Diese Heuristik ist eine Heuristik, keine Lebenswahrheit. Wer einen vollständigen Cross-Platform-Tech-Stack-Entscheid 2026 verantwortet, wird die genannten Frameworks in einem konkreten Spike-Projekt prototypisch durchspielen. Die jeweiligen Framework-Dokumentationen — flutter.dev für Flutter, reactnative.dev und expo.dev für React Native, kotlinlang.org/docs/multiplatform.html für KMP, learn.microsoft.com/dotnet/maui für MAUI — sind im Mai 2026 deutlich besser kuratiert als noch vor zwei Jahren. Was die Lektüre dieser Dokumentationen lohnenswert macht, ist die nüchterne Erkenntnis, dass keines der vier Frameworks ein universelles Optimum darstellt — und dass diese nüchterne Erkenntnis selbst der wichtigste Fortschritt der Cross-Platform-Landschaft seit 2018 ist.