Silent push-уведомления: как работают, настройка на iOS и Android и сценарии использования

Большинство гайдов по пушам разбирают сообщения, которые пользователь видит. Silent push-уведомления — это те, которые он не видит никогда, и работают они совершенно иначе.

Тихий пуш будит приложение в фоне, выполняет задачу и снова усыпляет его. Ни баннера, ни звука, ни бейджа. Пользователь открывает приложение — а свежий контент уже подгружен. Он даже не догадывается, что пришёл пуш. В этом и смысл.

В этом гайде — как silent push-уведомления работают на iOS и Android, как выглядит реализация в коде и как встроить их в автоматизацию customer journey. Попутно вы увидите, как Pushwoosh обеспечивает кросс-платформенную доставку тихих пушей и интегрирует их в автоматизированные сценарии. Тема особенно актуальна в июне: после WWDC команды пересматривают логику фоновых обновлений под изменения в iOS, и понимать механику silent push стоит заранее.

Что такое silent push-уведомления?

Silent push-уведомления — это инициированные сервером сообщения, которые будят приложение в фоне, ничего не показывая пользователю. Ни баннера, ни звука, ни бейджа. ОС получает пуш, на короткое время активирует приложение, оно выполняет фоновую задачу и снова засыпает.

Разница с обычным пушем простая: видимый пуш — это сообщение пользователю, а тихий пуш — это инструкция приложению.

Что приложение успевает сделать за эти фоновые секунды?

• Подгрузить новый контент. Получить свежие статьи, обновлённый каталог товаров или ленту — чтобы всё было готово к моменту открытия приложения.
• Синхронизировать данные. Обновить локальное состояние с изменениями, которые произошли на сервере или в других каналах: покупка на сайте, смена статуса в backend-системе.
• Проверить геопозицию. Оценить, вошёл ли пользователь в геозону или вышел из неё, без видимого уведомления в роли триггера.
• Обновить теги или сегментные данные. Отправить актуальные поведенческие сигналы обратно в CDP, чтобы таргетинг оставался точным.
• Подготовить контент к будущему видимому уведомлению. Заранее загрузить in-app сообщение или rich push payload, чтобы он отрисовался мгновенно.

Практическая ценность: пользователь открывает приложение, которое уже актуально. Никакого спиннера загрузки, никаких устаревших данных. Это ощущение скорости и свежести измеримо влияет на удержание — даже когда пользователь не может объяснить, почему приложением приятно пользоваться.

Как работают silent push-уведомления

Цепочка доставки та же, что у обычного пуша: ваш сервер отправляет payload в APNs (iOS) или FCM (Android), сервис доставляет его на устройство, ОС его обрабатывает. Отличается структура payload и то, что ОС делает при получении.

Поток доставки

1. Сервер отправляет payload. Ваш backend или Pushwoosh отправляет специально сформированное сообщение в APNs или FCM.
2. Сервис доставляет на устройство. APNs или FCM маршрутизирует payload на нужное устройство по сохранённому device token.
3. ОС будит приложение. Распознав флаги silent push в payload, ОС на короткое время активирует приложение в фоне.
4. Приложение выполняет фоновую задачу. Ваш код отрабатывает: подгрузить данные, синхронизировать состояние, проверить геопозицию, обновить тег.
5. Приложение сигнализирует о завершении. На iOS приложение вызывает completion handler. На Android onMessageReceived() возвращает управление. ОС снова усыпляет приложение.

Фоновое окно ограничено. iOS даёт примерно 30 секунд. На Android время зависит от устройства и режима энергопотребления. Фоновые задачи должны быть быстрыми или спроектированными под эти ограничения.

Различия payload: iOS vs. Android

Самая частая ошибка на iOS — забыть выставить apns-priority: 5 вместе с apns-push-type: background. Если priority равен 10 (значение по умолчанию для видимых пушей), Apple может отклонить сообщение или отобразить его визуально даже без alert-тела. Именно низкий priority сигнализирует APNs, что это фоновая задача, а не срочное уведомление.

На Android ключевое правило проще: никакого notification-объекта в FCM payload. Если notification-объект присутствует, Android обработает его как обычный пуш и покажет. Silent push — это только data.

Реализация на iOS

Настройка в Xcode

Включите Background Modes в Xcode до того, как писать код:

1. Откройте проект и выберите ваш app target.
2. Перейдите в ‘Signing & Capabilities’ и нажмите ’+ Capability’.
3. Добавьте ‘Background Modes’ и отметьте ‘Remote Notifications’.

У вашего App ID в Apple Developer Portal должны быть включены Push Notifications. После этого изменения перегенерируйте provisioning profiles.

Регистрация для remote notifications

Тихие пуши всё равно требуют регистрации устройства в APNs. Обрабатывайте это в AppDelegate:

import UIKit
import UserNotifications

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {

    func application(_ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions:
            [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

        UNUserNotificationCenter.current().delegate = self
        UNUserNotificationCenter.current().requestAuthorization(
            options: [.badge, .sound, .alert]
        ) { granted, _ in
            if granted {
                DispatchQueue.main.async {
                    application.registerForRemoteNotifications()
                }
            }
        }
        return true
    }

    func application(_ application: UIApplication,
        didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {
        let token = deviceToken.map {
            String(format: "%02.2hhx", $0) }.joined()
        // Pushwoosh iOS SDK отправляет токен автоматически
    }
}

Обработка silent push

Этот метод iOS вызывает при получении тихого пуша:

extension AppDelegate {

    func application(_ application: UIApplication,
        didReceiveRemoteNotification userInfo: [AnyHashable: Any],
        fetchCompletionHandler completionHandler:
            @escaping (UIBackgroundFetchResult) -> Void) {

        guard let aps = userInfo["aps"] as? [String: AnyObject],
              aps["content-available"] as? Int == 1 else {
            completionHandler(.noData)
            return
        }

        // Здесь выполняется ваша фоновая задача
        fetchLatestContent { success in
            completionHandler(success ? .newData : .noData)
        }
    }
}

Всегда вызывайте completionHandler до закрытия 30-секундного окна. Иначе iOS может завершить приложение и начать троттлить будущие silent push. Передавайте .newData, если что-то подгрузили, .noData, если ничего не изменилось, .failed, если задача завершилась с ошибкой.

APNs payload для silent push

{
    "aps": {
        "content-available": 1
    },
    "update_type": "content_refresh",
    "content_id": "latest_feed"
}

Обязательные заголовки APNs вместе с этим payload:

• apns-push-type: background
• apns-priority: 5

Реализация на Android

Настройка FCM и манифест

Добавьте FirebaseMessagingService в AndroidManifest.xml:

<service
    android:name=".MyFirebaseMessagingService"
    android:exported="false">
    <intent-filter>
        <action android:name="com.google.firebase.MESSAGING_EVENT" />
    </intent-filter>
</service>

Обработка data-сообщений на Kotlin

Расширьте FirebaseMessagingService и реализуйте onMessageReceived:

class MyFirebaseMessagingService : FirebaseMessagingService() {

    override fun onNewToken(token: String) {
        // Pushwoosh Android SDK отправляет токен автоматически
    }

    override fun onMessageReceived(remoteMessage: RemoteMessage) {
        // Silent push = только data payload, без notification-объекта
        if (remoteMessage.data.isNotEmpty()
            && remoteMessage.notification == null) {
            handleSilentPush(remoteMessage.data)
        }
    }

    private fun handleSilentPush(data: Map<String, String>) {
        when (data["update_type"]) {
            "content_refresh" -> {
                // Подгрузить новый контент с вашего сервера
                refreshContentFeed(data["content_id"])
            }
            "segment_update" -> {
                // Отправить обновлённые теги в Pushwoosh
                syncUserSegmentData()
            }
            "location_check" -> {
                // Оценить текущий статус геозоны
                evaluateGeofences()
            }
        }
    }
}

FCM payload для silent push

Payload должен содержать data-объект и не содержать notification-объекта:

{
    "to": "DEVICE_TOKEN",
    "data": {
        "update_type": "content_refresh",
        "content_id": "latest_news_feed"
    }
}

Выставляйте priority в ‘high’ только для срочных фоновых задач. Для большинства сценариев обновления контента подходит стандартный priority — он не нагружает батарею лишний раз.

Кросс-платформенный silent push с Pushwoosh

Управлять silent push вручную на iOS и Android — значит поддерживать два разных формата payload, два набора заголовков доставки и две интеграции SDK. Pushwoosh снимает эту нагрузку.

Когда вы запускаете silent push через Pushwoosh — из интерфейса или через API — платформа автоматически формирует корректный payload для каждой целевой платформы. APNs получает content-available: 1 с правильными заголовками. FCM получает data-only сообщение. Кампанию вы настраиваете один раз. Для диаспорных команд, у которых аудитория делится между iOS и Android примерно поровну, это особенно важно: один SDK, один API и один дашборд вместо двух параллельных интеграций — там, где OneSignal или «голый» Firebase оставляют вас наедине с двумя кодовыми путями.

Управление device token централизовано. iOS-токены, Android-токены и web push-подписки хранятся и обновляются в одном месте. При смене токена (переустановка, обновление ОС) Pushwoosh обрабатывает обновление сам.

Для нетехнических участников команды Pushwoosh даёт интерфейс для планирования и запуска тихих пушей без написания payload. Это делает практичным встраивание silent push в сценарии Customer Journey Builder наряду с видимыми уведомлениями и in-app сообщениями.

Стратегические сценарии использования

Silent push-уведомления наиболее ценны там, где видимость работала бы против вас. Вот сценарии, где они подходят лучше обычного пуша — с уклоном в e-commerce, gaming и FinTech, ключевые вертикали для продуктовых команд.

Предзагрузка контента для e-commerce и медиа-приложений

E-commerce приложение, которое отправляет промо-алерт о распродаже, выигрывает от silent push, отправленного на 30 секунд раньше. Тихий пуш будит приложение, оно подгружает обновлённый каталог и кеширует его локально. Когда срабатывает видимый алерт, тап по нему мгновенно открывает страницу акции. Никакого ожидания загрузки товаров.

Для приложений с персонализированными лентами silent push в типичное время пробуждения подгружает утренний контент до того, как пользователь откроет приложение. Приложение кажется быстрым, потому что оно действительно быстрое — данные уже на месте.

Оценка геозоны без видимого триггера

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

Подход через silent push: сервер отправляет тихий пуш, когда пользователь находится в пределах региона. Приложение проверяет точную геозону на стороне клиента. При совпадении условий активирует in-app сообщение или local notification в нужный момент. Видимая коммуникация происходит, только если логика прошла — а не как сам триггер.

Точные данные сегмента после активности вне приложения

Пользователь делает покупку на вашем сайте. Его RFM-сегмент должен обновиться немедленно. Но приложение не знает об этом, пока пользователь его не откроет. Для FinTech-приложений тот же принцип работает с транзакциями: статус операции меняется на сервере, и фоновое обновление синхронизирует его без видимого алерта.

Silent push, отправленный после покупки на сайте, будит приложение в фоне, и оно синхронизирует свежее событие покупки в Pushwoosh. Пользователь попадает в правильный RFM-сегмент в реальном времени. Follow-up кампания — бонус за лояльность, cross-sell, серия благодарностей — срабатывает на основе точных данных.

Предзагрузка контента для in-app сообщений

In-app сообщения, которым для отрисовки нужен запрос к серверу, могут заметно подтормаживать. Silent push, отправленный до того, как пользователь предположительно вызовет in-app сообщение, заранее подгружает контент и хранит его локально. Когда сообщение срабатывает, оно отображается мгновенно.

Этот паттерн хорошо работает для онбординг-флоу, анонсов функций и промо-оверлеев, где контент персонализирован и не может быть зашит в бинарник приложения. В gaming это удобно для live ops: контент ивента готов заранее, и оффер появляется ровно в момент, когда игрок входит в приложение.

Лучшие практики

Уважайте лимиты троттлинга ОС

iOS троттлит тихие пуши, которые приходят слишком часто. Рекомендация Apple — примерно 2–3 в час, то есть не чаще одного раза в 21 минуту. Приложения, которые превышают этот предел, могут обнаружить, что их silent push задерживаются или отбрасываются без какой-либо ошибки.

Doze mode и App Standby на Android ограничивают фоновое выполнение, когда устройство простаивает. Высокоприоритетные FCM-сообщения могут разбудить приложение во время Doze, но использовать их стоит выборочно. Сообщения стандартного priority откладываются до выхода устройства из Doze.

Практическое правило: отправляйте silent push только тогда, когда фоновая задача действительно срочная. Подгружать контент один раз в естественном ритме (утром или после серверного обновления) — нормально. Отправлять каждые 10 минут ради свежести данных — нет.

Держите payload маленьким, а задачи быстрыми

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

Фоновые задачи должны укладываться в лимит времени с запасом. Если задаче нужно больше нескольких секунд, проектируйте её прерываемой: сохраните прогресс, вызовите completion handler и продолжите при следующей возможности. Долгие фоновые задачи рискуют завершением со стороны ОС и могут заметно влиять на батарею.

Тестируйте на разных режимах питания и OEM-вариантах

Поведение silent push заметно различается между Android-OEM. У Xiaomi, Huawei и OnePlus агрессивная оптимизация батареи, которая может полностью блокировать фоновое выполнение для приложений не из whitelist. Тестируйте на реальных устройствах этих производителей, а не только на стоковых эмуляторах Android.

На iOS тестируйте в режиме энергосбережения и при принудительно закрытом приложении. Доставка silent push в этих состояниях менее надёжна, и ваша фоновая логика должна корректно отрабатывать случай, когда задача не выполнилась до открытия приложения пользователем.

Отслеживайте эффективность через downstream-события

Silent push не дают метрик кликов. Отслеживайте их эффективность через события, которые они должны запускать: content_refreshed, segment_updated, geofence_evaluated. Если эти события перестают срабатывать с ожидаемой частотой после запуска кампании silent push, доставка троттлится или фоновый обработчик сбоит.

Pushwoosh Analytics показывает события приложения рядом с данными кампаний. Сопоставьте события завершения фоновых задач с отправками silent push, чтобы убедиться, что пайплайн работает.

Встраивайте в автоматизацию сценариев, а не в разовые отправки

Silent push, отправленный сам по себе, — это техническая операция. Silent push, встроенный в Customer Journey, — стратегическая. Самые полезные паттерны используют тихие пуши как шаг, который делает лучше последующее видимое взаимодействие: обновить сегмент перед промо-пушем, подгрузить контент перед in-app сообщением, оценить геозону перед алертом на основе локации.

Customer Journey Builder от Pushwoosh поддерживает silent push как шаги сценария наряду с видимыми уведомлениями и in-app сообщениями.

Повышайте свежесть приложения и точность кампаний с Pushwoosh

Silent push-уведомления — это инфраструктурный слой под лучшим пользовательским опытом. Свежий контент при открытии, точные данные сегментов, бесшовные взаимодействия по геозонам — ничто из этого не работает надёжно без фоновых обновлений приложения.

Pushwoosh обеспечивает кросс-платформенную доставку silent push, форматирование payload, управление токенами и интеграцию с Customer Journey. Разработчики получают чистые абстракции SDK; маркетинговые команды получают silent push как полноценный шаг в автоматизированных сценариях.