.NET MAUI

Topics in this category

Advanced & Enterprise Advanced Data Binding & Collections App Lifecycle & Windows Best Practices & Architecture Concurrency & Threading Controls & Views Data Binding & MVVM Dependency Injection & Services Desktop - WinUI & Mac Catalyst Device Features & Essentials Fonts, Icons & Media Forms, Input & Validation Fundamentals & Architecture Gestures & Animations Graphics & Drawing Local Storage & Data Maps & Location Migration from Xamarin.Forms Native Interop & Libraries Networking & APIs

.NET MAUI

Migration from Xamarin.Forms

Q: What are the main steps to migrate a Xamarin.Forms app to MAUI?

Create a new MAUI project (or use the .NET Upgrade Assistant), move shared code and XAML in, consolidate the platform head projects into the single project's Platforms folders, update NuGet packages to MAUI-compatible versions, replace custom renderers with handlers, and fix namespace changes (Xamarin.Forms -> Microsoft.Maui). Then test each platform.

Q: How do namespaces and using directives change from Xamarin.Forms to MAUI?

Xamarin.Forms types move to Microsoft.Maui and Microsoft.Maui.Controls. Xamarin.Essentials merges into Microsoft.Maui.* namespaces. Update using directives and XAML namespace declarations (the default xmlns changes to the MAUI schema). Global usings can reduce repetitive imports.

Q: How do you convert a Xamarin.Forms custom renderer to a MAUI handler?

Identify what the renderer customized, then move that logic to a handler mapper (AppendToMapping/ModifyMapping) or a custom handler if you added a new control. Most simple renderer tweaks become a few lines in a mapper, removing the renderer class and its ExportRenderer attribute entirely.

Q: What common breaking changes should you expect when migrating to MAUI?

Watch for: removed/renamed layout options (StackLayout defaults, some AbsoluteLayout behavior), FormsApplicationDelegate/Activity base classes becoming Maui* equivalents, DependencyService replaced by DI, App.xaml resource resolution differences, image/font declaration changes, and third-party libraries needing MAUI versions. Test layouts closely since spacing/measure changed.

Q: How do you replace DependencyService with MAUI dependency injection?

Register the interface/implementation in MauiProgram's Services and inject via constructors instead of calling DependencyService.Get (). This is testable and explicit. For gradual migration you can keep a temporary service-locator shim, but the goal is constructor injection throughout.

Q: How do you decide between a big-bang and incremental MAUI migration?

For small apps, a big-bang rewrite into a fresh MAUI project is often fastest. For large apps, migrate incrementally: get it building on MAUI early, port and verify feature areas one at a time, and keep tests green throughout. Consider risk, team capacity, third-party library readiness, and release cadence.

6 question(s)

What are the main steps to migrate a Xamarin.Forms app to MAUI?

Beginner

Create a new MAUI project (or use the .NET Upgrade Assistant), move shared code and XAML in, consolidate the platform head projects into the single project's Platforms folders, update NuGet packages to MAUI-compatible versions, replace custom renderers with handlers, and fix namespace changes (Xamarin.Forms -> Microsoft.Maui). Then test each platform.

Real-world example A team uses the .NET Upgrade Assistant to scaffold the MAUI project, then ports pages incrementally while keeping the app buildable.

Common follow-ups: What tool assists migration? | What happens to head projects?

Migration Xamarin.Forms vs MAUI Migration from Xamarin.Forms

How do namespaces and using directives change from Xamarin.Forms to MAUI?

Intermediate

Xamarin.Forms types move to Microsoft.Maui and Microsoft.Maui.Controls. Xamarin.Essentials merges into Microsoft.Maui.* namespaces. Update using directives and XAML namespace declarations (the default xmlns changes to the MAUI schema). Global usings can reduce repetitive imports.

// Xamarin.Forms
using Xamarin.Forms;
// MAUI
using Microsoft.Maui;
using Microsoft.Maui.Controls;

Real-world example A migration sweeps the codebase replacing Xamarin.Forms usings with Microsoft.Maui equivalents and updates the XAML root xmlns.

Common follow-ups: Where did Xamarin.Essentials go? | What is the new XAML xmlns?

Migration Project Structure Migration from Xamarin.Forms

How do you convert a Xamarin.Forms custom renderer to a MAUI handler?

Intermediate

Identify what the renderer customized, then move that logic to a handler mapper (AppendToMapping/ModifyMapping) or a custom handler if you added a new control. Most simple renderer tweaks become a few lines in a mapper, removing the renderer class and its ExportRenderer attribute entirely.

// Old: custom EntryRenderer removing the underline
// New: EntryHandler mapper
EntryHandler.Mapper.AppendToMapping("NoLine", (h, v) => { /* native tweak */ });

Real-world example A dozen small renderers collapse into a handful of mapper customizations, cutting platform code significantly.

Common follow-ups: Do all renderers map to handlers 1:1? | What replaces ExportRenderer?

Handlers Migration Migration from Xamarin.Forms

What common breaking changes should you expect when migrating to MAUI?

Advanced

Watch for: removed/renamed layout options (StackLayout defaults, some AbsoluteLayout behavior), FormsApplicationDelegate/Activity base classes becoming Maui* equivalents, DependencyService replaced by DI, App.xaml resource resolution differences, image/font declaration changes, and third-party libraries needing MAUI versions. Test layouts closely since spacing/measure changed.

Real-world example A migrated screen looks slightly off until the team adjusts StackLayout spacing and switches DependencyService calls to injected services.

Common follow-ups: What replaces DependencyService? | Why re-test layouts after migration?

Migration Dependency Injection Migration from Xamarin.Forms

How do you replace DependencyService with MAUI dependency injection?

Intermediate

Register the interface/implementation in MauiProgram's Services and inject via constructors instead of calling DependencyService.Get<T>(). This is testable and explicit. For gradual migration you can keep a temporary service-locator shim, but the goal is constructor injection throughout.

// Old
var svc = DependencyService.Get<IPhotoService>();
// New
builder.Services.AddSingleton<IPhotoService, PhotoService>();
public MyViewModel(IPhotoService svc) { _svc = svc; }

Real-world example Platform photo access moves from DependencyService lookups to a normally injected IPhotoService.

Common follow-ups: Why is DI preferable? | Can you migrate incrementally?

Dependency Injection Migration Migration from Xamarin.Forms

How do you decide between a big-bang and incremental MAUI migration?

Advanced

For small apps, a big-bang rewrite into a fresh MAUI project is often fastest. For large apps, migrate incrementally: get it building on MAUI early, port and verify feature areas one at a time, and keep tests green throughout. Consider risk, team capacity, third-party library readiness, and release cadence.

Real-world example A large enterprise app is migrated feature-by-feature over several sprints, shipping intermediate builds rather than freezing releases for a rewrite.

Common follow-ups: What factors drive the choice? | How do tests help incremental migration?

Migration Architecture Migration from Xamarin.Forms