Flutter oder React Native? Die meisten Vergleiche hören bei zwei Frameworks auf und lassen die dritte starke Option weg. Dieser Ratgeber vergleicht Flutter, React Native und .NET MAUI nach den Kriterien, die für Entscheider wirklich zählen: Kosten, Wartbarkeit, Team-Verfügbarkeit und Zukunftssicherheit.
„Flutter oder React Native?“ Diese Frage bekommen wir in fast jedem Erstgespräch gestellt, in dem es um eine App für iOS und Android geht. Sie ist berechtigt. Die Entscheidung für ein Framework legt fest, wer die App überhaupt bauen kann, wie sie sich im Alltag anfühlt, was ihre Pflege jedes Jahr kostet und wie viel von ihr in fünf Jahren noch brauchbar ist. Nur ist die Frage zu klein gestellt. Wer Flutter und React Native als Zweikampf behandelt, lässt eine dritte Option weg, die gerade für B2B-Projekte im Mittelstand häufig besser passt: .NET MAUI von Microsoft.
Diese Lücke ist leicht nachzuprüfen. Wir haben uns angesehen, was Google zu dieser Suche ausspielt, und in den Top-10 taucht .NET MAUI in keinem einzigen Artikel als eigenständige Option auf. Deutsche Vergleichsartikel hören fast durchgängig bei zwei Frameworks auf. Für Projekte, deren Backend in Azure läuft, deren Fachlogik längst in C# geschrieben ist oder die neben Mobilgeräten auch Windows-Rechner in der Produktion bedienen müssen, fehlt damit genau die Option, die am besten passen würde.
Wir sind seit über 10 Jahren in der Cross-Platform-Entwicklung unterwegs, waren Xamarin Premier Partner, haben das Ende von Xamarin miterlebt und Kundenprojekte nach .NET MAUI überführt. Unser Haupt-Framework ist heute .NET MAUI, und diese Erfahrung prägt natürlich unsere Sicht. Eine Empfehlung für MAUI um jeden Preis findest du hier trotzdem nicht. Es gibt Projekte, für die wir Flutter empfehlen, es gibt Projekte für React Native, und es gibt Projekte, bei denen wir von Cross-Platform ganz abraten.
Dieser Artikel richtet sich an Entscheider, nicht an Entwickler. Code und Syntax-Vergleiche findest du hier keine. Stattdessen die Kriterien, die dein Projekt betreffen: Kosten über die gesamte Laufzeit, Verfügbarkeit von Entwicklern, Wartbarkeit, Integration in deine bestehende IT und die Verantwortung für die Technologie in fünf Jahren. Ein Kriterium kommt hinzu, das vor zwei Jahren noch in keinem Vergleich stand. Wie gut kommen KI-Assistenten mit dem jeweiligen Framework zurecht, und wie leicht bekommst du später KI-Funktionen in deine App?
In Angeboten und Gesprächen werden vier Begriffe regelmäßig durcheinandergeworfen, und am Ende kauft der Kunde etwas anderes als das, was er verstanden hat. Deshalb vorab die Sortierung.
Native Apps werden je Plattform getrennt entwickelt, für iOS mit Swift und SwiftUI, für Android mit Kotlin. Zwei Codebasen, zwei Teams oder zumindest zwei Skill-Sets, zwei Release-Prozesse. Der Zugriff auf alles, was das Gerät kann, ist unmittelbar und ohne Umwege.
Cross-Platform-Apps teilen eine gemeinsame Codebasis, die für jede Plattform in echte Apps kompiliert wird. Flutter, React Native und .NET MAUI gehören in diese Kategorie. Sie unterscheiden sich darin, wie die Oberfläche entsteht: React Native und .NET MAUI verwenden die echten Bedienelemente der Plattform, Flutter zeichnet die Oberfläche mit einer eigenen Grafik-Engine selbst.
Hybride Apps sind im Kern Webanwendungen in einem Container, klassisch mit Cordova oder Ionic. Die Oberfläche läuft in einem eingebetteten Browser. Das ist schnell gebaut und günstig, fühlt sich aber selten wie eine richtige App an, und bei Offline-Betrieb, Hintergrundprozessen oder intensiver Hardware-Nutzung wird es schnell mühsam. Wenn jemand „hybride App-Entwicklung“ anbietet, lohnt die Rückfrage, was genau gemeint ist. Häufig ist Cross-Platform gemeint, manchmal wirklich ein WebView.
Progressive Web Apps laufen komplett im Browser und werden nicht über die Stores verteilt. Für reine Informationsangebote eine solide Wahl, für Prozess-Apps mit Kamera, Bluetooth oder verlässlichem Offline-Modus meist nicht ausreichend.
Für diesen Vergleich ist nur die zweite Kategorie relevant. Wenn im weiteren Text von Cross-Platform die Rede ist, geht es immer um kompilierte Apps mit gemeinsamer Codebasis, nicht um verpackte Webseiten.
Der offensichtliche Vorteil einer gemeinsamen Codebasis ist der Aufwand, der nur einmal anfällt. Wichtiger ist ein Vorteil, der sich erst im zweiten Jahr zeigt. Eine Änderung an der Geschäftslogik passiert an einer Stelle und wirkt auf allen Plattformen gleich, ein Fehler wird einmal gefunden und einmal behoben, und ein Team trägt das Gesamtergebnis, statt dass zwei Teams mit auseinanderlaufenden Funktionsständen aufeinander warten. Das nennen wir Konsistenz.
Wer einmal erlebt hat, wie die Android-Version einer App der iOS-Version zwei Releases hinterherhinkt, weil die Kapazitäten anders verteilt waren, weiß, was das wert ist. Dass eine gemeinsame Codebasis auch günstiger ist als zwei getrennte, ist ein willkommener Nebeneffekt, aber es ist nicht der Grund, aus dem wir sie empfehlen.
Dazu kommt die kürzere Zeit bis zum Marktstart, weil Konzept, Design und Entwicklung nur einmal durchlaufen werden. Wie das im Detail aussieht und wie wir Projekte aufsetzen, zeigen wir auf unserer Seite zur Cross-Platform-Entwicklung mit .NET MAUI.
Genauso wichtig sind die Grenzen. Cross-Platform ist die falsche Wahl, wenn:
Unsere Faustregel aus der Praxis: Wenn zwei Plattformen gebraucht werden und die App im Kern Daten erfasst, anzeigt, synchronisiert und Prozesse abbildet, ist Cross-Platform fast immer die wirtschaftlich und organisatorisch bessere Wahl. Wenn die App ihr Alleinstellungsmerkmal aus Grafik, Sensorik oder Plattform-Tiefe zieht, wird es native.
Native oder Cross-Platform? Das klären wir in einem Gespräch
Du musst diese Grundsatzentscheidung nicht allein treffen. Schick uns kurz, was deine App leisten soll, und wir sagen dir in einer kostenlosen Erstberatung, welcher Weg zu deinem Projekt passt. Auch dann, wenn das gegen Cross-Platform spricht.
Kostenlose Erstberatung sichern
Alle drei Frameworks sind ausgereift, werden von großen Konzernen entwickelt und lösen dasselbe Grundproblem auf unterschiedlichen Wegen. Möglich ist mit allen dreien fast alles. Unterschiedlich ist, was dabei leicht fällt und was du dir erarbeiten musst.
Flutter nutzt die Programmiersprache Dart und zeichnet seine Oberfläche mit einer eigenen Grafik-Engine, seit den aktuellen Versionen mit Impeller auf iOS und Android. Flutter fragt die Plattform also nicht nach einem Button, es malt den Button selbst. Darin unterscheidet es sich grundlegend von den anderen beiden. Stand Mitte 2026 ist Flutter 3.44 mit Dart 3.12 aktuell, das Ökosystem ist groß und die Werkzeuge sind hervorragend.
Stärken: Eine Oberfläche sieht auf allen Plattformen exakt gleich aus, was bei starken Markenvorgaben ein echter Vorteil ist. Für aufwändige Animationen und individuelle Designs ist Flutter das produktivste der drei Frameworks. Hot Reload macht die Arbeit am Design schnell, und mit Web und Desktop gibt es zusätzliche Ausgabewege.
Grenzen: Dart wird außerhalb von Flutter praktisch nicht verwendet. Beim Teamaufbau suchst du damit keine Entwickler mit einer verbreiteten Sprache, du suchst Flutter-Entwickler. Weil Flutter die Oberfläche selbst zeichnet, folgt sie nicht automatisch dem Erscheinungsbild der Plattform, was mancher Nutzer bei Business-Apps als fremd empfindet. Die Anbindung nativer Bibliotheken ist etwas aufwändiger, und die fertigen Apps sind tendenziell größer.
React Native setzt auf JavaScript beziehungsweise TypeScript und steuert die echten Bedienelemente der Plattform an. Wer React aus der Webentwicklung kennt, findet sich sofort zurecht. Die überarbeitete Architektur mit JSI, Fabric und TurboModules ist seit Version 0.76 Standard und hat den früheren Flaschenhals zwischen JavaScript und nativem Code weitgehend beseitigt. Mit Version 0.86 aus dem Juni 2026 starten neue Projekte vollständig ohne die alte Brücke.
Stärken: Der Markt an JavaScript- und TypeScript-Entwicklern ist der größte von allen drei Optionen. Wenn du schon ein Webteam hast, kannst du Wissen und teilweise Code teilen. Das npm-Ökosystem ist riesig, für fast jede Anforderung existiert ein Paket, und mit Expo gibt es eine sehr komfortable Umgebung für Aufbau und Auslieferung.
Grenzen: Genau dieses Ökosystem ist auch die größte Schwachstelle. Viele Pakete werden von Einzelpersonen gepflegt, und ein Update von React Native kann eine Kette von Anpassungen auslösen. In langlebigen Enterprise-Projekten ist die Pflege der Abhängigkeiten ein dauerhafter Posten, der gern unterschätzt wird. Für Desktop-Anwendungen ist React Native nur mit zusätzlichen Projekten nutzbar.
.NET MAUI ist der Nachfolger von Xamarin.Forms, verwendet C# und XAML und erzeugt aus einer Codebasis Apps für iOS, Android, Windows und macOS. Wie React Native nutzt MAUI die echten Bedienelemente der Plattform. Es erscheint im festen Rhythmus von .NET, und mit .NET 10 liegt seit dem 11. November 2025 eine LTS-Version mit drei Jahren zugesagtem Support vor. .NET MAUI 11 ist bereits in der Vorschau.
Als ehemaliger Xamarin Premier Partner und einer der erfahrensten .NET MAUI-Anbieter in Deutschland sehen wir täglich, wo MAUI seine Stärken ausspielt, und das ist selten die schicke Consumer-App.
Stärken: MAUI ist dort stark, wo eine App Teil einer größeren Systemlandschaft ist. C# ist eine statisch typisierte Sprache mit ausgereiften Werkzeugen, in der viele Mittelstandsunternehmen ihre Fachlogik ohnehin schon geschrieben haben. Modelle, Validierungen und Services lassen sich zwischen Backend und App teilen, statt sie zweimal zu pflegen. Die Anbindung an Azure, Active Directory, Dynamics oder ein bestehendes .NET-Backend ist in MAUI Routine und kein eigenes Integrationsprojekt. Dazu behandelt MAUI als einziges der drei Frameworks Windows-Desktop als vollwertiges Ziel, und das gibt in der Industrie überraschend oft den Ausschlag.
Grenzen: Die Community ist deutlich kleiner als bei Flutter und React Native. An den Sternen auf GitHub lässt sich das grob ablesen: Flutter liegt bei rund 170.000, React Native bei rund 120.000, .NET MAUI bei gut 20.000. Für ein Nischenproblem findest du seltener eine fertige Antwort, und es gibt weniger vorgefertigte Pakete. Sehr individuelle, animationslastige Oberflächen sind in MAUI mehr Arbeit als in Flutter. Wer strategisch unabhängig von Microsoft bleiben will, hat mit MAUI das falsche Werkzeug gewählt.
Die folgende Übersicht fasst zusammen, was sich in Projekten tatsächlich unterscheidet. Sie ersetzt keine Beratung, aber sie zeigt schnell, in welche Richtung dein Projekt tendiert.
| Kriterium | Flutter | React Native | .NET MAUI |
|---|---|---|---|
| Sprache | Dart | JavaScript / TypeScript | C# und XAML |
| Oberfläche | Eigene Engine (Impeller) | Native Bedienelemente | Native Bedienelemente |
| Performance | Sehr gut | Gut bis sehr gut | Sehr gut |
| Community | Groß | Sehr groß | Mittel |
| Enterprise-Eignung | Gut | Gut | Sehr gut |
| Azure und Microsoft-Stack | Gering | Mittel | Nahtlos |
| Plattformen | iOS, Android, Web, Desktop | iOS, Android (Web und Desktop über Zusatzprojekte) | iOS, Android, Windows, macOS |
| Einstieg für C#-Teams | Hoch | Mittel | Niedrig |
| Unterstützung durch KI-Assistenten | Gut | Sehr gut | Sehr gut |
| Aufwand für Wartung | Mittel | Mittel bis hoch | Niedrig bis mittel |
Sprache und Team. Dieses Kriterium wird am häufigsten unterschätzt und ist meist ausschlaggebend. Die Frage ist nicht, welche Sprache die elegantere ist, sondern wer deine App in drei Jahren pflegt. Hast du bereits .NET-Entwickler im Haus, ist MAUI der kürzeste Weg, weil sie ohne Sprachwechsel produktiv werden. Hast du ein Webteam mit React-Erfahrung, gilt dasselbe für React Native. Dart lernt ein guter Entwickler in wenigen Wochen, aber es bleibt eine Sprache, die außerhalb von Flutter nichts bringt.
Oberfläche und Nutzergefühl. Flutter garantiert dir Pixelgleichheit über alle Plattformen. React Native und MAUI garantieren dir, dass sich die App wie eine iOS- oder Android-App anfühlt. Beides ist gleich gut gebaut. Du entscheidest hier nur, ob die Marke Vorrang hat oder die Gewohnheiten der Plattform. Bei internen Prozess-Apps gewinnt fast immer die Gewohnheit, weil Mitarbeiter dann nichts Neues lernen müssen. Bei markenstarken Consumer-Apps ist es umgekehrt. Welche Rolle das Design dabei spielt, beschreiben wir auf unserer Seite zum professionellen App-Design.
Performance. Dieses Kriterium füllt die meisten Diskussionen und entscheidet die wenigsten Projekte. Listen, Formulare, Kamera, Barcode, Offline-Sync und Karten laufen in allen drei Frameworks flüssig, und für die überwiegende Mehrheit der Business-Apps ist damit alles gesagt. Messbar wird der Unterschied erst bei sehr aufwändigen Animationen und langen Listen mit komplexen Zeilen, dort liegt Flutter durch die eigene Engine leicht vorn. Bei echten Extremanforderungen taugt keines der drei.
Ökosystem und Wartung. Für React Native gibt es zu jeder Anforderung ein Paket, und mit jedem Paket erbst du eine Abhängigkeit, die jemand pflegen muss, die bei einem Framework-Update brechen kann und die im schlechtesten Fall von einer einzelnen Person am Wochenende betreut wird. MAUI hat weniger Pakete, dafür stammt der Kern aus einer Hand und folgt einem planbaren Release-Zyklus. Flutter liegt dazwischen und hat mit pub.dev eine gut kuratierte Paketquelle. Zähl die Abhängigkeiten. Über fünf Jahre sagen sie mehr über deine Kosten als jede Performance-Messung.
Plattform-Reichweite. Wenn zu iOS und Android noch Windows dazukommt, etwa ein Leitstand in der Produktion oder eine Arbeitsplatz-Anwendung im Innendienst, ist MAUI derzeit die einzige Option mit ausgereiftem Desktop-Ziel aus derselben Codebasis. Flutter kann Desktop ebenfalls, ist dort aber weniger verbreitet. React Native braucht dafür zusätzliche Projekte.
Integration in deine IT. Eine App ist selten allein. Sie hängt an einem ERP, an einer Datenbank, an einer Benutzerverwaltung. Wenn dieses Umfeld auf Microsoft-Technologie läuft, spart MAUI dir eine ganze Integrationsschicht, weil Authentifizierung, Konfiguration und Datenmodelle in derselben Sprache leben. Läuft dein Backend auf Node.js, gilt der gleiche Gedanke für React Native.
Bis vor kurzem war die Wahl der Programmiersprache eine reine Personalfrage. Seit KI-Assistenten wie GitHub Copilot zum Alltag in der Entwicklung gehören, ist ein zweiter Aspekt dazugekommen, der in Framework-Vergleichen noch fast nie erwähnt wird.
KI im Entwicklungsprozess. Sprachmodelle sind dort am stärksten, wo am meisten Code existiert, an dem sie gelernt haben. Für TypeScript und C# heißt das: sehr gute Vorschläge, brauchbare Tests, verlässliche Erklärungen von fremdem Code. Dart ist deutlich seltener vertreten, entsprechend häufiger muss ein Entwickler bei Flutter nacharbeiten. Ein Ausschlusskriterium ist das nicht. Es verschiebt aber das Kriterium Sprache und Team spürbar, weil ein C#-Team mit KI-Unterstützung in .NET MAUI schneller produktiv wird als in einer Sprache, die weder das Team noch das Modell gut kennt. Bei uns beschleunigt KI vor allem Routinearbeit, also Testabdeckung, Migrationen und wiederkehrende Oberflächenbausteine. Architektur, Datenmodell und Prozesslogik entstehen weiter im Kopf.
KI-Funktionen in der App selbst. Immer mehr B2B-Projekte kommen mit einem KI-Baustein zu uns: eine Suche, die Freitext versteht, Belegerkennung per Kamera, Sprachnotizen, die zu strukturierten Meldungen werden, oder Assistenzfunktionen für den Außendienst. Technisch entscheidet sich das weniger im Framework als im Backend, denn die Modelle laufen in der Cloud oder auf dem Gerät. Nähe zum eigenen Stack zahlt sich hier aus. Wenn deine Dienste in Azure laufen, hängst du KI-Funktionen mit .NET MAUI ohne Umweg an, weil App und Backend dieselbe Sprache sprechen. Für Modelle direkt auf dem Gerät nutzen alle drei Frameworks die Plattform-Schnittstellen von Apple und Google, Flutter und React Native über zusätzliche Pakete.
Unsere Einordnung. KI schreibt Code, aber sie trifft keine Entscheidung und trägt keine Verantwortung. Wir sehen zunehmend Prototypen, die mit KI-Werkzeugen zusammengesetzt wurden und auf den ersten Blick funktionieren. Sobald Offline-Betrieb, Rechteverwaltung, Datenschutz oder ein Store-Review dazukommen, wird daraus Arbeit für Menschen, die wissen, was sie tun. Was das für die Haftung bedeutet, steht weiter unten.
Die häufigste Zahl in diesem Themenfeld ist die Ersparnis gegenüber zwei nativen Apps. In unseren Projekten liegt sie bei etwa 25 bis 35 Prozent. Die oft genannten 50 Prozent halten wir für zu optimistisch, weil Konzept, Design, Backend, Tests, Store-Einreichung und Projektsteuerung unabhängig von der Technologie anfallen. Geteilt wird die Oberflächen- und Logikentwicklung, und selbst dort bleibt ein plattformspezifischer Rest von etwa 10 bis 20 Prozent.
Als Orientierung für eine Cross-Platform-App mit iOS und Android:
Zwischen den Frameworks selbst sind die Unterschiede in der Erstentwicklung klein. Über das Budget entscheidet der Funktionsumfang. Relevant wird die Framework-Wahl bei den laufenden Kosten, und dort lohnt der Blick auf fünf Jahre statt auf das Angebot. Rechne mit etwa 15 bis 20 Prozent der Entwicklungskosten pro Jahr für Wartung und Weiterentwicklung. Wie sich diese Posten im Detail zusammensetzen, haben wir in unserer detaillierten Kostenübersicht und im Ratgeber Was kostet App-Entwicklung aufgeschlüsselt.
Die Posten, die in Angeboten regelmäßig fehlen:
Was würde deine App kosten?
Die Spannen oben sind Erfahrungswerte aus unseren Projekten. Welches Budget dein Vorhaben wirklich braucht, hängt am Funktionsumfang. In unserer Kostenübersicht findest du die einzelnen Posten aufgeschlüsselt, vom Konzept bis zur Wartung.
Kosten im Detail ansehen
Bevor du über Frameworks nachdenkst, klär die Grundsatzfrage. Diese fünf Punkte führen fast immer zu einem klaren Ergebnis.
Wenn drei oder mehr Antworten Richtung Cross-Platform zeigen, ist die Grundsatzentscheidung gefallen. Zeigen sie Richtung native, findest du auf unseren Seiten zur iOS-App-Entwicklung und zur Android-App-Entwicklung, wie wir dabei vorgehen.
Abstrakte Kriterien helfen nur bis zu einem Punkt. Deshalb hier die Szenarien, die uns in der Beratung am häufigsten begegnen, mit klarer Empfehlung.
B2B-App mit Azure-Backend und Anbindung an bestehende Systeme. Empfehlung: .NET MAUI. Ein Instandhaltungsteam erfasst Aufträge mobil, die Daten laufen in ein bestehendes .NET-Backend, Anmeldung über den Firmen-Verzeichnisdienst. Was hier Zeit spart, sind geteilte Datenmodelle und eine Anmeldung, die auf Anhieb funktioniert. Ein schickes Framework hilft dir an dieser Stelle nichts. Das ist unser typischer Projektzuschnitt.
Industrieanwendung für Mobilgeräte und Windows-Arbeitsplätze. Empfehlung: .NET MAUI. Wenn der Lagermitarbeiter das Handheld nutzt und der Meister denselben Prozess am Windows-Rechner sieht, brauchst du ein Framework, das Desktop nicht als Nebenprodukt behandelt. Das ist derzeit der klarste Einzelfall für MAUI.
Consumer-App mit aufwändigem Marken-Design. Empfehlung: Flutter. Wenn jede Animation sitzen muss und die App auf jedem Gerät identisch aussehen soll, ist Flutter das produktivste Werkzeug. In MAUI ginge das auch, es kostet dich nur deutlich mehr Zeit.
Start-up mit vorhandenem JavaScript-Team. Empfehlung: React Native. Wenn dein Webteam bereits React einsetzt, kannst du ohne Neuaufbau mobil werden und Wissen sowie Teile des Codes teilen. Der Preis ist die Pflege der Abhängigkeiten, die du von Anfang an einplanen solltest.
MVP zum Testen einer Geschäftsidee. Empfehlung: Flutter oder React Native, je nach Team. In dieser Phase zählt Geschwindigkeit, und beide Ökosysteme bieten für Standardfunktionen fertige Bausteine. Wenn absehbar ist, dass aus dem MVP eine Enterprise-Anwendung wird, lohnt es sich, MAUI von Anfang an mitzudenken, statt später zu wechseln. Wie so ein Projekt abläuft, beschreibt unser Leitfaden zum Thema App entwickeln lassen.
Bestehende Xamarin-App, die modernisiert werden muss. Empfehlung: .NET MAUI. Bei einem Wechsel zu Flutter oder React Native fängst du bei null an. Bei MAUI übernimmst du in der Regel Geschäftslogik, Datenzugriff und Services und stellst die Oberfläche schrittweise um. Alles, was wir zu diesem Weg gelernt haben, findest du auf unserer Seite zur Xamarin-Entwicklung und Migration.
Framework-Vergleiche enden meist bei Performance und Community-Größe. In Kundengesprächen beschäftigt uns etwas anderes am meisten. Was passiert, wenn die Technologie unter deiner App verschwindet?
Diese Frage können wir nicht theoretisch beantworten, wir haben sie erlebt. Der Support für Xamarin endete am 1. Mai 2024. Wir waren Xamarin Premier Partner, hatten über Jahre Apps darauf aufgebaut, und trotzdem lief eine Frist. Apps liefen weiter, aber ohne Sicherheitsupdates, und mit jeder neuen iOS- und Android-Version wuchs das Risiko. Kein Anbieter dieser Welt kann dir garantieren, dass Flutter, React Native oder .NET MAUI in zehn Jahren noch existieren.
Was du stattdessen prüfen kannst, sind vier belastbare Kriterien:
Damit hängt ein Punkt zusammen, der in Technologiediskussionen selten auftaucht, obwohl er für Geschäftsführer der wichtigste ist: Haftung. Seit der Neufassung der EU-Produkthaftungsrichtlinie im Jahr 2024 gilt Software ausdrücklich als Produkt. Wenn deine App einen geschäftskritischen Prozess trägt und ausfällt, ist die relevante Frage nicht, was die Entwicklung gekostet hat, sondern wer für den Ausfall verantwortlich ist. Eine mit KI zusammengesetzte App aus einem generischen Framework hat darauf keine Antwort. Ein Partner, der die Technologie beherrscht, den Support-Zyklus kennt und für sein Ergebnis einsteht, hat sie. Welche Projekte wir auf dieser Grundlage begleitet haben, siehst du in unseren Referenzprojekten, unter anderem für CLAAS, flaschenpost und MEDIFOX DAN.
Wir wären unglaubwürdig, wenn wir am Ende eines Vergleichs behaupten würden, unser Haupt-Framework sei für alles das Beste. Ist es nicht. Es gibt aber einen Projekttyp, für den wir es klar empfehlen, und der beschreibt einen großen Teil des deutschen Mittelstands: eine App, die einen Geschäftsprozess trägt, die an bestehende Systeme angebunden ist, die zehn Jahre leben soll und deren Umfeld auf Microsoft-Technologie läuft. Dort spielt MAUI seine Stärken aus, weil eine solche App keine Insel bleibt. Sie erweitert eine Landschaft, die schon in C# gedacht ist.
Konkret bedeutet das: Ein Team, eine Sprache, geteilte Modelle zwischen Backend und App, eine Anmeldung, die zur bestehenden Benutzerverwaltung passt, und bei Bedarf dieselbe Anwendung auf dem Windows-Rechner. Bei CLAAS, flaschenpost und MEDIFOX DAN haben wir genau diesen Zuschnitt umgesetzt, teils über Jahre von Xamarin bis .NET MAUI, ohne die Fachlogik neu zu bauen.
Und jetzt der ehrliche Teil. Wir raten von .NET MAUI ab, wenn:
Diese Ehrlichkeit ist kein Selbstzweck. Ein Projekt, das mit dem falschen Framework startet, wird für beide Seiten unangenehm, und wir haben schon Anfragen abgelehnt, weil ein anderer Ansatz besser gepasst hätte. Wenn du unsicher bist, welche Richtung für dein Projekt stimmt, klären wir das in einer kostenlosen Erstberatung, auch dann, wenn am Ende ein Framework steht, mit dem wir nicht arbeiten.
Eine Codebasis für iOS, Android und Windows
Wie wir Cross-Platform-Projekte mit .NET MAUI aufsetzen, von der Architektur über die Anbindung an bestehende Systeme bis zur Wartung, zeigen wir dir im Detail auf unserer Leistungsseite.
Cross-Platform-Entwicklung ansehen
In vielen B2B-Projekten lautet die Antwort auf „Flutter oder React Native?“ schlicht .NET MAUI. In anderen Projekten ist Flutter oder React Native eindeutig richtig, und manchmal führt der Weg zurück zur nativen Entwicklung. Presse und Beliebtheit helfen dir bei dieser Entscheidung nicht weiter. Was zählt, sind dein Team, deine IT-Landschaft und dein Zeithorizont.
Die Kurzfassung:
Wenn du wissen willst, wie ein Cross-Platform-Projekt konkret abläuft, welche Phasen es gibt und wie wir arbeiten, findest du das auf unserer Seite zur Cross-Platform-App-Entwicklung. Und wenn du deine Situation lieber einmal mit jemandem durchsprichst, der schon eine Framework-Ablösung von der anderen Seite erlebt hat, melde dich für eine Framework-Beratung. Wir sagen dir ganz offen, was wir empfehlen würden, auch wenn das kein Projekt für uns bedeutet.
In der Regel ja, aber weniger dramatisch als oft behauptet. Eine gemeinsame Codebasis für iOS und Android liegt in unserer Praxis etwa 25 bis 35 Prozent unter dem Aufwand für zwei getrennte native Apps. Richtig spürbar wird der Effekt aber erst im Betrieb, wenn eine Codebasis, ein Team und ein Release-Prozess das ganze Jahr über tragen. Preis allein ist deshalb ein schlechter Entscheidungsgrund. Frag lieber, welche Architektur du fünf Jahre lang zuverlässig pflegen kannst.
Für normale Business-Apps mit Listen, Formularen, Kamera und Offline-Sync sind Flutter, React Native und .NET MAUI alle schnell genug. Der Nutzer merkt keinen Unterschied. Relevant wird Performance erst bei sehr aufwändigen Animationen, Dauerbetrieb mit Sensordaten oder grafikintensiven Oberflächen. Dort hat Flutter mit seiner eigenen Rendering-Engine Impeller einen leichten Vorsprung, während React Native und .NET MAUI auf die native Bedienoberfläche der Plattform setzen. Bei echten Extremfällen wie 3D, AR oder Gaming ist native Entwicklung die richtige Wahl.
Ja. .NET MAUI kompiliert C#-Code für iOS, Android, Windows und macOS und nutzt dabei die echten Bedienelemente der jeweiligen Plattform. Eine iOS-App aus .NET MAUI sieht und fühlt sich wie eine iOS-App an und wird ganz normal über den App Store veröffentlicht. Für die Entwicklung und den Build der iOS-Version wird ein Mac benötigt, das ist bei jedem Framework so.
Ja. Der Support für Xamarin ist am 1. Mai 2024 ausgelaufen. Xamarin-Apps laufen zwar weiter, erhalten aber keine Sicherheitsupdates mehr und werden mit jeder neuen iOS- und Android-Version riskanter. Der Weg nach .NET MAUI ist gut vorbereitet, weil MAUI der direkte Nachfolger ist: Geschäftslogik, Datenzugriff und Services lassen sich meist übernehmen, die Oberfläche wird schrittweise umgestellt. Wir haben diesen Weg für mehrere Kundenprojekte begleitet, unter anderem für flaschenpost.
Ein fokussiertes MVP für iOS und Android ist meist in 3 bis 5 Monaten nutzbar. Eine mittelkomplexe Business-App mit Backend-Anbindung braucht 6 bis 9 Monate, eine Enterprise-App mit vielen Schnittstellen 9 bis 18 Monate. Gegenüber zwei getrennten nativen Apps gewinnst du vor allem deshalb Zeit, weil Konzept, Design, Tests und Releases nur einmal durchlaufen werden.
Wenn beide Plattformen gebraucht werden, lohnt es sich bei kleinen Apps sogar besonders. Der Anteil an Aufwand, der unabhängig von der Technologie anfällt, ist bei kleinen Projekten relativ hoch, und den zahlst du bei zwei nativen Apps doppelt. Wenn dagegen nur eine Plattform relevant ist, etwa weil alle Mitarbeiter dienstliche iPhones nutzen, ist eine native App oft der direktere Weg.
Eine hybride App ist im Kern eine Webseite, die in einem Container auf dem Gerät läuft, zum Beispiel mit Ionic oder Cordova. Bedienelemente werden im Browser nachgebaut. Eine Cross-Platform-App mit Flutter, React Native oder .NET MAUI wird dagegen kompiliert und greift direkt auf die Gerätefunktionen zu, ohne Browser dazwischen. Das Ergebnis fühlt sich deutlich näher an einer nativen App an. Umgangssprachlich werden beide Begriffe oft vermischt, technisch sind es zwei verschiedene Ansätze.
Für einen Prototyp oder eine interne Hilfslösung kann das reichen. Bei einer App, die einen Geschäftsprozess trägt, endet der Weg meist an denselben Punkten: Rechte- und Rollenkonzept, Offline-Betrieb, Datenschutz, Anbindung an bestehende Systeme, Store-Review und die jährlichen Betriebssystem-Updates. KI-Assistenten beschleunigen die Arbeit von Entwicklern erheblich, wir nutzen sie täglich. Sie treffen aber keine Architekturentscheidung und übernehmen keine Haftung. Seit der EU-Produkthaftungsrichtlinie von 2024 gilt Software ausdrücklich als Produkt, und im Schadensfall zählt, wer verantwortlich ist.
Das entscheidet sich weniger im Framework als im Backend, denn die Modelle laufen in der Cloud oder auf dem Gerät. Wenn deine Dienste in Azure liegen, ist .NET MAUI der kürzeste Weg, weil App und Backend dieselbe Sprache sprechen und du keine zusätzliche Integrationsschicht brauchst. Für Modelle direkt auf dem Gerät nutzen alle drei Frameworks die Schnittstellen von Apple und Google, bei Flutter und React Native über zusätzliche Pakete.
Alle drei werden von großen Konzernen entwickelt, und alle drei können eingestellt werden. Das haben wir mit Xamarin selbst erlebt. Prüfbare Kriterien helfen dir deshalb mehr als Versprechen: ein offizieller Support-Zeitraum, eine breite Nutzung in Unternehmen, ein realistischer Migrationspfad und die Frage, wie viel deiner Investition in Geschäftslogik statt in Framework-spezifische Oberflächen steckt. .NET MAUI hat mit dem LTS-Zyklus von .NET hier den formal klarsten Rahmen, Flutter und React Native die größere Verbreitung.
Als Mobile-Enthusiast und Geschäftsführer der Cayas Software GmbH ist es mir ein großes Anliegen, mein Team und unsere Kunden zu unterstützen, neue potenziale zu entdecken und gemeinsam zu wachsen. Hier schreibe ich vor allem zur Entwicklung von Android und iOS-Apps mit Xamarin und .NET MAUI.
Du willst eine App entwickeln lassen, weißt aber nicht, wo du anfangen sollst? Dieser Leitfaden führt dich durch den Ablauf, die Wahl zwischen Agentur, Freelancer und Offshore, das richtige Briefing und alle Fragen, die du vorher klären solltest.
Was kostet eine App? Dieser Budget-Ratgeber erklärt dir die Kostenfaktoren, zeigt ehrliche Preisspannen aus über 10 Jahren Agentur-Praxis und hilft dir, dein Budget realistisch zu planen.