Migracja z Xamarina: .NET MAUI czy Flutter, gdy masz własny zespół .NET

Najkrócej: MAUI, gdy chcesz zostać przy C# i masz kim to robić. Flutter, gdy aplikacja potrzebuje nowego interfejsu i ma się rozwijać przez kolejne lata. W obu przypadkach zacznij od audytu, bo dopiero kod pokaże, ile da się przenieść.

Czy Xamarin jest jeszcze wspierany?

Nie. Microsoft zakończył wsparcie wszystkich SDK Xamarina, razem z Xamarin.Forms, 1 maja 2024 roku. Od tego dnia nie ma poprawek ani łatek bezpieczeństwa, a ostatnie wersje, w które celuje Xamarin, to Xcode 15 i Android API 34.

Przez prawie dwa lata dało się z tym żyć. W 2026 roku sklepy zamknęły tę furtkę. Aplikacja dalej działa u ludzi, którzy ją mają, ale z projektu w Xamarinie nie wyślesz już zwykłej aktualizacji: ani poprawki błędu, ani nowej funkcji.

Ile masz czasu na migrację z Xamarina?

Mniej, niż się wydaje, bo większość terminów już minęła. Tak wygląda kalendarz na koniec października 2026:

W skrócie: aplikacja nie zniknie jutro ze sklepów, ale jest zamrożona. Każda nowa wersja iOS i Androida to ryzyko, na które nie odpowiesz już aktualizacją.

Co zostaje z pracy twojego zespołu .NET?

Więcej, niż się obawiasz, ale w każdej drodze co innego. Najczęstszy błąd w tej decyzji to założenie, że Flutter wyrzuca do kosza cały dorobek zespołu C#. Zwykle tak nie jest, bo duża część tego dorobku to backend.

Microsoft pisze wprost, że przy przejściu na .NET projekty z Xamarina nie muszą być przepisywane, ale muszą przejść na nowy format projektu (SDK-style). Przy Xamarin.Forms pomaga narzędzie .NET Upgrade Assistant, choć według samego Microsoftu po jego uruchomieniu aplikacja w większości przypadków i tak wymaga dodatkowej pracy.

Jedna rzecz do kalendarza zespołu .NET: dokumentacja .NET MAUI 11 podaje, że pakiet zgodności Microsoft.Maui.Controls.Compatibility nie jest już w tej wersji wydawany. Renderery, które na nim stoją, trzeba przenieść na handlery przed podbiciem wersji. Migracja do MAUI to więc nie jeden projekt, tylko początek corocznych aktualizacji.

.NET MAUI czy Flutter: co wybrać przy migracji z Xamarina?

To zależy od dwóch rzeczy: kto będzie rozwijał aplikację przez następne lata i czy jej interfejs jeszcze się broni.

Wybierz .NET MAUI, gdy:

• masz w firmie zespół C#, który zna tę aplikację i ma ją dalej rozwijać,
• interfejs działa i nie planujesz jego przebudowy,
• aplikacja ma przede wszystkim dalej wychodzić w sklepach, a nie szybko rosnąć,
• akceptujesz podbicie wersji MAUI mniej więcej raz w roku: MAUI 9 straciło wsparcie 12 maja 2026, MAUI 10 straci je 11 maja 2027.

Wybierz Fluttera, gdy:

• interfejs się zestarzał, więc ekrany i tak trzeba by zaprojektować od nowa,
• twój zespół .NET to ludzie od backendu, a nie od aplikacji mobilnych,
• aplikacja ma dostawać nowe funkcje co tydzień przez lata,
• chcesz jednego kodu na iOS i Androida, z opcją webu i desktopu, w otwartym frameworku od Google.

Jest też trzecia droga, Uno Platform: open source na licencji Apache 2.0, C# i XAML, a aplikacja działa na iOS, Androidzie, w przeglądarce, na Windowsie, macOS i Linuksie. Ma sens, gdy częścią produktu jest aplikacja na Windowsa.

Nie zawsze polecamy Fluttera. Jeśli masz mocny zespół C#, a aplikacja ma po prostu dalej działać, MAUI może kosztować mniej. Mówimy to w audycie, kiedy tak jest.

Jak przejść z Xamarina na Fluttera bez wyłączania aplikacji?

Nowa aplikacja wychodzi jako zwykła aktualizacja tej samej karty w sklepie. Użytkownik widzi nową wersję w App Store albo Google Play, aktualizuje i loguje się na to samo konto.

• Krok 1Audyt: kod, awarie, stan w sklepach i backend
• Krok 2Plan: ekrany, etapy i stała cena każdego etapu
• Krok 3Budowa ekran po ekranie, nowa wersja co tydzień
• Krok 4Testy w TestFlight i na ścieżkach testowych Google Play
• Krok 5Wydanie etapowe jako aktualizacja tej samej aplikacji

O powodzeniu decydują trzy szczegóły. Ten sam bundle ID na iOS. Ta sama nazwa pakietu i ten sam klucz podpisu na Androidzie, bo Android zainstaluje aktualizację tylko wtedy, gdy certyfikaty się zgadzają. I ten sam backend, dzięki któremu konta i dane są tam, gdzie były. Dane trzymane wyłącznie na telefonie wymagają osobnego kroku, a audyt je wypisuje.

W Google Play wdrożenie etapowe też trafia najpierw do części użytkowników i można je wstrzymać. Przez cały ten czas stara wersja działa u tych, którzy jeszcze nie zaktualizowali.

Jak wygląda taka migracja w dużej aplikacji?

Najlepiej pokazuje to Fitatu, licznik kalorii z ponad 10 milionami użytkowników. Aplikacja stała na Cordovie, nie na Xamarinie, ale zadanie było to samo: przenieść działający produkt na Fluttera, nie wyłączając go ani na dzień. Pełna historia jest w realizacji Fitatu (po angielsku).

• Najpierw jedna osoba. Daliśmy doświadczonego team leadera, który prowadził przejście z Cordovy na Fluttera.
• Flutter wewnątrz starej aplikacji. Na początku połączyliśmy Fluttera z Cordovą własnymi wtyczkami, więc nowe ekrany działały w starej aplikacji.
• Decyzja po 8 miesiącach. CTO Fitatu zdecydował o pełnym przejściu, a my dołożyliśmy trzech kolejnych developerów Fluttera.
• Natywne widżety. Przy okazji zbudowaliśmy natywne widżety w Swifcie i Kotlinie.
• Efekt. 99,7% sesji bez awarii po przepisaniu.

Przy Xamarinie punkt styku jest inny. Flutter oficjalnie wchodzi do aplikacji w Kotlinie, Javie, Swifcie i Objective-C, a Xamarina na tej liście nie ma. Dlatego nową aplikację budujemy obok starej i podmieniamy ją w sklepie: ta sama karta, ten sam backend, wydanie etapowe. Metoda z Fitatu zostaje, zmienia się tylko miejsce przełączenia.

Przenosi się też model pracy. W Fitatu decyzje podejmował ich CTO, a my dokładaliśmy ludzi. Jeśli masz zespół .NET, nasi developerzy Fluttera mogą do niego dołączyć w ramach wzmocnienia zespołu: 200 zł/h netto, minimum 120 h miesięcznie, 2 tygodnie wypowiedzenia.

Ile kosztuje migracja z Xamarina?

Pierwszy wydatek to audyt aplikacji: 17 500-28 000 zł netto. Kończy się planem z ceną każdego etapu, więc kwotę za całość znasz, zanim ktokolwiek przebuduje pierwszy ekran.

Ostateczna cena przepisania zależy od liczby ekranów, integracji i tego, ile backendu zostaje bez zmian. Płacisz stałą cenę za etap, fakturę dostajesz za każdy odebrany etap i po każdym możesz się zatrzymać. Aplikacja, którą budujemy, ma 6 miesięcy gwarancji.

W umowie pilnuj dwóch rzeczy: przeniesienia autorskich praw majątkowych do nowego kodu na piśmie, z wymienionymi polami eksploatacji, i kont w sklepach na twoją firmę. Co jeszcze sprawdza audyt, opisaliśmy w tekście audyt aplikacji mobilnej przed przejęciem. Pełne ceny są w cenniku Codigee, a o pracy z firmami, które mają już aplikację, piszemy na stronie dla firm.