Как технически пуш-уведомление приходит на устройство?

Что проверяют

Понимаете ли вы, через какие звенья проходит пуш, чтобы при баге «уведомление не пришло» знать, где искать. Следом обычно просят перечислить, почему пуш может не дойти, и как это протестировать.

Как отвечать

В цепочке четыре участника: приложение, бэкенд продукта, сервис доставки платформы и сама ОС.

• регистрация: приложение получает токен устройства у сервиса платформы. На Android это FCM (Firebase Cloud Messaging), на iOS APNs; на устройствах без сервисов Google бывают свои, например HMS Push или RuStore. Токен уходит на бэкенд и хранится рядом с пользователем;
• отправка: бэкенд шлёт сообщение с этим токеном в FCM или APNs по HTTPS с авторизацией: у FCM это HTTP v1 API с OAuth-токеном сервисного аккаунта, у APNs ключ .p8 или сертификат;
• доставка: устройство держит с сервисом платформы одно постоянное соединение на все приложения, по нему сообщение и приходит. Если устройство офлайн, сервис хранит его ограниченное время;
• показ: уведомление с блоком notification в фоне показывает сама ОС. Сообщение только с данными (data message на Android, silent push на iOS) будит приложение, и дальше решает его код.

Отсюда набор проверок: приложение открыто, свёрнуто, выгружено; разрешение выдано и отозвано (на Android 13+ это runtime-разрешение POST_NOTIFICATIONS); токен после переустановки и выхода из аккаунта; энергосбережение и «Не беспокоить»; каналы уведомлений на Android; переход по тапу в нужный экран. Тестовый пуш удобно слать из консоли Firebase, в симулятор iOS через xcrun simctl push или запросом к API.

Где спотыкаются

Думают, что сервер продукта соединяется с телефоном напрямую. Без FCM или APNs посередине это не работает.

Не различают notification и data message, поэтому не могут объяснить, почему пуш виден в фоне и не появляется в шторке при открытом приложении.

Проверяют только свежую установку. Много реальных багов связано с устаревшим токеном после переустановки, смены аккаунта или обновления.