Migracja z Xamarina, Cordovy i Ionica — co naprawdę grozi aplikacji i dokąd ją przenieść

Aplikacja napisana kilka lat temu w Xamarinie, Cordovie albo Ionicu często działa bez zarzutu. Użytkownicy z niej korzystają, backend odpowiada, nikt nie widzi powodu do zmian. Kłopot pojawia się, gdy trzeba wydać nową wersję: poprawić błąd, dodać funkcję albo spełnić kolejny wymóg sklepu.

Te trzy technologie często trafiają do jednego worka, a ich sytuacja jest różna. Xamarin nie ma już wsparcia. Cordova jest rozwijana, ale ryzyko siedzi we wtyczkach. Ionic Framework żyje dalej, za to kończą się jego płatne usługi. Od tego zależy, czy migrację trzeba zacząć teraz i jak duża będzie.

Xamarin: nowej wersji do sklepów już nie wydasz

Microsoft zakończył wsparcie wszystkich SDK Xamarina, także Xamarin.Forms, 1 maja 2024 roku. Ostatnie wersje, w które Xamarin celuje, to Android API 34 i Xcode 15. Wymagania sklepów poszły od tego czasu dalej:

Aplikacja nie znika z telefonów. Kto ją zainstalował, może z niej korzystać dalej. Właśnie dlatego sytuacja jest zdradliwa: wszystko wygląda dobrze do dnia, w którym trzeba wydać pilną poprawkę, bo zmieniło się API dostawcy płatności albo wyszła luka bezpieczeństwa. Wtedy okazuje się, że ścieżki wydania nie ma, a migracja zaczyna się pod presją czasu. Więcej o skutkach terminu w Google Play piszemy w tekście o tym, dlaczego aplikacja znika ze sklepu po terminie target API.

W przypadku Xamarina pytanie nie brzmi więc „czy migrować”, tylko „dokąd i kiedy”.

Cordova: projekt żyje, ryzyko siedzi we wtyczkach

Cordova wbrew obiegowej opinii nie jest martwa. cordova-android 15 z marca 2026 podniosła docelowy SDK do 36, a cordova-ios dostała wydanie 8.1.1 w lipcu 2026. Sam framework nie zmusza więc do ucieczki. Często wystarczy podnieść platformy do aktualnych wersji.

Problemem są wtyczki, bo to one zawierają kod natywny i to od nich zależą logowanie, płatności, powiadomienia czy aparat. Część z nich od lat nie ma nowych wydań. Najbliższy test to strony pamięci 16 KB: od 1 lutego 2027 Google Play nie przyjmie aktualizacji, które ich nie obsługują. Cordova sama nie zawiera bibliotek natywnych, ale wtyczki mogą je wnosić, a biblioteki .so skompilowane ze starym wyrównaniem blokują wydanie.

Sprawdzisz to na zbudowanej paczce: APK Analyzer w Android Studio pokazuje problemy w kolumnie Alignment, a to samo potwierdza polecenie zipalign -c -P 16 -v 4 aplikacja.apk. Jeśli kluczowa wtyczka nie przechodzi testu i nikt jej nie rozwija, zostają trzy opcje: własny fork, zamiennik albo migracja.

Ionic: framework zostaje, płatne usługi się kończą

Tutaj trzeba rozdzielić dwie rzeczy. Ionic Framework i Capacitor pozostają otwarte i są dalej utrzymywane. Koniec dotyczy produktów komercyjnych. Appflow (budowanie i aktualizacje na żywo) będzie dostępny do 31 grudnia 2027, a sprzedaż Identity Vault, Auth Connect, Secure Storage i Ionic Portals została zakończona i ich utrzymanie jest stopniowo wygaszane. Jeśli Twój proces wydań albo logowanie opiera się na którymś z nich, potrzebujesz planu zastępczego, nawet gdy reszta aplikacji jest w dobrym stanie.

Osobna kategoria to najstarsze projekty na Ionicu 1. Działają na AngularJS, którego wsparcie skończyło się z końcem 2021 roku, więc w praktyce warstwę interfejsu i tak trzeba napisać od nowa.

Dokąd przenieść aplikację

Najkrótsza droga prowadzi zwykle do następcy tej samej technologii. Nie zawsze jest jednak najlepsza.

.NET MAUI i .NET for Android/iOS. Microsoft podkreśla, że projektów nie trzeba przepisywać, ale muszą przejść na format SDK-style, a narzędzie do aktualizacji zwykle nie kończy pracy: według dokumentacji w większości przypadków potrzebny jest dodatkowy nakład. Własne renderery z Xamarin.Forms można przejściowo zachować, ale docelowo przenosi się je na model handlerów, a biblioteki bez wersji na .NET trzeba zastąpić. Paczki NuGet z własnymi bibliotekami .so mogą też nadal blokować wymóg 16 KB, nawet jeśli sam framework go spełnia.

Warto też policzyć koszt dalszego utrzymania. MAUI ma krótki cykl: wersja dostaje wsparcie co najmniej przez 6 miesięcy po wydaniu następczyni, a obecnie wspierana MAUI 10 ma termin 11 maja 2027. Coroczna aktualizacja musi więc znaleźć się w budżecie.

Capacitor. To najłagodniejsze wyjście z Cordovy. Kod webowy zostaje, identyfikator aplikacji przechodzi z config.xml, a Capacitor może przez pewien czas działać obok wtyczek Cordovy. Oficjalny przewodnik zaleca zacząć od przeglądu wtyczek: część okaże się zbędna, część ma odpowiedniki, choć nie zawsze o tym samym zakresie funkcji. Capacitor 8 wymaga Xcode 26, Android Studio 2025.2.1 i Node 22, więc środowisko budowania też trzeba podnieść.

Flutter lub aplikacje natywne. To już przepisanie interfejsu, a kod w C# czy JavaScripcie nie przejdzie wprost. Taka decyzja ma sens, gdy obecna technologia ogranicza produkt, nikt nie chce jej dalej utrzymywać albo i tak planujesz przebudowę. Pomocne będą nasze teksty: porównanie Fluttera, React Native i Kotlin Multiplatform oraz jak na liczbach zdecydować: refactor czy przepisanie od zera.

Wybór sprowadza się zwykle do trzech pytań. Kto będzie utrzymywał aplikację za dwa lata i w jakim języku pracuje? Ile kodu da się faktycznie zachować? Czy obecna technologia przeszkadza użytkownikom, czy tylko programistom?

Co musi przetrwać migrację

Użytkownik nie powinien zauważyć zmiany technologii. Najczęściej psują się te elementy:

• Identyfikator i podpis aplikacji. Ten sam applicationId i bundle ID oraz właściwy klucz podpisujący sprawiają, że nowa wersja jest aktualizacją. Bez tego powstaje nowa aplikacja: bez użytkowników, ocen i historii. Jak uporządkować klucze i konta, opisujemy w tekście o przenoszeniu aplikacji na inne konto.
• Dane na urządzeniu. Bazy SQLite, tokeny logowania i ustawienia muszą zostać odczytane po aktualizacji. W aplikacjach WebView znaczenie ma nawet schemat adresu: gdy aplikacja Ionic przechodzi z Cordovy na Capacitora, iOS domyślnie używa innego, co może skasować dane z LocalStorage, dlatego przewodnik zaleca ustawić server.iosScheme na ionic.
• Powiadomienia i linki. Trzeba sprawdzić rejestrację tokenów push, otwieranie aplikacji z powiadomienia, Universal Links i App Links.
• Płatności i subskrypcje. Identyfikatory produktów zostają, ale nowa biblioteka musi poprawnie rozpoznać zakupy już aktywne, także przy przywracaniu.
• Uprawnienia. Capacitor ustawia własny zestaw domyślny, więc to, co dotąd dodawały wtyczki, trzeba przenieść ręcznie.

Pierwsze wydanie po migracji powinno wyglądać i działać jak poprzednie. Nowe funkcje mogą poczekać. Wydaj je stopniowo przez staged rollout w Google Play i phased release w App Store, obserwując awarie, zanim wersja trafi do wszystkich.

Ile to trwa

Na czas pracy wpływają przede wszystkim liczba wtyczek, ilość własnego kodu natywnego i stan projektu, a dopiero potem liczba ekranów. Orientacyjnie:

To widełki, a nie wycena. Dokładniejszą liczbę da się podać po przejrzeniu projektu, jego zależności i procesu wydań.

Od czego zacząć

1. Zabezpiecz dostępy. Repozytorium, konta w sklepach, klucze podpisujące, usługi zewnętrzne. Pomocna będzie checklista przejęcia projektu po innym wykonawcy.
2. Zbuduj obecną wersję. Nawet jeśli wymaga to starego systemu i narzędzi, potrzebujesz punktu odniesienia. To też najszybszy sposób, by sprawdzić, czy masz kompletny kod.
3. Sprawdź ostrzeżenia w Play Console i aktualne wymagania Apple. Pokażą, jak blisko jest blokada.
4. Spisz wtyczki i biblioteki. Przy każdej zaznacz: zostaje, do zastąpienia albo do usunięcia. Ta lista wyznacza większość kosztu migracji.
5. Spisz kluczowe ścieżki. Logowanie, płatności, powiadomienia, najważniejsze ekrany. Po tej liście przetestujesz nową wersję, także gdy projekt nie ma testów automatycznych.
6. Dopiero wtedy wybierz kierunek. Decyzja podjęta bez tej wiedzy często kończy się albo niepotrzebnym przepisaniem, albo migracją, która zatrzymuje się na pierwszej wtyczce.

Im wcześniej to zrobisz, tym więcej masz opcji. Bez presji pilnej poprawki można spokojnie porównać drogi i wydać nową wersję etapami.

Pracujemy w Kotlinie, Swifcie i Flutterze i pomagamy właścicielom starszych aplikacji odzyskać możliwość ich wydawania — przez reaktywację aplikacji albo przejęcie aplikacji mobilnej od poprzedniego wykonawcy. Jeśli nie wiesz, jak pilna jest migracja w Twoim przypadku, zamów bezpłatną analizę aplikacji — wynik dostaniesz na piśmie.