Xamarin σε .NET MAUI: Οδηγός 2026

Ενημερώθηκε: 30 Μαΐου 2026

Η μετάβαση από Xamarin.Forms σε .NET MAUI γίνεται με το .NET Upgrade Assistant και απαιτεί τρία βασικά βήματα: αναβάθμιση του αρχείου project σε SDK-style μορφή, αντικατάσταση των Custom Renderers με Handlers, και μετάβαση της εκκίνησης από App.xaml.cs σε MauiProgram.cs. Η Microsoft έχει σταματήσει επίσημα την υποστήριξη του Xamarin.Forms από τις 1 Μαΐου 2024, επομένως κάθε εφαρμογή που ακόμη βασίζεται σε αυτό λειτουργεί χωρίς security patches. Σε αυτόν τον οδηγό περιγράφω βήμα-βήμα τη διαδικασία που έχω εφαρμόσει σε τρία production projects μέσα στο 2025–2026.

Η υποστήριξη του Xamarin.Forms έληξε επίσημα τον Μάιο 2024. Οι εφαρμογές που εξακολουθούν να βασίζονται σε αυτό δεν λαμβάνουν διορθώσεις ασφαλείας.
Το .NET Upgrade Assistant αυτοματοποιεί περίπου το 60–70% της μετάβασης, αλλά οι Custom Renderers απαιτούν χειροκίνητη μετατροπή σε Handlers.
Το νέο SDK-style csproj ενοποιεί iOS, Android, MacCatalyst και Windows σε ένα Multi-Targeted project, αντικαθιστώντας τα ξεχωριστά head projects του Xamarin.
Η εκκίνηση μετακινείται σε MauiProgram.cs με HostBuilder pattern, ενεργοποιώντας πλήρες Dependency Injection out-of-the-box.
Ένα μέσο production project Xamarin.Forms 5.x χρειάζεται 3–8 εβδομάδες για πλήρη μετάβαση, ανάλογα με τον αριθμό των Custom Renderers και των third-party πακέτων.
Στο .NET 10 (Νοέμβριος 2025) το MAUI υποστηρίζει NativeAOT σε iOS, μειώνοντας το μέγεθος του app bundle έως και 35%.

Γιατί πρέπει να μεταφέρετε τώρα την εφαρμογή σας

Ας ξεκινήσουμε με το πιο σημαντικό. Η Microsoft σταμάτησε επίσημα την υποστήριξη του Xamarin.Forms στις 1 Μαΐου 2024. Από τότε δεν εκδίδονται security patches, ούτε bug fixes, ούτε ενημερώσεις για νέες εκδόσεις iOS και Android. Στην πράξη αυτό σημαίνει ότι μια εφαρμογή Xamarin.Forms που υποβάλλεται σήμερα στο App Store ή στο Google Play κινδυνεύει με απόρριψη: το iOS 18 SDK και το Android 15 (API 35) απαιτούν target frameworks που υποστηρίζονται μόνο πλήρως από .NET 9 και .NET 10.

Έχω συμβουλεύσει τρεις πελάτες αυτή την περίοδο που καθυστέρησαν τη μετάβαση και κατέληξαν με επείγουσες, μη προγραμματισμένες ανανεώσεις όταν το Google Play Console απαίτησε target SDK 35 για όλες τις ενημερώσεις από τον Αύγουστο του 2025. Όταν αναγκάζεστε να κάνετε migration κάτω από πίεση deadline, ο κίνδυνος regression τριπλασιάζεται.

Πέρα από την υποχρεωτική συμμόρφωση, η μετάβαση σε MAUI ανοίγει συγκεκριμένες δυνατότητες που δεν υπάρχουν στο Xamarin.Forms: NativeAOT compilation στο iOS, Hot Reload με XAML state preservation, Mac Catalyst ως πρωτογενές target, και ένα ενοποιημένο handler architecture που επιτρέπει cross-platform customization χωρίς custom renderers ανά πλατφόρμα.

Ποιες είναι οι διαφορές μεταξύ Xamarin.Forms και .NET MAUI

Το .NET MAUI είναι η εξέλιξη του Xamarin.Forms, αλλά δεν είναι απλώς rebrand. Η αρχιτεκτονική έχει αναπτυχθεί σχεδόν εξ ολοκλήρου ξανά. Ακολουθεί συγκριτικός πίνακας των πιο σημαντικών αλλαγών που επηρεάζουν τη μετάβαση:

Χαρακτηριστικό	Xamarin.Forms 5.x	.NET MAUI (.NET 10)
Target Framework	netstandard2.0 + heads	net10.0-ios, net10.0-android κ.λπ. σε ένα project
Project Structure	Shared + iOS + Android + UWP heads	Ενιαίο multi-targeted SDK-style project
Cross-platform UI	Custom Renderers ανά πλατφόρμα	Handler architecture (PropertyMapper, CommandMapper)
App Startup	Application class σε κάθε head	MauiProgram.cs με HostBuilder
Dependency Injection	DependencyService ή third-party container	Built-in Microsoft.Extensions.DependencyInjection
Windows Support	UWP (deprecated)	WinUI 3 / Windows App SDK
macOS Support	Πειραματικό	Mac Catalyst επίσημα υποστηριζόμενο
NativeAOT	Όχι	Ναι (Android & iOS από .NET 10)

Η σημαντικότερη αρχιτεκτονική διαφορά είναι η μετάβαση από Renderers σε Handlers. Στο Xamarin.Forms, κάθε control είχε έναν renderer ανά πλατφόρμα που επέκτεινε τη συμπεριφορά του. Αυτό δούλευε, αλλά ήταν βαρύ (ο renderer κρατούσε αναφορά στο control και η αλληλεπίδραση γινόταν μέσω visual element lifecycle). Στο MAUI, οι Handlers είναι ελαφρύτεροι: ορίζονται μέσω PropertyMapper και CommandMapper dictionaries, με αποτέλεσμα ταχύτερη απόκριση και μικρότερη μνήμη.

Προετοιμασία του Xamarin.Forms project πριν τη μετάβαση

Προτού τρέξετε οποιοδήποτε εργαλείο migration, αφιερώστε μία ή δύο μέρες σε προετοιμασία. Στα τρία projects που έχω μεταφέρει, το 40% των προβλημάτων μετά τη μετάβαση οφειλόταν σε χαλαρή βάση πριν ξεκινήσει η διαδικασία.

Πρώτο βήμα: αναβαθμίστε το Xamarin.Forms στην έκδοση 5.0.0.2622 ή νεότερη. Αυτή είναι η τελευταία υποστηριζόμενη έκδοση και διαθέτει APIs σχεδόν ταυτόσημα με το MAUI. Οποιαδήποτε παλαιότερη έκδοση (π.χ. 4.8) θα προσθέσει πολλαπλά breaking changes ταυτόχρονα.

Δεύτερο βήμα: αφαιρέστε το παλιό AppCompat στο Android και χρησιμοποιήστε FormsAppCompatActivity με AndroidX. Επίσης ενεργοποιήστε το AndroidX migration από το NuGet. Εάν το project σας ακόμη βασίζεται στο Android Support Library, το migration θα αποτύχει σιωπηρά.

Τρίτο βήμα: τρέξτε όλα τα unit και UI tests και βεβαιωθείτε ότι περνούν. Η μετάβαση θα αλλάξει πολλά namespace references και θα είναι δύσκολο να διακρίνετε εάν ένα regression προκλήθηκε από τη μετάβαση ή υπήρχε ήδη. Εάν θέλετε να εμβαθύνετε στις στρατηγικές testing μετά τη μετάβαση, διαβάστε τον οδηγό μου για την offline-first αρχιτεκτονική με SQLite και EF Core σε .NET MAUI, ο οποίος καλύπτει testable patterns για data access.

Πώς λειτουργεί το .NET Upgrade Assistant βήμα-βήμα

Το .NET Upgrade Assistant είναι ένα CLI και Visual Studio extension που αυτοματοποιεί το μεγαλύτερο μέρος της μηχανικής εργασίας: μετατροπή του csproj σε SDK-style, ενημέρωση των target frameworks, αντικατάσταση Xamarin namespaces με τα αντίστοιχα Microsoft.Maui.* και προσθήκη του MauiProgram.cs entry point.

Εγκαταστήστε το ως global tool και τρέξτε το πάνω στο shared project:

dotnet tool install -g upgrade-assistant
cd /path/to/MyApp.sln
upgrade-assistant upgrade MyApp.sln

Το εργαλείο θα σας ρωτήσει ποια projects θέλετε να αναβαθμίσετε. Επιλέξτε πρώτα το shared library project (αυτό που περιέχει τα ViewModels και Pages), έπειτα τα head projects (Android, iOS). Για κάθε project, ο assistant εκτελεί μια σειρά steps που αναλαμβάνει συγκεκριμένη μετατροπή.

Μετά την εκτέλεση, ελέγξτε το νέο csproj. Θα δείτε κάτι σαν:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net10.0-android;net10.0-ios;net10.0-maccatalyst</TargetFrameworks>
    <TargetFrameworks Condition="$([MSBuild]::IsOSPlatform('windows'))">
      $(TargetFrameworks);net10.0-windows10.0.19041.0
    </TargetFrameworks>
    <OutputType>Exe</OutputType>
    <UseMaui>true</UseMaui>
    <SingleProject>true</SingleProject>
    <RootNamespace>MyApp</RootNamespace>
    <ApplicationId>com.company.myapp</ApplicationId>
    <ApplicationVersion>1</ApplicationVersion>
    <ApplicationDisplayVersion>1.0</ApplicationDisplayVersion>
  </PropertyGroup>
</Project>

Αυτή η ενιαία δομή αντικαθιστά τα τρία ή τέσσερα ξεχωριστά projects που είχατε στο Xamarin. Όλα τα assets (εικόνες, fonts, splash screens) τοποθετούνται πλέον σε φακέλους Resources/Images, Resources/Fonts, Resources/Raw και μοιράζονται μεταξύ πλατφορμών αυτόματα.

Μετατροπή Custom Renderers σε Handlers

Ειλικρινά, αυτό είναι το βήμα που το Upgrade Assistant δεν μπορεί να αυτοματοποιήσει πλήρως. Εάν η εφαρμογή σας έχει πολλούς custom renderers, υπολογίστε 2–4 ώρες ανά renderer για ποιοτική μετατροπή. Έχω δει εφαρμογές με 20+ renderers και το migration κράτησε εβδομάδες.

Καλά νέα: το MAUI υποστηρίζει compatibility shims που σας επιτρέπουν να τρέξετε υπάρχοντες renderers χωρίς αλλαγές, ως ενδιάμεσο βήμα. Στο MauiProgram.cs προσθέστε:

using Microsoft.Maui.Controls.Compatibility.Hosting;

var builder = MauiApp.CreateBuilder();
builder
    .UseMauiApp<App>()
    .UseMauiCompatibility(); // ενεργοποιεί παλιούς renderers

Αυτό σας δίνει χώρο να ξεκινήσετε το build χωρίς να πρέπει να μετατρέψετε αμέσως όλους τους renderers. Όμως μην το αφήσετε εκεί. Το MauiCompatibility προσθέτει memory overhead και περιορίζει το NativeAOT.

Δείτε ένα τυπικό παράδειγμα μετατροπής. Στο Xamarin είχατε έναν renderer για customized Entry:

// Xamarin.Forms (Android)
public class BorderlessEntryRenderer : EntryRenderer
{
    protected override void OnElementChanged(ElementChangedEventArgs<Entry> e)
    {
        base.OnElementChanged(e);
        if (Control != null)
        {
            Control.Background = null;
            Control.SetPadding(0, 0, 0, 0);
        }
    }
}

Το ίδιο στο MAUI γίνεται με PropertyMapper — δεν χρειάζεται καν ξεχωριστή κλάση ανά πλατφόρμα. Στο MauiProgram.cs:

#if ANDROID
Microsoft.Maui.Handlers.EntryHandler.Mapper.AppendToMapping(
    "BorderlessEntry",
    (handler, view) =>
    {
        if (view is BorderlessEntry)
        {
            handler.PlatformView.Background = null;
            handler.PlatformView.SetPadding(0, 0, 0, 0);
        }
    });
#endif

Το πλεονέκτημα: ο κώδικας ζει μαζί με την υπόλοιπη bootstrap λογική, είναι ευκολότερα testable, και δεν δημιουργεί ξεχωριστή renderer hierarchy. Για βαθύτερη εξήγηση των performance επιπτώσεων του handler architecture, διαβάστε τον οδηγό βελτιστοποίησης απόδοσης σε .NET MAUI.

Από App.xaml.cs σε MauiProgram.cs και Dependency Injection

Στο Xamarin.Forms, η εκκίνηση ξεκινούσε από την κλάση App σε κάθε head project. Στο MAUI, υπάρχει ένα κεντρικό MauiProgram.cs που χρησιμοποιεί τον HostBuilder pattern, με ίδια λογική με ASP.NET Core. Αυτό φέρνει built-in DI, configuration providers και logging χωρίς εξωτερικά πακέτα.

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

        // Dependency Injection
        builder.Services.AddSingleton<IDataService, ApiDataService>();
        builder.Services.AddTransient<MainPageViewModel>();
        builder.Services.AddTransient<MainPage>();

        // HttpClient με Polly retry policies
        builder.Services.AddHttpClient<IApiClient, ApiClient>(client =>
        {
            client.BaseAddress = new Uri("https://api.example.com");
            client.Timeout = TimeSpan.FromSeconds(30);
        });

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

        return builder.Build();
    }
}

Το παλιό DependencyService.Get<T>() εξακολουθεί να δουλεύει μέσω compatibility, αλλά εξαφανίζεται από τα MAUI templates. Αντί γι' αυτό, χρησιμοποιήστε constructor injection στα ViewModels και τα Pages. Εάν η εφαρμογή σας βασίζεται στο Shell navigation με MVVM pattern, η εγγραφή των routes και των ViewModels γίνεται στο ίδιο MauiProgram block.

Διαχείριση NuGet πακέτων και third-party εξαρτήσεων

Αυτό συχνά είναι το πιο αβέβαιο κομμάτι του migration. Πολλά παλιά Xamarin.Forms πακέτα είτε έχουν εγκαταλειφθεί είτε έχουν αντικατασταθεί από MAUI-native equivalents. Πριν ξεκινήσετε, καταγράψτε όλα τα NuGet dependencies και ελέγξτε τη συμβατότητα για κάθε ένα.

Στις περιπτώσεις που έχω συναντήσει, τα ακόλουθα έχουν επιβεβαιωμένα MAUI-ready ισοδύναμα:

Xamarin.Essentials → ενσωματώθηκε στο Microsoft.Maui.Essentials. Τα APIs είναι σχεδόν ταυτόσημα.
Xamarin.Forms.Maps → αντικαταστάθηκε από Microsoft.Maui.Controls.Maps.
FFImageLoading → η Image του MAUI χειρίζεται πλέον caching out-of-the-box, αλλά για advanced σενάρια χρησιμοποιήστε CommunityToolkit.Maui.
Prism.Forms → το Prism.Maui είναι ώριμο και υποστηρίζει IoC, navigation, modules.
SQLite-net-pcl → δουλεύει χωρίς αλλαγές, αλλά το EF Core είναι πλέον πλήρως υποστηριζόμενο σε MAUI.

Για third-party πακέτα που δεν έχουν MAUI version, ελέγξτε εάν το net10.0-android και net10.0-ios ως target functions. Συχνά παλιά Xamarin πακέτα δουλεύουν μέσω compatibility, αλλά χάνετε NativeAOT και τρέχετε σε μεγαλύτερο app size.

Πόσο διαρκεί μια μετάβαση Xamarin σε MAUI

Σε αυτή την παράγραφο μιλάω από προσωπική εμπειρία. Από τα τρία production projects που έχω μεταφέρει, οι χρονικές διάρκειες ήταν: ένα μικρό enterprise app (15 σελίδες, 3 custom renderers) σε 2,5 εβδομάδες, ένα μεσαίο consumer app (40 σελίδες, 12 renderers, 3 effects) σε 6 εβδομάδες, και ένα μεγάλο fintech app (80+ σελίδες, 20+ renderers, native bindings) σε 4 μήνες.

Το breakdown ωρών που χρησιμοποιώ για estimation:

Προετοιμασία (1 εβδομάδα): Xamarin.Forms 5.0.0.2622 upgrade, AndroidX migration, test stabilization.
Upgrade Assistant run και initial build (3–5 ημέρες): Φέρνει την εφαρμογή σε σημείο που compile χωρίς το UI να λειτουργεί ακόμα 100%.
Renderers σε Handlers (2 ώρες ανά απλό renderer, έως 8 ώρες ανά complex): Το μεγαλύτερο ποσοστό χρόνου.
Platform-specific code review (1 εβδομάδα): #if conditionals, native bindings, podfiles.
Regression testing και bug fixing (2–4 εβδομάδες): Visual regressions, gesture differences, performance tuning.

Σχεδιάστε feature freeze πριν ξεκινήσει το migration. Έχω δει teams να προσπαθούν να συνεχίσουν parallel feature development στο Xamarin codebase ενώ το MAUI migration προχωράει — το merging γίνεται εφιαλτικό και προσθέτει 30–50% στο συνολικό χρόνο.

Συνηθισμένα λάθη και πώς να τα αποφύγετε

Έχω συγκεντρώσει πέντε λάθη που έχω δει να επαναλαμβάνονται:

1. Big-bang migration χωρίς incremental verification. Πολλά teams τρέχουν Upgrade Assistant και προσπαθούν να φτάσουν σε green build από την πρώτη μέρα. Αντί γι' αυτό, χρησιμοποιήστε MauiCompatibility shims για να βάλετε την εφαρμογή σε λειτουργικό state νωρίς, και έπειτα μετατρέψτε renderers ένα-ένα.

2. Παράλειψη iOS-specific testing. Πολλές διαφορές handler behavior εμφανίζονται μόνο στο iOS (π.χ. το Entry handler έχει διαφορετική keyboard handling, και το CollectionView έχει διαφορετική scroll inertia). Δοκιμάστε σε πραγματική συσκευή, όχι μόνο σε simulator.

3. Μη ενημέρωση του Info.plist και AndroidManifest. Το νέο MAUI single project format συγχωνεύει manifest entries μέσω MauiAsset και MauiSplashScreen. Παλιά custom entries μπορεί να χαθούν σιωπηρά εάν δεν τα μετακινήσετε.

4. Αγνόηση των analyzers. Το MAUI SDK περιλαμβάνει νέους Roslyn analyzers (XC0045, MAUI0001 κ.λπ.) που πιάνουν binding errors at compile time. Πολλοί developers τους αγνοούν επειδή τα XAML αρχεία τους έχουν legacy patterns. Αλλά αυτά τα warnings συνήθως δείχνουν πραγματικά bugs.

5. Σύγχυση μεταξύ Compatibility namespace και MAUI namespace. Το Microsoft.Maui.Controls.Compatibility περιέχει τα παλιά Xamarin-style APIs. Όταν τα αφήσετε ανακατεμένα με τα modern MAUI APIs, παίρνετε type collisions και runtime exceptions που είναι δύσκολο να εντοπιστούν. Αφαιρέστε όλα τα Compatibility usings μόλις δεν τα χρειάζεστε.

Συχνές ερωτήσεις

Μπορώ να μεταφέρω αυτόματα Xamarin.Forms σε .NET MAUI;

Όχι πλήρως. Το .NET Upgrade Assistant αυτοματοποιεί περίπου το 60–70% της μετάβασης, κυρίως το csproj, τα namespaces και τη βασική δομή. Τα Custom Renderers, τα native bindings και τα platform-specific projects απαιτούν χειροκίνητη εργασία.

Είναι το .NET MAUI καλύτερο από το Xamarin.Forms;

Ναι, σε όλους τους τομείς. Το MAUI έχει ταχύτερο rendering μέσω handler architecture, υποστηρίζει NativeAOT για μικρότερα app sizes, ενσωματώνει modern .NET 10 features όπως built-in DI, και είναι το μόνο officially supported framework. Το Xamarin έχει σταματήσει υποστήριξη από το 2024.

Πόσο κοστίζει η μετάβαση από Xamarin σε MAUI;

Εξαρτάται από το μέγεθος του project. Για μικρές εφαρμογές με λίγους renderers, μιλάμε για 2–3 εβδομάδες developer time. Για μεσαίες εφαρμογές 4–8 εβδομάδες, και για μεγάλα enterprise apps με native bindings 3–6 μήνες.

Τι θα συμβεί εάν δεν μεταφέρω την εφαρμογή μου;

Η εφαρμογή θα συνεχίσει να τρέχει για χρήστες που την έχουν ήδη εγκαταστήσει, αλλά δεν θα μπορείτε να την ενημερώσετε στα app stores εάν αυτά απαιτήσουν νεότερα target SDKs. Επίσης δεν θα λαμβάνετε security patches, κάτι ιδιαίτερα κρίσιμο για apps που χειρίζονται προσωπικά ή οικονομικά δεδομένα.

Υποστηρίζει το .NET MAUI το Windows;

Ναι, μέσω WinUI 3 και Windows App SDK. Αυτό αντικαθιστά τη χαλαρή UWP υποστήριξη του Xamarin.Forms. Σημειώστε ότι ο Windows builds απαιτεί Visual Studio σε Windows machine, οπότε δεν μπορείτε να κάνετε Windows build από Mac.