История пуш-уведомлений начинается задолго до первого айфона: ещё в конце 1990-х компания Research In Motion сделала «пуш-почту» главной фишкой устройств BlackBerry, и именно там впервые сформировался принцип, который сегодня лежит в основе всех мобильных уведомлений. Сообщение не запрашивалось устройством по расписанию, а «проталкивалось» (push) сервером на устройство в момент поступления. Это экономило заряд батареи и делало доставку почти мгновенной — два свойства, которые и по сей день определяют ценность технологии.
Понимание этой истории полезно не только любопытства ради. Зная, как эволюционировали сервисы доставки уведомлений — от проприетарных решений к единым системным шлюзам и веб-стандартам, — проще разобраться, почему современные приложения ведут себя именно так: почему уведомления приходят с задержкой при агрессивной оптимизации батареи, почему веб-сайты просят разрешение на показ уведомлений и почему разработчики привязаны к сервисам APNs и FCM.
Предпосылки: пейджеры, SMS и опрос по расписанию
До появления полноценных пуш-систем короткие оповещения доставлялись через пейджерные сети и SMS. Эти каналы умели «проталкивать» сообщение к абоненту, но были дорогими, ограниченными по длине и никак не интегрировались с приложениями. Ранние мобильные программы, которым требовались свежие данные, использовали другой подход — периодический опрос сервера (polling): приложение каждые несколько минут само спрашивало, нет ли новостей.
У опроса по расписанию было два очевидных недостатка. Во-первых, постоянные запросы разряжали батарею и расходовали трафик, который в эпоху GPRS был медленным и дорогим. Во-вторых, между проверками возникала задержка: пользователь узнавал о новом письме или сообщении с опозданием. Индустрии требовался механизм, при котором сервер сам инициирует доставку.
- 📟 Пейджеры — односторонние оповещения без связи с приложениями.
- 💬 SMS — доставка «проталкиванием», но дорогая и ограниченная по формату.
- 🔄 Polling — приложение само опрашивает сервер, тратя батарею и трафик.
- 📧 Push-email — первый массовый пример сервер-инициированной доставки.
Эпоха BlackBerry: пуш-почта как убийственная функция
Именно BlackBerry в начале 2000-х превратила push-механику в массовый продукт. Корпоративная почта доставлялась на устройство через инфраструктуру компании — серверы BlackBerry Enterprise Server и сетевой центр оператора — практически мгновенно после поступления на почтовый ящик. Для деловых пользователей это стало настолько важным преимуществом, что устройства получили прозвище CrackBerry за вызываемую ими зависимость.
Ключевая идея, которую позже заимствуют все платформы, заключалась в постоянном соединении между устройством и сервером доставки. Вместо того чтобы каждое приложение держало свой канал, весь трафик оповещений шёл через единую инфраструктуру. Это снижало нагрузку на радиомодуль и батарею — принцип, который спустя годы ляжет в основу APNs и FCM.
2008–2009: Apple запускает APNs
Когда Apple открыла App Store в 2008 году, перед компанией встала дилемма. Сторонние приложения не могли работать в фоне — система этого не позволяла ради времени автономной работы. Но мессенджерам и почтовым клиентам нужно было как-то сообщать пользователю о новых событиях. Решением стал Apple Push Notification Service (APNs) — единый системный сервис, анонсированный в 2008 году и запущенный вместе с iPhone OS 3 в 2009 году.
Схема работы была элегантной. Сервер разработчика отправлял уведомление в APNs, а тот доставлял его на конкретное устройство по единственному постоянно поддерживаемому соединению. Приложению не нужно было висеть в памяти: система сама показывала баннер, проигрывала звук и обновляла бейдж на иконке. Позже APNs распространился на iPad, а затем и на другие платформы Apple, включая macOS.
Интересно, что изначальные ограничения формата — маленький размер полезной нагрузки и отсутствие гибкости — годами дорабатывались: со временем появились расширенные уведомления с изображениями, кнопками действий и возможностью тихой (фоновой) доставки для обновления контента.
2010–2016: Android и путь от C2DM к FCM
Google ответила собственным сервисом: в 2010 году появился Android Cloud to Device Messaging (C2DM). Он решал ту же задачу, что и APNs, но имел заметные ограничения — в частности, требовал привязки к учётной записи Google на устройстве и не давал богатых возможностей по формату сообщений.
В 2012 году C2DM заменил Google Cloud Messaging (GCM) — более гибкая система с поддержкой полезной нагрузки, сообщений «вверх» от устройства к серверу и групповой рассылки. Следующим крупным шагом стал запуск Firebase Cloud Messaging (FCM) в 2016 году после приобретения Google платформы Firebase: сервис унаследовал инфраструктуру GCM, но получил кроссплатформенность — единый API для Android, iOS и веб-приложений.
| Сервис | Компания | Год запуска | Особенность |
|---|---|---|---|
| Push-email BlackBerry | Research In Motion | начало 2000-х | Мгновенная доставка почты через свою инфраструктуру |
| APNs | Apple | 2009 | Единый системный канал уведомлений для iOS |
| C2DM | 2010 | Первая облачная доставка на Android | |
| GCM | 2012 | Полезная нагрузка и сообщения «вверх» | |
| FCM | 2016 | Кроссплатформенная доставка: Android, iOS, веб |
⚠️ Внимание: при изучении старой документации и устаревших руководств по интеграции уведомлений проверяйте, о каком сервисе идёт речь. C2DM и GCM давно закрыты, и примеры кода для них неприменимы — актуальные интеграции строятся на FCM и современных версиях APNs.
Выход в веб: Push API и сервис-воркеры
Долгое время уведомления оставались привилегией нативных приложений. Перелом наступил с появлением Service Worker — фонового скрипта браузера, способного принимать события даже при закрытой вкладке. На его основе сложился стандарт Web Push: сайт запрашивает у пользователя разрешение, получает подписку и далее может получать уведомления через push-сервис браузера.
Поддержку внедряли поэтапно: первыми возможность получили пользователи Chrome и Firefox, затем подтянулись другие браузеры. Важной вехой стала поддержка веб-пушей в Safari на iOS — она появилась значительно позже конкурентов и потребовала добавления сайта на домашний экран, что долго сдерживало распространение технологии на «яблочных» устройствах.
Как технически устроен Web Push
Сайт через Push API получает у браузера уникальный endpoint подписки и ключи шифрования. Сервер сайта отправляет зашифрованное сообщение на push-сервис браузера (у каждого браузера он свой), а тот будит Service Worker на устройстве пользователя, который и показывает уведомление. Контент шифруется, поэтому промежуточный сервис не видит текст сообщения.
Параллельно развивались и десктопные каналы: Windows получила собственную службу уведомлений WNS для приложений из магазина, а macOS — интеграцию с APNs. Таким образом, к середине 2010-х сложилась современная картина: у каждой крупной платформы есть свой шлюз, а разработчики либо работают с каждым напрямую, либо используют агрегаторы.
Современный этап: богатый контент и борьба со спамом
Сегодня пуш-уведомление — это уже не просто строка текста. Поддерживаются изображения, видео, кнопки быстрых действий, группировка по темам, тихие уведомления для фонового обновления данных и приоритезация доставки. Одновременно платформы усилили контроль: на Android, начиная с новых версий системы, приложения обязаны запрашивать разрешение на показ уведомлений, а браузеры ужесточили правила выдачи подписок сайтам.
Причина ужесточений очевидна: канал, созданный для пользы, стал инструментом навязчивого маркетинга и даже мошенничества. Поддельные уведомления с фишинговых сайтов заставили браузеры вводить «тихий» режим запроса разрешений и автоматическую блокировку для сайтов, которым пользователи часто отказывают.
⚠️ Внимание: уведомления — частый вектор фишинга. Если сайт просит разрешить уведомления под предлогом «подтвердите, что вы не робот», это почти наверняка попытка навязать рекламную или вредоносную рассылку. Отозвать разрешение можно в настройках браузера в разделе уведомлений.
Что важно знать о развитии технологии сегодня
Ретроспектива помогает понять текущие ограничения. Единый системный шлюз — наследие BlackBerry — по-прежнему означает, что доставка зависит от сервисов Apple и Google: если соединение устройства с ними разорвано или заблокировано, уведомления задерживаются. Агрессивные режимы энергосбережения на Android могут обрывать фоновые процессы приложений, поэтому критичные оповещения проектируют как высокоприоритетные сообщения FCM.
Для проверки собственной воронки уведомлений полезно пройтись по базовым пунктам:
☑️ Проверка доставки пуш-уведомлений
Историческая перспектива показывает и направление дальнейшего развития: унификация веб-стандартов, усиление приватности (шифрование полезной нагрузки уже стало нормой в Web Push) и всё более тонкая настройка того, какие уведомления пользователь готов получать. Технология, начавшаяся с доставки корпоративной почты, стала универсальным каналом связи между сервисами и людьми.
Часто задаваемые вопросы
Кто изобрёл пуш-уведомления?
Массово принцип push-доставки впервые реализовала компания Research In Motion в устройствах BlackBerry — для мгновенной доставки электронной почты. В привычном современном виде (системный сервис для сторонних приложений) технологию первой представила Apple, запустив APNs в 2009 году.
Чем отличаются GCM и FCM?
GCM (Google Cloud Messaging) — сервис доставки сообщений для Android, запущенный в 2012 году на смену C2DM. В 2016 году ему на смену пришёл FCM (Firebase Cloud Messaging), который унаследовал инфраструктуру, но стал кроссплатформенным: через него можно отправлять уведомления на Android, iOS и в веб. GCM полностью выведен из эксплуатации.
Могут ли сайты отправлять пуш-уведомления без приложения?
Да, благодаря стандарту Web Push. Сайт запрашивает у пользователя разрешение, а доставка идёт через push-сервис браузера и обрабатывается Service Worker — фоновым скриптом, который работает даже при закрытой вкладке. Поддержка зависит от браузера и платформы.
Почему уведомления иногда приходят с задержкой?
Доставка идёт через единый системный шлюз (APNs или FCM), и на неё влияют состояние соединения устройства с сервисом, режимы энергосбережения, приоритет сообщения и ограничения фоновой активности. Задержка обычно означает, что система отложила доставку ради экономии заряда или соединение временно отсутствовало.
Безопасно ли разрешать уведомления сайтам?
Для известных и доверенных сайтов — да: браузер позволяет в любой момент отозвать разрешение в настройках. Осторожность нужна с незнакомыми ресурсами: мошеннические сайты используют пуш-подписки для навязчивой рекламы и фишинга, поэтому запросы из всплывающих ловушек вроде «нажмите „Разрешить", чтобы продолжить» следует отклонять.