We've shipped four production .NET MAUI apps and have two more in flight. That's enough scar tissue to have an opinion, and not enough scar tissue to be jaded.
Short version: MAUI in 2026 is good. It is the tool we wanted Xamarin.Forms to be. The tooling has caught up, the platform abstractions are honest about what they can and can't do, and the productivity gains of one-codebase-two-stores are real.
It is also not always the right choice. Here's how we now decide.
Where MAUI earns its place
The case for MAUI is strongest when the app meets three conditions:
- It is a real app for real users, not a content-driven marketing surface that could just as well be a web app.
- The team is already a .NET team. This matters more than people admit — context-switching between Swift, Kotlin and a backend stack is genuinely expensive.
- The functionality is not bleeding-edge platform-specific — no ARKit, no Core ML on-device, no Android Auto integration. (These are doable in MAUI, but you'll work harder for them than you would in native.)
The apps we've shipped that fit cleanly into this:
- Optimise — a personal-training network app for trainers and clients. Programmes, bookings, payments, progress tracking. One codebase, iOS + Android, [YOU: confirm the 11k active clients / 4.8★ figures from the case study are still accurate for the post].
- MediBridge pharmacy app — patient-facing prescription tracking and ordering for a network of 60 independent pharmacies, with NHS Spine integration in a hardened Azure Function tier.
- Tilden Financial — client-facing mobile app for 140 advisers, alongside their Blazor adviser portal.
- Pickans Phase 2 (in build) — taking the human-only Q&A marketplace mobile.
For all four, the decisive factor wasn't "MAUI vs native" — it was "one codebase vs two." When the choice is between shipping iOS-only and iOS-plus-Android, "plus-Android" wins commercially every time. And building Android natively in Kotlin is a separate skill stack and team commitment we wouldn't take on for these clients.
What's good about MAUI now that wasn't good about Xamarin.Forms
Three things have genuinely improved:
Build times. Xamarin.Forms Android builds used to be a coffee break. MAUI Android builds are seconds. This is not a small thing; it's the difference between a tight feedback loop and a frustrated one.
The Handler architecture is fundamentally better than Renderers were. When you need to customise platform-specific behaviour — and you will — Handlers expose the native control directly. You write less code, and the code you write is more obvious.
Hot reload actually works on both XAML and C# changes. Not 100% of the time, but enough of the time that the workflow is fundamentally different. Xamarin.Forms hot reload was technically present and practically unusable. MAUI hot reload is technically imperfect and practically usable.
What still hurts
Honesty section. Three things that we still trip over:
iOS provisioning is still bad, and it's not MAUI's fault. It is just unavoidably bad. New developer joining the team? Half a day of certificate dance. Apple changed something? Half a day of certificate dance. We have not solved this, we have just learned to budget for it.
Some packages don't have MAUI versions yet. Less true than it was two years ago, much less true than it was three years ago, but still occasionally. The workaround is usually to bind the native SDK directly, which is fine but is not the developer experience the marketing pages imply.
XAML. It's still XAML. If you have a team that loves XAML, this is fine. If you don't, this is a culture clash and you'll feel it. We use Blazor Hybrid (Razor components hosted in MAUI) on some projects to avoid XAML, and we like that hybrid model a lot — though it has its own trade-offs around platform feel.
When we don't reach for MAUI
Cases where we've talked clients out of MAUI:
- A single-platform iOS app. If it's iOS-only, write it in SwiftUI. The cross-platform tax is real and it's not worth paying for one platform.
- An app whose primary purpose is content browsing with simple interactions. That's a Progressive Web App. PWAs are underrated; for some use cases they're the right answer and the user never knows the difference.
- An app that needs deep AR, on-device ML, or platform-specific hardware integration. Native. MAUI can do it, but you'll spend the savings of one codebase on the friction of bridging.
- An MVP for a feature you're not sure about. A PWA is faster to ship and easier to discard. Don't go through App Store review on a hypothesis.
The offline question
One thing MAUI is good at, and people don't always realise: offline-first apps. For our Optimise project (trainers on a gym floor with patchy Wi-Fi) and our Site Inspect platform (field engineers in venues with no signal), offline-first was a hard requirement.
The pattern that's worked for us:
- Local SQLite database on the device, mirroring the relevant slice of the server's domain model.
- Writes go to the local DB first, then sync.
- Sync is its own state machine —
pending,syncing,synced,conflict. The UI shows the current state honestly. - Conflict resolution is last-writer-wins with audit trail for most fields; specific high-stakes fields (e.g. financial transactions) are flagged and never auto-resolved.
The MAUI side of this is straightforward. The hard part is on the server: designing endpoints that accept batches of changes, return server-side IDs, and surface conflicts cleanly. That's a backend problem, not a MAUI problem.
Blazor Hybrid: the underrated middle path
The thing I'd flag to any team considering MAUI in 2026: look at Blazor Hybrid before defaulting to XAML.
Blazor Hybrid lets you build the UI in Razor components — the exact same components you'd use in a Blazor web app — and host them inside a MAUI shell. You get:
- The web component model, which most .NET teams already know.
- Code and component sharing with your Blazor web app, if you have one.
- Native shell integration where you need it (notifications, deep links, hardware access) via the MAUI side.
What you give up: pixel-perfect platform-native feel. A Blazor Hybrid app looks like a Blazor web app inside a chrome, because that's what it is. For internal apps, B2B apps, and apps where brand consistency matters more than platform-native feel, this is the right trade. For consumer apps where the iOS-ness or Android-ness is part of the product, it's not.
[YOU: we have a Blazor Hybrid app in production, right? Add a sentence here naming it if so. Otherwise frame as "we've evaluated and would use it for the right project."]
What about Flutter and React Native?
You'll get asked. Here's what we tell clients:
- Flutter is genuinely good. The performance is excellent, the tooling is excellent, the layout system is more pleasant than XAML. The trade-off is Dart — it's a language your .NET team doesn't know, and adopting Flutter means adopting an additional ecosystem.
- React Native is fine if your web team is already a React team. If it isn't, you're picking up React, the React Native ecosystem, and the JS toolchain — three things at once. We don't recommend React Native to .NET teams.
- MAUI wins for us because our clients' teams are .NET teams. The stack-consistency argument matters more in practice than the marginal quality of any individual framework.
Would we still pick it?
For our clients — SMEs who need a small-to-medium app, with a .NET backend team and no appetite for hiring a separate mobile team — yes, every time. The economics are clear, the tooling is good enough, and the productivity wins are real.
For a consumer app at startup-velocity with native-feel ambitions, we'd think harder. Probably still MAUI for the stack-consistency, but we'd be more open to Flutter than we used to be.
MAUI in 2026 is not perfect. It is, however, good enough that picking it is no longer a defensive choice. That's a significant change from where we were two years ago, and it's why MAUI is now the default in the toolbox rather than the exception.
Red Owl IT builds Microsoft software, including .NET MAUI apps for iOS and Android. We've shipped MAUI apps for healthcare, financial services, fitness and field engineering. If you're weighing MAUI against the alternatives, we'd happily compare notes.