.NET MAUI in 2026: Cross-Platform Entwicklung und Interviewfragen

.NET MAUI (Multi-platform App UI) hat sich mit .NET 10 zu einem ausgereiften, produktionsreifen plattformübergreifenden Framework entwickelt. Als Long-Term-Support-Version mit Unterstützung bis November 2028 wird .NET MAUI 10 als Workload und NuGet-Pakete ausgeliefert und bietet verbesserte Qualität, Performance und neue APIs wie HybridWebView-Erweiterungen und SafeAreaEdges. Dieses Tutorial führt durch die Entwicklung einer plattformübergreifenden App, erklärt die zugrundeliegende Architektur und behandelt die Interviewfragen, die bei Vorstellungsgesprächen im Jahr 2026 gestellt werden.

Ein .NET MAUI 10 Projekt von Grund auf einrichten

Der schnellste Weg zu einer laufenden MAUI-App beginnt mit der .NET CLI. .NET 10 bringt eine aktualisierte Projektvorlage mit, die .NET Aspire Service Defaults enthält und damit Telemetrie sowie Service Discovery out of the box verbindet.

# Install the MAUI workload (if not already present)
dotnet workload install maui

# Create a new MAUI app
dotnet new maui -n CrossPlatformDemo
cd CrossPlatformDemo

# Run on Android emulator
dotnet build -t:Run -f net10.0-android

Die Single-Project-Struktur fasst plattformspezifischen Code unter einem Platforms/-Ordner zusammen, während der Rest geteilt wird. Die Datei MauiProgram.cs dient als Composition Root, wo Services, Schriftarten und Handlers registriert werden.

using Microsoft.Extensions.Logging;

public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();
        builder
            .UseMauiApp<App>()
            .ConfigureFonts(fonts =>
            {
                fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
            });

        // Register services for dependency injection
        builder.Services.AddSingleton<IApiService, ApiService>();
        builder.Services.AddTransient<MainViewModel>();

#if DEBUG
        builder.Logging.AddDebug();
#endif

        return builder.Build();
    }
}

Dependency Injection in MAUI folgt dem gleichen Muster wie in ASP.NET Core. Singleton-Services bestehen für die gesamte App-Lebensdauer, Transient-Services werden pro Anfrage erstellt, und Scoped-Services erfordern Vorsicht, da MAUI kein eingebautes Scope-Konzept wie HTTP-Anfragen besitzt.

Handlers: Die Architektur hinter dem plattformübergreifenden Rendering

MAUI hat die Renderer von Xamarin.Forms durch eine Handler-Architektur ersetzt. Handlers bilden jedes plattformübergreifende Control über eine schlanke Abstraktionsschicht auf sein natives Gegenstück ab. Der entscheidende Unterschied: Handlers sind zustandslos und von der virtuellen View entkoppelt, was sie schneller und einfacher anpassbar macht.

using Microsoft.Maui.Handlers;

public class CustomEntryHandler : EntryHandler
{
    protected override void ConnectHandler(MauiAppCompatEditText platformView)
    {
        base.ConnectHandler(platformView);
        // Remove the default underline on Android
        platformView.SetBackgroundColor(Android.Graphics.Color.Transparent);
    }
}

// Register in MauiProgram.cs
builder.ConfigureMauiHandlers(handlers =>
{
    handlers.AddHandler<Entry, CustomEntryHandler>();
});

In .NET 10 wurde bei den Android-Controls Entry und Editor von AppCompatEditText auf MauiAppCompatEditText umgestellt, was native Unterstützung für das SelectionChanged-Event hinzufügt. Die verbesserten CollectionView- und CarouselView-Handler, die mit .NET 9 eingeführt wurden, sind jetzt Standard auf iOS und Mac Catalyst und lösen langjährige Stabilitätsprobleme.

Android 16 Edge-to-Edge: Breaking Change und erforderliche Anpassung

Android 16 entfernt den Opt-out-Mechanismus für die Edge-to-Edge-Darstellung. Apps, die auf API 36 abzielen, müssen System-Bar-Insets korrekt behandeln, sonst wird der Inhalt fehlerhaft gerendert. .NET 10 hat eine stille Breaking Change eingeführt: In .NET 9 respektierte ContentPage standardmäßig die Systemleisten (Container-Verhalten), aber .NET 10 verwendet standardmäßig Edge-to-Edge (None).

Die Lösung beinhaltet das Hinzufügen eines globalen impliziten Styles in App.xaml:

<!-- App.xaml -->
<Application xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="CrossPlatformDemo.App">
    <Application.Resources>
        <ResourceDictionary>
            <Style TargetType="ContentPage" ApplyToDerivedTypes="True">
                <Setter Property="SafeAreaEdges" Value="Container" />
            </Style>
        </ResourceDictionary>
    </Application.Resources>
</Application>

Das SafeAreaEdges-Enum bietet granulare Kontrolle:

• None: Edge-to-Edge-Inhalt ohne Safe-Area-Padding
• SoftInput: immer Padding für die Tastatur
• Container: unter der Tastatur fließen, aber außerhalb von Leisten und Notch bleiben
• Default: plattformspezifisches Standardverhalten
• All: alle Safe-Area-Insets beachten

Dieser Ansatz verwendet die Window Insets API zur Laufzeit und ist damit kompatibel mit Android 16, wo Opt-outs auf Manifest-Ebene nicht mehr funktionieren.

MVVM mit CommunityToolkit.Mvvm: Boilerplate eliminieren

Der CommunityToolkit.Mvvm Source Generator eliminiert ca. 80% des MVVM-Boilerplate-Codes. Kein manuelles INotifyPropertyChanged, keine Command-Wrapper: Attribute steuern die Codegenerierung.

using CommunityToolkit.Mvvm.ComponentModel;
using CommunityToolkit.Mvvm.Input;

public partial class MainViewModel : ObservableObject
{
    private readonly IApiService _apiService;

    public MainViewModel(IApiService apiService)
    {
        _apiService = apiService;
    }

    // Source generator creates the 'Title' property with change notification
    [ObservableProperty]
    private string _title = string.Empty;

    // Source generator creates the 'IsLoading' property
    [ObservableProperty]
    private bool _isLoading;

    // Source generator creates an async ICommand
    [RelayCommand]
    private async Task LoadDataAsync()
    {
        IsLoading = true;
        try
        {
            Title = await _apiService.FetchTitleAsync();
        }
        finally
        {
            IsLoading = false;
        }
    }
}

Das XAML bindet direkt an die generierten Eigenschaften und Commands:

<!-- MainPage.xaml -->
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:vm="clr-namespace:CrossPlatformDemo.ViewModels"
             x:DataType="vm:MainViewModel">
    <VerticalStackLayout Padding="20" Spacing="16">
        <Label Text="{Binding Title}"
               FontSize="24"
               HorizontalOptions="Center" />
        <Button Text="Load Data"
                Command="{Binding LoadDataCommand}"
                IsEnabled="{Binding IsLoading, Converter={StaticResource InverseBoolConverter}}" />
        <ActivityIndicator IsRunning="{Binding IsLoading}"
                           IsVisible="{Binding IsLoading}" />
    </VerticalStackLayout>
</ContentPage>

Das x:DataType-Attribut aktiviert kompilierte Bindings, die schneller als reflexionsbasierte Bindings sind und Kompilierungsfehler erzeugen, wenn ein Binding-Pfad falsch ist.

XAML Source Generator in .NET 10

.NET MAUI 10 führt einen XAML Source Generator ein, der XAML zur Build-Zeit kompiliert statt zur Laufzeit zu parsen. Das verbessert die Startperformance und fängt XAML-Fehler während der Kompilierung ab.

Um die XAML Source Generation zu aktivieren, muss die folgende Eigenschaft zur Projektdatei hinzugefügt werden:

<PropertyGroup>
  <MauiXamlInflator>SourceGen</MauiXamlInflator>
</PropertyGroup>

.NET 10 Preview 5 hat auch implizite XML-Namespaces eingeführt, die Boilerplate-xmlns-Deklarationen eliminieren. Eine GlobalXmlns.cs-Datei kann mehrere Namespaces zusammenfassen:

[assembly: XmlnsDefinition(
    "http://schemas.microsoft.com/dotnet/maui/global",
    "MyApp.Views")]
[assembly: XmlnsDefinition(
    "http://schemas.microsoft.com/dotnet/maui/global",
    "MyApp.Controls")]

Mit diesem Setup werden XAML-Dateien sauberer:

<!-- Vorher -->
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
        xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
        xmlns:controls="clr-namespace:MyApp.Controls"
        x:Class="MyApp.MainPage">
    <controls:TagView />
</ContentPage>

<!-- Nachher (mit globalem xmlns) -->
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/maui/global"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="MyApp.MainPage">
    <TagView />
</ContentPage>

HybridWebView in .NET 10: Brücke zwischen Nativ und Web

HybridWebView ermöglicht das Einbetten von Webinhalten in eine MAUI-App bei gleichzeitiger bidirektionaler Kommunikation zwischen C# und JavaScript. .NET 10 fügt drei Fähigkeiten hinzu: Fire-and-Forget-JavaScript-Aufrufe, Initialisierungsevents für plattformspezifische Konfiguration und Web-Request-Interception.

public partial class MainPage : ContentPage
{
    public MainPage()
    {
        InitializeComponent();

        // Initialization event for platform-specific tweaks
        hybridWebView.WebViewInitialized += (sender, args) =>
        {
            System.Diagnostics.Debug.WriteLine("WebView ready");
        };
    }

    // Call JavaScript from C#
    private async void OnCallJsClicked(object sender, EventArgs e)
    {
        var result = await hybridWebView.InvokeJavaScriptAsync<string>(
            "getFormData",
            HybridSampleContext.Default.String
        );
        await DisplayAlertAsync("Result", result, "OK");
    }

    // Fire-and-forget: no return type needed (.NET 10)
    private async void OnResetClicked(object sender, EventArgs e)
    {
        await hybridWebView.InvokeJavaScriptAsync("resetForm");
    }
}

JavaScript-Ausnahmen, die während InvokeJavaScriptAsync geworfen werden, werden jetzt automatisch als .NET-Exceptions weitergeleitet, wodurch stille Fehler der Vergangenheit angehören. Web-Request-Interception ermöglicht das Ändern von Headern oder das Bereitstellen lokaler Antworten:

webView.WebResourceRequested += (s, e) =>
{
    if (e.Uri.ToString().Contains("api/secure"))
    {
        e.Handled = true;
        e.SetResponse(200, "OK", "application/json", GetCustomStream());
    }
};

Veraltete APIs und Migrationspfad

.NET MAUI 10 markiert mehrere APIs als veraltet. Anwendungen, die diese verwenden, sollten zu den empfohlenen Alternativen migrieren.

ListView und zugehörige Cells: ListView, EntryCell, ImageCell, SwitchCell, TextCell und ViewCell sind veraltet. Stattdessen sollte CollectionView verwendet werden, das bessere Performance und Stabilität mit den neuen iOS/Mac Catalyst Handlers bietet.

MessagingCenter: In .NET 10 intern gemacht. Ersatz durch WeakReferenceMessenger aus CommunityToolkit.Mvvm.

Animation-Methoden: FadeTo, RotateTo, ScaleTo und ähnliche Methoden sind veraltet. Die async-Äquivalente sollten verwendet werden: FadeToAsync, RotateToAsync, ScaleToAsync.

TableView: Veraltet zugunsten von CollectionView.

DisplayAlert/DisplayActionSheet: Ersetzt durch DisplayAlertAsync und DisplayActionSheetAsync.

Migration von Xamarin.Forms zu .NET MAUI

Der Support für Xamarin.Forms endete im Mai 2024. Die Migration zu MAUI erfordert strukturelle Änderungen, die über einen Namespace-Tausch hinausgehen. Hier ist eine Migrationscheckliste basierend auf Praxiserfahrungen aus realen Projekten:

1. Projektstruktur: Umstellung von plattformspezifischen Projekten auf das MAUI-Single-Project-Modell. Gemeinsamer Code kommt ins Stammverzeichnis, plattformspezifischer Code unter Platforms/.
2. Namespaces: Ersetze Xamarin.Forms durch Microsoft.Maui.Controls und Xamarin.Essentials durch Microsoft.Maui.Essentials (jetzt in MAUI integriert).
3. Renderer zu Handlers: Custom Renderer müssen als Handlers neu geschrieben werden. Die Handler-API ist einfacher, aber die Mapping-Logik unterscheidet sich.
4. Startup: Ersetze die App.xaml.cs-Initialisierung durch MauiProgram.cs mit dem Builder-Pattern.
5. NuGet-Pakete: Viele Pakete aus der Xamarin-Ära haben MAUI-Äquivalente. Kompatibilität vor dem Upgrade prüfen.
6. Dependency Injection: MAUI nutzt Microsoft.Extensions.DependencyInjection nativ. Jegliche Drittanbieter-DI-Container oder DependencyService-Aufrufe ersetzen.

Der .NET Upgrade Assistant automatisiert Teile der Schritte 1-2, aber Handlers (Schritt 3) und Anpassungen der Geschäftslogik erfordern manuelle Arbeit.

Die wichtigsten .NET MAUI Interviewfragen für 2026

Diese Fragen spiegeln wider, was Entwicklerteams im Jahr 2026 in Vorstellungsgesprächen fragen, basierend auf dem aktuellen .NET 10 Ökosystem. Für weitere C# und .NET Interviewvorbereitung siehe den vollständigen .NET Interview-Guide.

Wie unterscheidet sich die MAUI-Handler-Architektur von Xamarin.Forms-Renderern?

Renderer in Xamarin.Forms waren eng an sowohl das plattformübergreifende Control als auch an die native View gekoppelt, wodurch eine bidirektionale Abhängigkeit entstand. Handlers in MAUI sind zustandslose Mapper: Sie empfangen Property-Change-Benachrichtigungen und wenden diese über ein Mapper-Dictionary auf die native View an. Diese Entkopplung bedeutet, dass Handlers einfacher zu testen, zu erweitern und wiederzuverwenden sind. Die PropertyMapper- und CommandMapper-Dictionaries ersetzen das OnElementPropertyChanged-Override-Pattern und machen Anpassungen explizit statt in Switch-Statements vergraben.

Welche Fallstricke gibt es bei DI-Lifetimes speziell in MAUI?

MAUI unterstützt Singleton-, Transient- und Scoped-Lifetimes, aber Scoped verhält sich anders als in ASP.NET Core. Es gibt keine natürliche Scope-Grenze (wie einen HTTP-Request). Ein Scoped-Service, der in MAUI registriert wird, verhält sich wie ein Singleton, es sei denn, benutzerdefinierte Scopes werden manuell erstellt. Häufige Fehler: Ein ViewModel als Singleton registrieren, obwohl es seitenspezifischen Zustand hält (veraltete Daten bei Navigation), oder eine Datenbankverbindung als Transient registrieren (Connection-Pool-Erschöpfung). Die Faustregel: ViewModels sind Transient, Services sind Singleton, und Scoped wird vermieden, es sei denn, der Scope-Lifecycle wird explizit verwaltet.

Wie unterscheidet sich kompiliertes Binding von reflexionsbasiertem Binding in MAUI?

Reflexionsbasierte Bindings lösen Property-Pfade zur Laufzeit mit System.Reflection auf, was langsam ist und bei Tippfehlern Laufzeitfehler erzeugt. Kompilierte Bindings, aktiviert mit x:DataType, lösen Binding-Pfade zur Kompilierzeit auf. Der Compiler erzeugt direkten Property-Zugriffscode und umgeht Reflection vollständig. Das verbessert die Startzeit, reduziert Speicher-Allokationen und fängt Binding-Fehler während des Builds ab. In .NET 10 optimiert der neue XAML-Source-Generator dies weiter, indem XAML zur Build-Zeit kompiliert wird statt es zur Laufzeit zu parsen.

Welche Strategien gibt es zur Code-Sharing zwischen MAUI-App und ASP.NET Core Backend?

Der empfohlene Ansatz verwendet eine Shared Class Library mit DTOs, Validierungslogik und Business Rules. Sowohl die MAUI-App als auch das ASP.NET Core Backend referenzieren diese Library. .NET 10 verstärkt dieses Pattern mit der neuen .NET Aspire Integration für MAUI, die Service Discovery und Telemetrie über Mobile- und Backend-Projekte hinweg bereitstellt. Geteilte Contracts mit System.Text.Json-Source-Generatoren stellen Serialisierungskonsistenz sicher. Die wichtigste Einschränkung: Die Shared Library muss net10.0 targeten (nicht plattformspezifische TFMs), um portabel zu bleiben.

Wie unterscheidet sich HybridWebView von BlazorWebView in MAUI?

BlazorWebView hostet eine vollständige Blazor-Anwendung innerhalb der MAUI-App. Razor-Komponenten rendern in ein eingebettetes WebView, aber die .NET-Runtime läuft nativ (nicht über WebAssembly). HybridWebView ist leichtgewichtiger: Es lädt statische HTML/CSS/JS-Inhalte und bietet C#-zu-JavaScript-Interop ohne den Overhead des Blazor-Frameworks. Die Wahl hängt vom Anwendungsfall ab. BlazorWebView eignet sich für Teams mit bestehenden Blazor-Komponenten, die Code wiederverwenden möchten. HybridWebView eignet sich für Szenarien, in denen bestehende Webinhalte (Dashboards, Karten, Editoren) ohne ein vollständiges Framework nativ integriert werden sollen.

Weitere .NET Interviewfragen auf SharpSkill helfen dabei, diese Konzepte mit interaktiven Übungen zu festigen.

Quellen

• What's new in .NET MAUI for .NET 10 - offizielle Dokumentation mit allen .NET 10 MAUI Features
• .NET MAUI GitHub Releases - Service Release Notes für 10.0.x Versionen
• Edge-to-Edge Is Now Mandatory in Android 16 - Migrationsguide für Android 16 Anforderungen
• MAUI GitHub Discussion #34171 - Community-Feedback zur .NET MAUI 10 Stabilität

Das Wichtigste für .NET MAUI 10 Entwickler

• .NET MAUI 10 ist ein LTS-Release (Unterstützung bis November 2028), das auf Stabilität und Performance setzt, was es zu einer zuverlässigen Wahl für plattformübergreifende Produktions-Apps macht
• Android 16 macht Edge-to-Edge verpflichtend: SafeAreaEdges="Container" als globalen Style in App.xaml hinzufügen, um das .NET 9 Verhalten wiederherzustellen
• Der XAML Source Generator (MauiXamlInflator=SourceGen) kompiliert XAML zur Build-Zeit und verbessert die Startperformance sowie frühere Fehlererkennung
• ListView, TableView und MessagingCenter sind veraltet: Migration zu CollectionView und WeakReferenceMessenger erforderlich
• Die Handler-Architektur ersetzt Xamarin-Renderer durch zustandslose Mapper und verbessert die Testbarkeit durch PropertyMapper und CommandMapper
• CommunityToolkit.Mvvm Source Generators entfernen den Großteil des MVVM-Boilerplates: [ObservableProperty]- und [RelayCommand]-Attribute ersetzen manuelle Implementierungen
• HybridWebView in .NET 10 fügt Fire-and-Forget-JavaScript-Aufrufe, Initialisierungsevents und Request-Interception für die Native-Web-Integration hinzu
• Die Interviewvorbereitung sollte sich auf Handler- vs. Renderer-Architektur, DI-Lifetime-Fallstricke in langlebigen Apps, kompilierte Bindings und HybridWebView vs. BlazorWebView-Abwägungen konzentrieren