Push-уведомления есть почти в каждом приложении, и вопросы о них проверяют понимание платформ: как устроена доставка, почему тихий push ненадёжен, как открыть экран по нажатию.
Как это работает
приложение → токен устройства → ваш сервер
ваш сервер → APNs / FCM (по токену) → устройство
Устройство держит одно системное соединение с сервисом платформы. Прямых соединений вашего сервера с телефоном нет.
Токен меняется: при переустановке, восстановлении из бэкапа, по решению сервиса (onNewToken в FCM). Поэтому его отправляют на сервер при каждом получении, привязывают к пользователю и устройству и удаляют привязку при выходе из аккаунта.
Авторизация в APNs: ключ .p8 с JWT (не истекает, один на все приложения команды) или устаревающий ежегодно сертификат. Отдельные окружения sandbox и production: сборка не того окружения не получит пуши.
Разрешение
На iOS разрешение запрашивают через requestAuthorization, на Android с версии 13 нужно runtime-разрешение POST_NOTIFICATIONS. Спрашивают в момент понятной пользы («сообщить о доставке заказа?»), а не при первом запуске: отказ потом трудно изменить.
Типы уведомлений
- Видимые: заголовок, текст, звук, бейдж.
- Тихие (
content-available: 1на iOS, data-сообщения на Android): будят приложение для короткой фоновой работы. Apple ограничивает частоту и не доставляет их, если пользователь принудительно закрыл приложение. Строить на них критичную логику нельзя. - Rich: картинка, видео, кнопки действий, ответ из уведомления.
FCM на Android: notification-сообщение в фоне показывает система сама; data-сообщение всегда приходит в onMessageReceived, и приложение само строит уведомление.
Notification Service Extension (iOS): при mutable-content: 1 расширение получает около 30 секунд, чтобы изменить уведомление: расшифровать текст (сквозное шифрование), скачать картинку.
Размер payload ограничен примерно 4 КБ: в push кладут идентификаторы и короткий текст, остальное догружают.
Нажатие
В payload кладут маршрут или deep link. Обработчик нажатия передаёт его в общий роутер, который учитывает вход, онбординг и состояние приложения. Один код для ссылок, пушей и виджетов.
Надёжность
Доставка не гарантирована. Путь делят на этапы и меряют каждый:
- Сервер отправил.
- APNs/FCM принял.
- Устройство получило (событие из Notification Service Extension или
onMessageReceived). - Пользователь открыл.
Типичные потери: устаревшие токены, неверное окружение, отключённые уведомления или категории, агрессивное энергосбережение у некоторых производителей Android, устройства без сервисов Google. Для них подключают альтернативных провайдеров (в РФ, например, RuStore Push или HMS Push Kit) через общую абстракцию.
Архитектурный вывод: push это сигнал, а не транспорт данных. Сообщения и статусы всё равно синхронизируются при открытии приложения.
Пользователь и спам
Настройки по категориям (на Android notification channels, на iOS категории и сводки), частотные лимиты на сервере, тихие часы. Иначе пользователь отключит всё.
Что спросят на собесе
- Как push доходит от сервера до устройства?
- Что делать с токеном и когда он меняется?
- Чем тихий push отличается от обычного и почему он ненадёжен?
- Как показать картинку или расшифровать текст уведомления на iOS?
- Как открыть нужный экран по нажатию?