Modernizacja aplikacji mobilnej — migracja do Jetpack Compose i SwiftUI bez przepisywania wszystkiego

„Trzeba by to przepisać na Compose” — jeśli masz aplikację na Androida starszą niż kilka lat, prawdopodobnie usłyszałeś to od programisty. Po stronie iOS to samo zdanie brzmi „trzeba przejść na SwiftUI”. Zwykle pada przy wycenie nowej funkcji, która z jakiegoś powodu kosztuje dwa razy więcej, niż się spodziewałeś.

Migracja interfejsu do Jetpack Compose i SwiftUI to dziś najczęstsza forma modernizacji aplikacji mobilnej. Dobra wiadomość: nie wymaga przepisania aplikacji od zera ani wstrzymania rozwoju na pół roku. Zła: źle zaplanowana potrafi ciągnąć się latami i zostawić projekt z dwoma sposobami budowania ekranów zamiast jednego. W tym tekście pokazujemy, kiedy migracja ma sens, jak ją przeprowadzić stopniowo i ile to realnie kosztuje.

O co właściwie chodzi

Oba systemy mają dwa sposoby budowania interfejsu:

• Android: klasyczne widoki opisywane w plikach XML (View system) i nowszy Jetpack Compose, w którym interfejs opisuje się w kodzie Kotlin.
• iOS: UIKit, na którym powstała większość aplikacji do mniej więcej 2020 roku, i nowszy SwiftUI.

Nowe podejścia są deklaratywne: zamiast ręcznie aktualizować każdy element ekranu, opisujesz, jak ekran ma wyglądać dla danego stanu, a resztą zajmuje się framework. W praktyce oznacza to mniej kodu, mniej błędów typu „przycisk się nie odświeżył” i szybsze budowanie typowych ekranów.

Warto od razu rozwiać jeden mit: ani widoki XML, ani UIKit nie są przestarzałe w sensie technicznym. Google i Apple nadal je wspierają, a aplikacja na starszej technologii będzie działać. Kierunek jest jednak jednoznaczny — nowe komponenty, przykłady w dokumentacji i narzędzia powstają przede wszystkim dla Compose i SwiftUI.

Kiedy migracja ma sens (a kiedy nie)

Migracja się opłaca, gdy aplikacja będzie dalej rozwijana. Wtedy każdy nowy ekran w nowej technologii jest szybszy do zbudowania i tańszy w utrzymaniu, a różnica kumuluje się z każdym miesiącem. Konkretne sygnały:

• Nowe funkcje trwają nieproporcjonalnie długo, bo każdy ekran wymaga dużo powtarzalnego kodu (adaptery list, ręczne odświeżanie widoków, rozbudowane pliki XML).
• Masz problem z rekrutacją lub wdrożeniem nowych osób. Młodsi programiści Androida uczą się dziś przede wszystkim Compose, a iOS — SwiftUI. Stary kod zaczyna być barierą wejścia.
• Planujesz odświeżenie wyglądu aplikacji. Jeśli i tak przebudowujesz ekrany pod nowy design, zrobienie tego od razu w nowej technologii kosztuje niewiele więcej.
• Aplikacja musi dobrze działać na tabletach i składanych telefonach. Nowe wersje Androida coraz mocniej wymuszają obsługę różnych rozmiarów ekranu, a w Compose buduje się takie układy znacznie łatwiej — więcej o tym w tekście o tym, co się zmieniło w nowym Androidzie i iOS.

Migracja nie ma sensu, gdy:

• aplikacja jest w trybie „utrzymać przy życiu” i poza aktualizacjami systemowymi nic się w niej nie zmienia;
• produkt ma zostać wygaszony albo zastąpiony w ciągu roku–dwóch;
• głównym problemem jest coś innego — np. niestabilny backend, brak testów czy chaos w architekturze. Nowy interfejs na złych fundamentach to ten sam problem w ładniejszym opakowaniu. W takiej sytuacji zacznij od rozpoznania długu technicznego.

Migracja stopniowa: stary i nowy kod obok siebie

Najważniejsza informacja dla właściciela produktu: nie trzeba migrować wszystkiego naraz. Oba frameworki zostały zaprojektowane tak, żeby stary i nowy kod mogły współistnieć w jednej aplikacji:

• na Androidzie komponent Compose można osadzić w istniejącym ekranie XML (ComposeView), a stary widok wewnątrz ekranu Compose (AndroidView);
• na iOS ekran SwiftUI umieszcza się w aplikacji UIKit przez UIHostingController, a istniejące komponenty UIKit wewnątrz SwiftUI przez UIViewRepresentable.

Dzięki temu migracja może iść równolegle z rozwojem produktu. Użytkownik nie widzi, który ekran jest w jakiej technologii, a zespół nie musi zamrażać nowych funkcji. To ta sama idea, którą opisywaliśmy przy okazji decyzji refactor czy przepisać od zera — stopniowe zastępowanie starego kodu nowym zamiast jednego wielkiego skoku.

Plan migracji krok po kroku

1. Fundamenty: motyw i komponenty bazowe

Zanim powstanie pierwszy nowy ekran, trzeba przenieść system projektowy: kolory, typografię, odstępy i najczęściej używane komponenty (przyciski, pola formularzy, karty, nagłówki). Bez tego każdy migrowany ekran będzie trochę inny, a po roku aplikacja wygląda jak sklejona z dwóch projektów. To etap, który najczęściej się pomija — i najczęściej żałuje.

2. Testy zrzutów ekranu przed zmianami

Migracja interfejsu to zmiana, której nie widać w testach logiki biznesowej. Zanim zaczniesz przepisywać ekran, zrób testy porównujące zrzuty ekranu (na Androidzie np. Paparazzi lub Roborazzi, na iOS biblioteka snapshot testing). Po migracji porównujesz obraz przed i po — różnica w odstępie o kilka pikseli wychodzi od razu, a nie w recenzji od klienta.

3. Nowe ekrany od razu w nowej technologii

Od dnia zero każdy nowy ekran powstaje w Compose lub SwiftUI. To najtańsza część migracji, bo nie trzeba niczego przepisywać — i najszybciej pokazuje zespołowi, czy nowe podejście przyspiesza pracę.

4. Stare ekrany przy okazji

Istniejące ekrany migruje się wtedy, gdy i tak trzeba je zmienić — przy nowej funkcji, poprawce błędu czy zmianie wyglądu. Dodatkowy koszt migracji rozkłada się wtedy na normalną pracę i jest znacznie niższy niż w osobnym projekcie. Kolejność warto ustalić według dwóch kryteriów: jak często ekran się zmienia i jak bardzo jest problematyczny.

5. Nawigacja na końcu

Nawigacja między ekranami to kręgosłup aplikacji. Przepięcie jej na nowe rozwiązanie ma sens dopiero wtedy, gdy większość ekranów jest już zmigrowana. Zrobiona za wcześnie oznacza ciągłe przełączanie się między światami i dużo kodu pośredniego.

Pułapki, o których warto wiedzieć

• Minimalna wersja systemu na iOS. Możliwości SwiftUI mocno zależą od wersji iOS — nowoczesna nawigacja wymaga iOS 16, a nowy model obserwowania danych iOS 17. Jeśli aplikacja musi działać na iOS 15 lub starszym, migracja jest trudniejsza i mniej opłacalna. Warto sprawdzić w statystykach, ilu użytkowników faktycznie ma tak stare telefony — często jest to ułamek procenta.
• Wydajność długich list. Źle napisane listy w Compose i SwiftUI potrafią przerysowywać się bez potrzeby. To nie wada frameworka, tylko brak doświadczenia — ale objawia się przycinaniem przy przewijaniu, które użytkownik widzi od razu.
• Dwa style w jednym projekcie na zawsze. Najgorszy scenariusz to migracja zaczęta z entuzjazmem i porzucona w połowie. Dlatego potrzebny jest plan z kolejnością ekranów i decyzja, co jest „wystarczająco zmigrowane”. Nie każdy ekran trzeba przepisać — rzadko używany ekran ustawień może spokojnie zostać w starej technologii.
• Aktualizacja reszty projektu. Compose i nowe wersje SwiftUI wymagają aktualnych narzędzi: Kotlina, Gradle, Xcode. Jeśli projekt stał w miejscu przez lata, pierwszym krokiem migracji jest aktualizacja środowiska — i to ona bywa najbardziej nieprzewidywalna.

Ile to kosztuje

Koszt zależy od liczby ekranów, ich złożoności i stanu projektu, więc poniższe widełki traktuj orientacyjnie — jako punkt wyjścia do rozmowy, a nie wycenę:

Dla aplikacji z 30–40 ekranami pełna migracja jednej platformy to zwykle od dwóch do czterech miesięcy pracy jednej osoby. Przy migracji „przy okazji” duża część tego kosztu i tak zostałaby poniesiona na modyfikacje ekranów — realny dodatkowy wydatek jest więc wyraźnie niższy niż suma z tabeli. Jeśli nie wiesz, w jakim stanie jest projekt, rozsądnie jest zacząć od krótkiego audytu kodu, który odpowie, czy migracja jest dobrym pierwszym krokiem.

Podsumowanie

Migracja do Jetpack Compose i SwiftUI to modernizacja, która zwraca się wtedy, gdy aplikacja ma przed sobą lata rozwoju. Najlepiej przeprowadzić ją stopniowo: najpierw fundamenty i testy zrzutów ekranu, potem nowe ekrany w nowej technologii, stare przy okazji zmian, a nawigację na końcu. Dzięki temu produkt rozwija się bez przerwy, a koszt migracji rozkłada się na zwykłą pracę.

Modernizację aplikacji — od audytu i planu migracji po jej przeprowadzenie — realizujemy w ramach utrzymania aplikacji mobilnych albo jako wsparcie Twojego zespołu, gdy macie własnych programistów i potrzebujecie doświadczenia z migracji. Jeśli chcesz sprawdzić, od czego zacząć w Twoim projekcie, napisz do nas albo zamów konsultację.