Wycofane SDK i API — dlaczego aplikacja przestaje działać, choć nikt jej nie zmieniał

Użytkownicy zgłaszają, że link z newslettera otwiera stronę błędu, a reset hasła przestał działać. Nikt nie wydawał nowej wersji aplikacji ani nie zmieniał backendu. Przyczyna leży poza aplikacją: usługa, z której korzystała, została wyłączona.

Typowa aplikacja mobilna w dużej części składa się z cudzego kodu. Logowanie, płatności, analityka, mapy, powiadomienia, raportowanie awarii — za każdą z tych funkcji stoi SDK albo API zewnętrznego dostawcy. Każde ma własny cykl życia, a dostawca wycofuje je według swojego kalendarza, nie Twojego. Aplikacja nie musi się zmieniać, żeby przestać działać.

Trzy sposoby, w jakie wycofane SDK psuje aplikację

1. Dostawca wyłącza usługę. To najgroźniejszy przypadek, bo awaria następuje bez żadnego wydania i dotyczy wszystkich wersji aplikacji naraz.
2. Sklep blokuje wydania ze starą wersją biblioteki. Aplikacja działa dalej, ale nowej wersji nie wydasz, dopóki nie zaktualizujesz zależności. Zwykle wychodzi to wtedy, gdy trzeba szybko wypuścić poprawkę.
3. Biblioteka jest przestarzała, ale bez daty wyłączenia. Dziś nic się nie dzieje. Biblioteka nie dostaje jednak poprawek, a termin może zostać ogłoszony w każdej chwili.

Przykłady z ostatnich lat

Jedna rzecz łączy te przypadki: termin był znany z dużym wyprzedzeniem. Wyłączenie Dynamic Links Google ogłosił w 2023 roku, dwa lata przed faktem. Billing Library ma stały, dwuletni cykl wycofywania, a tabela terminów na kolejne wersje jest publiczna. O powiadomieniach push i wyłączeniu starego API FCM piszemy szerzej w tekście o tym, dlaczego powiadomienia push przestały działać.

Warto też wiedzieć, że wyłączenie usługi nie zawsze oznacza crash. Firebase opisuje, że samo SDK Dynamic Links nie wyłoży aplikacji, ale zacznie zwracać błędy albo puste dane. Aplikacja się uruchamia, a funkcja po cichu przestaje działać. Takiej awarii nie zobaczysz w raporcie crashy, tylko w zgłoszeniach od użytkowników albo w spadku konwersji.

Dlaczego nikt tego nie zauważa

Dostawcy ostrzegają, tylko nie tam, gdzie patrzy właściciel aplikacji:

• e-maile trafiają na adres przypisany do konta Firebase, Google Cloud albo konta deweloperskiego, czyli często na skrzynkę programisty, który dawno odszedł,
• ostrzeżenia o SDK wyświetla Play Console na stronach wydań, które otwiera się tylko przy publikacji,
• informacje o wycofaniu są w notach wydań bibliotek, których nikt nie czyta, gdy projekt nie jest rozwijany.

To jeden z pięciu sygnałów, które opisujemy w tekście o tym, po czym poznać, że aplikacja umiera po cichu.

Inwentaryzacja: z czego składa się Twoja aplikacja

Pierwszy krok to lista zależności. Programista znajdzie ją w kilku miejscach:

• Android: build.gradle lub build.gradle.kts oraz libs.versions.toml,
• iOS: Podfile albo zależności Swift Package Manager,
• Flutter: pubspec.yaml, React Native: package.json.

Do tego dochodzą dwie grupy, których w kodzie aplikacji nie widać. Pierwsza to integracje po stronie backendu: weryfikacja zakupów, wysyłka powiadomień, zapytania do map czy płatności. Druga to usługi skonfigurowane w panelach dostawców, np. domeny linków albo projekty w Firebase.

Dla każdej pozycji warto zapisać kilka informacji:

Status u dostawcy sprawdzisz w dokumentacji i notach wydań. Pomaga też Play Console: wyświetla ostrzeżenia, gdy aplikacja korzysta z wersji SDK, którą jej dostawca zgłosił jako nieaktualną albo z krytycznymi problemami, a w części przypadków blokuje kolejne wydania z taką wersją.

W jakiej kolejności wymieniać

1. Usługi już wyłączone, z których aplikacja wciąż korzysta. To awarie, które trwają teraz, nawet jeśli nikt ich jeszcze nie zgłosił. Sprawdź przynajmniej Dynamic Links, App Center i sposób wysyłki powiadomień.
2. Terminy, które zablokują wydania w najbliższych miesiącach. Jeśli przegapisz taki termin, każda pilna poprawka zacznie się od aktualizacji biblioteki.
3. Przestarzałe biblioteki w funkcjach krytycznych dla biznesu. Logowanie i płatności wymieniaj na spokojnie, zanim dostawca ogłosi datę.
4. Pozostałe zależności. Te aktualizuj w ramach zwykłego utrzymania, małymi krokami.

Wymiana biblioteki to nie zawsze podbicie numeru wersji. Billing Library między głównymi wersjami zmienia API, a przejście z Google Sign-In na Credential Manager oznacza przepisanie ścieżki logowania. Takie prace najlepiej wydawać osobno, bez dokładania nowych funkcji, żeby w razie problemu było wiadomo, gdzie szukać przyczyny.

Stare wersje w rękach użytkowników

Gdy dostawca wyłącza usługę, poprawiona wersja aplikacji pomaga tylko tym, którzy ją zainstalują. Reszta dalej korzysta z wersji, która woła nieistniejący serwis.

Dlatego warto mieć mechanizm minimalnej wersji, zanim będzie potrzebny. Na Androidzie Google udostępnia In-App Updates z trybem natychmiastowym: pełnoekranowy komunikat wymaga aktualizacji i ponownego uruchomienia aplikacji. Na iOS nie ma odpowiednika, więc aplikacja sama sprawdza minimalną wersję pobraną z backendu albo zdalnej konfiguracji i pokazuje ekran aktualizacji. Ten mechanizm musi być w aplikacji wcześniej — dodany dopiero w wersji z poprawką nie zadziała w starszych wersjach.

Jak nie dać się zaskoczyć

• Adresy kontaktowe kont w Google Play, Apple, Firebase i Google Cloud ustaw na firmową skrzynkę, którą czyta więcej niż jedna osoba.
• Rejestr zależności z terminami wpisanymi do kalendarza, z zapasem kilku miesięcy.
• Przegląd zależności co kwartał i aktualizacje małymi krokami zamiast jednego dużego skoku co kilka lat.
• Monitoring awarii i kluczowych ścieżek, który pokaże problem szybciej niż zgłoszenia użytkowników. Opisujemy go w tekście o monitoringu awarii aplikacji.
• Zapis w umowie na utrzymanie, kto odpowiada za śledzenie wycofywanych zależności. Więcej o tym w tekście o tym, co zapisać w umowie na utrzymanie aplikacji.

Regularne aktualizacje bibliotek i SDK to stała część utrzymania aplikacji mobilnych, którym się zajmujemy. Jeśli nie wiesz, z jakich SDK korzysta Twoja aplikacja i które z nich mają już wyznaczony termin, zamów bezpłatną analizę aplikacji. Sprawdzamy w niej m.in., jak daleko w tyle są biblioteki, SDK i targetSdk, a wynik dostaniesz na piśmie.