.NET MAUI 2026: Plattformübergreifende Entwicklung und Fragen für Vorstellungsgespräche

.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 konzentriert sich .NET MAUI 10 auf 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 — hier werden Services, Schriftarten und Handlers registriert.

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 — obwohl verfügbar — 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.

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.

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) =>
        {
            // Access the native platform view after initialization
            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",  // JS function name
            HybridSampleContext.Default.String  // JSON serialization context
        );
        await DisplayAlert("Result", result, "OK");
    }

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

Das zugehörige JavaScript empfängt Aufrufe und kann Nachrichten zurück an C# senden:

function getFormData() {
    return JSON.stringify({
        name: document.getElementById('name').value,
        email: document.getElementById('email').value
    });
}

function resetForm() {
    document.getElementById('name').value = '';
    document.getElementById('email').value = '';
}

JavaScript-Ausnahmen, die während InvokeJavaScriptAsync geworfen werden, werden jetzt automatisch als .NET-Exceptions weitergeleitet, wodurch stille Fehler der Vergangenheit angehören.

SafeAreaEdges: Pixelgenaue Layouts auf jedem Gerät

.NET MAUI 10 führt die SafeAreaEdges-Eigenschaft für Layout, ContentView, ContentPage, Border und ScrollView ein. Das neue Enum (None, SoftInput, Container, Default, All) ersetzt das veraltete iOS-spezifische Page.UseSafeArea durch einen plattformübergreifenden Ansatz.

<!-- Granular safe area control per section -->
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             SafeAreaEdges="All">
    <Grid RowDefinitions="Auto,*,Auto">
        <!-- Header respects all safe areas -->
        <Border Grid.Row="0" SafeAreaEdges="Container">
            <Label Text="Header" />
        </Border>

        <!-- Content scrolls under safe areas -->
        <ScrollView Grid.Row="1" SafeAreaEdges="SoftInput">
            <VerticalStackLayout Padding="16">
                <Entry Placeholder="Type here..." />
            </VerticalStackLayout>
        </ScrollView>

        <!-- Footer avoids home indicator -->
        <Border Grid.Row="2" SafeAreaEdges="Container">
            <Label Text="Footer" />
        </Border>
    </Grid>
</ContentPage>

SoftInput passt den Inhalt an, wenn die Bildschirmtastatur erscheint. Container vermeidet Notches, Sensorgehäuse und den Home-Indicator. Diese können pro Control kombiniert werden, sodass ein Header unter der Statusleiste sitzen kann, während der Inhaltsbereich frei bleibt.

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.

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.

Fazit

• .NET MAUI 10 ist ein LTS-Release (Unterstützung bis November 2028), das auf Stabilität und Performance setzt statt auf Feature-Inflation — eine zuverlässige Wahl für plattformübergreifende Produktions-Apps
• Die Handler-Architektur ersetzt Xamarin-Renderer durch zustandslose Mapper und verbessert die Testbarkeit und Anpassbarkeit durch PropertyMapper und CommandMapper
• CommunityToolkit.Mvvm-Source-Generatoren entfernen den Großteil des MVVM-Boilerplates — [ObservableProperty]- und [RelayCommand]-Attribute ersetzen manuelle INotifyPropertyChanged- und Command-Implementierungen
• HybridWebView in .NET 10 fügt Fire-and-Forget-JavaScript-Aufrufe, Initialisierungsevents und Request-Interception für die Native-Web-Integration hinzu
• SafeAreaEdges bietet granulare, plattformübergreifende Kontrolle über Geräteausschnitte, Tastaturen und Systemleisten und ersetzt das veraltete iOS-only UseSafeArea
• Die Xamarin.Forms-Migration erfordert Handler-Umschreibungen und Startup-Refactoring — der .NET Upgrade Assistant übernimmt Namespace-Änderungen, aber manuelle Arbeit bleibt bei Custom Renderern
• Die Interviewvorbereitung sollte sich auf Handler- vs. Renderer-Architektur, DI-Lifetime-Fallstricke in langlebigen Apps, kompilierte Bindings und HybridWebView vs. BlazorWebView-Abwägungen konzentrieren