Powiadomienia push przestały działać — najczęstsze przyczyny i jak je naprawić

Powiadomienia push to często najważniejszy kanał kontaktu aplikacji z użytkownikiem: przypomnienie o wizycie, status zamówienia, kod do logowania, informacja o promocji. Gdy przestają dochodzić, nikt tego od razu nie zauważa — aplikacja się nie wyłącza, w panelu sklepu nie ma alarmu, a wysyłka po stronie backendu „przechodzi”. Pierwszym sygnałem bywa spadek zamówień albo pytanie od klienta, dlaczego nie dostał przypomnienia.

Dobra wiadomość: przyczyn jest skończenie wiele i większość da się zdiagnozować w ciągu jednego–dwóch dni. Ten tekst opisuje, jak ustalić, gdzie leży problem, i jak go naprawić — po kolei, od najczęstszych przypadków.

Jak działa wysyłka powiadomień push

Żeby szukać przyczyny, trzeba wiedzieć, przez ile rąk przechodzi jedno powiadomienie:

1. Aplikacja przy starcie rejestruje się w usłudze push i dostaje token urządzenia.
2. Aplikacja wysyła token do Twojego backendu, który go zapisuje.
3. Gdy trzeba wysłać powiadomienie, backend wysyła je do usługi push: Firebase Cloud Messaging (FCM) dla Androida, Apple Push Notification service (APNs) dla iOS. Często iOS też idzie przez FCM, które przekazuje wiadomość dalej do APNs.
4. Usługa push dostarcza wiadomość do urządzenia.
5. System urządzenia decyduje, czy powiadomienie pokazać — zależnie od zgody użytkownika, kanałów, trybu oszczędzania baterii i skupienia.

Problem może być na każdym z tych etapów. Dlatego zanim ktokolwiek zacznie zmieniać kod, warto ustalić, kogo problem dotyczy.

Krok 1: ustal zakres problemu

Kilka pytań, które zawężają poszukiwania bardziej niż godzina czytania kodu:

• Wszyscy użytkownicy czy tylko część? Jeśli nikt nie dostaje powiadomień — problem jest prawie na pewno po stronie backendu albo konfiguracji usługi push.
• Jedna platforma czy obie? Gdy Android działa, a iOS nie (lub odwrotnie), szukaj w konfiguracji tej jednej platformy: certyfikatach APNs, kluczach w Firebase, uprawnieniach.
• Od kiedy? Zestaw datę z wydaniami aplikacji, zmianami na serwerze i terminami ogłaszanymi przez Google i Apple.
• Nowi czy dotychczasowi użytkownicy? Jeśli powiadomienia nie dochodzą tylko do osób, które zainstalowały aplikację niedawno, problem leży zwykle w prośbie o zgodę albo w rejestracji tokenu.
• Konkretni producenci telefonów? Skargi tylko od użytkowników Xiaomi albo Huawei wskazują na oszczędzanie baterii albo brak usług Google.

Następnie zajrzyj do logów backendu z odpowiedziami usług push. FCM i APNs zwracają przy każdej wysyłce konkretny kod błędu — UNREGISTERED, THIRD_PARTY_AUTH_ERROR, BadDeviceToken, ExpiredProviderToken. Jeśli backend tych odpowiedzi nie zapisuje, to pierwsza rzecz do poprawienia — bez nich diagnozujesz po omacku.

Najczęstsze przyczyny

Poniżej szczegóły każdej z tych przyczyn.

Stare API Firebase Cloud Messaging

To najczęstsza przyczyna w aplikacjach, których nikt nie rozwijał od kilku lat. Google oznaczył starsze API wysyłki FCM (tzw. legacy HTTP i XMPP, z autoryzacją kluczem serwera) jako przestarzałe w czerwcu 2023 r., a od 2024 r. je wyłączał. Backend, który wysyłał powiadomienia „po staremu”, dostaje dziś błędy — a jeśli nikt nie zapisuje odpowiedzi FCM, wygląda to tak, jakby wysyłka działała.

Naprawa polega na przejściu na FCM HTTP v1 API: zamiast stałego klucza serwera backend używa konta serwisowego Google i krótko żyjących tokenów OAuth 2.0, a format wiadomości jest nieco inny. Zmiana dotyczy wyłącznie backendu — aplikacji w sklepie nie trzeba aktualizować. Przy typowym backendzie to praca na jeden–trzy dni razem z testami.

Jeśli wysyłacie przez pośrednika — OneSignal, Azure Notification Hubs, Expo — sprawdź, czy w jego panelu skonfigurowane są dane dostępowe do FCM v1. Ci dostawcy również wymagali migracji.

Certyfikaty i klucze APNs (iOS)

Apple pozwala uwierzytelniać się w APNs na dwa sposoby:

• Certyfikat (.p12) — ważny rok. Po wygaśnięciu wysyłka na iOS przestaje działać z dnia na dzień, a Android działa dalej. Przy aplikacjach, które przejmujemy, to wciąż częsty scenariusz: certyfikat odnawiała osoba, która już nie współpracuje z firmą.
• Klucz (.p8) — nie wygasa, działa dla wszystkich aplikacji na koncie. Może jednak zostać unieważniony, np. przy porządkowaniu konta.

Jeśli iOS idzie przez FCM, certyfikat lub klucz jest wgrany w ustawieniach projektu Firebase. Wygaśnięcie objawia się tam błędem THIRD_PARTY_AUTH_ERROR. Rozwiązanie: wygeneruj klucz .p8, wgraj go do Firebase (albo do własnego backendu) i usuń stary certyfikat z konfiguracji. Przy okazji zapisz, kto ma dostęp do konta Apple Developer — to częsty problem, gdy programista zniknął.

Inne błędy po stronie iOS:

• Pomylone środowiska. Wersje deweloperskie dostają tokeny środowiska sandbox, a TestFlight i App Store — production. Token wysłany do złego środowiska kończy się błędem BadDeviceToken.
• Token JWT dla APNs musi być odświeżany — APNs odrzuca token starszy niż godzina (ExpiredProviderToken) i nie lubi, gdy generujesz nowy przy każdej wysyłce.
• Stary magazyn certyfikatów na serwerze. Na początku 2025 r. Apple zmienił urząd certyfikacji serwerów APNs. Backend uruchomiony na starym systemie albo starej wersji Javy może nie ufać nowemu certyfikatowi i nie nawiązać połączenia.

Do testów przydaje się Push Notifications Console w panelu Apple Developer: pozwala wysłać testowe powiadomienie na konkretny token i sprawdzić log dostarczenia.

Zgoda na powiadomienia w Androidzie 13 i nowszych

Od Androida 13 powiadomienia wymagają zgody użytkownika, tak jak na iOS. Aplikacja, która celuje w Androida 13 lub nowszego (target API 33+), musi sama poprosić o uprawnienie POST_NOTIFICATIONS. Jeśli tego nie robi, nowi użytkownicy mają powiadomienia wyłączone i nawet o tym nie wiedzą.

To częsty skutek uboczny wymuszonych aktualizacji. Google Play wymaga, by aktualizacje celowały w coraz nowsze API — w 2026 r. jest to API 36. Ktoś podnosi target API, żeby aplikacja przeszła przez sklep, nie dodaje prośby o zgodę — i od tej wersji nowi użytkownicy przestają dostawać powiadomienia. Dotychczasowi zwykle zachowują zgodę, więc problem narasta powoli i trudno go powiązać z konkretnym wydaniem.

Przy okazji sprawdź kanały powiadomień (od Androida 8). Powiadomienie wysłane na kanał, którego aplikacja nie utworzyła, nie zostanie pokazane. Użytkownik może też wyłączyć pojedynczy kanał, np. „Promocje”, zostawiając inne.

Dobra praktyka to prośba o zgodę w momencie, w którym ma sens — np. po złożeniu zamówienia („Powiadomić Cię o statusie dostawy?”), a nie przy pierwszym uruchomieniu. Odmowy przy pierwszym starcie są najczęstsze, a szans jest mało: iOS pokazuje systemowe okno tylko raz, Android po dwóch odmowach przestaje je wyświetlać. Więcej o zmianach w nowych wersjach systemów: aplikacja nie działa na nowym Androidzie lub iOS.

Tokeny urządzeń: nieaktualne i niezapisane

Token urządzenia nie jest stały. Zmienia się po ponownej instalacji aplikacji, wyczyszczeniu danych, przywróceniu telefonu z kopii, a czasem bez wyraźnego powodu. FCM uznaje za wygasły token urządzenia, które nie łączyło się z usługą przez ponad 270 dni.

Typowe błędy w tej części:

• Aplikacja wysyła token tylko przy pierwszej rejestracji, a nie po jego odświeżeniu. Backend wysyła na stary token, który już nie działa.
• Backend nie usuwa nieaktualnych tokenów. Odpowiedzi UNREGISTERED czy BadDeviceToken są ignorowane, baza rośnie, a statystyki wysyłek są coraz mniej wiarygodne.
• Token jest przypisany do konta, a nie do urządzenia. Użytkownik z telefonem i tabletem dostaje powiadomienia tylko na jedno z nich — albo po wylogowaniu wciąż dostaje powiadomienia cudzego konta.

Zalecenie Firebase: aplikacja przy każdym starcie (lub co najmniej raz w miesiącu) przesyła aktualny token razem z datą, a backend usuwa tokeny, które zwracają błąd albo długo się nie odświeżały.

Oszczędzanie baterii i telefony bez usług Google

Android pozwala producentom ingerować w działanie aplikacji w tle. Xiaomi, Samsung, Oppo czy Huawei mają własne mechanizmy usypiania aplikacji, które potrafią opóźniać albo blokować powiadomienia — zwłaszcza w aplikacjach rzadko otwieranych.

Co możesz zrobić po stronie aplikacji i backendu:

• Wysyłaj powiadomienia widoczne dla użytkownika z wysokim priorytetem — ale tylko te. Android obniża priorytet aplikacjom, które wysyłają wiadomości o wysokim priorytecie, a potem nie pokazują powiadomienia.
• Używaj wiadomości z sekcją notification dla zwykłych powiadomień. Wiadomości z samymi danymi (data-only) wymagają, żeby aplikacja się wybudziła i sama zbudowała powiadomienie — a to jest dokładnie to, co blokuje oszczędzanie baterii.
• Na iOS ciche powiadomienia (content-available) są ograniczane przez system i nie docierają do aplikacji zamkniętej ręcznie przez użytkownika. Nie opieraj na nich niczego, co musi dotrzeć.

Osobny przypadek to telefony Huawei bez usług Google (modele sprzedawane od 2019–2020 r.). FCM na nich nie działa. Jeśli ta grupa jest dla Ciebie ważna, potrzebna jest integracja z Huawei Push Kit — albo świadoma decyzja, że ci użytkownicy dostaną informacje inną drogą, np. SMS-em lub e-mailem.

Problem po przeniesieniu aplikacji lub zmianie wykonawcy

Przy przeniesieniu aplikacji na inne konto albo przejęciu jej od innej firmy powiadomienia psują się bardzo często, bo ich konfiguracja jest rozsiana po kilku miejscach:

• projekt Firebase może należeć do konta Google poprzedniego wykonawcy — wtedy razem z nim możesz stracić dostęp do wysyłki i statystyk,
• klucz APNs jest przypisany do zespołu w Apple Developer; po przeniesieniu aplikacji na inne konto trzeba wygenerować nowy klucz w nowym zespole,
• dane dostępowe do usługi push leżą w zmiennych środowiskowych serwera, do którego nikt nie ma dostępu.

Dlatego dostęp do Firebase, kluczy APNs i konfiguracji serwera powinien być na liście rzeczy do odebrania przy każdej zmianie wykonawcy.

Jak testować, żeby nie zgadywać

Kolejność, która pozwala szybko wskazać etap, na którym ginie powiadomienie:

1. Wyślij testowe powiadomienie bezpośrednio na token konkretnego urządzenia — z konsoli Firebase (Android i iOS przez FCM) albo z Push Notifications Console Apple. Jeśli dochodzi, usługa push i urządzenie działają, a problem jest w backendzie.
2. Wyślij to samo z backendu i sprawdź odpowiedź usługi push. Błąd autoryzacji wskazuje na klucze i API, błąd tokenu — na rejestrację.
3. Zainstaluj aplikację od zera na Androidzie 13+ i na iOS. Sprawdź, czy aplikacja prosi o zgodę i czy token trafia do backendu.
4. Sprawdź raporty dostarczeń. Firebase pokazuje statystyki dostarczenia wiadomości (z możliwością eksportu do BigQuery), Apple — log dostarczenia dla konkretnego tokenu.

Na przyszłość warto mierzyć odsetek udanych wysyłek i liczbę błędów w czasie — tak samo, jak monitoruje się awarie aplikacji. Nagły skok błędów to sygnał, że coś się zmieniło, zanim zauważą to klienci.

Ile trwa naprawa

Czas zależy głównie od tego, czy masz dostęp do kodu, kont i serwera. Jeśli trzeba najpierw odzyskać dostęp do Firebase albo konta Apple Developer, to zwykle ten etap trwa najdłużej.

Podsumowanie

Powiadomienia push przestają działać zwykle z jednego z kilku powodów: wyłączone stare API FCM, wygasły certyfikat APNs, brak prośby o zgodę po podniesieniu target API, nieaktualne tokeny albo konfiguracja, która została na koncie poprzedniego wykonawcy. Zacznij od ustalenia zakresu problemu i od odpowiedzi usług push w logach — to w większości przypadków wskazuje przyczynę bez długiego szukania.

Jeśli powiadomienia w Twojej aplikacji przestały dochodzić i nie wiesz, od czego zacząć, zamów bezpłatną analizę aplikacji — sprawdzimy konfigurację wysyłki, uprawnienia i dostęp do kont. Stałą opiekę nad aplikacją, w tym nad kluczami, certyfikatami i dostosowaniem do nowych wersji systemów, prowadzimy w ramach utrzymania aplikacji mobilnych.