How .NET MAUI works: one project, many platforms, and Tizen

If your team already writes C# and .NET, .NET MAUI is the obvious candidate when someone asks for an app on phones, tablets and desktops. The pitch is one codebase, one project and native results. Before committing, a technical lead needs to know how that works underneath, where the seams show, and which platforms are properly covered.

This article is a technical orientation, written as of 23 October 2026. It follows our business-level explanation of when one app for every platform makes sense. It covers the project model, how the UI reaches native controls, where platform code goes, the toolchain, the support policy, and a platform table that includes Tizen, which needs particular care.

Code samples are illustrative and have not been compiled for this article. As a Microsoft licence reseller we know these tools well, but whether MAUI suits you depends on your team and your users.

The single project

.NET MAUI is an open-source framework for building native mobile and desktop apps with C# and XAML. It's the evolution of Xamarin.Forms, extended from mobile to desktop. Where a Xamarin solution had a shared library and a head project per platform, MAUI uses one project that multi-targets.

At build time, only the Platforms folder matching the current target is compiled. Fonts, images, app icons and splash screens live in a shared Resources folder, and images are generated for each platform at build time from a single source file. There is one app entry point, MauiProgram.CreateMauiApp(), where you register services, fonts and handlers.

The project file lists the target frameworks. For .NET 10 they follow the pattern net10.0-android, net10.0-ios, net10.0-maccatalyst and a Windows target, which the standard project template writes with a Windows SDK version suffix (net10.0-windows10.0.19041.0 in the template at the time of writing). The Windows target is only included when you build on Windows. Check the exact strings in the project template for your SDK, because they change with the .NET version. Microsoft's target framework list also shows net10.0-tizen; we come back to what that does and doesn't tell you.

How the UI reaches native controls

You describe the UI in XAML or in C# markup. Controls such as Button or Entry are cross-platform "virtual views". A handler maps each one to a native view on each platform: a Button becomes a UIButton on iOS and a MaterialButton on Android. Handlers expose the native control as PlatformView, and property mappers update it when a cross-platform property changes.

Handler customisation is global. If you change the Entry handler, every Entry in the app changes. That is powerful and easy to forget, so keep customisations small and in one place.

For teams with web skills, Blazor Hybrid is another option. Razor components run natively on the device and render into an embedded web view through BlazorWebView, so one set of web UI components can be reused across mobile, desktop and web. Styling inside a web view is platform dependent, so expect some per-platform CSS.

Where platform-specific code goes

There are four common routes, and most real apps use more than one:

1. Conditional compilation, with #if ANDROID, #elif IOS and #elif WINDOWS blocks. Fine for a couple of lines, messy beyond that.
2. Partial classes and methods, declared in shared code and implemented in the Platforms folders. This is the approach Microsoft's platform code guide describes.
3. Multi-targeting by filename or folder, such as *.Android.cs or *.MaciOS.cs, which lets platform code live outside Platforms (how to configure it).
4. Handler customisation, for changing how a control looks or behaves natively.

Wrapping platform code behind an interface and registering it with dependency injection keeps the rest of the app testable. An illustrative example, a service that reports free storage:

// Shared code: Services/FreeSpaceService.cs
namespace MyApp.Services;

public interface IFreeSpaceService
{
    long GetFreeBytes();
}

public partial class FreeSpaceService : IFreeSpaceService
{
    public partial long GetFreeBytes();
}

// Platforms/Android/FreeSpaceService.cs
namespace MyApp.Services;

public partial class FreeSpaceService
{
    public partial long GetFreeBytes()
    {
        var stat = new Android.OS.StatFs(Android.OS.Environment.DataDirectory!.Path);
        return stat.AvailableBytes;
    }
}

// Platforms/iOS/FreeSpaceService.cs (Mac Catalyst needs its own copy, or the MaciOS naming convention)
using Foundation;

namespace MyApp.Services;

public partial class FreeSpaceService
{
    public partial long GetFreeBytes()
    {
        var attrs = NSFileManager.DefaultManager.GetFileSystemAttributes(
            Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments));
        return attrs is null ? 0 : (long)attrs.FreeSize;
    }
}

// MauiProgram.cs
builder.Services.AddSingleton<IFreeSpaceService, FreeSpaceService>();

Each target you build needs an implementation, or the build fails. That is a useful property: adding a platform tells you straight away where the gaps are.

The toolchain

• Visual Studio on Windows, with the .NET Multi-platform App UI development workload. For MAUI 10, which runs on .NET 10, that means Visual Studio 2026, which ships the .NET 10 SDK; Visual Studio 2022 warns that targeting .NET 10 is not supported. The alternative is the latest Visual Studio Code with the .NET MAUI extension. Microsoft's installation page still mentions Visual Studio 2022 17.12, which predates .NET 10, so go by the SDK rather than that line.
• Hot Reload lets you edit managed code and XAML while the app runs, preserving navigation state and data.
• A Mac is needed for iOS and Mac Catalyst. Microsoft's installation page lists a Mac compatible with Xcode, a specific Xcode version for your MAUI release, and an Apple ID with paid Apple Developer Program enrolment. From Visual Studio on Windows, iOS builds go through a networked Mac.

Testing and CI

Put business logic in plain class libraries, with no UI or platform dependencies, and test those with ordinary unit tests. Anything that touches handlers, platform services or layout needs a real device, an emulator or a device farm. Test the shared code heavily and keep the platform layer thin.

For CI, Android and Windows builds do not need a Mac. The iOS and Mac Catalyst builds need a macOS agent, which is where most teams meet an unexpected cost or delay. Verify the agent images and Xcode versions your CI provider offers against the Xcode version your MAUI release requires, which is given in the dotnet/macios release notes, linked from the MAUI release versions wiki.

Store, signing and packaging

This is the cost people forget. Microsoft's deployment overview lists, per platform:

• Android: an APK for direct installation, or an AAB (Android App Bundle) for publishing to a store.
• iOS: an .ipa file, a provisioning profile, and devices registered with Apple for testing.
• Mac Catalyst: an .app or .pkg, with a provisioning profile.
• Windows: a folder publish or an MSIX package, with Developer Mode for local testing.

Certificates, profiles and store accounts have to be created, stored safely and renewed. Plan for that work and for whoever owns it.

Releases and support

MAUI follows the .NET cadence. Under the MAUI support policy, a major version is supported for a minimum of six months after its successor ships. Servicing updates ship on the same monthly cycle as the rest of .NET, may mix security and non-security fixes, and to receive technical support from Microsoft you need to be on the latest servicing level.

As of 23 October 2026, .NET MAUI 9 has been out of support since 12 May 2026, and .NET MAUI 10 is the current version. Microsoft publishes an end date for each version only once its successor ships, so we don't give one for MAUI 10 here. Check the policy page for the latest position. If you have an app on MAUI 9 or earlier, it is on a version that no longer receives fixes. That's a case for the sort of planning we describe in what "out of support" means.

Platform support

The minimums come from Microsoft's supported platforms page and change between releases, so check them again for whichever release you commit to.

Where Tizen fits

Tizen is Samsung's operating system for televisions, wearables and other devices. Microsoft's supported platforms page says .NET MAUI includes Tizen support, provided by Samsung. That means support comes from Samsung, not Microsoft, and it is installed separately as the Tizen .NET workload, with Samsung's own SDK and tooling. Samsung's Tizen .NET overview says its Visual Studio Tools for Tizen add Tizen support for MAUI, and that its Tizen.TV.UIControls extension APIs work only on Tizen TV devices that support Tizen .NET.

What we could and could not confirm, as of 23 October 2026:

• Samsung's Tizen.NET repository README and its workload installation wiki page describe .NET 6. The wiki was last edited on 27 June 2023, and the README says to install the .NET 6 SDK. The repository shows no releases.
• Samsung workload manifest packages for newer .NET SDK bands do exist on NuGet, for example Samsung.NET.Sdk.Tizen.Manifest-8.0.400, with versions up to 10.0.126 (last updated 19 May 2026). The listing carries no notes about MAUI compatibility.
• The .NET target framework list includes net10.0-tizen, but that is a name in a catalogue. It doesn't tell you whether Samsung's tooling supports MAUI 10.
• We could not confirm from Samsung's pages whether Tizen is supported for MAUI 10 and .NET 10. We have not seen Samsung state that it works on current .NET, so we are not claiming it does.

If Tizen televisions or wearables are a requirement, confirm the current position with Samsung before you commit. Treat Tizen as a separate platform with its own SDK, test devices and support path.

A sensible first step

Pick the one screen or service in your app that is most platform-specific, such as storage, notifications or file access. Build it as an interface with a partial-class implementation, as above, for the two platforms you care about most, and run it on real devices. That single exercise tells you more about the effort involved than a feature comparison will. List your target platforms and check each against Microsoft's page, and against Samsung's if Tizen is on it.

We build .NET MAUI apps and migrate Xamarin apps to .NET MAUI, building on our earlier Xamarin work. If you would like to talk through whether MAUI fits your project, our software and integration work is the place to start, and software care covers keeping an app supported once it is live.