С 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 (НХЛ, Премьер-лига, чемпионаты мира) и пересчитывает очки в реальном времени.
Фронтенд — это 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 минуты новая версия у всех пользователей. Никакой публикации, никакого ожидания, никакого жонглирования совместимостью версий клиента и бэкенда. Если я делаю ломающее изменение в API, на следующий день я могу выкатить фикс, и он сразу у всех.
Одна кодовая база на всё. iOS, Android, Windows, macOS, Linux — везде одно и то же приложение. Никаких платформенно-специфичных багов («это ломается только на iPhone 13 в тёмной теме»), никаких дублирующих реализаций.
Короткий путь к пользователю. Отправил ссылку, клик — и ты в приложении. Никаких «скачайте наше приложение из App Store, зарегистрируйтесь, а потом войдите». Для B2B-продуктов с редким использованием (лига прогнозов работает только во время спортивного турнира) это огромный плюс для конверсии.
Push-уведомления работают даже без установки. Service Worker регистрирует подписку на push. Как только пользователь нажимает «Разрешить уведомления», он начинает получать оповещения перед матчами — независимо от того, добавил ли он приложение на главный экран или просто иногда открывает его в Safari.
Чего PWA не умеет (честный разбор)
Здесь честность важнее маркетинга. У PWA есть реальные ограничения, с которыми мы столкнулись в продакшене.
Push-уведомления на iOS идут с оговорками. Apple Web Push существует с iOS 16.4, но работает только если пользователь добавил PWA на главный экран. Если же он пользуется приложением через вкладки Safari, подписка на push не закрепляется. Это трение, которого у нативных приложений нет.
Отсутствие в App Store. Для некоторых типов покупателей (HR-отделы, корпоративные ИТ-менеджеры) «нет в 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 долларов в год на аккаунтах разработчика плюс около 30 % комиссии с транзакций (которая иначе применялась бы к встроенным покупкам).
Но главная бизнес-выгода была не технической. Это скорость итераций. Если клиент писал «вот эта функция мне бы помогла», я обычно начинал работу в тот же день и выкатывал её в течение недели. С нативным приложением это попросту невозможно.
Кому я порекомендовал бы PWA сегодня
PWA подходит, если выполняются хотя бы два из условий:
- У вас ограниченные ресурсы, и вы не можете позволить себе два нативных приложения плюс веб-версию.
- Ваши пользователи заходят в приложение время от времени (не каждый день), поэтому важна низкая планка входа при первом открытии.
- Вашему приложению не нужны хардкорные API операционной системы (Bluetooth, NFC, полный доступ к файлам).
- Вы хотите выкатывать обновления без сторов на пути.
- Ваша аудитория смешанная — iOS и Android, мобильные устройства и десктоп.
PWA, скорее всего, не лучший выбор, если:
- Ваше приложение используется ежедневно, по несколько часов в день, и интенсивно (соцсети, мессенджеры).
- Вам нужны продвинутые интеграции с операционной системой.
- Ваши покупатели ожидают присутствия в App Store.
- Производительность критична (игры, видео, AR).
Заключение
Хайп вокруг PWA, возможно, и прошёл, но технология незаметно доросла до уровня, на котором для многих продуктов это лучший выбор, чем нативная разработка. Trefa.app живёт на PWA уже год, и я не вижу причин что-то менять. Наоборот — если бы я начинал сегодня заново, то двигался бы быстрее.
Если вы взвешиваете PWA против нативного приложения для своего проекта, учтите помимо технических аргументов ещё одну вещь: PWA выводит вас в продакшен быстрее. А на ранних этапах скорость итераций ценнее всего остального.
Кстати, trefa.app можно попробовать самому — без установки, просто клик, и вы уже прогнозируете.