У 2017–2020 роках навколо PWA був справжній технологічний хайп. Конференції, статті в блогах, офіційна підтримка від Google та Microsoft. Потім настало розчарування — iOS тримала ключові API закритими, запити на встановлення виявилися заплутаними, а маркетинг нативних застосунків залишався сильнішим. Спільнота перейшла на Flutter, React Native та Capacitor.
Але непомітно відбулося дещо інше. Стек PWA продовжував розвиватися. За останні роки Apple додала відсутні API, браузери покращили процес встановлення, а специфікація service worker стабілізувалася. І для продуктових команд без великих бюджетів PWA стала напрочуд вдалим вибором.
Ця стаття — чесний кейс trefa.app, корпоративної ліги прогнозів, створеної як PWA, після року в продакшені. Що спрацювало, що ні, та кому б я порадив PWA сьогодні.
Контекст: що таке trefa.app
Trefa.app — це вебзастосунок для корпоративних ліг прогнозів. Користувач входить через Google, створює лігу для своєї компанії, запрошує колег за посиланням або QR-кодом, і всі разом прогнозують результати матчів. Застосунок синхронізує дані зі спортивних API (NHL, Premier League, чемпіонати світу) і в реальному часі перераховує очки.
Фронтенд — це Next.js 16 + React 19 + Tailwind, розміщений на Vercel. Бекенд — Django 5 + DRF + Channels на Hetzner. Між ними — PostgreSQL на Supabase і Redis для зв'язку в реальному часі.
Приємна деталь: нативного застосунку для iOS чи Android не існує. PWA — єдиний клієнт. Користувачі на iPhone, Android, Windows і macOS працюють з абсолютно однаковою річчю.
Чому ми обрали PWA замість нативного застосунку
Рішення було значною мірою економічним. Нативний застосунок означав би:
- Розробку двох паралельних клієнтів (iOS Swift + Android Kotlin) або крос-платформного фреймворку (Flutter, React Native).
- Процес публікації в App Store + Google Play — внески за публікацію, затримки на рев'ю, періодичне перевидання при змінах бекенд-API.
- Push-сповіщення через APNs і FCM — дві окремі інфраструктури, два окремі процеси сертифікації.
- Оновлення через магазини — користувач має сам активно оновлюватися, частина людей місяцями лишається на старій версії.
Для продукту з відносно невеликою цільовою аудиторією (корпоративні команди, а не масовий ринок) витрати на нативну розробку були значно вищими за вигоду. PWA усунула всі ці пункти одразу.
Технічні переваги, яких користувачі ніколи не помітять
Це та частина, яку я недооцінив би до виходу в продакшен. З погляду розробки PWA дає низку конкретних переваг, що економлять тижні роботи на рік:
Деплой миттєвий. Push у main → Vercel збирає білд → за 2 хвилини нова версія вже в усіх користувачів. Жодних публікацій, жодного очікування, жодного жонглювання сумісністю версій клієнта та бекенда. Якщо я зроблю breaking change в API, наступного дня я можу випустити фікс, і всі отримають його одразу.
Один код для всього. iOS, Android, Windows, macOS, Linux — всюди той самий застосунок. Жодних платформо-специфічних багів («це ламається лише на iPhone 13 у темному режимі»), жодної дубльованої реалізації.
Короткий шлях до користувача. Надсилаєш посилання, клік — і він уже в застосунку. Жодного «завантажте наш застосунок з App Store, зареєструйтеся, а потім увійдіть». Для B2B-продуктів з нечастим використанням (ліга прогнозів працює лише під час спортивного турніру) це величезна перевага для конверсії.
Push-сповіщення працюють навіть без встановлення. Service worker реєструє push-підписку. Щойно користувач натискає «Дозволити сповіщення», він починає отримувати нагадування перед матчами незалежно від того, чи додав застосунок на головний екран, чи лише час від часу відкриває його в Safari.
Чого не вміє PWA (чесно про недоліки)
Тут чесність важливіша за маркетинг. У PWA є реальні обмеження, на які ми натрапили в продакшені.
iOS push-сповіщення мають свої умови. Apple Web Push існує з iOS 16.4, але працює лише якщо користувач додав PWA на головний екран. Якщо він користується застосунком через вкладки Safari, push-підписка не зберігається. Це тертя, якого немає в нативних застосунків.
Бракує присутності в App Store. Для деяких типів покупців (HR-відділи, IT-менеджери в корпораціях) «цього немає в App Store» дорівнює «це несерйозно». Суб'єктивно, але реально.
Деякі API операційної системи недоступні. Bluetooth Low Energy, NFC, повний доступ до файлової системи — для типового застосунку це не проблема, але якщо тобі потрібні ці можливості, PWA тебе обмежує.
Офлайн-режим можливий, але не автоматичний. Service worker треба налаштувати вручну, продумати стратегії кешування, реалізувати черги синхронізації. Для повністю офлайн-first застосунку це більше роботи, ніж уявляють собі розробники.
Бенчмарк продуктивності проти нативу: PWA приблизно на 15–25 % повільніша при першому завантаженні (через парсинг JS-бандла) і на 5–10 % у щоденній взаємодії. Для більшості застосунків це непомітно, для хардкорних ігор чи відеомонтажу — це фактор, який все вирішує.
Результати за рік у продакшені
Конкретні дані з trefa.app після року роботи:
- Крос-платформна стабільність — команда розробки з однієї людини підтримує застосунок на всіх операційних системах без платформо-специфічних багів. Однаковий цикл тестування для всіх.
- Частота деплоїв — у середньому 3–5 деплоїв на тиждень через Vercel. Жоден з них не впирається в затримки публікації в App Store.
- Push-сповіщення — близько 70 % користувачів активні, рівень доставки push приблизно 95 % на Android і 85 % на iOS (через вимогу встановлення на головний екран).
- Жодних комісій App Store — заощаджено приблизно 70 USD на рік на акаунтах розробника плюс близько 30 % комісії з транзакцій (яка інакше діяла б для покупок усередині застосунку).
Утім, головна бізнес-вигода була не технічною. Це була швидкість ітерацій. Якщо клієнт писав «ця функція мені б знадобилася», я зазвичай починав над нею того ж дня і випускав протягом тижня. З нативним застосунком це просто неможливо.
Кому б я порадив PWA сьогодні
PWA підходить, якщо справджуються принаймні два з наведених пунктів:
- У тебе обмежені ресурси і ти не можеш дозволити собі два нативні застосунки плюс вебверсію.
- Твої користувачі користуються застосунком час від часу (не щодня), тож низьке тертя при першому відкритті має значення.
- Твоєму застосунку не потрібні хардкорні API операційної системи (Bluetooth, NFC, повна файлова система).
- Ти хочеш деплоїти без перешкод у вигляді магазинів застосунків.
- Твоя аудиторія змішана — iOS і Android, мобільні та десктопні пристрої.
PWA, ймовірно, не найкращий вибір, якщо:
- Твій застосунок працює щодня, по кілька годин на день, і користувачі застосовують його інтенсивно (соцмережі, месенджери).
- Тобі потрібні просунуті інтеграції з операційною системою.
- Твої покупці очікують присутності в App Store.
- Продуктивність критична (ігри, відео, AR).
Висновки
Хайп навколо PWA, можливо, минув, але технологія непомітно доросла до точки, у якій для багатьох продуктів вона є кращим вибором, ніж нативна розробка. Trefa.app стоїть на PWA вже рік, і я не бачу причин це змінювати. Навпаки — якби я починав сьогодні, рухався б ще швидше.
Якщо ти зважуєш PWA проти нативного застосунку для свого проєкту, врахуй одну річ поза технічними аргументами: PWA швидше доведе тебе до продакшену. А на ранніх етапах швидкість ітерацій цінніша за будь-що інше.
До речі, trefa.app можна спробувати самому — без встановлення, лише клік, і ти вже прогнозуєш.