Warum die Migration 2026 kein optionales Projekt mehr ist
Seit Mai 2024 ist der Microsoft-Support für sämtliche Xamarin-SDKs offiziell beendet. Keine Sicherheitsupdates, keine Bugfixes, keine Kompatibilitätspatches. Punkt. Wer Anfang 2026 noch eine Xamarin.Forms-App in Produktion betreibt, hat ein ganz konkretes Problem: Die App lässt sich zunehmend nicht mehr aktualisieren — und irgendwann überhaupt nicht mehr veröffentlichen.
Google verlangt ab August 2026 mindestens Android API Level 36 für alle neuen Apps und Updates im Play Store. Xamarin unterstützt maximal API Level 34. Auf der Apple-Seite sieht es nicht besser aus — Xcode 26 und die neuesten iOS-SDKs sind mit Xamarin schlicht nicht kompatibel.
Das heißt im Klartext: Kein Store-Update, keine neuen Nutzer, und bestehende Installationen werden bei Betriebssystem-Updates zunehmend instabil. Nicht gerade die Aussichten, die man sich wünscht.
Die gute Nachricht: .NET MAUI 10 ist als Long-Term-Support-Release (LTS) für drei Jahre unterstützt und bietet einen realistischen, gut dokumentierten Migrationspfad. Dieser Leitfaden führt Sie durch jeden einzelnen Schritt — von der Bestandsaufnahme bis zur fertigen .NET MAUI 10 App. Ich habe selbst mehrere dieser Migrationen begleitet, und ehrlich gesagt: Mit der richtigen Vorbereitung ist es deutlich weniger schmerzhaft, als viele befürchten.
Voraussetzungen und Werkzeuge einrichten
Bevor Sie auch nur eine einzige Codezeile ändern, müssen die Entwicklungswerkzeuge stimmen. Klingt banal, aber genau hier stolpern überraschend viele Teams. .NET MAUI 10 erfordert konkret:
- Visual Studio 2026 (oder neuer) mit der Workload „.NET Multi-platform App UI development"
- .NET 10 SDK — installieren und mit
dotnet --versionüberprüfen - Xcode 26 auf dem Mac (für iOS- und macOS-Builds)
- Android SDK mit API Level 36
Installieren Sie die MAUI-Workload über die Kommandozeile:
dotnet workload install maui
dotnet workload listKurzer Hinweis: Der bisherige .NET Upgrade Assistant ist mittlerweile als veraltet markiert. Microsoft empfiehlt stattdessen den GitHub Copilot Modernization Agent, der in Visual Studio 2026 integriert ist. Er analysiert Ihr Projekt, erstellt einen Migrationsplan und führt automatische Code-Korrekturen durch.
Aber — und das ist wichtig — verlassen Sie sich nicht blind darauf. Manuelle Nacharbeit ist fast immer nötig. Der Agent übersieht subtile Abhängigkeiten und macht bei komplexeren Renderer-Migrationen gerne mal fragwürdige Vorschläge.
Schritt 1: Bestandsaufnahme und Abhängigkeiten prüfen
Der häufigste Grund, warum Migrationen scheitern? Mangelnde Vorbereitung. Ernsthaft. Nehmen Sie sich die Zeit für eine gründliche Analyse, bevor Sie Code anfassen.
NuGet-Pakete inventarisieren
Erstellen Sie eine Liste aller NuGet-Pakete in Ihrer Lösung und prüfen Sie für jedes Paket:
- Gibt es eine .NET MAUI-kompatible Version? (z. B.
Xamarin.CommunityToolkit→CommunityToolkit.Maui) - Gibt es ein Nachfolgepaket eines anderen Anbieters?
- Muss die Funktionalität selbst implementiert werden?
Hier die typischen Paket-Umbenennungen, die Sie kennen sollten:
// Vorher (Xamarin) → Nachher (.NET MAUI)
Xamarin.Forms → Microsoft.Maui.Controls
Xamarin.Essentials → (in MAUI integriert)
Xamarin.CommunityToolkit → CommunityToolkit.Maui
Xamarin.CommunityToolkit.Markup → CommunityToolkit.Maui.Markup
Xamarin.Forms.Maps → Microsoft.Maui.Controls.Maps
DevExpress.XamarinForms.Charts → DevExpress.Maui.Charts
Telerik.XamarinForms.Common → Telerik.UI.for.MauiCustom Renderer zählen
Suchen Sie in Ihrer Lösung nach allen Klassen, die von ViewRenderer, PageRenderer oder VisualElementRenderer erben. Notieren Sie die Anzahl — jeder einzelne muss entweder zu einem Handler migriert oder über den Kompatibilitätsmodus weiterverwendet werden. Bei mehr als zehn Custom Renderern sollten Sie ernsthaft über eine schrittweise Migration nachdenken.
Performance-Baseline erstellen
Dieser Schritt wird gerne übersprungen, ist aber Gold wert: Messen Sie die Startzeit und den Speicherverbrauch Ihrer aktuellen Xamarin-App auf echten Geräten. Diese Werte brauchen Sie später als Vergleichsbasis, um den Erfolg der Migration objektiv zu bewerten.
Schritt 2: Neues .NET MAUI 10 Projekt erstellen
Microsoft empfiehlt explizit, nicht die bestehende Projektstruktur in-place zu upgraden, sondern ein frisches .NET MAUI Projekt anzulegen und den Code schrittweise zu migrieren. Und da stimme ich voll zu — das ist deutlich sauberer und vermeidet versteckte Altlasten in den Projektdateien.
dotnet new maui -n MeineApp -o MeineApp
cd MeineAppDie neue Projektdatei (.csproj) sieht im SDK-Stil deutlich kompakter aus als die alte Xamarin-Version:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net10.0-android;net10.0-ios;net10.0-maccatalyst</TargetFrameworks>
<OutputType>Exe</OutputType>
<RootNamespace>MeineApp</RootNamespace>
<UseMaui>true</UseMaui>
<SingleProject>true</SingleProject>
<ApplicationTitle>MeineApp</ApplicationTitle>
<ApplicationId>com.meinefirma.meineapp</ApplicationId>
<ApplicationDisplayVersion>2.0.0</ApplicationDisplayVersion>
<ApplicationVersion>1</ApplicationVersion>
</PropertyGroup>
</Project>Statt drei separater Projekte (Shared, Android, iOS) haben Sie jetzt ein einzelnes Projekt mit einer Platforms-Ordnerstruktur. Plattformspezifischer Code lebt in Platforms/Android, Platforms/iOS und so weiter. Allein das macht die Lösung schon übersichtlicher.
Schritt 3: Namespaces und XAML-Deklarationen aktualisieren
Jetzt wird es mechanisch — aber Vorsicht, genau hier passieren die meisten Fehler. Jede Datei in Ihrem Projekt muss aktualisiert werden, und eine einzige vergessene Datei kann den kompletten Build sabotieren.
C#-Namespaces ersetzen
Die wichtigsten Namespace-Änderungen im Überblick:
// Alte Xamarin-Namespaces
using Xamarin.Forms;
using Xamarin.Forms.Xaml;
using Xamarin.Essentials;
using Xamarin.Forms.Maps;
// Neue .NET MAUI Namespaces
using Microsoft.Maui;
using Microsoft.Maui.Controls;
using Microsoft.Maui.Controls.Xaml;
using Microsoft.Maui.ApplicationModel;
using Microsoft.Maui.Controls.Maps;Achtung: Ein einfaches „Suchen und Ersetzen" reicht hier nicht. Manche Klassen wurden in komplett andere Namespaces verschoben, und bestimmte APIs haben sich geändert. Die Color-Klasse zum Beispiel ist von Xamarin.Forms.Color nach Microsoft.Maui.Graphics.Color gewandert — und die Werte sind jetzt float statt double. So etwas entdecken Sie erst, wenn der Compiler meckert.
XAML-Stammnamespace aktualisieren
In jeder XAML-Datei muss der Root-Namespace geändert werden. Vergessen Sie auch nur eine Datei, schlagen alle InitializeComponent()-Aufrufe fehl — und die Fehlermeldungen sind leider nicht immer hilfreich:
<!-- Vorher (Xamarin.Forms) -->
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml">
<!-- Nachher (.NET MAUI) -->
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml">Globale XAML-Namespaces nutzen (neu in .NET 10)
Ein echtes Highlight von .NET MAUI 10: globale XAML-Namespaces. Damit registrieren Sie häufig verwendete CLR-Namespaces in einer einzigen Datei (GlobalXmlns.cs) und eliminieren die endlosen xmlns:-Deklarationen in Ihren XAML-Seiten:
[assembly: XmlnsDefinition(
"http://schemas.microsoft.com/dotnet/2021/maui",
"MeineApp.ViewModels")]
[assembly: XmlnsDefinition(
"http://schemas.microsoft.com/dotnet/2021/maui",
"MeineApp.Converters")]Danach können Sie Ihre ViewModels und Converter direkt im XAML verwenden, ohne zusätzliche xmlns:-Präfixe. Wer viele eigene Typen im XAML nutzt, wird das lieben.
Schritt 4: Breaking Changes in .NET MAUI 10 behandeln
.NET MAUI 10 bringt neben vielen Verbesserungen auch einige API-Änderungen mit, die bei der Migration berücksichtigt werden müssen. Hier sind die wichtigsten.
ListView und TableView sind veraltet
Das dürfte für einige ein Schock sein: Die Klassen ListView, TableView und sämtliche zugehörigen Zelltypen (TextCell, ImageCell, SwitchCell, EntryCell, ViewCell) sind in .NET MAUI 10 offiziell als veraltet markiert. Verwenden Sie stattdessen CollectionView:
<!-- Vorher: ListView -->
<ListView ItemsSource="{Binding Aufgaben}">
<ListView.ItemTemplate>
<DataTemplate>
<TextCell Text="{Binding Titel}" Detail="{Binding Beschreibung}" />
</DataTemplate>
</ListView.ItemTemplate>
</ListView>
<!-- Nachher: CollectionView -->
<CollectionView ItemsSource="{Binding Aufgaben}">
<CollectionView.ItemTemplate>
<DataTemplate>
<VerticalStackLayout Padding="10">
<Label Text="{Binding Titel}" FontAttributes="Bold" />
<Label Text="{Binding Beschreibung}" TextColor="Gray" />
</VerticalStackLayout>
</DataTemplate>
</CollectionView.ItemTemplate>
</CollectionView>Die Migration von ListView zu CollectionView ist in den meisten Fällen unkompliziert. Die CollectionView bietet ohnehin bessere Performance und mehr Flexibilität (Grouping, Header, Footer, verschiedene Layouts).
MessagingCenter ist intern
In .NET MAUI 10 wurde MessagingCenter intern gemacht und ist nicht mehr direkt zugänglich. Der empfohlene Ersatz ist WeakReferenceMessenger aus dem CommunityToolkit.Mvvm-Paket:
// Vorher (Xamarin.Forms)
MessagingCenter.Send(this, "AufgabeErledigt", aufgabe);
MessagingCenter.Subscribe<MainViewModel, Aufgabe>(
this, "AufgabeErledigt", (sender, arg) => { /* ... */ });
// Nachher (.NET MAUI 10 mit CommunityToolkit.Mvvm)
WeakReferenceMessenger.Default.Send(new AufgabeErledigtMessage(aufgabe));
WeakReferenceMessenger.Default.Register<AufgabeErledigtMessage>(
this, (recipient, message) => { /* ... */ });Mal ganz nebenbei: Der WeakReferenceMessenger ist dem alten MessagingCenter in jeder Hinsicht überlegen — typsichere Messages, besseres Memory Management, und er lässt sich viel einfacher testen.
Nullable DatePicker und TimePicker
DatePicker.Date ist jetzt DateTime? statt DateTime, und TimePicker.Time ist TimeSpan? statt TimeSpan. Klingt nach einer Kleinigkeit, kann aber zu subtilen Bugs führen. Prüfen Sie alle Bindungen, die diese Properties verwenden, und passen Sie Ihre ViewModels entsprechend an.
DisplayAlert und DisplayActionSheet
Die bisherigen Methoden sind als veraltet markiert. Verwenden Sie die neuen asynchronen Varianten, die konsistenter in die .NET MAUI Architektur integriert sind.
Schritt 5: Custom Renderer zu Handlern migrieren
So, jetzt kommen wir zum technisch anspruchsvollsten Teil der Migration. Sie haben grundsätzlich zwei Optionen — und die Wahl hängt von der Komplexität und Menge Ihrer Renderer ab.
Option A: Kompatibilitätsmodus (schnelle Lösung)
Wenn Sie viele Custom Renderer haben und zunächst einfach eine funktionierende App brauchen, können Sie den Kompatibilitätsmodus nutzen. Dabei passen Sie die bestehenden Renderer minimal an:
// 1. Namespaces aktualisieren
// Vorher: using Xamarin.Forms.Platform.Android;
using Microsoft.Maui.Controls.Compatibility.Platform.Android;
using Microsoft.Maui.Controls.Platform;
// 2. ExportRenderer-Attribut entfernen (!)
// [assembly: ExportRenderer(...)] ← weg damit
// 3. In MauiProgram.cs registrieren
builder.UseMauiCompatibility();
builder.ConfigureMauiHandlers(handlers =>
{
handlers.AddCompatibilityRenderer(
typeof(MeinCustomEntry),
typeof(MeinCustomEntryRenderer));
});Das funktioniert und kann als Zwischenschritt sinnvoll sein. Aber seien Sie gewarnt: Microsoft garantiert nicht, dass der Kompatibilitätsmodus in zukünftigen .NET-Versionen erhalten bleibt. Planen Sie also, die Renderer mittelfristig richtig zu migrieren.
Option B: Handler-Migration (empfohlen)
Der saubere Weg ist die Migration zu Handlern. Hier ein konkretes Beispiel — ein Custom Entry mit abgerundeten Ecken:
// 1. Interface für das plattformübergreifende Control
public interface ICustomEntry : IView
{
string Text { get; }
Color TextColor { get; }
float CornerRadius { get; }
}
// 2. Das Control selbst
public class CustomEntry : View, ICustomEntry
{
public static readonly BindableProperty TextProperty =
BindableProperty.Create(nameof(Text), typeof(string),
typeof(CustomEntry), string.Empty);
public static readonly BindableProperty CornerRadiusProperty =
BindableProperty.Create(nameof(CornerRadius), typeof(float),
typeof(CustomEntry), 8f);
public string Text
{
get => (string)GetValue(TextProperty);
set => SetValue(TextProperty, value);
}
public float CornerRadius
{
get => (float)GetValue(CornerRadiusProperty);
set => SetValue(CornerRadiusProperty, value);
}
// TextColor analog
}// 3. Handler (Android-Teil als Partial Class)
public partial class CustomEntryHandler :
ViewHandler<ICustomEntry, EditText>
{
public static IPropertyMapper<ICustomEntry, CustomEntryHandler>
Mapper = new PropertyMapper<ICustomEntry, CustomEntryHandler>(
ViewMapper)
{
[nameof(ICustomEntry.Text)] = MapText,
[nameof(ICustomEntry.CornerRadius)] = MapCornerRadius,
};
public CustomEntryHandler() : base(Mapper) { }
protected override EditText CreatePlatformView() => new(Context);
static void MapText(CustomEntryHandler handler,
ICustomEntry entry)
{
handler.PlatformView.Text = entry.Text;
}
static void MapCornerRadius(CustomEntryHandler handler,
ICustomEntry entry)
{
var drawable = new GradientDrawable();
drawable.SetCornerRadius(entry.CornerRadius *
handler.Context.Resources.DisplayMetrics.Density);
handler.PlatformView.Background = drawable;
}
}// 4. In MauiProgram.cs registrieren
builder.ConfigureMauiHandlers(handlers =>
{
handlers.AddHandler<CustomEntry, CustomEntryHandler>();
});Der entscheidende Unterschied zum alten Renderer-Modell: Beim Handler gibt es kein übergeordnetes Layout-Element mehr. Das reduziert die View-Hierarchie und verbessert die Rendering-Performance messbar — gerade bei komplexen Listen mit vielen Custom Controls ein echter Gewinn.
Schritt 6: Plattformspezifischen Code anpassen
In Xamarin.Forms war plattformspezifischer Code in separaten Projekten untergebracht. In .NET MAUI haben Sie dafür die Platforms-Ordnerstruktur und mehrere Ansätze.
Conditional Compilation
public string GetPlattformName()
{
#if ANDROID
return "Android";
#elif IOS
return "iOS";
#elif MACCATALYST
return "macOS";
#elif WINDOWS
return "Windows";
#else
return "Unbekannt";
#endif
}Partial Classes
Für umfangreicheren plattformspezifischen Code sind Partial Classes der deutlich sauberere Weg. Erstellen Sie einfach eine Datei pro Plattform:
// Services/NativeService.cs (gemeinsame Schnittstelle)
public partial class NativeService
{
public partial string GetDeviceInfo();
}
// Platforms/Android/Services/NativeService.cs
public partial class NativeService
{
public partial string GetDeviceInfo()
=> $"Android {Android.OS.Build.VERSION.Release}";
}
// Platforms/iOS/Services/NativeService.cs
public partial class NativeService
{
public partial string GetDeviceInfo()
=> $"iOS {UIKit.UIDevice.CurrentDevice.SystemVersion}";
}Xamarin.Essentials ist jetzt integriert
Ein häufiger Stolperstein, der immer wieder auftaucht: In .NET MAUI ist Xamarin.Essentials direkt integriert. Kein separates NuGet-Paket nötig. Entfernen Sie einfach alle using Xamarin.Essentials;-Direktiven — die APIs leben jetzt unter Microsoft.Maui.ApplicationModel, Microsoft.Maui.Devices, Microsoft.Maui.Storage und so weiter.
Schritt 7: App-Einstiegspunkt und Dependency Injection einrichten
In Xamarin.Forms gab es App.xaml.cs mit MainPage = new NavigationPage(new MainPage()). Das war simpel, aber auch ziemlich limitiert. In .NET MAUI läuft alles über die MauiProgram-Klasse mit dem Builder-Pattern und — endlich — integriertem Dependency Injection:
public static class MauiProgram
{
public static MauiApp CreateMauiApp()
{
var builder = MauiApp.CreateBuilder();
builder
.UseMauiApp<App>()
.ConfigureFonts(fonts =>
{
fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
});
// Services registrieren
builder.Services.AddSingleton<IApiService, ApiService>();
builder.Services.AddSingleton<IDatenbankService, DatenbankService>();
// ViewModels registrieren
builder.Services.AddTransient<MainViewModel>();
builder.Services.AddTransient<DetailViewModel>();
// Views registrieren
builder.Services.AddTransient<MainPage>();
builder.Services.AddTransient<DetailPage>();
return builder.Build();
}
}Der DI-Container löst Abhängigkeiten automatisch über Constructor Injection auf. Ihr ViewModel bekommt die Services direkt im Konstruktor — kein DependencyService.Get<T>() mehr nötig. Wer vorher schon ein DI-Framework wie Autofac oder TinyIoC benutzt hat, kann das jetzt komplett ersetzen.
Schritt 8: Testen und CI/CD-Pipeline aktualisieren
Die Migration ist fast geschafft — aber bitte überspringen Sie diesen Schritt nicht. Nach der Migration müssen Sie Ihre App gründlich testen und Ihre Build-Pipeline an die neue Struktur anpassen.
Manuelle Testcheckliste
- App startet auf allen Zielplattformen ohne Absturz
- Navigation zwischen allen Seiten funktioniert
- Datenbindungen zeigen korrekte Werte
- Plattformspezifische Features (Kamera, GPS, Push-Benachrichtigungen) funktionieren
- Performance-Messwerte liegen auf dem Niveau der Xamarin-App oder besser
GitHub Actions für .NET MAUI 10
Ihre alte Xamarin-CI/CD-Pipeline wird mit .NET MAUI 10 definitiv nicht mehr funktionieren. Hier ein aktuelles GitHub-Actions-Beispiel für den Android-Build:
name: MAUI Android Build
on: [push, pull_request]
jobs:
build-android:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: .NET 10 SDK einrichten
uses: actions/setup-dotnet@v4
with:
dotnet-version: '10.0.x'
- name: MAUI Workload installieren
run: dotnet workload install maui-android
- name: NuGet-Pakete wiederherstellen
run: dotnet restore
- name: Release-Build erstellen
run: dotnet publish -f net10.0-android -c Release
- name: Artefakt hochladen
uses: actions/upload-artifact@v4
with:
name: android-build
path: ./**/publish/*.aabFür iOS-Builds benötigen Sie einen macos-latest Runner mit Xcode 26 und den entsprechenden Signierungszertifikaten. Das Setup ist etwas aufwändiger, aber Apple macht es einem ja auch nie leicht.
Häufige Fehler und deren Lösung
Aus meiner Erfahrung tauchen diese Probleme bei fast jeder Xamarin-zu-MAUI-Migration auf. Sparen Sie sich die Debugging-Zeit und schauen Sie hier zuerst nach.
XFC0000: Cannot resolve type
Ursache: Ein Namespace in einer XAML-Datei wurde nicht aktualisiert. Prüfen Sie, ob wirklich alle XAML-Dateien den neuen Root-Namespace http://schemas.microsoft.com/dotnet/2021/maui verwenden. Eine einzige vergessene Datei reicht aus, um Fehler in der gesamten Lösung auszulösen.
NullReferenceException bei Farben
Die Color-API hat sich geändert, und das ist eine häufige Falle. Wenn Sie NullReferenceException-Fehler bei Controls erhalten, setzen Sie alle Farb-Properties explizit. In .NET MAUI liegt Color unter Microsoft.Maui.Graphics.Color und die vordefinierte Farbpalette unter Microsoft.Maui.Graphics.Colors.
StackLayout-Verhalten hat sich geändert
In .NET MAUI sollten Sie VerticalStackLayout und HorizontalStackLayout statt StackLayout verwenden. Die neuen Varianten sind performanter, weil sie jeweils nur eine Richtung unterstützen und dadurch weniger Layout-Berechnungen durchführen müssen. Ein einfacher Tausch mit großer Wirkung.
RelativeLayout existiert nicht mehr
RelativeLayout wurde in .NET MAUI komplett entfernt. Verwenden Sie Grid als Ersatz — es bietet die gleiche Flexibilität bei deutlich besserer Performance. Ehrlich gesagt war RelativeLayout schon in Xamarin keine gute Idee.
Build-Fehler nach Workload-Update
Wenn nach einem Workload-Update plötzlich nichts mehr kompiliert (ja, das passiert leider), hilft meistens ein vollständiger Reset:
dotnet workload repair
dotnet nuget locals all --clear
dotnet restoreMigrationsstrategie: Alles auf einmal oder inkrementell?
Die richtige Strategie hängt von der Projektgröße ab:
- Kleine Apps (unter 20 Seiten): Eine vollständige Migration in einem Rutsch ist absolut machbar. Erstellen Sie ein neues MAUI-Projekt und kopieren Sie den Code schrittweise hinüber.
- Mittelgroße Apps (20–50 Seiten): Migrieren Sie modulweise. Beginnen Sie mit den Kernmodellen und Services, dann die ViewModels, und zuletzt die Views.
- Große Apps (über 50 Seiten): Planen Sie eine inkrementelle Migration über mehrere Sprints. Nutzen Sie zunächst den Kompatibilitätsmodus für Custom Renderer und migrieren Sie diese schrittweise zu Handlern.
Unabhängig von der Größe gilt: Erstellen Sie vor der Migration einen vollständigen Git-Branch. Committen Sie nach jedem abgeschlossenen Migrationsschritt, damit Sie bei Problemen gezielt zurückrollen können. Das klingt selbstverständlich, wird aber unter Zeitdruck gerne vergessen.
Was Sie nach der Migration gewinnen
Die Mühe lohnt sich. Das ist kein leeres Versprechen — Erfahrungsberichte aus der Community zeigen konsistent:
- Schnellere Startzeiten: Dank NativeAOT-Unterstützung und verbessertem Trimming starten .NET MAUI 10 Apps auf Android bis zu 40 % schneller.
- Kleinere App-Bundles: Die optimierte Kompilierung reduziert die App-Größe um durchschnittlich 25 %.
- Bessere Tooling-Integration: Hot Reload für XAML und C#, integriertes Dependency Injection und der XAML Source Generator in .NET 10 beschleunigen die Entwicklung erheblich.
- Zukunftssicherheit: Mit einem LTS-Release und aktiver Community-Unterstützung sind Sie für die nächsten drei Jahre abgesichert.
Häufig gestellte Fragen
Wie lange dauert die Migration von Xamarin.Forms zu .NET MAUI?
Das hängt stark von der Projektgröße und -komplexität ab. Kleine Apps mit wenigen Custom Renderern und Standard-NuGet-Paketen lassen sich in wenigen Tagen migrieren. Bei großen Enterprise-Apps mit vielen plattformspezifischen Anpassungen sollten Sie mit mehreren Wochen rechnen. Der größte Zeitfresser sind in der Regel inkompatible NuGet-Pakete und Custom Renderer, die zu Handlern umgeschrieben werden müssen.
Kann ich Xamarin-Custom-Renderer in .NET MAUI weiterverwenden?
Ja, über den Kompatibilitätsmodus (UseMauiCompatibility()) können bestehende Renderer mit minimalen Anpassungen weiterverwendet werden. Sie müssen die Namespaces aktualisieren und das ExportRenderer-Attribut entfernen. Allerdings ist dies nur als Übergangslösung gedacht — planen Sie die schrittweise Migration zu Handlern ein.
Muss ich direkt auf .NET MAUI 10 migrieren oder kann ich zunächst .NET 9 verwenden?
.NET 9 wird noch unterstützt, aber .NET 10 ist für neue Migrationen die deutlich bessere Wahl. Als LTS-Release bietet es drei Jahre Support, während .NET 9 als Standard-Release kürzer unterstützt wird. Außerdem profitieren Sie sofort von Features wie dem XAML Source Generator, globalen Namespaces und den verbesserten CollectionView-Handlern.
Was passiert, wenn ein NuGet-Paket keine .NET MAUI Version hat?
Prüfen Sie zunächst, ob der Anbieter eine Roadmap für .NET MAUI veröffentlicht hat. Alternativ suchen Sie nach Community-Forks oder ähnlichen Paketen. Als letzte Option können Sie die benötigte Funktionalität selbst implementieren oder das Feature über einen nativen Handler direkt an die Plattform-APIs anbinden. In der Praxis betrifft das zum Glück immer weniger Pakete.
Funktioniert die Migration auch auf einem Mac ohne Visual Studio 2026?
Ja, die Migration ist auch über die Kommandozeile mit dem .NET CLI möglich. Sie brauchen das .NET 10 SDK und die MAUI-Workloads. Für iOS-Builds ist Xcode 26 erforderlich. Allerdings fehlen Ihnen ohne Visual Studio 2026 der integrierte Copilot Modernization Agent und einige Komfort-Features wie automatische Namespace-Korrekturen. Für erfahrene Entwickler ist das aber kein Showstopper.