PWA или мобильное приложение: что выбрать для бизнеса

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

Сравните не названия, а сценарии

Отсутствие сети не должно превращать старый остаток в обещание наличия. В обоих форматах отдельно проектируют, что пользователь может посмотреть, что сохранить как черновик, а что требует подтверждения сервера.

Учебный пример: магазин расходных материалов

Представим магазин, где постоянный покупатель заказывает одни и те же фильтры. Ему нужны история заказов, актуальная персональная цена и быстрый повтор корзины. Для первой версии можно проверить PWA: покупатель открывает ссылку без установки, а затем добавляет сервис на главный экран.

Другой сценарий — сотрудник склада сканирует маркировку, работает с промышленным считывателем и собирает заказ при нестабильной связи. Здесь сначала проверяют совместимость оборудования и платформенных библиотек. Тест одного рискованного сценария полезнее большого списка обещаний о «полном доступе ко всем функциям телефона».

Установка и уведомления зависят от среды

MDN описывает различия установки PWA между браузерами и операционными системами. Нельзя обещать одинаковую кнопку установки везде. Веб-приложение, обычная вкладка и ярлык сайта также не всегда ведут себя одинаково.

Для уведомлений на iPhone важны режим запуска и разрешение пользователя. Базовые условия описаны в документации WebKit о Web Push. Подробную диагностику вынесли в инструкцию по PWA на iPhone, чтобы не подменять выбор формата перечислением настроек браузера.

Как принять решение до большой разработки

1. Запишите три действия, ради которых клиент будет возвращаться.
2. Укажите поддерживаемые устройства и способ распространения.
3. Отметьте зависимость от камеры, геолокации, уведомлений, оплаты и офлайн-данных.
4. Проверьте самый рискованный сценарий на нужных устройствах.
5. Согласуйте критерии приёмки и бюджет сопровождения.

В протокол проверки включите отказ в разрешении, выход из аккаунта и повторный запрос после потери связи. Оценивать стоит завершённое действие, а не только внешний вид экранов. Для описания первой версии пригодится определение MVP.

Что сравнить в предложениях подрядчиков

Сопоставляйте одинаковый состав: прототип, интерфейс, серверную часть, интеграции, тестирование, передачу исходников и порядок выпуска. Не сравнивайте цену готового клиентского интерфейса с ценой проекта, где ещё нужно создать API и привести в порядок каталог.

В ISKAR разработка PWA начинается от 400 000 ₽, iOS — от 600 000 ₽ за одну платформу, Android — от 600 000 ₽ отдельно. Комплекс iOS + Android + PWA — самостоятельное предложение от 1 200 000 ₽, а не автоматическая сумма отдельных услуг. Состав уточняется в смете; все стартовые цены собраны отдельно.

Проверьте формат на одном законченном действии

Проверьте возможность вернуться к действию

Перед запуском проведите учебную проверку с человеком, который не участвовал в проектировании. Дайте ему задачу: найти прошлый заказ, изменить количество и понять срок получения. Не объясняйте расположение кнопок. Запишите, на каком шаге понадобилась подсказка, какую информацию человек не увидел и смог ли вернуться после прерывания.

Повторите тот же путь без установки приложения. Если пользователь приходит из поиска впервые, обязательная установка до просмотра ассортимента может стать лишним препятствием. Сравнивать надо не только установленный клиент с сайтом, но и первый визит с повторным: у этих людей разные ожидания и разная готовность тратить время.

Разделите каналы измерения

В журнале запуска отдельно отмечайте открытие ссылки, установку, первый вход и полезное действие. Число иконок на устройствах ничего не говорит о выполненных заказах. Для повторного заказа важны актуальный состав, отсутствие дубля и подтверждение приёма, а для записи — выбранное время и понятный статус.

Не объявляйте предпочтение формата на основании одного удобного показа. Если участник не нашёл доставку из-за отсутствующего текста, это проблема содержания, которая может повториться в обоих интерфейсах. Если не сработало необходимое оборудование, это уже техническое ограничение, влияющее на выбор реализации.

Что должно остаться у владельца проекта

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

Такое описание позволяет вернуться к выбору, если потребности изменятся. Например, сначала покупателю достаточно повторной корзины в PWA, а позднее сотрудникам нужен специальный Android-клиент. Общие данные могут сохраниться, но новый интерфейс и оборудование потребуют собственной оценки, а не автоматической бесплатной миграции.

Частые ошибки

• Заказывать приложение, не проверив, зачем клиент станет им пользоваться повторно.
• Считать PWA готовым офлайн-магазином после подключения одного Service Worker.
• Обещать прохождение модерации магазина приложений заранее.
• Переносить неудобную корзину сайта в приложение без изменения сценария.

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

PWA заменит мобильную версию сайта?

Нет: доступность и удобство веб-интерфейса остаются основой. Возможности установки и кеширования добавляют к работающему сценарию, а не используют вместо адаптации страниц.

Можно начать с PWA, а потом добавить приложения?

Да, если заранее согласовать общие данные и API. Это не означает автоматического переноса всего интерфейса: клиентскую часть и платформенные функции оценивают отдельно.

Что отправить для оценки?

Ссылку на действующий сервис, описание главного действия клиента, список интеграций и целевых устройств. По этим данным можно обсудить формат разработки без искусственного выбора технологии заранее.