Короткий ответ: выбор делает обязательный сценарий
Выбирайте PWA, когда важны вход по ссылке, поиск, единая веб-версия и выпуск обновлений без магазинной проверки. При этом главное действие должно предсказуемо работать на нужных телефонах и в нужных браузерах. Выбирайте мобильное приложение, когда ценность зависит от глубокого доступа к функциям телефона, например к длительной работе с Bluetooth или геолокацией в фоне, магазинного канала или других системных возможностей, для которых веб не даёт нужной надёжности.
Начните с действия, а не с технологии. Что человек делает повторно? Какая сеть у него в этот момент? Что случится после блокировки экрана? Какой отказ недопустим? Один критичный запрет важнее девяти удобных преимуществ. Для фото документа возможностей PWA может хватить. Для непрерывного обмена с Bluetooth-датчиком в фоне одного факта «Bluetooth поддерживается» недостаточно.
Матрица PWA и приложения по 10 критериям
Скопируйте таблицу в рабочий документ и замените общие формулировки требованиями своего продукта. Если в строке с обязательной функцией остаётся «проверить», решение ещё не принято.
| Критерий | PWA | Приложение | Что проверить |
|---|---|---|---|
| 1. Первый вход | Ссылка, поиск, QR-код, письмо | Карточка магазина или прямая ссылка после установки | Откуда реально приходит новый пользователь |
| 2. Установка | Путь и подсказки зависят от браузера и ОС | Магазин, загрузка и первый запуск | Сколько шагов до первой пользы на каждой платформе |
| 3. Повторный запуск | Ярлык, история браузера, ссылка или уведомление | Иконка, системный поиск, ссылка или уведомление | Сохраняются ли вход, экран и незавершённое действие |
| 4. Уведомления | Доступность зависит от режима установки, ОС и согласия | Системный канал с разрешениями и правилами ОС | Доставка, нажатие и возврат в нужный экран |
| 5. Слабая сеть | Кэш, локальные данные и очередь нужно проектировать | Локальную модель и синхронизацию тоже нужно проектировать | Нет ли потерь и дублей после восстановления связи |
| 6. Фоновая работа | Браузер ограничивает время и доступные механизмы | Больше специальных режимов, но они также ограничены ОС | Что должно произойти после блокировки экрана |
| 7. Функции устройства | Камера, файлы и геолокация часто доступны; поддержка сложных функций различается | Глубже работает с системой и внешними устройствами | Точная связка «устройство + ОС + браузер + разрешение» |
| 8. Как люди находят продукт | Публичные страницы могут находиться через веб-поиск | Карточка участвует в поиске и рекомендациях магазина | Какой канал действительно приводит целевых людей |
| 9. Платежи | Веб-оплата зависит от рынка, товара и провайдера | Добавляются правила магазина для цифровых покупок | Тип товара, страна, возвраты и восстановление покупки |
| 10. Владение | Одна веб-версия, но остаются браузеры, кэш, устройства и поддержка | Сборки, магазины и версии ОС, зато меньше веб-обходов для системных функций | Полная стоимость за один и тот же период поддержки |
Сохраните или перешлите матрицу команде. Она полезна до выбора подрядчика и не обязывает заказывать разработку. Сначала заполните колонку «Что проверить», затем обсуждайте формат и оценку.
Четыре развилки
Ссылка важнее установки?
PWA получает преимущество.
Фон или функции устройства в ядре?
Проверяйте приложение первым.
Нужны поиск и глубокая системная интеграция?
Рассмотрите связку.
Действие редкое?
Возможно, достаточно сайта.
Матрица даёт предварительный ответ. Теперь пройдём её строки по порядку и посмотрим, где чаще всего возникает риск дорогой переделки.
Что PWA означает сегодня
Под PWA понимают веб-приложение, которое браузер позволяет добавить на главный экран телефона. Веб-манифест хранит название, иконки и режим запуска. Service worker работает как служебный сценарий браузера: он управляет сетевыми запросами и помогает загружать сохранённые данные без сети. Но сам ярлык ничего не гарантирует: работу без интернета и синхронизацию команда всё равно проектирует отдельно.
Граница стала менее чёткой. Начиная с iOS и iPadOS 26 любой сайт, добавленный на экран «Домой», по умолчанию открывается как веб-приложение; пользователь может выключить режим «Открывать как веб-приложение» (Open as Web App). Это расширяет сценарий установки, но не делает веб равным мобильному приложению и не отменяет различия браузеров, версий ОС и политик хранения. Поэтому требование формулируют через наблюдаемое поведение: «после повторного запуска доступен последний подтверждённый заказ», а не «у нас PWA».
Первый вход и установка: ссылка против витрины
PWA можно открыть из поиска, QR-кода, письма или мессенджера без магазина. Это сильный путь для первого касания: человек сразу видит товар, расчёт или личный кабинет. Установка зависит от браузера и платформы: подсказка, меню и терминология отличаются. Нельзя строить критичную воронку на предположении, что каждый увидит одинаковый системный баннер.
Мобильное приложение требует перехода в магазин, загрузки и первого запуска. Взамен продукт получает привычную карточку, отзывы, обновления и понятный канал установки и обновлений. Магазин полезен, если аудитория ищет продукт там или корпоративное управление требует установочный пакет. При этом публикация добавляет аккаунты, подписи, сведения о конфиденциальности, проверку версий и ответы на замечания.
Допустим, сервис нужен гостю мероприятия один раз: QR-код, расписание, маршрут. Установка приложения только удлинит путь. Для ежедневной работы сотрудника на управляемом устройстве установочный пакет может быть удобнее ссылки. Решение определяет реальный канал входа, а не престиж иконки.
Повторный запуск: вернётся ли человек в нужное место
Первый экран легко сравнить на демонстрации. Намного полезнее закрыть продукт, подождать, перейти по уведомлению или ссылке и проверить возврат. PWA может запускаться с ярлыка, из истории браузера или по адресу конкретного экрана. Приложение получает системную иконку и прямые ссылки, но в обоих форматах команда должна сохранить авторизацию, контекст и незавершённое действие.
Представьте, что пользователь заполнял форму, переключился в SMS за одноразовым кодом и вернулся. Если данные исчезли или его отправило на главную, внешнее сходство форматов не имеет значения. Зафиксируйте критерий приёмки заранее: «после возврата открыт тот же заказ, введённые поля сохранены, следующий шаг понятен».
Слабая сеть и работа без интернета: открыть недостаточно
Работу без сети всегда нужно проектировать. Команда выбирает, что хранится на устройстве, можно ли создавать и менять записи без связи, как устроена очередь и кто побеждает при конфликте. Фраза «страница открылась в авиарежиме» проверяет лишь оболочку. Она ничего не говорит о сохранении заказа.
Допустим, сотрудник изменил статус заказа в подвале. Интерфейс показывает «сохранено на устройстве», после чего человек закрывает PWA. Когда связь вернётся, сервер должен получить ровно одно изменение. Для этого нужны локальный идентификатор, повторяемый безопасный запрос, понятные состояния синхронизации и ручной повтор при ошибке.
Та же задача существует и в мобильном приложении. Разница в доступных механизмах и ограничениях ОС, а не в наличии волшебной галочки. Пройдите путь целиком: отключите сеть, измените данные, закройте продукт, верните связь и проверьте итог на сервере.
Уведомления и фоновая работа: две разные задачи
Начиная с iOS и iPadOS 16.4 веб-приложения, добавленные на экран «Домой», поддерживают веб-уведомления (Web Push). Запрос разрешения должен следовать за явным действием пользователя, например за нажатием «Включить уведомления». Обычного открытия ссылки недостаточно.
WebKit требует показывать уведомление пользователю: скрытые уведомления для произвольной фоновой синхронизации не разрешены. Браузер и ОС также могут остановить service worker ради батареи, памяти и приватности. У мобильного приложения больше специальных фоновых режимов, включая геолокацию, аудио и передачу данных, но у каждого есть свои разрешения и ограничения.
Разделите требования: уведомление возвращает человека; синхронизация делает данные на устройстве и сервере одинаковыми и актуальными; фоновый режим выполняет ограниченную работу. Если процесс должен стартовать ровно в момент X, добавьте серверное событие и запасной путь.
Функции устройства: одинаковое название не означает одинаковую глубину
Веб работает с камерой, микрофоном, геолокацией, файлами и частью других функций при защищённом соединении, разрешениях и поддержке конкретного браузера. Доступ к Bluetooth из браузера (Web Bluetooth), напротив, имеет ограниченную доступность и не работает в ряде широко используемых браузеров. NFC, USB, контакты, фоновые датчики, системные виджеты, CarPlay и Android Auto требуют отдельной проверки; иногда веб-аналога нужного сценария нет.
Составьте карту «действие → API → браузер → ОС → устройство». Проверьте отказ в разрешении, повторный запрос, блокировку экрана, энергосбережение, входящий звонок и возврат из системного окна. Для разового сканирования QR-кода веба может быть достаточно. Для датчика с длительной Bluetooth-сессией и обязательной доставкой измерений нужен прототип приложения и документация производителя.
Если приложение уже вошло в короткий список, отдельный материал поможет выбрать нативную или кроссплатформенную реализацию. Это следующий вопрос: сначала нужно доказать, что магазинный продукт вообще нужен.
Магазины, проверка и обнаружение
PWA распространяется через веб. Это снимает обязательную проверку каждого выпуска магазином, но ответственность за безопасность, доступность и совместимость остаётся у владельца. Мобильное приложение получает App Store и Google Play, однако правила магазинов могут влиять на аккаунт, контент, платежи и сроки выхода версии.
Иногда веб-продукт помещают в системную оболочку, чтобы попасть в магазин или подключить несколько функций устройства. Такой путь не запрещён автоматически. Но правило Apple 4.2 требует пользы, функций и интерфейса сверх переупакованного сайта. Google Play также требует стабильной работы и содержательной функциональности. Оболочка не обходит проверку: она добавляет сборки, сертификаты, магазинные метаданные и тесты.
Способы обнаружения тоже различаются. Публичные страницы PWA могут находиться через веб-поиск и открываться на нужном экране. Карточка приложения участвует в поиске магазина, рекомендациях и брендовых запросах, но его внутреннее содержимое не становится автоматически доступным веб-поиску. Иногда разумно разделить роли: веб знакомит с продуктом, приложение обслуживает частое использование.
SEO и прямые ссылки: как человек попадает в нужный экран
У PWA есть адреса, поэтому продукт может получить органический вход, если важные страницы доступны поисковому роботу, сервер отдаёт осмысленный HTML, поисковику правильно указан главный адрес страницы, а авторизация не закрывает всё содержимое. Сама технология PWA не улучшает SEO: тяжёлая отрисовка в браузере, дубли адресов и медленная загрузка способны ухудшить результат.
Прямая ссылка должна вести не просто «в продукт», а в конкретный заказ, товар или шаг. В вебе это обычный URL. В приложении системные прямые ссылки (Universal Links на iPhone и App Links на Android) открывают нужный экран, если приложение установлено. Иначе человек должен попасть на понятную веб-страницу. Проверьте ссылки из почты, мессенджеров, рекламы и QR-кодов, авторизацию после перехода и сохранение целевого экрана.
Платежи и подписки
В PWA обычно применяются веб-платежи и правила платёжного провайдера. Доступные методы зависят от страны, браузера, банка и типа товара. В приложении добавляются правила магазина: для цифрового контента и функций могут действовать требования платформенной покупки, исключения и региональные условия. Их проверяют до расчёта выручки и расходов продукта.
Не выбирайте канал только по комиссии. Посчитайте возвраты, чеки, налоги, подписку, восстановление покупки, семейный доступ, смену устройства, промокоды, поддержку и сверку с бухгалтерией. Физический товар, цифровая подписка и доступ для компаний требуют разных схем. Прототип оплаты должен пройти на реальных тестовых аккаунтах и показать, как сервер подтверждает право доступа, а не доверяет одному экрану успеха.
Интерфейс, производительность и доступность
Хорошая PWA не обязана копировать мобильное приложение. Её сила в знакомом веб-входе, адаптивности и общем контенте. Но нужно убрать браузерные сюрпризы: скачки интерфейса, потерю введённых данных, конфликт жестов, неверную высоту экрана и медленное восстановление после выгрузки. Приложение получает платформенные компоненты, но при плохой реализации тоже бывает медленным и неудобным.
Проверяйте время до полезного действия, отклик после нажатия, слабую сеть, старое устройство и восстановление состояния. Доступность входит в обязательный сценарий: крупный шрифт, экранный диктор, внешняя клавиатура, контраст, фокус, подписи полей и сообщения об ошибках. После возврата из SMS пользователь должен увидеть прежние данные и понять следующий шаг. Это требование важнее выбора технологии кнопки.
Стоимость владения: считать не код, а эксплуатацию продукта
Полная стоимость владения включает исследование, дизайн, клиентскую и серверную части, модель работы без сети, аналитику, безопасность, проверку качества, устройства, магазины, поддержку и обновления. PWA может упростить выпуск веб-изменений, но требует тестов в разных браузерах и контроля кэша. Приложение добавляет сборки, магазины и версии ОС, зато прямее решает часть задач с системными функциями.
Представьте два предложения подрядчиков. В первом дешевле старт PWA, но обязательный Bluetooth-сценарий пока проверен только в Chrome на одном Android. Во втором дороже первая версия приложения, зато предусмотрены прототип на iPhone, восстановление соединения и диагностика ошибок. Сравнивать суммы без этих строк бессмысленно.
Попросите две оценки с одинаковым объёмом работ и периодом расчёта. В обе включите:
- первую версию и регулярные выпуски;
- обновления ОС, браузеров, сторонних библиотек и инструментов разработки (SDK);
- инциденты, поддержку и возможную миграцию.
Сравните итог без универсального процента экономии. Дешевле тот вариант, где обязательное действие поддерживается без хрупких обходов.
PWA и приложение вместе: когда связка оправдана
Выбор не обязан быть вечным и взаимоисключающим. PWA может привлекать пользователя из поиска, показывать каталог и проверять спрос. Приложение может обслуживать частый персональный сценарий, функции устройства и фоновые режимы. Общими остаются серверные интерфейсы, модель данных, дизайн-система, аналитические события и контент. При этом каждому каналу нужна ясная роль.
Переход планируют по наблюдаемому сигналу: появился регулярный сценарий, обязательная системная функция, критичный отказ из-за веб-ограничения или важный магазинный канал. Серверные контракты и знания можно сохранить, но навигацию, локальные данные, уведомления, авторизацию и тесты придётся адаптировать. Обратный путь тоже возможен: редкие функции приложения переводят в веб, если установка больше не даёт пользы.
Если вы выбираете не только между PWA и приложением, а между лендингом, корпоративным сайтом, интернет-магазином и приложением, используйте общий гид по цифровым форматам. Здесь граница уже: мы предполагаем, что интерактивный повторный сценарий существует, и разбираем способ его доставки.
Что проверить на устройствах до договора
- Назовите одно главное действие и недопустимый отказ.
- Зафиксируйте модели устройств, версии ОС и браузеры реальной аудитории.
- Пройдите установку из каждого канала и повторный запуск.
- Отключите сеть до, во время и после изменения данных.
- Проверьте уведомления после осознанного согласия и долгого простоя.
- Заблокируйте экран; включите энергосбережение; выгрузите продукт из памяти.
- Откажите в разрешении камеры, геолокации или Bluetooth и восстановите его.
- Пройдите прямую ссылку без установки, после установки и после авторизации.
- Проверьте оплату, отмену, возврат и восстановление доступа.
- Включите крупный шрифт и экранный диктор, используйте внешнюю клавиатуру.
Результат проверки храните в журнале: устройство, версия, шаги, ожидаемое и фактическое поведение, критичность, ответственный и решение. Если риск касается ядра, сделайте узкий технический прототип. Не стройте весь интерфейс, чтобы узнать, что критичная функция недоступна. Для расширения плана используйте отдельные материалы про проверку веб-продуктов и проверку мобильных приложений.
Когда не нужны ни PWA, ни приложение
Представьте ежегодную подачу показаний или разовую заявку по ссылке из сообщения. Пользователь не хочет устанавливать продукт, включать уведомления и учиться навигации. Быстрый адаптивный сайт с сохранением черновика решает задачу честнее. Возможности PWA добавят смысл лишь при повторном использовании или реальной потребности в работе без сети.
Не нужен новый клиент и тогда, когда проблема находится в процессе: данные не готовы, статусы противоречат друг другу, сотрудники обрабатывают заявки вручную, а владельца продукта нет. Иконка не исправит интеграцию. Сначала стабилизируйте API, роли и бизнес-правила; затем станет видно, какой интерфейс нужен.
Официальные источники и дата проверки
Платформенные сведения проверены 10 августа 2026 года. Перед реализацией сверяйте текущие версии документации и правила целевых магазинов: возможности браузеров и требования публикации меняются.
- WebKit: установка сайтов на экран «Домой» в Safari 26.
- WebKit: Web Push для веб-приложений на iOS и iPadOS 16.4.
- WebKit: требование показывать видимое уведомление.
- MDN: работа PWA без сети и фоновые операции.
- MDN: ограниченная доступность Web Bluetooth.
- Apple: правила проверки приложений, раздел 4.2.
- Google Play: требования к функциональности и стабильности.
FAQ
Может ли PWA полностью заменить мобильное приложение?
Иногда да: если обязательный сценарий надёжно работает в целевых браузерах, не зависит от недоступной функции телефона и имеет понятный запасной путь для слабой сети и фоновых ограничений. Для Bluetooth-оборудования, сложной фоновой геолокации, системных виджетов или других платформенных возможностей чаще нужен прототип мобильного приложения.
Работает ли PWA без интернета?
Да, если команда заранее определила, какие экраны и данные доступны без сети, как сохраняются изменения, когда повторяется отправка и как решаются конфликты. Service worker представляет собой служебный сценарий в браузере. Вместе с браузерными хранилищами он даёт инструменты, но не делает весь продукт автономным автоматически.
Работают ли push-уведомления PWA на iPhone?
Да. Начиная с iOS и iPadOS 16.4 веб-уведомления (Web Push) доступны веб-приложениям, добавленным на экран «Домой». Запрос разрешения должен следовать за явным действием пользователя. Уведомление нельзя считать скрытым каналом фоновой синхронизации.
Можно ли опубликовать PWA в App Store или Google Play?
Веб-продукт можно упаковать в магазинную оболочку, но публикация создаёт отдельный процесс сборки, правил, платежей, проверки и поддержки. Оболочки не запрещены автоматически, однако правила Apple о минимальной функциональности и другие требования магазина всё равно применяются.
Что дешевле в поддержке: PWA или приложение?
Ответ зависит от функций и того, сколько лет продукт нужно поддерживать. PWA сохраняет тестирование браузеров, устройств, кэша, уведомлений и серверной части. Приложение добавляет сборки и магазины, зато может убрать дорогие веб-обходы для системных функций. Сравнивайте одинаковый объём работ.
Когда не нужны ни PWA, ни мобильное приложение?
Если действие редкое, начинается со ссылки или поиска и не требует установки, работы без сети, уведомлений или глубоких функций устройства, достаточно быстрого адаптивного сайта. Иконка на экране сама по себе не создаёт повторного спроса.
Проверим формат на трёх обязательных функциях
Оставьте имя и телефон. На первой встрече назовите три обязательные функции, целевые ОС и браузеры и покажите сценарий повторного входа. Мы разложим путь по десяти критериям и вернём матрицу применимости со списком проверок: станет понятно, нужен прототип, можно считать оценку или достаточно более простого веб-формата.