Почему PWA могут навредить бизнесу — и когда они всё же оправданы в 2026 году

Почему Фора Софт написала этот разбор по PWA

Провокационный заголовок здесь — намеренный. PWA — реальная, зрелая технология, на которой работают настоящие бизнесы: Twitter Lite, Pinterest, Uber, Starbucks, Tinder. Это не обман и не вчерашний день. Но выбрать PWA для неподходящего продукта — одно из самых дорогих решений по умолчанию, какие мы видим у основателей. Цена всплывает не на запуске, а через шесть–девять месяцев, когда основатель обнаруживает, что витрина App Store не работает, пуши на iOS не доходят, а путь к встроенным покупкам, на котором держалась монетизация, оказывается невозможным.

Фора Софт делает софт с 2005 года: нативный iOS, нативный Android, React Native, Flutter, Capacitor и чистый веб. Мы используем PWA там, где они уместны, и нативные приложения — там, где они нужны. Цель этой статьи — зафиксировать наше решение письменно, чтобы вы выбирали подход осознанно, а не случайно.

Конкретное подтверждение: по нашему портфолио — Perspire.tv (стриминг фитнес-тренировок в реальном времени, натив + веб), CirrusMED (телемедицина с HIPAA), BrainCert (виртуальный класс на WebRTC) — в каждом случае мы выбирали платформу индивидуально, и инженерная экономика напрямую зависела от этого выбора. Мы поможем вам сделать такой же осознанный выбор для вашего продукта.

Что такое PWA на самом деле в 2026 году

Progressive Web App — это веб-приложение, которому соответствуют три технических требования: HTTPS, Web App Manifest (JSON-файл, описывающий приложение для браузера) и Service Worker (JavaScript-прокси, работающий в фоне и обеспечивающий офлайн-режим, кэширование и пуш-уведомления). Современные PWA можно установить на главный экран Android и iOS одним касанием, они запускаются в отдельном окне без элементов браузера и для большинства пользователей выглядят и работают как нативные приложения.

В 2026 году все основные браузеры поддерживают ключевые API PWA, а service worker’ы доступны примерно 87% пользователей интернета. Ограничивающий фактор — iOS Safari: пуш-уведомления в PWA он поддерживает только с iOS 16.4 (март 2023), по-прежнему не поддерживает Background Sync, имеет более жёсткие лимиты на объём хранилища, чем Chrome, и исторически ограничивает возможности PWA по сравнению с нативными приложениями. Хорошая новость в том, что базовые функции Apple поддерживает, а спор вокруг DMA в ЕС в 2024 году заставил компанию сохранить поддержку PWA на iOS. Плохая — в том, что пользовательский опыт PWA на iOS по-прежнему заметно уступает таковому на Android.

Если коротко: PWA работают и готовы к использованию, но именно iOS решает, подойдут ли они вашему продукту. Читайте дальше.

Аргументы ЗА PWA в 2026 году

Стоимость. Разработка PWA по отраслевым ориентирам 2026 года обходится примерно в 1,8–6 млн ₽. Нативный iOS, Android и веб для того же объёма работ обычно стоят 6–15 млн ₽ и выше. PWA обходятся на 30–50% дешевле одной нативной платформы и на 60–70% дешевле связки iOS + Android + веб.

Единая кодовая база, мгновенные обновления. Одна кодовая база на JavaScript работает на iOS, Android, десктопном и мобильном вебе. Обновления выходят за считанные минуты — без необходимости проходить ревью в App Store. Для продукта, который ещё ищет свою форму, такая скорость итераций очень важна.

Меньше трения при привлечении. PWA устанавливается по одному URL за одно касание. Нативное приложение требует, чтобы пользователь покинул ваш сайт, открыл магазин приложений, нашёл вас, установил программу и вернулся обратно. Потери на этом пути настолько велики, что их приходится учитывать как отдельную статью маркетингового бюджета.

SEO и индексируемость. Google индексирует PWA и показывает их в органической выдаче. Нативные приложения там не отображаются. Для контентных продуктов — новостных сайтов, интернет-магазинов, блогов — одного только поискового трафика зачастую достаточно, чтобы окупить разработку.

Реально измеренный эффект. После запуска PWA Twitter Lite сообщил о росте числа отправленных твитов на 75% и количества просматриваемых страниц за сессию на 65%, а показатель отказов снизился на 20%. Pinterest зафиксировал увеличение времени в приложении на 40% и ключевой метрики вовлечённости — на 60%. Starbucks удвоил число ежедневных активных пользователей, а его PWA оказалось на 99,84% легче iOS-приложения. Tinder сократил время загрузки с 11,91 до 4,69 секунды, а его PWA — на 90% легче нативного Android-приложения. Базовая версия PWA от Uber весит 50 КБ в сжатом виде и загружается менее чем за три секунды даже в сетях 2G. Успешные примеры уже есть.

Риски против PWA — о чём говорит заголовок

1. Ограничения iOS Safari. Apple исторически ограничивала возможности PWA, чтобы защитить доходы от App Store. Пуш-уведомления появились только в iOS 16.4 (2023). Background Sync, Periodic Background Sync и Background Fetch на iOS не поддерживаются — то есть ваш PWA не может обновлять данные в фоне, пока пользователь не открыл приложение. Объём хранилища строже, чем в Chrome, а кэш может удаляться после длительного простоя.

2. Потеря витрины App Store. Пользователи заходят в магазины приложений с определённой целью: ищут по категориям, читают отзывы, ставят оценки. PWA в этом канале отсутствуют полностью. Для продукта, рост которого зависит от позиции в магазине или видимости в категории, потеря этого канала означает утрату бизнес-модели.

3. Нет нативных API. Bluetooth, NFC (ограниченно), HealthKit, ARKit, продвинутое управление камерой, выполнение машинного обучения на устройстве, биометрическая аутентификация через secure enclave. В 2020 году Apple отказалась от внедрения в Safari 16 веб-стандартов, включая Web Bluetooth, Web NFC, WebUSB, Web Serial и Web MIDI. Если вашему продукту нужна поддержка этих функций, PWA — неподходящий выбор.

4. Трение в монетизации. В App Store нет встроенных покупок и нативного управления подписками. Apple Pay работает через Payment Request API, но бесшовная покупка в одно касание, которая хорошо конвертирует в нативной версии, на вебе реализуется сложнее. Аргумент «вы экономите комиссию Apple в 15–30%» верен; контраргумент «ваша конверсия может оказаться на 30–50% ниже» тоже верен. Считайте экономику с обеих сторон.

5. Слабые пуши на iOS. Даже на iOS 16.4+ пуш-уведомления работают только для PWA, которые пользователь сам добавил на главный экран, и только если разрешение на них было запрошено в ответ на его действие. Многие пользователи так и не добавляют PWA на экран. Кривая удержания у iOS-PWA отстаёт от нативных приложений на 20–40% на продуктах с высокой вовлечённостью.

6. Потолок по производительности. Тяжёлое видео в реальном времени, AR, продвинутая 3D-графика, ИИ-инференс на устройстве, многопоточный WebRTC под нагрузкой — здесь нативные приложения всё ещё впереди. PWA работают быстро с контентом, но сталкиваются с ограничениями при решении вычислительно или медиаплотных задач.

7. Разрыв в сигнале доверия. Многие пользователи не доверяют «сайтам, выдающим себя за приложения». Иконка в App Store вызывает доверие, которого у баннеров PWA нет. Для потребительских B2C-продуктов эта репутационная потеря вполне реальна.

8. Риск зависимости от Apple. В феврале 2024 года Apple объявила о планах убрать поддержку PWA на домашнем экране в ЕС в рамках DMA. Еврокомиссия начала расследование — и за две недели Apple отыграла назад. Урок: PWA на iOS существуют по милости Apple, и Apple показала, что готова отозвать или урезать поддержку, как только сойдутся коммерческие стимулы. Закладывайтесь на это ограничение, а не надейтесь, что оно само исчезнет.

PWA, натив и гибрид — практическое сравнение

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

Когда PWA — верный выбор

Выбирайте PWA, если большинство из этих условий выполняются одновременно.

Контентные продукты. Новости, блоги, просмотр товаров в e-commerce. Индексируемость и возможность делиться ссылками — каналы роста; App Store в любом случае не был бы основным способом привлечения пользователей.

Внутренние B2B-инструменты. Пользователи приходят из писем, Slack или корпоративного интранета. Онбординг по ссылке работает лучше, чем установка из магазина. Выручка формируется за счёт контрактов, а не внутренних покупок.

Потребительские приложения для развивающихся рынков. Слабые устройства, мало памяти, дорогой мобильный интернет. PWA объёмом 50 КБ запускается за три секунды даже на 2G — и выигрывает у нативного приложения в 50 МБ.

Продукты с низкой вовлечённостью. Пользователи возвращаются раз в неделю или реже. Удержание через пуш-уведомления — не панацея; закладки в браузере срабатывают лучше.

Продукты, которым нужны мгновенные обновления. Ежедневное A/B-тестирование, срочный исправление критичного бага в два часа ночи, быстрое внедрение маркетинговых изменений. Циклы ревью в App Store здесь не подходят.

Когда PWA — неверный выбор

Выбирайте натив (или гибрид), если большинство из этих условий выполняются одновременно.

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

Зависимость от нативных API. Фильтры для камеры, подключение по Bluetooth, машинное обучение на устройстве, ARKit, HealthKit. В PWA этого нет, и в ближайшие сроки не появится.

Монетизация по подписке без сильного веб-сценария. Если подписка привязана к встроенным покупкам App Store или вы не можете организовать удобный веб-оплат, PWA сильно ограничит монетизацию и может свести бизнес-модель на нет.

Видео, аудио, AR в реальном времени. Многопоточный WebRTC под нагрузкой, AR-наложения, инференс ИИ на устройстве. По задержке, управлению кодеками и расходу батареи нативная реализация по-прежнему лучше.

Витрина App Store как канал роста. Если вы привлекаете пользователей через позиции в категориях, поиск по магазину и редакционные подборки, отказаться от присутствия в App Store нельзя. PWA здесь не подойдёт.

Гибридные подходы — PWA и нативная разработка на основе общей кодовой базы

Недооценённый третий путь: объединить PWA с тонкой нативной оболочкой, чтобы получить выгоду от единой кодовой базы, присутствие в App Store и доступ к нативным API там, где это действительно важно.

Trusted Web Activities (TWA). Google Play принимает PWA, упакованные в TWA — по сути, это оболочка на базе Chrome, которая запускает ваше PWA. Digital Asset Links подтверждают связь между Android-приложением и вашим доменом. Приложение появляется в Play Store, устанавливается как обычное приложение для Android, но использует кодовую базу PWA. Самый дешёвый способ получить присутствие в магазине, не удваивая усилия по разработке.

Capacitor. Оборачивает веб-приложение в нативную оболочку для iOS или Android и предоставляет доступ к нативным функциям — камере, уведомлениям, биометрии — через систему плагинов. Используется в приложениях на Ionic. Позволяет использовать одну кодовую базу для публикации в App Store и Google Play с возможностью подключения нужных нативных возможностей.

React Native и Flutter. Кросс-платформенные нативные фреймворки с общей бизнес-логикой и адаптивным интерфейсом под каждую платформу. Дороговаты по сравнению с PWA или Capacitor, но дешевле, чем нанимать две отдельные команды для iOS и Android. В 2026 году — стандартный выбор для потребительских приложений, работающих на нескольких платформах.

Kotlin Multiplatform (KMP). Самый новый игрок, набравший популярность в 2025–2026 годах. Делит бизнес-логику на Kotlin между iOS и Android; UI остаётся платформенным (SwiftUI на iOS, Jetpack Compose на Android). Подходит, когда UI важен, а бизнес-логика сложная.

Стоимость и поддержка — расчёт на двенадцать месяцев

Чистый PWA. Разработка — от 1,8 до 6 млн ₽. Годовая поддержка — около 15% от стоимости разработки, то есть примерно 300–900 тыс. ₽. Нет налога за ревью в App Store. Одна команда, один репозиторий, один пайплайн деплоя. Самая низкая совокупная стоимость владения для подходящего продукта.

Натив iOS, Android и веб. Разработка — от 6 до 15 млн ₽ и выше. Годовая поддержка — 20–25% от стоимости разработки, то есть около 1,2–3,7 млн ₽. Три отдельные команды или одна команда на трёх стеках; налог на интеграцию — необходимость поддерживать одинаковый функционал на всех платформах — реальный и постоянный.

Гибрид (React Native, Flutter, Capacitor). Разработка — 4,5–11 млн ₽. Годовая поддержка — 15–25% от стоимости разработки, то есть примерно 675 тыс.–2,7 млн ₽. Такой подход сокращает время разработки на 30–40%, но не исключает необходимость платформенного тестирования, прохождения ревью в App Store и устранения багов на конкретных устройствах.

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

Пять ловушек PWA, с которыми мы чаще всего сталкиваемся

1. Баги service worker и инвалидация кэша. Плохой service worker может вечно отдавать устаревший контент. Переделывать стратегию кэширования задним числом сложно; продумайте механизм обновления сразу. Используйте Workbox, задавайте явные версии кэша и закладывайте путь «принудительного обновления».

2. Очистка хранилища на iOS. Кэш service worker может исчезнуть после длительного простоя на iOS. Не полагайтесь на то, что он сохранится надолго — лучше считать его временным. Важные данные должны храниться на вашем бэкенде.

3. Трение при установке. На iOS пользователь должен вручную через меню «Поделиться» выбрать «На экран „Домой“». Большинство этого не делает. Воронке установки PWA нужны чёткое объяснение и подходящий момент — подсказка, которая работает, не бывает универсальной.

4. UX пуш-уведомлений. Пуш-уведомления на iOS работают только после установки приложения. Разрешение на них нужно запрашивать в ответ на действие пользователя, а не сразу при запуске. Сценарий «подпишитесь на уведомления», который хорошо работает на Android, на iOS без доработки не сработает.

5. Восприятие «это не настоящее приложение». Часть пользователей не доверяет PWA, воспринимая их как обычные сайты. Визуальные признаки — отдельное окно, иконка, стартовый экран, навигация в стиле приложения — здесь важнее, чем в нативных приложениях. Если на этом сэкономить, можно потерять пользователей ещё до установки.

Мини-кейс — как Фора Софт выбирает платформу

Полезное подтверждение паттерна. Три реальных проекта — три разных решения по платформе.

Perspire.tv — натив плюс веб. Стриминг фитнес-тренировок в реальном времени с двусторонним коучингом и низкой задержкой, удержанием через пуш-уведомления и монетизацией по подписке. Мы разработали нативные приложения для iOS и Android, а также дополнительный веб-интерфейс. PWA не подошёл бы — для задач вроде RTC, пушей и встроенных покупок нужен полноценный нативный контроль.

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

CirrusMED — нативное приложение с веб-компаньоном. Телемедицине с поддержкой HIPAA требуются надёжная безопасность на уровне устройства, биометрическая аутентификация, защищённое локальное хранилище и стабильные пуш-уведомления для напоминаний о приёмах. Поэтому выбрали нативную разработку. PWA не прошёл бы проверку по требованиям — уже из-за ограничений в части хранения данных и биометрии. Хотите аналогичное решение под свою платформу?

Фреймворк выбора платформы из пяти вопросов

В1. Откуда приходят пользователи? Если по ссылкам — из писем, Slack или поисковой системы — PWA выигрывает за счёт удобства. А если пользователь ищет приложение в магазине приложений, то нативное приложение выигрывает благодаря лучшей видимости.

В2. Как устроена монетизация? Веб-подписка, контракты или B2B-биллинг → PWA жизнеспособен. Встроенные покупки в App Store, freemium с пейволлами, внутриигровая валюта → нужен нативный.

В3. Нужны ли нативные API? Камера, AR, Bluetooth, HealthKit, продвинутый ML, биометрическая аутентификация, NFC. Если да — PWA не подойдёт.

В4. Как устроено удержание? Ежедневная вовлечённость — через пуш-уведомления и нативные элементы. Вовлечённость раз в неделю или реже — через ссылки. PWA в таких условиях жизнеспособен.

В5. Какова реальность бюджета? Если вы можете позволить себе только один из вариантов — веб, iOS или Android — PWA даёт вам все три сразу. Если же бюджет позволяет реализовать все три платформы, сравнивайте PWA, гибридные и нативные решения исходя из задачи, а не только по цене.

Частые вопросы

Что почитать дальше

Готовы сделать осознанный выбор платформы?

PWA — не обман и не устаревшая технология. Но и не универсальное решение для любого продукта. Выбор в пользу PWA — не вопрос веры, а результат анализа задач: откуда приходят пользователи, как работает монетизация, какие нативные API требуются, что обеспечивает удержание и где бюджет. Компании, которым PWA действительно помогает, выбирают его осознанно. Те, кто терпит неудачу, выбирают его из соображений экономии и через полгода понимают, что «дешевле» обошлось им потерей присутствия в App Store, возможностей для пуш-уведомлений или пути к встроенным покупкам, на котором держалась их бизнес-модель.

Самый полезный следующий шаг — 30-минутный звонок по платформе с senior-инженерами, которые выпускали продукты на каждом стеке. Принесите объём работ, модель монетизации и каналы роста. Мы вернёмся с правильным решением — PWA, натив или гибрид — и расчётами под него. Смысл в том, чтобы принять решение осознанно, с доказательствами, прежде чем что-то подписывать.