5 znaków, że Twoja aplikacja mobilna umiera po cichu

Aplikacje mobilne rzadko umierają z hukiem

Nie ma jednego dnia, w którym aplikacja przestaje działać. Nie ma alertu „projekt zakończony", nie ma awarii, po której ktoś zwołuje kryzysowe spotkanie. Aplikacja umiera stopniowo i po cichu — przez kilkanaście miesięcy, w trakcie których wszyscy są zajęci ważniejszymi rzeczami.

Znamy ten scenariusz z audytów. Telefon zwykle brzmi tak: „mamy aplikację, działa, ale chcielibyśmy dodać jedną funkcję". Otwieramy repozytorium i okazuje się, że dodanie tej jednej funkcji wymaga wcześniej trzech miesięcy pracy, bo projekt nie kompiluje się na żadnym współczesnym środowisku, a połowa bibliotek nie ma już wsparcia.

Poniżej pięć sygnałów, które w takich projektach widzimy najczęściej. Nie są to abstrakcyjne „dobre praktyki" — to konkretne objawy z konkretnymi konsekwencjami. Jeśli rozpoznasz u siebie dwa lub więcej, aplikacja prawdopodobnie jest już w fazie, w której koszt naprawy rośnie szybciej niż wartość, którą aplikacja dowozi.

Znak 1: ostatnie wydanie było ponad rok temu

To najłatwiejszy do sprawdzenia sygnał — wystarczy wejść do App Store albo Google Play i zobaczyć datę ostatniej aktualizacji.

Brak wydań przez 12 miesięcy nie oznacza, że „aplikacja jest skończona i stabilna". Oznacza, że przez rok świat wokół niej się zmienił, a ona nie:

• wyszła nowa major wersja iOS i Androida, a nikt nie sprawdził, czy aplikacja się na nich poprawnie zachowuje;
• zmieniły się rozdzielczości i proporcje ekranów w nowych modelach telefonów;
• biblioteki, z których korzysta projekt, dostały aktualizacje bezpieczeństwa — których nie wdrożono;
• integracje po stronie backendu (płatności, mapy, logowanie, powiadomienia) zmieniły API albo wycofały stare wersje.

Najgorsza część jest niewidoczna: każdy miesiąc bez wydania podnosi koszt następnego wydania. Projekt, który aktualizuje zależności co kwartał, robi to w kilka godzin. Projekt, który nie robił tego przez dwa lata, wymaga migracji przez kilka wersji major naraz — a każda z nich ma swoje breaking changes. To nie jest liniowy przyrost pracy, tylko wykładniczy.

Praktyczny test: poproś zespół o wypuszczenie wersji, która zmienia jedno słowo w tekście. Jeśli odpowiedź brzmi „musimy najpierw sprawdzić, czy to się w ogóle zbuduje" — masz odpowiedź.

Znak 2: crash rate rośnie, a nikt na to nie patrzy

Drugi sygnał jest podstępny, bo dane zwykle są — tylko nikt do nich nie zagląda. Google Play Console ma sekcję Android Vitals, App Store Connect ma metryki stabilności, w projekcie często siedzi zapomniany Crashlytics albo Sentry. Problem w tym, że nikt nie ma tego w obowiązkach.

Dlaczego to ma znaczenie biznesowe, a nie tylko techniczne:

• Google Play traktuje stabilność jako czynnik rankingowy i dystrybucyjny. Przekroczenie progów złego zachowania (orientacyjnie ok. 1,09% sesji z awarią widoczną dla użytkownika i ok. 0,47% ANR-ów) może skutkować ostrzeżeniem w konsoli i ograniczeniem widoczności aplikacji w sklepie.
• Użytkownik po drugim crashu zwykle nie zgłasza błędu. Odinstalowuje aplikację i nie wraca. Nie zobaczysz tego w zgłoszeniach do supportu — zobaczysz to w retencji, kilka miesięcy później, gdy trudno już powiązać przyczynę ze skutkiem.
• Rosnący crash rate przy braku wydań prawie zawsze oznacza, że aplikacja zaczyna się rozjeżdżać z nowymi wersjami systemu. To sygnał wyprzedzający, nie opóźniony.

Zdrowy punkt odniesienia dla aplikacji produkcyjnej to powyżej 99,5% sesji bez awarii, a dla ścieżek krytycznych (logowanie, płatność, wysłanie zamówienia) — praktycznie 100%. Jeśli nie znasz swojej liczby, to jest właśnie objaw: nie chodzi o to, że jest zła. Chodzi o to, że nie istnieje w niczyich raportach.

Znak 3: jedyny developer, który znał projekt, odszedł

W literaturze zarządzania nazywa się to bus factor — ile osób musiałoby zniknąć z zespołu, żeby projekt stanął. Gdy odpowiedź brzmi „jedna" i ta jedna osoba już odeszła, bus factor wynosi zero. Projekt formalnie żyje, ale nikt nie ma o nim wiedzy.

Co dokładnie znika razem z tą osobą:

• Decyzje architektoniczne bez uzasadnienia w kodzie. Dlaczego tu jest własna implementacja cache'u zamiast biblioteki? Bo trzy lata temu biblioteka miała buga? Bo ktoś nie wiedział, że biblioteka istnieje? Nikt nie wie, więc nikt nie odważy się tego dotknąć.
• Wiedza operacyjna. Gdzie stoi serwer buildów, jak wygląda proces wydania, co trzeba zrobić ręcznie przed wypuszczeniem wersji, którą flagę ustawić w konfiguracji produkcyjnej.
• Kontekst produktowy. Dlaczego ten ekran wygląda tak dziwnie? Bo klient tak chciał, czy to obejście problemu z API?

Efekt jest mierzalny: każda zmiana staje się dochodzeniem. Nowy programista wycenia trzydniowe zadanie na dwa tygodnie — i ma rację, bo dwanaście dni to czytanie kodu, a jeden to zmiana. Zespół zaczyna omijać ryzykowne obszary, obudowywać je kolejnymi wyjątkami zamiast poprawiać, i dług rośnie dalej.

Zapasowy scenariusz, którego prawie nikt nie ma przygotowanego: czy wiesz, kto ma dostęp do konta deweloperskiego, kluczy podpisujących i repozytorium? W projektach po odejściu jedynego developera odpowiedź brzmi zaskakująco często „chyba on". O tym za chwilę osobno.

Znak 4: build trwa 15 minut — albo nikt nie wie, jak go uruchomić

Piętnastominutowy build wygląda jak drobna niedogodność. W praktyce jest to mnożnik wszystkich pozostałych problemów.

Policzmy uczciwie. Programista poprawiający błąd wykonuje cykl „zmiana → build → sprawdzenie" kilkanaście razy dziennie. Przy 15 minutach na build to 2–4 godziny dziennie czekania. Skutki nie są jednak wyłącznie arytmetyczne — psuje się sposób pracy:

• ludzie przestają testować lokalnie, bo to za drogie czasowo, i wrzucają zmiany „na próbę" od razu na CI;
• zmiany robią się większe i rzadsze, bo skoro i tak trzeba czekać, to lepiej wrzucić pięć rzeczy naraz — a większe zmiany są trudniejsze do zrewidowania i częściej coś psują;
• testy przestają być uruchamiane, bo wydłużyłyby cykl jeszcze bardziej;
• naprawa krytycznego błędu w produkcji zajmuje pół dnia zamiast godziny, niezależnie od tego, jak prosta jest sama poprawka.

Wersja skrajna, którą też spotykamy: build nie działa w ogóle na nowej maszynie. Projekt wymaga konkretnej starej wersji Xcode'a albo Android Studio, konkretnej wersji Javy, zależności pobieranej z repozytorium, które przestało istnieć, i lokalnego pliku konfiguracyjnego, którego nie ma w repo, bo „każdy ma swój". Uruchomienie takiego projektu to samodzielny, kilkudniowy projekt archeologiczny — jeszcze przed napisaniem pierwszej linijki nowego kodu.

Zdrowa wartość odniesienia: build inkrementalny poniżej minuty, pełny build z testami na CI w granicach kilku minut. Jeśli jesteś dziesięć razy powyżej, to nie jest kwestia komfortu zespołu, tylko realnego kosztu każdej przyszłej zmiany.

Znak 5: ostrzeżenia ze sklepów trafiają do skrzynki, której nikt nie czyta

To znak, który najczęściej wywołuje prawdziwy kryzys — i jednocześnie najłatwiejszy do przeoczenia, bo cała komunikacja idzie mailem na adres założony przy publikacji aplikacji cztery lata temu. Często na adres osoby, która już nie pracuje w firmie.

Co przychodzi na taką skrzynkę:

• Wymagania dotyczące target API level. Google Play co roku podnosi minimalny poziom API, na który muszą celować aktualizowane aplikacje. Po terminie nie da się wypuścić aktualizacji, a starsze aplikacje przestają być pokazywane użytkownikom nowszych urządzeń. Apple analogicznie wymaga budowania najnowszym SDK.
• Wymagania compliance. Deklaracje prywatności, informacje o zbieranych danych, wymogi dotyczące dostępności (EAA i WCAG 2.2), zgody na przetwarzanie danych. Brak reakcji oznacza odrzucenie aktualizacji, a w skrajnych przypadkach usunięcie aplikacji ze sklepu.
• Wygasające certyfikaty i konta. Konto Apple Developer jest płatne rocznie. Certyfikaty dystrybucyjne i profile provisioningu mają terminy ważności. Wygaśnięcie konta oznacza zniknięcie aplikacji ze sklepu — bez ostrzeżenia widocznego dla kogokolwiek poza właścicielem skrzynki.

Najbardziej kosztowny wariant tego problemu to utrata dostępu do klucza podpisującego Androida. Bez niego nie da się wypuścić aktualizacji istniejącej aplikacji — trzeba opublikować nową pozycję w sklepie, co oznacza utratę wszystkich recenzji, ocen, pozycji w wynikach wyszukiwania i konieczność ręcznej migracji użytkowników. Google oferuje procedurę odzyskiwania przez Play App Signing, ale tylko jeśli zostało to wcześniej skonfigurowane.

Pięciominutowy test, który warto zrobić dziś: sprawdź, kto odbiera maile z App Store Connect i Google Play Console, czy ten ktoś nadal pracuje w firmie i kiedy ostatnio otworzył konsolę.

Ile to naprawdę kosztuje

Aplikacja w tym stanie generuje koszty, których nie widać w budżecie IT, bo są rozproszone:

Warto porównać to z kosztem regularnego utrzymania, który realnie wynosi 15–20% budżetu wdrożenia rocznie — więcej o tym w tekście Ile kosztuje aplikacja mobilna w 2026. Zaniechanie utrzymania nie jest oszczędnością. Jest odroczeniem płatności z bardzo wysokim oprocentowaniem.

Co zrobić, jeśli rozpoznajesz swoją aplikację

Kolejność ma znaczenie. Najczęstszy błąd to zaczynanie od pisania nowych funkcji w projekcie, którego nikt nie kontroluje.

Krok 1: odzyskaj kontrolę (dni, nie tygodnie). Zbierz i zweryfikuj w jednym miejscu: dostępy do kont deweloperskich, klucze podpisujące, repozytorium, konfiguracje CI, dostęp do backendu i integracji. Sprawdź, czy adres kontaktowy w obu sklepach jest aktualny i czytany. To najtańszy element całej listy, a jednocześnie ten, którego brak potrafi zablokować wszystko pozostałe.

Krok 2: zmierz stan faktyczny. Włącz albo odgrzeb monitoring awarii, sprawdź Android Vitals i metryki w App Store Connect, ustal realną liczbę aktywnych użytkowników. Bez liczb każda dalsza decyzja jest zgadywaniem — a bardzo często okazuje się, że aplikacja ma albo znacznie mniej, albo znacznie więcej użytkowników, niż zakłada firma.

Krok 3: zrób audyt techniczny i policz warianty. Chodzi o odpowiedź na jedno pytanie: czy taniej jest reanimować, czy przepisać? Odpowiedź zależy od tego, jak duża część kodu nadaje się do utrzymania, jak przestarzały jest stos technologiczny i czy backend da się zachować. Robimy takie audyty i konsultacje właśnie po to, żeby ta decyzja opierała się na przeglądzie kodu, a nie na przeczuciu.

Z naszego doświadczenia: reanimacja zwykle wygrywa, jeśli architektura jest sensowna, a problemem są głównie zaległe aktualizacje i brak procesu. Przepisanie ma sens, gdy projekt stoi na technologii bez wsparcia, kod uniemożliwia bezpieczne wprowadzanie zmian albo produkt i tak wymaga poważnej zmiany zakresu — wtedy warto przy okazji rozważyć nowoczesne podejście cross-platform, które obniża koszt utrzymania dwóch platform.

Osobna uwaga dla projektów rozwijanych w ostatnim czasie głównie z pomocą asystentów AI: tam objawy bywają odwrotne — wydania są częste, ale kod nigdy nie został przeczytany ze zrozumieniem. Opisaliśmy to w tekście o kodzie pisanym przez AI w produkcji.

Jak nie wrócić do tego stanu

Utrzymanie aplikacji przy życiu nie wymaga dużego budżetu — wymaga regularności i przypisanej odpowiedzialności:

1. Wydanie co kwartał, nawet bez nowych funkcji. Same aktualizacje zależności i zgodność z nowym systemem. To najtańsza polisa, jaka istnieje.
2. Jedna osoba odpowiedzialna za metryki stabilności. Comiesięczny przegląd crash rate i ANR — piętnaście minut miesięcznie.
3. Kalendarz z terminami platform. Wymagania target API, odnowienia kont, wygaśnięcia certyfikatów. Wpisane raz, przypominane automatycznie.
4. Bus factor minimum dwa. Co najmniej dwie osoby potrafiące zbudować i wydać aplikację — plus README, które faktycznie opisuje, jak to zrobić.
5. Build w budżecie czasowym. Traktuj czas builda jak metrykę produktową: jeśli rośnie, ktoś ma zadanie, żeby go skrócić.

Podsumowanie

Aplikacja mobilna nie jest projektem z datą końca — jest produktem, który wymaga stałego, choć niewielkiego, dopływu uwagi. Pięć znaków z tego tekstu — brak wydań od roku, rosnący i nieobserwowany crash rate, zerowy bus factor, wielominutowy build i nieczytana skrzynka ze sklepów — to nie osobne problemy. To ten sam problem widziany z pięciu stron: nikt nie jest właścicielem tej aplikacji.

Dobra wiadomość jest taka, że pierwsze dwa kroki naprawcze — odzyskanie dostępów i włączenie pomiaru — są tanie i można je zrobić w tydzień. Dopiero one pozwalają sensownie zdecydować, co dalej.

W Mobilesoft przejmujemy i reanimujemy takie projekty regularnie — od odzyskania kontroli nad wydaniami po pełne przepisanie tam, gdzie to się opłaca. Zobacz, jak podchodzimy do budowy i utrzymania aplikacji mobilnych oraz backendu i API, sprawdź nasze realizacje albo od razu wyceń projekt.

Jeśli po lekturze tej listy masz nieprzyjemne przeczucie co do własnej aplikacji — napiszcie do nas. Przejrzymy repozytorium i powiemy wprost, czy to jeszcze zaległości w utrzymaniu, czy już projekt do odbudowy.