Twoja aplikacja znika z Google Play dla nowych telefonów: termin 1 listopada i dlaczego aplikacja bez aktualizacji „gnije”

Aplikację do zamówień, rezerwacji albo obsługi klientów zbudowała dla Ciebie firma zewnętrzna dwa lata temu. Działa, klienci z niej korzystają, nikt nie zgłasza błędów, więc od ostatniej wersji w sklepie nikt jej nie dotykał. Aż do dnia, w którym nowy klient mówi, że nie może jej znaleźć w Google Play, a w skrzynce właściciela konta czeka kilka wiadomości od Google z datą 1 listopada.

To nie awaria ani kara za błąd, tylko coroczne podniesienie wymagań przez sklepy. W tym roku Google Play od 31 sierpnia przyjmuje wyłącznie aktualizacje przygotowane pod Androida 16, a kto poprosił o przedłużenie, zyskał czas tylko do 1 listopada. Apple zrobił podobny ruch już w kwietniu.

W tym wpisie wyjaśniamy, co zmieniły sklepy, dlaczego aplikacja, której nikt nie ruszał, „gnije” sama z siebie, i jak policzyć koszt nadrobienia zaległości w godzinach, przy jednej stawce 600 zł netto za godzinę. Bez straszenia: dla części aplikacji to kilka dni pracy, a dla części uczciwa odpowiedź brzmi „nie warto”.

Co dokładnie zmieniły sklepy w 2026 roku

Od szczegółów zależy, co musisz zrobić i do kiedy:

• Google Play, nowe aplikacje i aktualizacje. Od 31 sierpnia 2026 r. muszą być przygotowane pod Androida 16 (w nomenklaturze Google: docelowy poziom API 36). Aktualizacji przygotowanej pod starszy system sklep już nie przyjmie.
• Google Play, aplikacje już opublikowane. Jeśli aplikacja jest przygotowana pod system starszy niż Android 15 (API 35), przestaje być widoczna dla nowych użytkowników na telefonach z nowszym Androidem. Kto ma ją już zainstalowaną, na razie niczego nie zauważy.
• Przedłużenie. Google pozwalał jednorazowo przesunąć termin, ale tylko do 1 listopada 2026 r. Później przygotowanie aplikacji pod Androida 16 jest jedyną drogą do wydania jakiejkolwiek poprawki.
• App Store. Od 28 kwietnia 2026 r. Apple przyjmuje wyłącznie wersje przygotowane w iOS 26 SDK i Xcode 26, czyli najnowszych narzędziach Apple. Każda kolejna poprawka, nawet zmiana jednego napisu w aplikacji, wymaga przejścia na te narzędzia.

W praktyce najbardziej boli nie sama niewidoczność, tylko blokada poprawek. Dopóki aplikacja działa, brak aktualizacji nic nie kosztuje. Koszt pojawia się w dniu, w którym trzeba coś zmienić szybko, np. gdy klienci zgłaszają błąd na nowym telefonie. Wtedy przed godziną na poprawkę czeka Cię całe zaległe przygotowanie pod nowy system, a po niej 1–7 dni przeglądu w sklepie, na który nikt nie ma wpływu.

Dlaczego aplikacja, której nikt nie ruszał, „gnije”

Kod się nie psuje: to, co odebrałeś dwa lata temu, jest dziś dokładnie takie samo. Psuje się wszystko dookoła, bo aplikacja mobilna to zestaw połączeń z rzeczami, które zmieniają się niezależnie od Ciebie:

• System na telefonach. Co roku przychodzi nowy Android i nowy iOS, z nowymi zasadami zgód na powiadomienia, lokalizację czy aparat. Aplikacja przygotowana pod stary system działa na nowym coraz gorzej, a sklepy w końcu przestają na to pozwalać.
• Biblioteki, czyli gotowe klocki. Logowania, płatności, map i powiadomień rzadko pisze się od zera. Ich twórcy wydają nowe wersje, a stare po jakimś czasie przestają poprawiać, także pod kątem bezpieczeństwa.
• Usługi zewnętrzne. Operator płatności, dostawca SMS-ów czy map zmienia sposób połączenia i daje kilka miesięcy na przejście. Jeśli nikt aplikacji nie pilnuje, właściciel dowiaduje się o tym w dniu wyłączenia starej wersji.
• Wymogi sklepów poza wersją systemu. Apple i Google co jakiś czas dokładają nowe obowiązki, np. opis danych, które aplikacja zbiera. Bez aktualizacji ich nie spełnisz.

Najważniejsze dla rachunku: sama zmiana numeru wersji systemu to minuty pracy. Godziny zjada łańcuch, który za nią idzie. Nowy system wymaga nowszych bibliotek, nowsze biblioteki wymagają zmian w kodzie, który z nich korzysta, a każda zmiana wymaga sprawdzenia na prawdziwych telefonach. Im więcej wersji przeskakujesz naraz, tym dłuższy łańcuch.

Ile kosztuje nadrabianie i kiedy nie warto

Czas aktualizacji zależy głównie od tego, jak dawno aplikacja była ostatnio wydana. Polski software house mobilesoft.pl podaje orientacyjne widełki, które dobrze pokazują tę zależność:

• Aplikacja utrzymywana na bieżąco: 1–3 dni pracy.
• Ostatnie wydanie sprzed 1–2 lat: 1–3 tyg.
• Brak wydań od ponad 2 lat: 4–8 tyg.

To nie jest liniowy wzrost, bo zaległości w bibliotekach nakładają się na siebie, a część z nich po drodze przestaje być rozwijana i trzeba je wymienić na inne. Regularność jest tańsza nie dzięki rabatowi, tylko dlatego, że nie ma czego odrabiać.

U nas ten sam rachunek liczymy w godzinach, z dokładnością do kwadransa: godzina to 600 zł netto (738 zł brutto), kwadrans 150 zł. Zanim ruszy aktualizacja, inżynier przegląda kod i podaje estymatę na piśmie, rozbitą na etapy. Taka wiadomość może wyglądać tak:

Przejrzałem repozytorium. Aplikacja jest przygotowana pod Androida 14, ostatnie wydanie było 19 miesięcy temu. Szacuję 14 h: 2 h przejście na nowe wersje systemów i narzędzi, 6 h aktualizacja bibliotek płatności i powiadomień z poprawkami kodu, 4 h testy na telefonach z Androidem 15 i 16 oraz iOS 26, 2 h przygotowanie wersji do obu sklepów. Razem 8 400 zł netto. Biblioteka map nie jest już rozwijana. Jeśli jej wymiana okaże się większa, odezwę się przed przekroczeniem estymaty.

Estymata to także moment decyzji, bo nie każdą aplikację warto ratować. Po przeglądzie kodu masz zwykle trzy drogi, a wybór zależy od liczb, nie od sentymentu:

• Aktualizacja. Aplikacja jest używana, kod jest w rozsądnym stanie, a estymata to kilka lub kilkanaście godzin. To najprostszy scenariusz.
• Budowa od nowa. Aplikacja stoi na technologii, której nikt już nie rozwija, a estymata aktualizacji zbliża się do kosztu zbudowania tego samego zakresu od zera. Dla prostej aplikacji punktem odniesienia jest u nas MVP: 30 h, czyli 18 000 zł netto. Wtedy porównaj obie drogi, zanim zapłacisz za łatanie.
• Wygaszenie albo wersja w przeglądarce. Jeśli z aplikacji korzysta garstka osób, a to samo da się zrobić w przeglądarce na telefonie, czasem najrozsądniej jest przestać ją wydawać w sklepach. Aplikacja webowa nie przechodzi przeglądów Apple i Google i nie podlega ich corocznym terminom.

O tym, która droga ma sens, usłyszysz wprost po przeglądzie. Jeśli odpowiedź brzmi „nie aktualizujcie, szkoda pieniędzy”, dostaniesz ją tak samo jak estymatę.

Aplikacja po innym wykonawcy: co musisz mieć w ręku

Termin sklepu bywa pierwszym momentem, w którym właściciel aplikacji po innym wykonawcy sprawdza, co właściwie ma. Zanim ktokolwiek policzy aktualizację, upewnij się, że masz:

• Kod źródłowy z historią zmian. Nie plik z gotową aplikacją, tylko pełne repozytorium. Bez niego nikt nie przygotuje nowej wersji, a jedyną drogą zostaje budowa od nowa.
• Konta dewelopera na swoją firmę. Google Play Console i Apple Developer powinny należeć do Ciebie, nie do wykonawcy. Kto ma konto, ten decyduje o publikacji.
• Klucz do podpisywania wersji na Androida. Każdą nową wersję trzeba nim podpisać, więc powinien być u Ciebie albo w Google Play. Jego brak potrafi zamienić prostą aktualizację w procedurę odzyskiwania dostępu.
• Dostępy do usług, z których aplikacja korzysta. Serwer, operator płatności, dostawca powiadomień i SMS-ów. Przekazanie ich zajmuje zwykle do godziny łącznie, o ile wiesz, gdzie są.

U nas ta lista jest domyślna od pierwszego dnia: kod i pełne prawa majątkowe są w 100% Twoje po każdym opłaconym etapie, repozytorium i dokumentacja zostają u Ciebie, a konta dewelopera zakłada się na Twoją firmę. Dzięki temu aktualizację może zrobić dowolny programista, niekoniecznie my.

Aplikację do zamawiania zrobiła nam firma, z którą nie mamy już kontaktu. Google przysłał maile o terminie 1 listopada. Konto w Google Play jest na nas, kod dostaliśmy przy odbiorze dwa lata temu, ale nie wiemy, czy to ostatnia wersja. Od czego zacząć?

Utrzymanie w rytmie zamiast gaszenia pożaru raz w roku

Terminy sklepów są przewidywalne: w tym roku Apple wyznaczył datę pod koniec kwietnia, Google pod koniec sierpnia, i oba sklepy powtarzają ten rytm co roku. Po wdrożeniu masz u nas dwie drogi:

• Samodzielność (0 zł). Masz repozytorium, dokumentację i dostępy, więc aktualizację zrobi Twój zespół albo dowolny programista. Pilnowanie terminów jest wtedy po Twojej stronie.
• Plan opieki (opcjonalny). Bierzemy na siebie aktualizacje bibliotek, zgodność z nowymi wersjami systemów i wymogi App Store oraz Google Play. Rozliczenie w tej samej stawce 600 zł netto/h, za faktycznie przepracowane godziny, bez abonamentu na zapas. Zakres ustalamy pod konkretną aplikację, a plan można wypowiedzieć w każdej chwili.

Jedno rozróżnienie warto znać: gwarancja jakości z regulaminu (12 miesięcy) obejmuje błędy w tym, co zbudowaliśmy, ale nie czynniki zewnętrzne, a nowy wymóg Google czy Apple jest właśnie takim czynnikiem. Aplikacja działa jak w dniu odbioru, zmienił się świat wokół niej, więc dostosowanie to zwykła praca w godzinach, nie naprawa gwarancyjna.

Jak to policzyć u nas, zanim minie 1 listopada

Licząc wstecz od terminu: 1–7 dni przeglądu w sklepie, kilka dni testów na telefonach, a przed nimi sama praca. Przy zaległościach sprzed 1–2 lat to nie jest temat na ostatni tydzień października.

Zacznij od bezpłatnej rozmowy (15 minut): opowiadasz, co to za aplikacja, kto ją zbudował i jakie masz dostępy. Jeśli sprawa ma sens, kupujesz godziny i w 24 godziny odzywa się inżynier prowadzący. Przegląd kodu to już praca z salda, a jego wynikiem jest estymata aktualizacji na piśmie, zanim cokolwiek zmienimy w aplikacji.

Przy małych pakietach bonus jest niewielki, ale jest: za 10 opłaconych godzin (6 000 zł netto) masz na saldzie 10,25 h, za 20 godzin (12 000 zł netto) 21 h. Postęp widzisz w logu panelu, każda godzina ma opis i efekt, a pracę akceptujesz co 2–8 h. Testy jadą na danych syntetycznych, więc dane Twoich klientów nie krążą po wersjach testowych. Kod i prawa zostają w 100% przy Tobie, a fakturę VAT wystawia aveneo, software house działający od 2008 roku, którego marką jest uncrn.

Termin 1 listopada nie jest końcem świata dla aplikacji, która działa. Jest przypomnieniem, że aplikacja mobilna wymaga regularnej uwagi, a im wcześniej ją zaplanujesz, tym mniej godzin pochłonie. Jeśli zaś okaże się, że aplikacji nie warto ratować, lepiej wiedzieć to przed wydaniem pieniędzy niż po.

← wszystkie wpisy