Aplikacja odrzucona przez App Store lub Google Play — co zrobić krok po kroku

Wysyłacie aktualizację na dzień przed kampanią, a rano w skrzynce ląduje wiadomość: „We noticed an issue with your app” albo „Twoja aplikacja nie spełnia zasad Google Play”. Wydanie stoi, marketing pyta o termin, a w treści odrzucenia jest numer wytycznej i dwa zdania ogólnika.

Dobra wiadomość: odrzucenie to normalny etap procesu wydawniczego, a nie kara. Zdecydowana większość odrzuceń wraca do sklepu w ciągu jednego–dwóch dni, o ile odpowiecie konkretnie i nie popełnicie kilku typowych błędów. Ten tekst pokazuje, co zrobić po kolei: jak odczytać powód, jak odpowiedzieć recenzentowi, kiedy się odwołać i jak nie wrócić do tego przy kolejnym wydaniu.

Najpierw ustal, co się właściwie stało

Trzy sytuacje wyglądają podobnie w e-mailu, a różnią się skalą problemu:

• Odrzucenie aktualizacji (rejection). Nowa wersja nie przeszła recenzji. Poprzednia wersja nadal działa w sklepie, użytkownicy nie tracą dostępu. To zdecydowanie najczęstszy przypadek i najmniej groźny.
• Usunięcie aplikacji ze sklepu (removal / suspension). Aplikacja przestaje być dostępna do pobrania. Osoby, które już ją mają, zwykle mogą z niej korzystać, ale nowych pobrań nie ma.
• Zawieszenie konta deweloperskiego. Najpoważniejszy scenariusz, zwykle po serii naruszeń albo przy podejrzeniu oszustwa. Dotyczy wszystkich aplikacji na koncie.

Sprawdź to, zanim zaczniesz cokolwiek poprawiać. W App Store Connect status zgłoszenia i wiadomość od recenzenta znajdziesz w Resolution Center. W Google Play Console powód i zakres kary pokazuje sekcja Stan zasad (Policy status) przy aplikacji — to tam, a nie w e-mailu, jest pełna treść decyzji.

Odrębna sprawa, którą łatwo pomylić z karą: aplikacja przestaje być widoczna dla części użytkowników, bo nie spełnia wymaganego poziomu targetSdk. Nikt jej nie odrzucił — minął termin. Opisaliśmy ten przypadek osobno w tekście o tym, dlaczego aplikacja znika z Google Play po terminie target API.

Przeczytaj decyzję dosłownie i znajdź numer wytycznej

Największy błąd na tym etapie to domyślanie się. Recenzent prawie zawsze podaje numer wytycznej — u Apple na przykład 2.1, 4.2 czy 5.1.1, u Google nazwę konkretnej zasady, jak „Uprawnienia i interfejsy API umożliwiające dostęp do informacji poufnych”.

Zrób trzy rzeczy:

1. Otwórz treść tej konkretnej wytycznej w App Store Review Guidelines albo w Centrum zasad Google Play i przeczytaj ją w całości. Numeracja i nazwy zasad zmieniają się z czasem, więc zawsze sprawdzaj w źródle, a nie w artykule sprzed dwóch lat.
2. Wypisz, czego dokładnie dotyczy zarzut — konkretnego ekranu, uprawnienia, wpisu w opisie sklepu czy zrzutu ekranu. Odrzucenie prawie nigdy nie dotyczy „całej aplikacji”.
3. Sprawdź, czy to problem w kodzie, czy w metadanych. To rozróżnienie decyduje o tym, ile zajmie poprawka. Zmiana opisu, zrzutów ekranu, formularza o danych czy polityki prywatności nie wymaga nowej wersji aplikacji i bywa gotowa w godzinę.

Najczęstsze powody odrzucenia w App Store

Apple odrzuca ręcznie i szczegółowo. Kilka kategorii wraca regularnie:

• Aplikacja nie działa u recenzenta. Crash przy starcie, ekran logowania bez działającego konta testowego, funkcja, do której nie da się dojść. To najczęstszy powód odrzuceń i zwykle najprostszy do usunięcia: konto demo, dokładna ścieżka w notatkach dla recenzenta, nagranie wideo.
• Za mało funkcji lub aplikacja jest opakowaną stroną WWW. Jeśli aplikacja to głównie widok przeglądarki z tą samą treścią co serwis, Apple oczekuje realnej wartości natywnej: powiadomień, pracy offline, integracji z systemem.
• Prywatność i konta użytkowników. Zbieranie danych bez wyraźnej zgody, brak polityki prywatności, wymuszanie rejestracji tam, gdzie nie jest potrzebna. Osobna, często pomijana rzecz: aplikacja, która pozwala założyć konto, musi też pozwalać je usunąć z poziomu aplikacji.
• Płatności poza mechanizmem sklepu. Sprzedaż treści cyfrowych z pominięciem zakupów w aplikacji albo odsyłanie do płatności w przeglądarce. Granicę między tym, co dozwolone, a co nie, rozrysowaliśmy w tekście BLIK a wytyczne App Store i Google Play.
• Metadane niezgodne z aplikacją. Zrzuty ekranu z funkcjami, których nie ma, obce marki w opisie, zła kategoria wiekowa, placeholdery w tekstach.
• Śledzenie bez zgody. Korzystanie z identyfikatora reklamowego lub SDK marketingowych bez okna zgody na śledzenie.

Najczęstsze powody odrzucenia w Google Play

Google w dużej mierze ocenia automatycznie, dlatego decyzje bywają bardziej suche, a najczęstsze problemy dotyczą deklaracji, a nie kodu:

• Wrażliwe uprawnienia bez uzasadnienia. Lokalizacja w tle, dostęp do SMS-ów i historii połączeń, dostęp do wszystkich plików, lista zainstalowanych aplikacji. Każde z nich wymaga deklaracji i realnej, widocznej dla użytkownika funkcji. Jeśli uprawnienie zostało w projekcie po bibliotece, której już nie używacie — usuńcie je, to najszybsza droga.
• Formularz Bezpieczeństwo danych niezgodny ze stanem faktycznym. Aplikacja wysyła dane, których nie zadeklarowaliście — najczęściej przez SDK analityki lub reklam dodane przy okazji innej zmiany. Formularz trzeba aktualizować przy każdej zmianie zestawu bibliotek.
• Brak lub niedostępna polityka prywatności. Link musi działać, prowadzić do strony publicznej i opisywać tę konkretną aplikację.
• Aplikacja nie działa poprawnie. Awarie, puste ekrany, funkcje niedostępne bez logowania, brak danych testowych.
• Treść i metadane. Obietnice w opisie niepokryte funkcjami, słowa kluczowe upchane w tytule, kategoria niezgodna z zawartością, nieprawidłowa deklaracja dla aplikacji kierowanych do dzieci.
• Wymagania techniczne. Poziom targetSdk, wymagane deklaracje dla aplikacji finansowych, zdrowotnych czy AI — zestaw zasad rośnie z roku na rok.

Co zrobić w pierwszej godzinie

1. Nie wysyłaj ponownie tej samej wersji. Ponowne zgłoszenie bez zmian i bez wyjaśnienia najczęściej kończy się tym samym odrzuceniem, a przy Google podbija licznik naruszeń na koncie.
2. Zrób zrzut całej decyzji. Treść wiadomości, numer wytycznej, datę, numer wersji. Przy dłuższej wymianie zdań z recenzentem ta historia jest bezcenna.
3. Odtwórz problem u siebie. Na tym samym modelu urządzenia i wersji systemu co recenzent, jeśli je podał, i na tym samym buildzie, który wysłaliście — nie na wersji deweloperskiej.
4. Sprawdź, czy poprawka wymaga nowej wersji. Metadane, formularz danych, polityka prywatności i deklaracje uprawnień zmienia się bez wydawania aplikacji.
5. Przygotuj dowody. Działające konto testowe bez wygasania, krótkie nagranie ekranu pokazujące kwestionowaną funkcję, notatki dla recenzenta po angielsku.

Jak napisać odpowiedź do recenzenta

Odpowiedź, która działa, jest krótka, rzeczowa i odnosi się punkt po punkcie do zarzutu. Recenzent nie zna Waszego produktu i nie ma czasu go poznawać.

Kilka zasad, które realnie skracają wymianę wiadomości:

• Pisz po angielsku, konkretnie i bez emocji. „Nie zgadzamy się” bez dowodów wydłuża proces o kolejne rundy.
• Odnieś się do numeru wytycznej i napisz wprost, co zmieniliście albo dlaczego uważacie, że wymóg jest spełniony.
• Podaj dokładną ścieżkę. „Zaloguj się kontem demo, ekran główny → Zamówienia → przycisk Nowe zamówienie” jest warte więcej niż akapit wyjaśnień.
• Dołącz nagranie. Przy zarzutach typu „nie mogliśmy uruchomić funkcji” wideo rozstrzyga sprawę najszybciej.
• Jeśli to wymóg prawny, powiedz to wprost i wskaż przepis — na przykład przy weryfikacji tożsamości w aplikacji finansowej.
• Nie zmieniaj przy okazji dziesięciu innych rzeczy. Im mniejsza różnica między wersjami, tym krótsza recenzja i tym łatwiej ustalić, co zadziałało.

Kiedy się odwołać

Jeżeli po przeczytaniu wytycznej nadal uważacie, że decyzja jest błędna, obie platformy mają ścieżkę odwoławczą.

Apple. Najpierw wyjaśnienie w Resolution Center — część odrzuceń wynika po prostu z nieporozumienia i kończy się tam. Jeśli to nie pomoże, można poprosić o ponowne rozpatrzenie przez zespół odwoławczy (App Review Board) albo, gdy Wasz przypadek nie mieści się w zasadzie, złożyć wniosek o wyjątek od wytycznej.

Google. Odwołanie składa się przez formularz w Play Console, przy konkretnym naruszeniu w sekcji Stan zasad. W odwołaniu opisz, co dokładnie robi aplikacja, dlaczego uprawnienie jest jej potrzebne i co już poprawiliście. Przy decyzjach automatycznych to często jedyny sposób, żeby sprawę zobaczył człowiek.

Odwołanie ma sens, gdy macie argument merytoryczny. Jeśli zarzut jest trafny, szybciej jest poprawić i wydać nową wersję niż spierać się przez tydzień.

Ile to trwa

Apple podaje, że większość zgłoszeń rozpatruje w ciągu jednego–dwóch dni, a po poprawce zgłoszenie wraca do kolejki od nowa. Google potrafi zatwierdzić aktualizację w kilka godzin, ale przy nowych kontach, wrażliwych uprawnieniach i po naruszeniu recenzja trwa dłużej — nawet ponad tydzień. Odwołania są wolniejsze od zwykłej recenzji.

Praktyczny wniosek dla planowania wydań: nie wypuszczaj aktualizacji krytycznej dla biznesu dzień przed terminem. Zapas dwóch–trzech dni roboczych kosztuje nic, a oszczędza sytuacji, w której kampania rusza bez aplikacji. Przy aplikacjach z regularnymi wydaniami warto też zbudować proces wydawniczy, w którym zgłoszenie do sklepu jest rutyną, a nie jednorazową akcją.

Gdy aplikacja została usunięta, a nie odrzucona

Tu tryb działania jest inny, bo tykający zegar to utracone pobrania:

1. Sprawdź zakres. W Play Console zobaczysz, czy to usunięcie z listingu, ograniczenie w wybranych krajach, czy zawieszenie. U Apple informację znajdziesz w wiadomości i statusie aplikacji.
2. Ustal, czy problem dotyczy jednej wersji, czy konta. Naruszenie na poziomie konta wymaga uporządkowania wszystkich aplikacji, nie tylko tej jednej.
3. Popraw i zgłoś wraz z wyjaśnieniem. Przy usunięciu sama poprawka nie wystarczy — trzeba przejść przez odwołanie albo ponowne zgłoszenie z opisem zmian.
4. Zadbaj o komunikację. Użytkownicy, którzy nie mogą pobrać aplikacji, zostawiają oceny. Krótka informacja na stronie i w mediach ogranicza szkody.

Jeśli przy okazji okazuje się, że nie macie dostępu do konta w sklepie, kluczy podpisujących ani aktualnego kodu, problem jest większy niż odrzucenie — to kwestia odzyskania kontroli nad projektem.

Jak ograniczyć ryzyko przy kolejnym wydaniu

Odrzuceń nie da się wyeliminować, ale da się je uczynić rzadkimi:

• Stałe konto testowe, które nie wygasa, nie wymaga SMS-a z polskiego numeru i ma dane demonstracyjne.
• Notatki dla recenzenta z opisem, jak dojść do funkcji wymagających kontekstu — skanowania kodu, płatności, integracji z urządzeniem.
• Przegląd uprawnień przed każdym wydaniem. Po każdej zmianie bibliotek sprawdź, co faktycznie trafiło do manifestu aplikacji.
• Aktualizacja formularza o danych razem z każdą zmianą SDK, nie raz na rok.
• Testy na najnowszej wersji systemu — także w wersji beta, zanim trafi do użytkowników.
• Stopniowe udostępnianie wydania (staged rollout), żeby błąd nie trafił od razu do wszystkich.
• Wewnętrzna lista kontrolna oparta na Waszych poprzednich odrzuceniach. Powtarzają się zaskakująco często.

Podsumowanie

Odrzucenie aplikacji jest irytujące, ale w większości przypadków to sprawa na jeden dzień pracy: przeczytać wytyczną, ustalić, czy problem jest w kodzie czy w deklaracjach, poprawić jedną rzecz i odpowiedzieć konkretnie. Problemem staje się dopiero wtedy, gdy nikt w firmie nie rozumie decyzji, nie ma kto przygotować nowego wydania albo dostępy do sklepu są u kogoś, z kim nie ma kontaktu.

Rozwiązywanie odrzuceń, wydania na App Store i Google Play oraz coroczne podbicia wymagań sklepów robimy w ramach utrzymania aplikacji mobilnych — w wymiarze godzin dopasowanym do projektu, o czym więcej w tekście o koszcie utrzymania aplikacji. Jeśli aplikacja od dawna nie miała wydania i nie wiadomo, czy w ogóle się jeszcze zbuduje, zacznij od reaktywacji albo po prostu napisz do nas.