Czy Twoja aplikacja przetrwa 2027? Checklista 15 punktów do samodzielnego sprawdzenia

Aplikacja nie musi być stara, żeby przestać działać

Większość aplikacji mobilnych nie przestaje działać dlatego, że ktoś je zepsuł. Przestają działać dlatego, że przestały nadążać — za wymaganiami sklepów, wersjami systemów, bibliotekami i ludźmi, którzy je znali. Objawy pojawiają się dopiero wtedy, gdy trzeba coś wypuścić: nagle okazuje się, że aktualizacja nie przechodzi weryfikacji, projekt nie kompiluje się na nowym laptopie, a klucza podpisującego nikt nie widział od dwóch lat.

Ten tekst jest praktyczną checklistą. Piętnaście punktów, które możesz sprawdzić samodzielnie — bez audytu, bez konsultacji, w większości przypadków w jedno popołudnie. Do każdego podajemy, gdzie dokładnie patrzeć, i co jest czerwoną flagą.

Na końcu znajdziesz prostą punktację i interpretację wyniku. Jeśli szukasz szerszego kontekstu — objawy zaniedbanej aplikacji opisaliśmy w tekście 5 znaków, że aplikacja mobilna umiera po cichu. Tutaj skupiamy się na konkretach do odhaczenia.

Część 1. Zgodność z platformami i sklepami (punkty 1–4)

To jedyna część listy, w której konsekwencją zaniedbania jest twarda blokada: nie „będzie trudniej", tylko „nie wypuścisz aktualizacji".

1. Czy targetSdk spełnia aktualny wymóg Google Play?

Google Play co roku podnosi minimalny poziom API, na który muszą celować publikowane i aktualizowane aplikacje — termin przypada zwykle na przełom sierpnia i września i dotyczy wersji Androida sprzed roku. Po jego upływie nie da się wgrać nowej wersji aplikacji celującej w starszy poziom.

Gdzie sprawdzić: wartość targetSdk (dawniej targetSdkVersion) w app/build.gradle.kts lub app/build.gradle. Aktualny wymagany poziom i termin pokazuje sama Google Play Console — jeśli aplikacja jest poniżej progu, wyświetla ostrzeżenie z datą.

Czerwona flaga: targetSdk niższy niż wymagany przez sklep albo taki, którego nikt w zespole nie potrafi wskazać z pamięci.

Uwaga: podniesienie targetSdk to nie jest zmiana jednej liczby. Każdy poziom API wprowadza nowe restrykcje — dostęp do plików, uprawnienia, praca w tle, wymagania dla usług pierwszoplanowych. To realna praca deweloperska, którą lepiej rozłożyć na kwartały niż robić w panice na dwa tygodnie przed terminem.

2. Czy aplikacja jest budowana aktualnym SDK iOS?

Apple analogicznie wymaga, żeby aplikacje wysyłane do App Store były budowane najnowszym publicznym SDK — wymóg wchodzi w życie zwykle na wiosnę, kilka miesięcy po premierze nowej wersji systemu.

Gdzie sprawdzić: wersja Xcode na maszynie budującej i w konfiguracji CI, wartość IPHONEOS_DEPLOYMENT_TARGET w ustawieniach projektu.

Czerwona flaga: projekt wymaga konkretnej starszej wersji Xcode'a, bo „na nowszej się nie kompiluje". To znaczy, że blokada przy najbliższym wydaniu jest tylko kwestią czasu.

3. Czy deklaracje prywatności i wymogi compliance są aktualne?

Obie platformy wymagają dziś deklaracji dotyczących danych: sekcji Data safety w Google Play i etykiet prywatności w App Store, a po stronie iOS także manifestów prywatności dla bibliotek korzystających z wybranych API. Do tego doszły wymagania dostępności — od czerwca 2025 obowiązuje Europejski Akt o Dostępności, który dla wielu produktów cyfrowych oznacza konieczność spełnienia WCAG 2.2 na poziomie AA.

Gdzie sprawdzić: App Store Connect → sekcja prywatności; Play Console → Data safety; polityka prywatności podlinkowana w obu sklepach.

Czerwona flaga: deklaracja nie była aktualizowana od czasu, gdy dodano nową integrację — analitykę, SDK reklamowe, płatności czy logowanie przez zewnętrznego dostawcę. Deklaracja niezgodna ze stanem faktycznym to podstawa do odrzucenia aktualizacji.

4. Czy aplikacja działa poprawnie na najnowszych systemach?

Prosty test, którego zaskakująco często nikt nie wykonał: zainstaluj produkcyjną wersję ze sklepu na telefonie z najnowszym iOS i najnowszym Androidem i przejdź trzy główne ścieżki użytkownika.

Czerwona flaga: cokolwiek, co wygląda inaczej, niż powinno — ucięte teksty, nakładające się elementy na ekranach z wycięciem, nieobsłużone gesty, prośby o uprawnienia w złym momencie, brak reakcji na tryb ciemny. Aplikacja nie „przestaje działać" nagle; najpierw zaczyna wyglądać na porzuconą.

Część 2. Kod i zależności (punkty 5–7)

5. Ile zależności jest przeterminowanych?

Gdzie sprawdzić — jedna komenda, zależnie od stosu:

# Android (z pluginem ben-manes/versions)
./gradlew dependencyUpdates

# Flutter
flutter pub outdated

# React Native / Node
npm outdated

# iOS
pod outdated

Czerwona flaga: więcej niż kilka zależności zapóźnionych o całą wersję major, albo jakakolwiek biblioteka bez wydania od dwóch lat, która nie jest świadomie wybraną, stabilną zależnością.

Kluczowa jest tu dynamika: aktualizacja robiona co kwartał to godziny pracy, aktualizacja po dwóch latach to przejście przez kilka wersji major naraz, każda ze swoimi breaking changes. Koszt nie rośnie liniowo.

6. Czy w zależnościach są znane podatności, a w repozytorium sekrety?

Dwa skany, które warto uruchomić przy okazji tego samego wieczoru.

Gdzie sprawdzić:

npm audit                          # Node / React Native
./gradlew dependencyCheckAnalyze   # OWASP Dependency-Check
gitleaks detect                    # sekrety w całej historii Gita

Czerwona flaga (podatności): cokolwiek o wysokim lub krytycznym poziomie w zależności używanej produkcyjnie — szczególnie w bibliotekach sieciowych, kryptograficznych, do parsowania danych albo obsługi obrazów. Osobna czerwona flaga: nikt nie wie, czy takie skanowanie w ogóle jest uruchamiane. Najtańsze rozwiązanie to włączyć Dependabota albo odpowiednik w repozytorium — robi to automatycznie.

Czerwona flaga (sekrety): klucz API, connection string albo token w kodzie lub w commitowanym .env. Kluczowa świadomość: usunięcie sekretu kolejnym commitem go nie usuwa — zostaje w historii Gita. Znaleziony żywy sekret oznacza natychmiastową rotację, bo trzeba założyć, że wyciekł. Ten problem szczególnie urósł w projektach rozwijanych z pomocą asystentów AI; opisaliśmy to w tekście o kodzie pisanym przez AI w produkcji.

7. Czy framework i język są w wersji objętej wsparciem?

Dotyczy szczególnie projektów cross-platform, gdzie tempo zmian jest wyższe niż w natywnych. React Native i Flutter realnie wspierają wąskie okno ostatnich wersji — starsze nie dostają poprawek bezpieczeństwa ani zgodności z nowymi systemami.

Gdzie sprawdzić: flutter --version, wersja react-native w package.json, wersja Kotlina lub Swifta w konfiguracji projektu.

Czerwona flaga: wersja frameworka starsza o więcej niż rok. Jeśli stoisz przed decyzją o większej migracji, warto przy okazji przemyśleć sam wybór technologii — porównanie znajdziesz w tekście Flutter vs React Native vs Kotlin Multiplatform.

Część 3. Stabilność i dane (punkty 8–10)

8. Jaki jest crash-free rate?

Gdzie sprawdzić: Google Play Console → Android Vitals; App Store Connect → Metryki; Crashlytics albo Sentry, jeśli są wpięte.

Zdrowa wartość: powyżej 99,5% sesji bez awarii, a na ścieżkach krytycznych — logowanie, płatność, złożenie zamówienia — praktycznie 100%. Google Play traktuje stabilność jako czynnik dystrybucyjny: przekroczenie progów złego zachowania (orientacyjnie ok. 1,09% awarii widocznych dla użytkownika) może ograniczyć widoczność aplikacji w sklepie.

Czerwona flaga: nie znasz swojej liczby. To gorszy wynik niż zła liczba — złą liczbę przynajmniej ktoś widzi.

9. Jaki jest wskaźnik ANR i czas startu aplikacji?

Na Androidzie ANR (Application Not Responding) bywa groźniejszy niż crashe, bo dla użytkownika wygląda jak zawieszenie telefonu. Google Play stosuje osobny próg — orientacyjnie ok. 0,47% sesji.

Gdzie sprawdzić: Android Vitals → ANR rate oraz czas uruchomienia (cold start). Dla iOS: App Store Connect → Metryki → Launch Time.

Czerwona flaga: cold start powyżej 2–3 sekund albo rosnący ANR rate po ostatnich wydaniach. Częsta przyczyna: synchroniczne wywołania sieciowe lub ciężka inicjalizacja SDK na starcie — problem zwykle leży po stronie backendu i API, nie samej aplikacji.

10. Czy znasz liczbę aktywnych użytkowników i czy monitoring ma odbiorcę?

Narzędzie zbierające dane, do którego nikt nie zagląda, nie jest monitoringiem — jest archiwum.

Gdzie sprawdzić: analityka produktowa (Firebase, Amplitude, cokolwiek), Play Console → Statystyki, App Store Connect → Analityka. Porównaj liczbę instalacji z liczbą aktywnych użytkowników w ostatnich 30 dniach. Sprawdź też, czy alerty o wzroście awarii trafiają na kanał, który ktoś czyta, i czy istnieje imiennie wskazana osoba odpowiedzialna za przegląd metryk.

Czerwona flaga: brak analityki w ogóle, rozjazd między tym, co zakłada firma, a tym, co pokazują dane, albo alerty idące na skrzynkę grupową wyciszoną przez wszystkich. Rozjazd w danych to najczęstsza niespodzianka w audytach — i działa w obie strony: bywa, że aplikacja uznana za „nieużywaną" ma stabilną grupę wiernych użytkowników, których wyłączenie usługi realnie zaboli.

Część 4. Proces wytwarzania (punkty 11–12)

11. Ile trwa build i czy da się wydać wersję dzisiaj?

Dwa pytania, jedna odpowiedź o kondycji projektu.

Gdzie sprawdzić: zmierz czas pełnego builda release (./gradlew --profile assembleRelease, w Xcode — Product → Perform Action → Build With Timing Summary) oraz czas przejścia pipeline'u na CI.

Zdrowa wartość: build inkrementalny poniżej minuty, pełny build z testami na CI w granicach kilku minut.

Test praktyczny: poproś zespół o wypuszczenie wersji, która zmienia jedno słowo w interfejsie. Jeśli odpowiedź brzmi „musimy najpierw sprawdzić, czy to się w ogóle zbuduje", nie masz działającego procesu wydawniczego — masz projekt archeologiczny.

Czerwona flaga: build trwa kilkanaście minut i nikt nie traktuje tego jako problemu; albo projekt buduje się wyłącznie na jednej konkretnej maszynie.

12. Czy istnieją testy i czy ktoś je uruchamia?

Nie chodzi o pokrycie liczbowe, tylko o istnienie siatki bezpieczeństwa pod ścieżkami, które bolą najbardziej.

Gdzie sprawdzić: czy testy przechodzą (./gradlew test, flutter test, npm test), czy są uruchamiane automatycznie na każdym pull requeście i czy pokrywają logowanie, płatności oraz zapis danych.

Czerwona flaga: testy są, ale wyłączone „bo się psuły". To gorsze niż ich brak, bo daje fałszywe poczucie bezpieczeństwa. Drugi wariant: testy sprawdzają wyłącznie mocki i przechodzą także wtedy, gdy logika jest błędna.

Część 5. Ciągłość i kontrola (punkty 13–15)

Najkrótsza część listy i jednocześnie ta, w której pojedynczy brak potrafi unieruchomić cały produkt. Na te trzy pytania trzeba umieć odpowiedzieć imiennie, a nie „chyba ktoś z IT".

13. Kto jest właścicielem kont w sklepach i kto czyta z nich maile?

Czy firma jest właścicielem konta Apple Developer i Google Play Console, czy konto należy do agencji albo byłego pracownika? Czy adres kontaktowy odbiera osoba, która nadal u Was pracuje? Konto Apple Developer odnawia się rocznie — jego wygaśnięcie oznacza zniknięcie aplikacji ze sklepu, a ostrzeżenia idą wyłącznie na ten adres.

Gdzie sprawdzić: App Store Connect → Users and Access (kto ma rolę Account Holder); Play Console → Users and permissions.

Czerwona flaga: rola właściciela przypisana do prywatnej skrzynki, konta agencji zewnętrznej albo adresu, na który nikt się nie loguje.

14. Gdzie są klucze podpisujące i kiedy wygasają certyfikaty?

Na Androidzie: czy aplikacja korzysta z Play App Signing, czy z lokalnego keystore'a? Jeśli z lokalnego i plik zaginie — nie wypuścisz już aktualizacji istniejącej aplikacji. Trzeba opublikować nową pozycję w sklepie i stracić wszystkie oceny, recenzje, pozycję w wynikach wyszukiwania oraz historię instalacji. Na iOS: gdzie są certyfikaty dystrybucyjne, kiedy wygasają i kto ma uprawnienia, żeby je odnowić.

Gdzie sprawdzić: Play Console → Setup → App integrity (czy Play App Signing jest włączone); Apple Developer → Certificates, Identifiers & Profiles → daty ważności.

Czerwona flaga: keystore „gdzieś na dysku" byłego programisty, hasło do niego w niczyjej pamięci, brak kopii zapasowej w menedżerze sekretów firmy.

15. Ile osób potrafi zbudować i wydać tę aplikację?

Klasyczny bus factor. Pytanie brzmi konkretnie: ile osób potrafi dziś, na czystej maszynie, sklonować repozytorium, zbudować wersję produkcyjną i wysłać ją do sklepu?

Gdzie sprawdzić: README w repozytorium. Jeśli nie opisuje, jak uruchomić projekt i jak wydać wersję, wiedza istnieje wyłącznie w czyjejś głowie.

Czerwona flaga: odpowiedź „jedna osoba". To pojedynczy punkt awarii, który nie jest technologiczny — i jedyny na tej liście, którego nie da się naprawić pieniędzmi w trybie awaryjnym.

Punktacja: policz swoje odpowiedzi

Przyznaj sobie 1 punkt za każdy punkt bez czerwonej flagi. Maksimum: 15.

Jedna uwaga do interpretacji: punkty nie są równoważne. Brak dostępu do klucza podpisującego (punkt 14) albo targetSdk poniżej wymogu na miesiąc przed terminem (punkt 1) to problemy blokujące — ważą więcej niż pięć punktów z części o zależnościach. Jeśli którykolwiek z tych dwóch wypadł źle, potraktuj go jako priorytet niezależnie od sumy.

Kolejność naprawy

Jeśli lista ujawniła więcej, niż się spodziewałeś, nie zaczynaj od najciekawszego technicznie problemu. Kolejność, która sprawdza się w praktyce:

1. Odzyskaj kontrolę (punkty 13–15). Konta, klucze, adresy kontaktowe, dostęp do repozytorium i CI. Tanie, szybkie i warunkuje wszystko pozostałe.
2. Usuń blokady platformowe (punkty 1–3). Rzeczy z twardymi terminami narzuconymi z zewnątrz — nie da się ich przesunąć negocjacjami.
3. Włącz pomiar (punkty 8–10). Bez danych każda kolejna decyzja jest zgadywaniem.
4. Skróć pętlę zwrotną (punkty 11–12). Build i testy są mnożnikiem kosztu wszystkich przyszłych zmian.
5. Dopiero teraz zależności i dług techniczny (punkty 5–7). Wtedy już wiadomo, co jest realnym ryzykiem, a co tylko wygląda staro.

Ile to kosztuje utrzymać

Regularne utrzymanie aplikacji mobilnej to realnie 15–20% budżetu wdrożenia rocznie — więcej o strukturze tych kosztów w tekście Ile kosztuje aplikacja mobilna w 2026. W tej kwocie mieści się większość rzeczy z powyższej listy: kwartalne wydania, aktualizacje zależności, reakcja na wymogi platform, przegląd metryk.

Odłożenie tego wydatku nie jest oszczędnością — jest przesunięciem płatności w czasie, z odsetkami. Projekt zaniedbany przez dwa lata wymaga na wejściu kilkutygodniowej pracy, zanim w ogóle da się w nim cokolwiek dodać.

Podsumowanie

Pytanie z tytułu — czy aplikacja przetrwa 2027 — w praktyce sprowadza się do jednego: czy da się ją wydać ponownie. Nie „czy działa", bo działać może jeszcze długo. Chodzi o to, czy w momencie, gdy pojawi się nowy wymóg sklepu, krytyczny błąd albo szansa biznesowa, będziesz w stanie zareagować w dniach, a nie w kwartałach.

Wszystkie piętnaście punktów sprowadza się do trzech rzeczy: zgodności z platformami, mierzalności i możliwości wydania. Reszta jest ważna, ale wtórna.

W Mobilesoft przechodzimy przez taką listę na wejściu do każdego przejmowanego projektu — efektem jest priorytetyzowany plan, a nie lista zarzutów. Jeśli chcesz, żeby ktoś zrobił to za Ciebie i powiedział wprost, co jest ryzykiem blokującym, a co może poczekać, zajmujemy się tym w ramach audytów i konsultacji. Zobacz też, jak podchodzimy do budowy i utrzymania aplikacji mobilnych, sprawdź nasze realizacje albo od razu wyceń projekt.

A jeśli chcesz tylko skonfrontować swój wynik z drugą opinią — napisz do nas. Przejdziemy przez tę listę razem.