Should you build your mobile app in C# instead of Flutter or React Native?

If you are weighing .NET MAUI vs Flutter vs React Native and you have no C# developer on payroll, the answer is usually no. We say that as a team that ships MAUI apps and maintains two open-source MAUI libraries: TwStyling and Shadcn.Maui. The framework is not the problem. The framework is almost never the thing that sinks a project.

What sinks it is year two. The one developer who knew C# leaves. The designer keeps asking for a transition the native control will not do. Your 25 MB install lands in a market where people count megabytes before they tap install. So this post starts with where MAUI is the wrong call, and only then gets to where it is the right one.

The answer in one paragraph

If you have a .NET backend, at least one C# developer on staff, and an app that is mostly forms, lists and data, build it in MAUI. If you need Windows desktop and mobile from the same codebase, build it in MAUI. Everything else goes elsewhere. Take React Native with Expo if your team already writes TypeScript. Take Flutter if the app is animation-heavy, or if you want one rendering engine behaving identically on both platforms. And if the app is a login, a list and a form, consider not building an app at all yet. A responsive web build ships faster and costs less. You can wrap it later if the store listing turns out to matter.

Where .NET MAUI loses to Flutter and React Native

There are three situations where we will talk a client out of MAUI. That includes clients who asked for it by name.

Animation-heavy consumer UI belongs somewhere else

MAUI maps its controls to the platform’s own: a Label becomes a UILabel on iOS and a TextView on Android. That is the correct architecture for a settings screen. It is the wrong one for a shared-element transition running across three screens, with a physics curve on the way out. The moment your motion spec gets specific, you start writing platform handlers. Those handlers are the exact cost you bought a cross-platform framework to avoid.

Flutter draws every pixel itself through its own renderer. One rendering path, one set of frame timings, one place to debug a dropped frame instead of two. If your Figma file has motion notes in it, that difference decides the stack. No other argument gets a turn.

No C# person on the team is a hiring problem, not a learning curve

This is where the raw numbers mislead people, so read them carefully. The 2025 Stack Overflow Developer Survey drew 49,000-plus responses across 177 countries. It puts C# at 27.8% of respondents and Dart at 5.9%. JavaScript sits at 66% and TypeScript at 43.6%. On that reading the C# pool is roughly 4.7 times the Dart pool, and the argument looks settled.

It is not settled, and anyone searching “C# vs Dart developers” deserves the second half of the sentence. Almost every Dart developer you will meet is a mobile developer, because Dart’s reason to exist is Flutter. Most C# developers are not. They write ASP.NET services, WPF desktop tools and Unity gameplay code. Now narrow the pool to people who have shipped a MAUI app through both store reviews, handled iOS provisioning profiles, and debugged an Android release build that only fails when trimmed. That subset, not the 27.8%, is your actual hiring pool. It is small.

There is a cheap test. Post both roles and run them for two weeks. Count how many candidates can show you a live store listing they built. Do that before you commit engineering time, not after your first MAUI hire resigns.

Install size decides installs in some markets

A default .NET MAUI project is heavy before you write a line of your own code. Take dotnet/maui issue #31316, filed 24 August 2025. The reporter measured the stock template APK at 24,249 KB on .NET 9, and 25,298 KB on .NET 10 Preview 7. That is roughly 24 to 25 MB of scaffolding.

Flutter publishes its own figure in its app size documentation. The default demo app on Flutter 1.17 reported 5.4 MB compressed and 13.7 MB uncompressed, for App plus On Demand Resources. Those two numbers are not like-for-like, and we will not pretend they are. One is an Android package measured in 2025. The other is an iOS size report from an older Flutter release. What they establish is a gap large enough to matter, not a precise ratio.

If you sell into markets where a 25 MB install costs you conversions, that gap is a business number, not a technical one. Check it yourself rather than trusting us. Run dotnet new maui and flutter create, build both in release, compare the artefacts. Half an hour, and the result is specific to your toolchain rather than ours.

The .NET MAUI app size problem has a fix with a bill attached

Microsoft’s own answer is Native AOT. Its Native AOT deployment documentation states that a published Native AOT app on iOS and Mac Catalyst is typically up to 2.5 times smaller than the default Mono deployment. It also starts up to 2 times faster. Those are Microsoft’s numbers for a dotnet new maui app, and Microsoft is careful to say the charts are hardware dependent.

The bill is on the same page. It is long:

• Every trimming and AOT warning has to be fixed, including warnings from third-party libraries you do not control.
• Runtime XAML parsing through LoadFromXaml is gone.
• String-based bindings become compiled bindings, with x:DataType everywhere.
• The OnPlatform and OnIdiom markup extensions give way to their generic class equivalents.
• QueryPropertyAttribute navigation has to be rewritten as IQueryAttributable.
• Heap analysis is not supported at all.

That is real engineering. It is also engineering a founder without a .NET person cannot supervise. Budget it as a work item, not a checkbox in the project file.

The support window is 18 months, not three years

This is the number we most often have to put in front of a founder planning a five-year internal app. No competing comparison page we found cites it. Per Microsoft’s .NET MAUI support policy, .NET MAUI 10 was released on 11 November 2025 and goes out of support on 11 May 2027. .NET MAUI 9 shipped 12 November 2024 and left support on 12 May 2026. The rule behind those dates: each major version gets a minimum of six months of support after the next major version ships.

So the .NET 10 runtime carries a long-term support badge. MAUI on top of it gives you about eighteen months. Servicing lands on the second Tuesday of each month. Microsoft’s support terms require you to be on the latest servicing level to get help. The current patch is 10.0.90, published 22 July 2026, and .NET MAUI 11 preview 6 was published on 20 July 2026.

The practical consequence is simple, and worth pricing now. Plan a framework upgrade every year, forever. Put a developer’s time against it in the budget. That is not a reason to avoid MAUI. It is a reason not to be surprised.

Open issue counts measure scale, not quality

Founders like issue counts as a maturity signal. Here are current ones, all checked on 11 August 2026 through GitHub’s own search.

Do not read that as a ranking. Flutter’s number is larger partly because Flutter’s user base is larger. Its tracker is also where a very large community files everything. React Native’s figure sits on a different measure, because that API endpoint counts pull requests too.

The honest use of these figures is narrower. All three projects carry a backlog you will eventually land in. Before you choose, search the tracker for your two hardest requirements: background location, in-app purchase edge cases, camera pipelines, Bluetooth. If your requirement already has a three-year-old open issue with 200 thumbs-up, that is the signal, not the total.

For cadence, React Native’s latest tagged release is v0.86.2, published 27 July 2026 per the GitHub releases API. Flutter’s current stable line is 3.44.0, with 3.47 already listed in its release notes index. All three ship regularly. None of them is stalling.

Where .NET MAUI earns its place

Now the other side, because a comparison that only names downsides is just a different kind of sales pitch.

You already run a .NET backend

If your API is ASP.NET Core, MAUI lets you share actual code rather than concepts. DTOs, validation rules, enums and business logic sit in a shared project referenced by both. One language across the whole stack, one CI pipeline, one set of code review habits. That is a genuine reduction in moving parts. It is the strongest argument for C# mobile app development that exists.

Windows desktop and mobile from one codebase

MAUI targets iOS, Android, macOS through Mac Catalyst, and Windows through WinUI, all from the same project. Say your customer runs a Windows desktop app on the warehouse floor and a phone app in the yard. That is one team and one repository instead of two. Flutter and React Native both have desktop stories. Neither is as settled on Windows as MAUI’s.

Long-lived line-of-business apps

Twenty screens of forms, offline sync, role-based permissions, a ten-year life, and a handover to whoever maintains it in 2031. XAML with C# and MVVM is a boring, well-documented, legible way to build that. Boring is the correct choice for software someone else will inherit. The conservatism that makes MAUI a poor fit for a consumer app with a motion designer makes it a good fit here.

How .NET MAUI vs Flutter vs React Native resolves for a founder with no C# team

We will recommend the smaller option, including when it costs us the larger build.

Start by asking whether you need a native app in the first quarter at all. A responsive web build answers most early product questions faster and cheaper. Say you genuinely need the store listing, push notifications or the camera, and your team writes TypeScript. Then React Native with Expo is the shortest path from your existing skills to a shipped build. If the product is animation-led, go Flutter. Accept the smaller hiring pool as the price.

Reach for MAUI when at least two of these are true:

• You already run .NET services.
• You need Windows desktop from the same codebase.
• The app’s life is measured in years rather than funding rounds.

One of those alone is usually not enough.

What this post does not tell you

We are not publishing our clients’ binary sizes or a device-lab cold-start table here. Those binaries are not ours to publish, and a table you cannot reproduce is worth nothing to you. Everything cited above is a figure you can pull yourself: a GitHub issue, a Microsoft support page, a survey result, a template you can build in half an hour.

Microsoft’s Native AOT performance charts are worth the same caution. They show relative improvement without axis figures or named devices. So we quoted the multipliers Microsoft states in text, and nothing more.

The next step

Send us the three hardest screens in your product. Then tell us who maintains the app in three years. That second answer usually settles the stack before the first one does. If the honest recommendation is Expo, or a web build, or not yet, that is what you will get. Dawloom’s public record is 525 delivered orders on Fiverr at 4.9 across 335 reviews, and 5.0 across 156 reviews on Freelancer. It did not get there by selling people the bigger build.