Push-сервіси для PWA: OneSignal, FCM, Pushwoosh, WonderPush і Braze:

Коли я розбирав Web Push для PWA на iOS, усе будувалося на власному бекенді: VAPID-ключі, збереження підписок і відправка через бібліотеку на Spring Boot. Природне наступне питання: чи не передати цю частину готовому сервісу. Тут я порівнюю п'ять найпопулярніших варіантів: OneSignal, FCM, Pushwoosh, WonderPush і Braze. Важливе застереження: я їх у продакшені не підключав, тож порівняння базується на офіційній документації та сторінках вендорів станом на 19 жовтня 2026 року

⚡ Коротко: чим ці сервіси відрізняються

• ✅ Це різні класи рішень. FCM — інфраструктура доставки від Google, OneSignal, Pushwoosh і WonderPush — платформи push-розсилок, Braze — корпоративна платформа взаємодії з клієнтами (CEP).
• ✅ Усі п'ять за документацією підтримують iOS web push для PWA, доданих на домашній екран.
• ⚠️ Жоден сервіс не прибирає обмежень iOS: установка на домашній екран і запит дозволу по кліку залишаються.
• ⚠️ Усі вимагають свого Service Worker або підключення своєї бібліотеки до вашого, тож з власним кешуванням і push handler доведеться їх поєднувати.

📚 Зміст статті

• Як я порівнюю: методологія й застереження
• Три типи сервісів: інфраструктура, push-платформи, CEP
• Як працює Web Push і де в цьому ланцюжку сервіс
• iOS і PWA: чого не вирішує жоден сервіс
• Розбір кожного сервісу
• Порівняльна таблиця
• Відправка з бекенду: що кажуть документації
• Build vs buy: коли власний бекенд, а коли сервіс
• Ризики: Service Worker, привʼязка до вендора й дані
• Чек-лист вибору
• Часті питання (FAQ)
• Висновки
• Джерела

🧭 Як я порівнюю: методологія й застереження

Що це за порівняння. Я пишу про ці сервіси за їхньою офіційною документацією, сторінками продуктів і тарифів, а не за власними тестами. Тому в статті немає рейтингів, «найкращих» виборів і тверджень про швидкість чи відсоток доставки. Там, де я не зміг знайти підтвердження, це прямо вказано.

За якими критеріями порівнюю:

• тип сервісу;
• підтримка iOS web push за документацією;
• як сервіс підключається (Service Worker, SDK, ключі);
• як надсилати з власного бекенду;
• модель оплати (лише з офіційних сторінок і з датою);
• на що звернути увагу перед вибором.

Умови, тарифи й можливості змінюються, тож перед рішенням звіряйтеся з документацією вендора.

🧱 Три типи сервісів: інфраструктура, push-платформи, CEP

Терміни «Push Provider Platform» чи «платформа push-розсилок» не мають єдиного стандартного визначення, тож для ясності я ділю їх так:

• Інфраструктура доставки (FCM). Сервіс Google, який доставляє повідомлення. Логіку кампаній, сегментацію й аналітику ви будуєте самі або через інші Firebase-інструменти.
• Платформи push-розсилок (OneSignal, Pushwoosh, WonderPush). SaaS із панеллю для кампаній, сегментацією й аналітикою та API для відправки з бекенду.
• Платформа взаємодії з клієнтами, CEP (Braze). Збирає поведінкові дані з сайту, застосунків і бекенду у профілі користувачів і запускає автоматизовані повідомлення через push, email, SMS та інші канали. Це рішення для великих команд і складних сценаріїв.

Тому порівнювати FCM і Braze «в лоб» некоректно: це різні рівні абстракції.

⚙️ Як працює Web Push і де в цьому ланцюжку сервіс

У стандартному Web Push є три учасники: ваш сайт (Service Worker і підписка), push-сервіс браузера і ваш бекенд, який шле повідомлення на endpoint підписки. На iOS endpoint, як правило, веде на інфраструктуру Apple (про це я писав у статті про iOS Push), а сама підтримка Web Push для веб-застосунків із домашнього екрана описана в блозі WebKit.

Готовий сервіс вбудовується в цей ланцюжок з двох боків:

• на клієнті: свій SDK і Service Worker замість (або разом із) вашим;
• на бекенді: зберігання підписок і відправка за його API, а не через вашу бібліотеку Web Push.

🍎 iOS і PWA: чого не вирішує жоден сервіс

Документація переглянутих сервісів описує однакові обмеження iOS:

• Установка на домашній екран. У FCM для iOS і iPadOS це обов'язкова умова. OneSignal вимагає iOS 16.4+, додавання сайту на домашній екран і відкриття застосунку звідти. Pushwoosh описує iOS web push як роботу через PWA з домашнього екрана (Safari 16.4+).
• Запит дозволу по дії користувача. Braze пише, що запросити дозвіл на Safari iOS можна лише після додавання сайту на домашній екран, і лише у відповідь на дію, наприклад, натискання кнопки. Якщо користувач відповів (прийняв чи відхилив), для повторного запиту застосунок треба видалити й додати знову.
• Нестабільність підписок. У документації OneSignal прямо зазначено, що в частини розробників iOS web push спершу працює, а потім раптово зупиняється.
• Не в звичайних вкладках і вбудованих браузерах. Pushwoosh у блозі про iOS push зазначає, що web push не працює у вбудованих браузерах (WKWebView).

Declarative Web Push: нова можливість iOS 18.4

Окремо варто знати про Declarative Web Push. За блогом WebKit, він дозволяє запитати підписку й показувати сповіщення без Service Worker, а на iOS і iPadOS 18.4 цей спосіб доступний для застосунків із домашнього екрана. Чи підтримують його SDK розглянутих сервісів, я не перевіряв: це варто уточнити в документації вибраного вендора.

🔍 Розбір кожного сервісу

Для кожного сервісу нижче одна схема. Це опис за документацією, не оцінка якості.

Firebase Cloud Messaging (FCM)

• Тип: інфраструктура доставки повідомлень від Google.
• iOS web push: так. FCM підтримує Safari, а на iOS і iPadOS (16.4+) застосунок має бути на домашньому екрані.
• Інтеграція: за документацією FCM для Web, потрібно підключити Firebase JS SDK, згенерувати VAPID-ключ у розділі Web Push certificates консолі Firebase і викликати getToken() з цим ключем. Потрібен файл firebase-messaging-sw.js у корені домену.
• Модель оплати: перевірте на сторінці продукту Firebase: я не знайшов офіційного підтвердження цінових умов у переглянутих джерелах.
• Що врахувати: файл воркера має конкретну назву й розташування. Якщо у вас уже є власний Service Worker, його код доведеться поєднати.

OneSignal

• Тип: платформа push-розсилок (SaaS), реєстрація безкоштовна.
• iOS web push: так. iOS/iPadOS 16.4+, додавання на домашній екран із Safari, Chrome або Edge. Service Worker OneSignal для iOS обов'язковий.
• Інтеграція: файл OneSignalSDKWorker.js за замовчуванням шукається в корені сайту. Його можна розмістити в підпапці або додати рядок importScripts до наявного воркера.
• Відправка з бекенду: документація згадує Create message API.
• Модель оплати: тарифні умови перевірте на офіційній сторінці OneSignal.
• Що врахувати: у документації прямо зазначено, що воркер OneSignal із кореневою областю дії може конфліктувати з PWA, тоді рекомендують окремий воркер або об'єднання файлів.

Pushwoosh

• Тип: платформа push-розсилок (SaaS).
• iOS web push: так. На сторінці продукту сказано, що на iOS та iPadOS web push працює через PWA з домашнього екрана (Safari 16.4+).
• Інтеграція: JS-код, npm-пакет або Google Tag Manager. Service Worker потрібно розмістити в корені сайту. Для Chrome, Edge, Firefox, Opera і Samsung Internet Pushwoosh сам генерує VAPID-ключі, а для Safari та iOS потрібно зареєструвати Website Push ID (сервіс збирає push-пакет). Створення Website Push ID, найімовірніше, вимагає облікового запису Apple Developer: перевірте в документації.
• Свій воркер: документація SDK описує параметр serviceWorkerUrl і підключення воркера Pushwoosh через importScripts до вашого файлу.
• Модель оплати: [ПЕРЕВІРТЕ на офіційній сторінці тарифів Pushwoosh].

WonderPush

• Тип: платформа push-розсилок (SaaS). На сайті вказано, що WonderPush тепер є компанією Brevo.
• iOS web push: так. Сумісність із iOS 16.4 заявлено в день релізу iOS 16.4, 24 березня 2023. За документацією, потрібен manifest із "display": "standalone" (якщо власного немає, сервіс додає свій), а сповіщення на iOS текстові, без картинок і кнопок. Сторінка давно не оновлювалась, тож перевірте актуальність.
• Відправка з бекенду: Management API, де HTTP-виклики на management-api.wonderpush.com дозволяють виконувати з бекенду те, що доступно в панелі.
• Модель оплати: за офіційною сторінкою тарифів, від €1 на місяць за 1–1000 підписників і +€1 за кожну додаткову тисячу, без кредитної картки (станом на дату перегляду; умови можуть змінитися).
• Дані: на головній сторінці вказано, що через API ви самі вирішуєте, як довго зберігаються ваші дані на їхніх серверах.

Braze

• Тип: корпоративна платформа взаємодії з клієнтами (CEP). Веб-пуші там лише один із каналів поряд з email, SMS, in-app та іншими.
• iOS web push: так. Документація вимагає manifest, Service Worker, що імпортує бібліотеку Braze, додавання на домашній екран і запит дозволу після дії користувача.
• Відправка з бекенду: REST API (наприклад, ендпоінт /messages/send), хост залежить від регіону вашого інстансу.
• Модель оплати: офіційної публічної цінової сторінки я не знайшов. За сторонніми оглядами, ціни індивідуальні й залежать від кількості активних користувачів та каналів. Умови уточнюйте в Braze.
• Що врахувати: це рішення для великих команд і складних сценаріїв. Для простої розсилки нових публікацій воно може бути надлишковим (це моя оцінка, а не вимога документації).

📊 Порівняльна таблиця

Дані станом на 19 жовтня 2026 року, зі сторінок, на які є посилання вище. Це не рейтинг: порядок стовпців нічого не означає.

☕ Відправка з бекенду: що кажуть документації

Власний бекенд на Spring Boot із бібліотекою Web Push (як у моїй статті про iOS) зберігає підписки й сам викликає endpoint кожної підписки. У готових сервісів роль інша: підписки лежать у них, а ваш бекенд надсилає їм команду «відправити це повідомлення цим користувачам» через REST API. Документація згадує такі варіанти: Create message API у OneSignal, Management API у WonderPush і REST API Braze. Для Java це звичайні HTTP-виклики, а конкретні поля запитів дивіться в документації сервісу. Я цей код не писав і не перевіряв, тому прикладів тут немає.

⚖️ Build vs buy: коли власний бекенд, а коли сервіс

Це моя оцінка, виходячи з досвіду з власним бекендом.

Власний бекенд лишається розумним вибором, якщо:

• сценарій простий («нова публікація», «нагадування»), як у проєктах, де я використовував власну відправку;
• важливо, щоб дані підписників не залишали вашу інфраструктуру;
• вам потрібен мінімум залежностей і повний контроль над логікою відправки.

Сервіс має сенс, якщо:

• немає ресурсів підтримувати власну відправку й очищення недійсних підписок;
• потрібні сегментація, аналітика, кампанії, якими керує маркетинг без розробників;
• сповіщення потрібні одночасно з вебу й нативних застосунків. У цьому випадку корисно також прочитати порівняння PWA і нативного застосунку.

🛡️ Ризики: Service Worker, привʼязка до вендора й дані

• Конфлікт Service Worker. Усі сервіси вимагають свого воркера або бібліотеки у вашому. Якщо у вас уже є кешування й push handler, їх треба акуратно поєднати. Документація OneSignal прямо описує, що кореневий воркер може конфліктувати з PWA, а FCM вимагає файл конкретної назви. Типові помилки кешування в PWA я розбирав у статті «8 критичних помилок при інтеграції PWA».
• Привʼязка до вендора. Підписки зберігаються в сервісі. Перехід на іншого постачальника або власний бекенд може означати повторну підписку частини користувачів. Це моє припущення зі специфіки Web Push: перевірте на своєму кейсі. Деякі сервіси описують імпорт підписників: це є у документації WonderPush (розділи про імпорт і міграцію).
• Дані й приватність. Подивіться, де зберігаються дані підписників, як довго і як це узгоджується з вашою політикою конфіденційності.
• Невизначеність з новими можливостями. Чи підтримує SDK сервісу Declarative Web Push, у документації треба перевіряти окремо.

✅ Чек-лист вибору

• ☐ Яка частка ваших користувачів сидить на iPhone? (дивіться у власній аналітиці)
• ☐ Чи потрібні сегментація, кампанії й аналітика, чи достатньо простої відправки?
• ☐ Чи потрібні також нативні застосунки?
• ☐ Хто підтримуватиме відправку: розробники чи маркетинг?
• ☐ Чи є у вас власний Service Worker (кешування, push handler) і як ви його поєднаєте з воркером сервісу?
• ☐ Які умови оплати при вашій кількості підписників (за офіційною сторінкою на сьогодні)?
• ☐ Де зберігаються дані підписників і чи це прийнятно за вашою політикою?
• ☐ Чи можна експортувати підписки, якщо ви захочете піти?
• ☐ Чи підтримує SDK Declarative Web Push і чи це для вас важливо?
• ☐ Чи вирішено, як ви заохочуватимете користувачів додати PWA на домашній екран (без цього жоден сервіс не допоможе)?

❓ Часті питання (FAQ)

Чи потрібен сервіс на кшталт OneSignal, щоб PWA Push працював на iOS?

Ні. Web Push на iOS працює й без сторонніх сервісів: достатньо Service Worker, VAPID-ключів і бібліотеки на бекенді. Сервіс бере на себе частину бекенд-роботи, але не знімає умов iOS (домашній екран, запит дозволу по кліку).

OneSignal чи FCM: що обрати?

Це різні класи: FCM є інфраструктурою доставки, а OneSignal — платформою з панеллю кампаній. Вибір залежить від того, чи потрібні вам сегментація й аналітика «з коробки», чи ви готові будувати їх самі. Без власних тестів я не можу сказати, який із них стабільніший на iOS.

Чи працює Braze для простих PWA-сповіщень?

Технічно так: у документації є окрема інструкція для Safari на iOS. Але це корпоративна платформа з індивідуальними цінами, і для простої розсилки вона може бути надлишковою (моя оцінка).

Чи безкоштовний FCM?

Я не знайшов в офіційних джерелах підтвердження цінових умов, тож перевірте їх на сторінці продукту Firebase.

Чи можна поєднати свій Service Worker із воркером сервісу?

За документацією, так: OneSignal і Pushwoosh описують підключення через importScripts, а Braze вимагає, щоб воркер імпортував його бібліотеку. Для FCM потрібен файл firebase-messaging-sw.js. Деталі залежать від сервісу.

🏁 Висновки

• 🔹 П'ять сервісів належать до трьох класів: інфраструктура (FCM), push-платформи (OneSignal, Pushwoosh, WonderPush) і CEP (Braze).
• 🔹 За документацією всі підтримують iOS web push, але жоден не знімає умов iOS: домашній екран, запит по кліку, нестабільність підписок.
• 🔹 Головний технічний ризик — поєднання вашого Service Worker із воркером сервісу.
• 🔹 Для простих сценаріїв власний бекенд лишається розумною альтернативою, а сервіс виграє там, де потрібні сегментація, аналітика й кілька каналів.
• 🔹 Це порівняння за документацією станом на 19 жовтня 2026 року. Умови й можливості змінюються, тому перед вибором перевіряйте їх у вендора.

📖 Читайте також

• PWA Push-сповіщення на iOS у 2026: що реально працює
• 8 критичних помилок при інтеграції PWA: сценарії, причини та рішення з кодом
• PWA vs Native у 2026: порівняння, сценарії вибору та реальний кейс

📎 Джерела

• Firebase Blog: FCM for Safari
• Firebase: Get started with FCM in Web apps
• OneSignal: iOS web push setup
• OneSignal: Service Worker
• Pushwoosh: Web Push Notification Service
• Pushwoosh Docs: Web push SDK 3.0
• Pushwoosh Blog: iOS push notifications
• WonderPush Docs: iOS web push
• WonderPush: Pricing
• WonderPush: Management API
• Braze Docs: Safari Mobile Web Push
• PPC Land: Braze
• WebKit: Web Push for Web Apps on iOS and iPadOS
• WebKit: Meet Declarative Web Push

Важливо: умови, тарифи й можливості сервісів змінюються. Перед вибором перевіряйте актуальну документацію вендора. Матеріал актуальний на 19 жовтня 2026 року і ґрунтується на документації, а не на власному тестуванні.