.NET MAUI: one C# codebase for cross-platform desktop and mobile, when it really pays off

Paolo has been leading a .NET team for ten years, and until now he has never had a reason to look at .NET MAUI.

His Windows business application runs smoothly across two hundred customers.

Then, in March, senior management changes the rules: the company needs mobile.

Tablets for the sales force, phones for the field engineers and, while we are at it, the Macs in the marketing department too.

Paolo says yes.

What else was he supposed to say?

That his team cannot handle it?

So he does the most sensible thing for anyone who lives inside .NET: he puts .NET MAUI for desktop and mobile development with C# on the table, the framework Microsoft built for exactly this.

One language for the computer and for the phone.

The reasoning is sound.

The team already speaks C# and XAML, so MAUI will be a more modern WPF, with mobile included in the package.

Four months later, the picture looks very different.

The Mac version does not behave like the Windows one.

Building the iPhone app requires a Mac running inside the build chain, and nobody had put that in the budget.

Two features of the old application simply do not exist in the new world: they have to be written from scratch.

And one Monday morning Paolo has to walk into a room and explain to management why the date is slipping.

For that particular moment, no slide deck will save you.

The point is that Paolo did not fail through incompetence.

He failed because he trusted one sentence: it is a "modern WPF, with mobile included".

That is how almost everyone introduces .NET MAUI.

It is a sentence that promises a painless move: take what you know about the desktop and shift it onto the phone, unchanged.

And it forgets to tell you where that move gets stuck.

Which happens to be the only part that decides whether the project reaches the finish line or stalls halfway.

Let me be blunt: MAUI is a good tool that is badly explained.

The people explaining it from a stage usually have forty minutes to fill, not a project to deliver by March.

In twenty-five years inside these systems I have watched every generation of "write once, run anywhere" tools go by.

The promise holds, but only for those who read the small print before signing.

This article is that small print.

Plus everything else.

I will explain what MAUI really is and how it is built under the bonnet.

Then what you can reuse exactly as it is across Windows, Mac, iPhone and Android, and what you cannot.

And finally I will take you where the tutorials do not follow: the office computer, the three mistakes that sink projects, the limits to plan for before you start.

So that your next decision is made with the numbers Paolo discovered afterwards.

Not with the expectations he had before.

What .NET MAUI is and the problem it actually solves

MAUI stands for Multi-platform App UI.

It is Microsoft's official tool for building real, "native" apps from a single project written in C# and XAML.

It covers four platforms: Windows, Mac, iPhone and Android.

The word that matters is "native".

MAUI does not take a web page and wrap it in a shell dressed up as an app.

It translates everything into the real components of each system.

A button, on the iPhone, becomes a genuine iPhone button.

On Android, an Android button.

On Windows, a Windows button.

So much for the textbook definition.

Which does not get you far.

The part you care about is different: which problem does MAUI take off your table?

Without a tool like this, covering desktop and phone means keeping separate projects alive.

Swift for the Apple world, Kotlin for Android, WPF or WinUI for Windows.

Three worlds, three languages.

And every feature written and tested three times.

Translated into daily life: the same fix applied three times, three rounds of testing, three chances to get it wrong.

The biggest cost is not even the initial build.

It is maintenance, which multiplies by the number of platforms.

You pay it on every change and every operating system update, for as long as the product lives.

And you pay it in late evenings and on-call rotations: line items that never appear in a budget, but that your team knows very well.

MAUI brings everything back inside one language and one runtime.

Application logic, data access, service calls, validation rules: you write them once in C#, and they behave the same everywhere.

For a company that already has a .NET team, the arithmetic is concrete.

You keep the people you have, instead of chasing iPhone and Android specialists, who are scarce and expensive to hold on to.

In practice, your team's ten years of C# stop being baggage from the past and become an advantage again.

What changed between Xamarin and .NET MAUI?

MAUI did not appear out of nowhere.

It is the direct descendant of Xamarin.Forms, the tool Microsoft relied on until 2022.

There are three differences, and all three go in the right direction.

• A single project: no more duplicates, one per platform. Now one project declares where you want to ship and holds icons, resources and start-up together.
• The runtime is today's .NET, the same one behind ASP.NET Core: no longer a separate engine living its own life.
• The third one is more technical, and I will come back to it shortly: the old Renderers have been replaced by Handlers, lighter and easier to shape around your needs.

But the detail that really decides is another one: Xamarin has been out of support since May 2024.

No more updates, no more security fixes.

Every Xamarin app still in circulation is a ticking clock that will have to be dealt with sooner or later.

It only takes one iPhone update that breaks the app, or one security review requested by a customer, and the conversation stops being about code and starts being about obligations and liability.

The conclusion: any new cross-platform .NET project starts from MAUI.

And any Xamarin project still running needs a migration date in the calendar.

Better now, on a schedule you choose, than in six months on a schedule a customer chooses for you.

If you want the wider picture before going into detail, start from the page on what .NET MAUI is.

The value of MAUI is not the single-codebase slogan: it is making the C# your team already owns pay off.

The MAUI Course by Sviluppatore Migliore starts exactly here, and takes you where the tutorials stop: architecture, logic reuse and the traps that cost Paolo four months.

How .NET MAUI works: the architecture explained without jargon

You do not need to know every moving part to use MAUI well.

You need three clear ideas.

They are the three ideas that separate an app that works with the tool from one that argues with it every single day.

And arguing with your tools has a precise price: it is called Friday evening at your desk, wondering why a list behaves differently on Android.

• One project that produces several native apps. In the project you declare the platforms you want to reach, and the build prepares a real app for each of them. The logic you share lives in ordinary C# classes, identical to those in any other .NET project. When you need something specific to one platform, there is a dedicated folder: whatever you put in there stays there, without polluting the rest.
• Handlers, the bridge between your controls and the real ones in the system. Every element you use in MAUI, a text field, a button, a list, is a kind of placeholder that at the right moment gets translated into the real component of that platform. Compared with Xamarin's old Renderers, Handlers are lighter and far simpler to customise. Want to change how every text field behaves on Android? Adjust the translation point, a few lines, and you are done. With Xamarin, the same change required a dedicated class for each platform. It is the kind of design decision you do not notice in a twenty-minute demo, and that saves your project after three weeks of real work.
• The MVVM pattern with automatic data binding. In plain terms: you describe how the screens look in XAML, the logic that drives them sits in a separate class, and a mechanism keeps the two sides in sync on its own, without you writing code to do it by hand. One library, CommunityToolkit.Mvvm, takes most of the repetitive work off your hands: you declare a property or a command with a small attribute, and the machine writes the rest for you.

Anyone arriving from WPF feels at home immediately: XAML, data binding and MVVM are the same concepts as always.

And that feeling of familiarity is exactly the ground on which the misunderstanding we started with grows.

The concepts travel, the context does not.

So no, what you know is not outdated.

It is incomplete in one place only.

And that one place costs four months, if you discover it on the job instead of beforehand.

One codebase for four platforms: what you share fully and what you do not

The "write it once" promise is seductive.

But it has to be read correctly.

What you share completely is one thing, what you share only in part is another.

Confusing the two leads to wrong estimates and to projects that derail halfway.

Let us start with what you share entirely, no exceptions: the application logic.

Services, models, validation rules, calls to your own services, state management.

It is plain C#, and it runs identically on every platform.

If you already have a .NET library doing this work, you reuse it as it is.

And that is usually the most expensive part to build and to test.

Sharing it is the saving that counts.

The interface, on the other hand, you share for the most part.

Not always in full.

A screen with lists, forms and navigation works everywhere with the same code.

But the details change.

What sits comfortably in three columns on a monitor wants a single column on a phone.

The way people move between screens follows different habits on iPhone and on Android.

Notifications, fingerprint authentication and the camera each need a little tailored code per system, even if you then hide it behind one shared door.

MAUI gives you the tools to handle these differences in an orderly way.

But that adaptation work exists, and it belongs in the budget from the first estimate.

On device access, the question from anyone coming from desktop or web is always the same: do I lose the native capabilities?

The short answer: no.

There are the Essentials, a set of ready-made functions: GPS with Geolocation, camera with MediaPicker, files with FilePicker, network state with Connectivity, preferences with Preferences and secure storage with SecureStorage.

One line of C# each, identical across the four platforms.

And when you need something the Essentials do not cover, you drop down to platform-specific code while keeping the shared part clean.

Here is the full picture, component by component:

One last thing, and it is not a minor detail: for MAUI the office computer is a first-class citizen.

Windows with WinUI 3 and Mac with Mac Catalyst are not forced afterthoughts bolted onto a phone-first tool, which is what Xamarin was.

Precisely for that reason, though, the desktop deserves a discussion of its own.

That is where Paolo's misunderstanding sent the bill.

.NET MAUI on Windows and Mac desktop: where the "modern WPF" illusion sends the bill

You will not find this part in the tutorials.

Not because it is a secret: because it does not fit into ten minutes of video, and nobody watches a video about Apple certificates.

And yet it is exactly the part that separates a project that starts on the right foot from one that accumulates trouble from week one.

If you are coming from WPF and you are convinced MAUI is WPF with mobile bolted on, read this section before all the others.

Desktop layout is not phone layout made bigger

In WPF you design full-width screens, side panels, toolbars, right-click menus, columns you can widen as you please.

In MAUI the same screen has to look right on a six-inch phone and on a twenty-seven-inch monitor.

It is not a matter of adjusting widths.

The navigation patterns change, what a finger expects differs from what a mouse expects, and the order in which you present information changes too.

MAUI's tools help you, but designing for desktop and phone together is a project decision, not a last-minute tweak.

Skip it and you end up with a business application that looks like a phone app inflated to full screen.

And users notice on the first click.

Mac Catalyst is not a true Mac application

On the Mac, MAUI uses Mac Catalyst: the technology Apple provides to run iPad apps on the Mac.

The result works, but the experience is slightly different from a program written specifically for the Mac.

System menus, trackpad gestures, keyboard shortcuts: that is where the difference shows.

For the vast majority of business applications and internal tools this is not a problem.

But if somebody is expecting a Mac experience polished to the pixel, they will be disappointed.

Better to spell that out when the contract is signed.

The iPhone and Mac app has to go through a Mac

Apple requires the final build of the iPhone and Mac app to happen on a Mac with Xcode installed.

This is not a MAUI quirk: it applies in exactly the same way to Flutter and to native development.

In practice, if your build chain runs on Windows or Linux, you have to add a Mac to it.

Or rent one from a cloud service, at an additional cost.

This is the line item Paolo's team discovered once the work had already started.

Plan for it in advance.

For a MAUI app targeting only Windows and Android, this constraint does not exist.

If instead your question is "do I stay on WPF or move to MAUI on Windows?", the full comparison is in the article on WPF in 2026.

There you will find when WPF remains the right choice and when MAUI is the sensible step.

It took Paolo four months to put the project back in order.

A bill no tutorial puts in the estimate.

Reading this article saves you the time, but it does not give you the practice.

I know what you are thinking: "I can find all this online for free".

Absolutely true.

In the same way you can find, for free, everything you need to perform an appendectomy.

And yet nobody operates on themselves by watching videos.

What you will not find for free is someone who looks at your project and tells you: this decision, in three months, will cost you double.

Layout decisions, the discipline of shared code, the Apple paperwork: you learn those by building, with someone who straightens out your approach before it becomes a problem.

The MAUI Course by Sviluppatore Migliore exists for exactly that: a path through XAML, MVVM, Blazor Hybrid and publishing, built on examples that reflect what the market actually asks for.

The outcome is not "knowing MAUI".

It is becoming the person your company hands the cross-platform project to.

The one who chooses with judgement.

And that kind of person is not replaced by a cheaper quote.

Do the arithmetic properly, then decide: months set up badly cost more than any course (ours included).

And you pay for them without taking anything home.

Blazor Hybrid: pieces of the web inside a real app, with no browser

If there is one thing in MAUI that widens the range of options, it is Blazor Hybrid.

Instead of building screens in XAML, you build them with Blazor components: files containing HTML, CSS and C# logic, displayed inside the app by an element called BlazorWebView.

The word "web" is misleading here.

This is not a site loaded in a browser.

It does not run on the web and it does not need a server.

The C# code in these components runs natively inside the app, with full access to device features.

BlazorWebView is only the engine that draws the HTML and the CSS.

The result: a real app, for desktop and phone, whose interface is built with the bricks of the web.

For many teams this is the turning point.

If you already have a Blazor portal or Razor components to reuse, you bring them into MAUI with minimal adjustments.

You end up with an installable app that shares its interface with your web product, without maintaining the same screen twice.

And maintaining the same screen twice means every change made twice, every bug fixed twice: the sensation of running while standing still.

XAML or Blazor Hybrid: how to choose

This is not a holy war.

The two approaches live side by side in the same app.

XAML makes sense when the team has a WPF or Xamarin background, and when you want the look as close as possible to each system's native feel.

It also makes sense where the interface is full of phone-specific gestures.

Blazor Hybrid makes sense when the team knows web development well, and when there are components ready to reuse.

And it makes sense where screens are dense with data and tables, the territory on which HTML and CSS remain faster and more flexible.

In practice, the pattern that works is this: Blazor Hybrid for complex, data-heavy screens, XAML for navigation and for the elements that have to feel native to the touch.

The wrong choice does not show in the first month.

It shows the day you have to change something and discover what it costs you.

.NET MAUI, native or Flutter: the choice is made on context, not on enthusiasm

This is the question that separates a mature decision from a trend.

And in software, trends are always paid for by the same people: the ones left holding the project together once whoever chose it has moved on.

Native development, Swift for Apple and Kotlin for Android, is not dead.

Flutter, Google's toolkit, is the most serious competitor.

The right answer depends on context.

And context is measured on three things: the team you have, the code you have, the type of app you have to build.

When .NET MAUI is the rational choice

MAUI wins when the team already knows C# and .NET.

Reusing the people you have, instead of hiring specialists, is a significant saving.

If you have spent ten years on C#, this is where those ten years are worth double instead of half.

It wins when there is a .NET backend or .NET logic to reuse, because sharing becomes concrete rather than theoretical.

It wins when you have to cover desktop and phone together, because few technologies do both well.

And it wins for the broadest family of business applications: back-office systems, sales force apps, internal tools, data dashboards.

Places where development speed and ease of maintenance matter more than the latest visual effect.

When native still leads

Native wins when you need performance at the limit or heavy graphics: games, live video editing, three-dimensional animation.

It wins when you need the very latest system features on the day Apple or Google release them.

Every cross-platform layer introduces a small, unavoidable delay.

And it wins when the app is the product's shop window, every movement is polished to the pixel, and the company has the budget for two specialised teams.

If you are in one of those cases, MAUI is not your answer.

And I would rather tell you here than later.

But for most companies, those are not the real constraints.

.NET MAUI or Flutter: the difference that decides

The deepest difference lies in how the screens are drawn.

Flutter draws every pixel with its own graphics engine: the controls are not native, they are recreated to look native.

That gives absolute consistency across platforms, and it is at its best in heavily animated interfaces.

MAUI uses the real native controls, through Handlers: the app feels more integrated with the system, in exchange for slightly less absolute control over the rendering.

The second difference is the language.

Flutter uses Dart, which most .NET teams do not know.

MAUI uses the same C# as your backend, your services and your tests.

Your experience in C# is not dead weight to overcome in order to keep up.

It is the reason why, on this particular decision, you start a step ahead of everyone else.

The other side deserves saying too: the supply of ready-made components around Flutter is somewhat richer today.

MAUI, in exchange, fits perfectly with Visual Studio, Azure and the tools a .NET team already uses every day.

The comparison, reduced to what actually matters:

The three mistakes that sink a .NET MAUI project in production

The MAUI projects I have watched fail did not sink because of the tool.

They sank because of three mistakes, always the same ones, all avoidable, all born of the same root: starting with the "modern WPF with mobile included" mindset instead of cross-platform discipline:

• Putting the logic inside the screen's code instead of in a separate class. Anyone learning in fragments from tutorials loads the data straight into the page file, because it is the quickest way to see something move. The trouble is that it holds up terribly as the app grows: the screen becomes impossible to test on its own, navigation gets tangled, and every visual tweak drags pieces of logic along with it. You know how it ends: there is exactly one person in the company willing to touch that screen. If that person is you, it is not a compliment. It is a cage. The MVVM pattern, with the CommunityToolkit.Mvvm library, cuts the problem off at the root. But it has to be adopted from day one, not after the first rude awakening.
• Handling platform differences without a clear pattern. Sooner or later every real app needs some tailored behaviour: a notification on Android, a permission on iPhone. The temptation is to fill the shared code with small scattered exceptions, a bit here and a bit there. After six months nobody reads that code any more. And what nobody reads, newcomers will not touch: everything falls back on the same shoulders as always. The right approach is to define a single door for each service that varies, implement it in the platform folders and wire it up. The shared code talks to the door and does not even know which system it is running on.
• Underestimating Apple's signing and permissions paperwork during planning. Certificates, profiles, entitlements, App Store Connect: every step has its traps. Discovering all of them in the last week before release is the ending nobody wants. Releases almost never slip because of a hard problem. They slip because of three days of certificates. The fix is simple, and almost nobody applies it: publish to a test environment as early as possible, even when the app is still a skeleton.

The first publication is the most painful one.

Do it while the calendar is not on fire.

Three real situations where .NET MAUI delivers concrete value

These are the three I see working in the companies I work with.

The first: the app for sales people and for engineers out in the field.

It has to run on tablets and phones, it has to work without a network connection and sync with the central system when the connection returns.

This is MAUI working in the conditions it was designed for.

You share the sync logic and the models with your .NET system, the app runs on company iPhones and Android devices, and a desktop version covers whoever works from the office.

All with a single C# team, speaking the same language from the database to the tablet screen.

No hiring to justify, no external supplier to chase.

The second: internal tools and productivity apps.

Data dashboards, requests to approve, documents to consult.

Here MAUI with Blazor Hybrid is particularly effective, because you reuse the components of the web portal you already have.

You get an app installable on desktop and phone in a short time, built with technologies the team already commands.

In a mid-sized company, that is often the difference between the project being approved and the project being pushed to next year.

The third: the long-standing Windows application that has to add mobile without giving up the desktop.

This is Paolo's situation: do not throw the system away, extend it.

You start from the Windows app and add Android for the people on the road.

The XAML and MVVM work already done on the desktop is reused wholesale, with the precautions described above.

It is not a leap into the dark.

It is extending what the team already knows how to do.

The thread is always the same: MAUI is at its best when there is a .NET investment to make pay off, and when the app belongs to the business software family rather than being a consumer product built entirely on visual polish.

If you recognised your company in one of these three scenarios, what is missing is not understanding whether MAUI is right: it is knowing how to take it into production.

The MAUI Course by Sviluppatore Migliore takes you from your first project to publishing on the stores, on cases that mirror the market you work in.

From your first .NET MAUI project to publishing on the stores

Let us get practical: what you need to write the first line and reach your users.

What to set up and in what order to learn

You need .NET 10, or .NET 8 as a minimum, and Visual Studio 2026 with the MAUI workload.

Alternatively, for those who prefer something lighter, VS Code with the official extension.

Do not go looking for a separate C# download: the language is already inside .NET, whichever editor you choose.

To build the iPhone and Mac app you need a Mac with Xcode, the Apple constraint we have already covered.

The MAUI project in front of you has a recognisable shape: start-up and navigation files, resources, folders for platform-specific code.

And one place where you register services and classes, exactly as you would in an ASP.NET Core app.

If you already know C#, the climb is gentle.

This is the right order:

• XAML and page layout, to understand how screens are built
• MVVM and data binding, to keep logic and interface separate
• navigation between pages
• device features with the Essentials
• preparing and publishing to the stores

Written like that, it looks obvious.

Reconstructing it on your own, jumping from one video to the next, takes months.

And for all those months you have no idea whether you are making progress or going in circles, which is the part that really wears you down.

The typical mistake of people learning from scattered tutorials is skipping the order and ending up with an app that works but cannot be maintained.

The official MAUI documentation is excellent as a reference, less so as a map: the order is something you have to give yourself.

Publishing to the App Store, Google Play and the Microsoft Store

Writing the app is half the job.

The other half is getting it to people.

• For Android you prepare the package for Google Play or for direct delivery, signed with your own key.
• For iPhone you prepare the package signed with your Apple account certificates and publish it through App Store Connect.
• For Windows you create the package for the Microsoft Store or for internal distribution.
• For Mac you need a package signed and notarised according to Apple's rules.

The point that matters, if you are thinking long term, is automation.

The whole round trip, meaning build, signing and publishing, can be driven from the command line and orchestrated in a pipeline on Azure DevOps or GitHub Actions, exactly as you would for an ordinary server-side service.

Repeatable releases, no shaky manual steps, distribution to every platform through the same flow.

The difference compared with three separate native projects is that here there is a single pipeline: same repository, same build file, four artefacts coming out.

A team that automates its releases stops being afraid of releasing.

And a team that is not afraid of releasing ships more often.

The limits of .NET MAUI to plan for before you start

I would have little credibility if I only told you about the strengths.

Anyone who presents a technology with no drawbacks is not explaining a technology to you. They are selling you a ticket.

There are four real limits, and none of the four appears in the slogans.

• The first: third-party ready-made components. Syncfusion, Telerik and DevExpress have mature MAUI suites, but outside those three the catalogue thins out quickly, whereas on Flutter you find community packages for almost anything. For very particular requirements you may find yourself writing a binding to native code instead of downloading a ready-made library.
• The second: build times and the smoothness of hot reload. On an average project a full Android build is measured in minutes rather than seconds, and hot reload drops more often than in WPF: plan for a few extra restarts during the day.
• The third: diagnosing problems that appear on one platform only takes expertise. When a defect shows up on the iPhone alone, you need to know enough about the iPhone to get to the bottom of it. The MAUI layer does not excuse you from knowing the platforms underneath.
• The fourth is the one almost nobody plans for: testing multiplies by platform. The code is one, but the behaviours to verify are four, across devices with different screens, versions and permissions.

"A single codebase" does not mean "a single round of testing".

Test plans and devices, real or rented in the cloud, have to be budgeted from the start.

None of these limits is a wall, for the kind of app MAUI is designed for.

But the difference between a project that reaches production and one that runs aground almost always sits here: choosing MAUI for the right situation, and planning for the constraints before you start instead of discovering them in month four, like Paolo.

I have listed them for you now, at no cost.

So that a customer does not list them for you in September, in a tone you already know.

Knowing the limits before you start is half the work; the other half is managing them without discovering them in month four.

And that half is learned by building: on the MAUI Course by Sviluppatore Migliore you work on real projects, with someone who straightens out your approach before it becomes a problem.

.NET MAUI pays off when the .NET investment is already there

Let us go back to the original request: the Windows business application to be taken onto tablets, phones and Macs.

Now the answer has the right shape.

There is no need to write it three times.

There is no need for specialists in three platforms.

And there is no need to believe the slogan either.

What you need is to make the C# you already have pay off and share the logic in full.

And to adapt the interface where it has to be adapted, planning for the constraints of Apple and of the office computer.

This is the job MAUI was born for.

And it is a job that repays the effort.

For anyone whose users stay on a Windows computer and who has no need for mobile, WPF remains a solid, mature choice.

But for most business applications the calculation changes.

For teams with a .NET investment to exploit across several platforms, MAUI today offers the best balance between speed, coverage and maintenance.

The cost of not deciding, though, is precise.

Every week built on the wrong expectation is a week somebody will have to redo.

And every month spent postponing is a month in which your competitors ship on the devices your customers already work with.

The difference between those who pay the bill for the illusion and those who avoid it is not talent.

It is the method by which the decision is framed.

Some people spend a career carrying out decisions made by others, and then picking up the pieces.

And some people frame the decisions, and get called in when a difficult one comes along.

Which side you are on is your call.

Nobody decides it for you.

Paolo, the one from the beginning, had the app in production on Android tablets and Windows computers six months later.

The Mac version was planned properly, not promised verbally.

Not because he learned more technologies: because he replaced expectations with a method, and stopped discovering constraints after the fact.

The programme is not for everyone, and admission is by application.

Matteo Migliore, who leads it, follows every team personally; so the places cannot be unlimited.

If it turns out during the conversation that it does not make sense for you, I will tell you: I would rather give a clear no today than leave someone disappointed in three months.

What this article cannot give you, a reading of your specific case, is exactly where a call begins.