PWA или нативное приложение? Руководство по выбору

Вопрос «PWA или нативное приложение» обычно ставят неверно. Правильный вопрос не в том, что «лучше», а в том, какой доступ к оборудованию действительно нужен вашему проекту и насколько вы готовы зависеть от процесса модерации в сторе. В этой статье решение основано на конкретных критериях и официальных правилах платформ.

Кратко

• Разница не в качестве платформы, а в доступе к оборудованию и модели дистрибуции.
• PWA можно официально опубликовать в Google Play Store через Trusted Web Activity.
• У Apple нет официального пути для PWA в стор; обёртки, попадающие в App Store, подчиняются правилу 4.2.
• Push-уведомления на iOS работают только начиная с версии 16.4 и позже (март 2023).
• Начать с PWA и перейти на нативное приложение при подтверждённом спросе — разумная последовательность, снижающая риск.

Что означают эти два подхода

PWA (Progressive Web App) — это сайт, который работает в браузере, но благодаря манифесту веб-приложения и service worker может быть добавлен на главный экран, работать офлайн и отправлять push-уведомления. Единая кодовая база работает одновременно на десктопе, Android и iOS.

Нативное приложение пишется на языках конкретной платформы — Swift/SwiftUI для iOS, Kotlin для Android — и напрямую обращается ко всем API устройства, распространяясь через App Store и Google Play. Для двух платформ обычно нужны две отдельные кодовые базы (либо общий слой вроде React Native или Flutter).

Разницу часто сводят к спору «что выглядит более профессионально», но это неверная точка отсчёта. Пользователь обычно не замечает, PWA перед ним или нативное приложение, — он замечает, быстро ли оно открывается, работает ли функция и отвечает ли она его потребности. Выбор — это технический вопрос о том, к каким API оборудования и к какой модели дистрибуции действительно нужен доступ вашему продукту, а не вопрос пользовательского восприятия.

Матрица решения

Критерий	В пользу PWA	В пользу нативного приложения
Доступ к оборудованию	Достаточно камеры, геолокации, уведомлений	Bluetooth, NFC, фоновая геолокация, продвинутые сенсоры
Дистрибуция	Единая кодовая база, обновление мгновенно	Модерация в сторе, управление версиями
Бюджет	Низкий старт	Отдельная разработка для двух платформ
Присутствие в сторе	Возможно в Play Store, неопределённо в App Store	Гарантировано в обоих сторах
Работа офлайн	Полноценная поддержка через service worker	Полный контроль, без ограничений
Потолок производительности	В рамках возможностей веб-платформы	Может быть оптимизирован на уровне ОС
Корпоративное доверие	В некоторых отраслях воспринимается как «просто сайт»	Воспринимается как «настоящее приложение»
Поддержка	Одна поставка, один цикл тестирования	Две платформы, два цикла тестирования

Технические требования PWA — это не заявление, а критерий

То, что PWA считается «устанавливаемым», — не декларация, а конкретный чек-лист, который проверяют браузеры. Согласно критериям устанавливаемости web.dev, чтобы Chrome показал предложение установки, веб-приложение должно:

• обслуживаться по HTTPS,
• иметь корректный манифест веб-приложения с полями name/short_name, start_url, display (fullscreen/standalone/minimal-ui/window-controls-overlay),
• иметь в манифесте определённые иконки размером 192px и 512px,
• дождаться, пока пользователь хотя бы раз провзаимодействовал со страницей и провёл на ней не менее 30 секунд.

Это технические пороги, проверяемые браузером; именно здесь проходит грань между «мы сделали PWA» и «мы сделали устанавливаемое PWA».

Реальное ограничение на стороне iOS: дата появления push-уведомлений

Самым частым возражением против PWA было «на iPhone нормально не работает» — и до определённого момента это было справедливо. Согласно объявлению WebKit, поддержка Web Push для веб-приложений, добавленных на главный экран, появилась только начиная с iOS и iPadOS 16.4 (март 2023), и уведомления используют тот же сервис Apple Push Notification, что и нативные приложения, — они появляются на экране блокировки и на Apple Watch.

Как выстроить офлайн-опыт

Самое неверно понимаемое свойство PWA — офлайн-работа. Фраза «мы добавили service worker, теперь всё работает офлайн» неполна: то, какие данные будут доступны без подключения, — это осознанное архитектурное решение, а не автоматический побочный эффект. На практике выделяют три отдельных слоя:

1. Оболочка приложения (app shell) — навигация, базовый интерфейс, статические ресурсы. Её кэширование относительно простое и делается почти в каждом PWA.
2. Ранее просмотренный контент — страница товара, статья, список. Становится доступным офлайн благодаря стратегии кэширования service worker (например, stale-while-revalidate).
3. Операции реального времени или требующие транзакции — оплата, проверка наличия, актуальная цена. Их нельзя имитировать офлайн; их проектируют отдельно, с фоновой синхронизацией после восстановления соединения, иначе возникает риск показать пользователю неверную информацию.

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

Публикация в сторе: две платформы, две разные реальности

Google Play: есть официальный и задокументированный путь

На Android перенос PWA в стор называется Trusted Web Activity (TWA). Согласно официальному руководству Chrome for Developers, это поддерживаемый способ упаковать PWA через Chrome Custom Tabs как настоящее Android-приложение и загрузить в Play Store. Необходимые шаги:

1. Сайт соответствует стандартам PWA (HTTPS, манифест, service worker, нужные размеры иконок).
2. С помощью Bubblewrap или PWABuilder создаётся Android-пакет (AAB).
3. Файл assetlinks.json, связывающий домен с приложением, публикуется в /.well-known/ (проверка Digital Asset Links).
4. Проверка и публикация проходят через Play Console как для обычного Android-приложения.

App Store: официального пути нет, есть риск по пункту 4.2

У Apple нет официального механизма, аналогичного TWA у Google, для прямого переноса PWA в стор. С помощью инструментов вроде PWABuilder можно создать WebView-обёртку и отправить её, но такой пакет подпадает под пункт 4.2 (Minimum Functionality) App Store Review Guidelines. Формулировка Apple однозначна:

"Your app should include features, content, and UI that elevate it beyond a repackaged website."

Подпункт 4.2.2 прямо нацелен на приложения типа «web clipping». На практике это означает, что при отправке сайта «как есть» в WebView риск отклонения высок, и обойтись без нативной навигации, управления офлайн-состоянием и специфичного для платформы пользовательского опыта сложно.

Число шагов до публикации (схематично)

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

PWA (прямая публикация в вебе)2Деплой + добавление на главный экран

Android (TWA + Play Store)5Упаковка, asset links, проверка

iOS (нативное + App Store)7Сборка, TestFlight, проверка по 4.2

Когда PWA достаточно

1. Контентные, дашборд-, каталожные или e-commerce-проекты — большинство продуктов, которым не нужен особый доступ к оборудованию помимо камеры и уведомлений, попадают в эту категорию.
2. Важен быстрый выход на рынок. Единая кодовая база означает мгновенное обновление без ожидания модерации в сторе.
3. Бюджета не хватает на разработку под две отдельные платформы. PWA строится на технологиях, которые уже знает ваша веб-команда.
4. Важны SEO и трафик из веба. PWA остаётся индексируемым сайтом; этот подход мы рассматривали и в руководстве о быстром сайте.

Когда переходить на нативное приложение

1. Нужны Bluetooth, NFC или продвинутые функции камеры/AR — API оборудования, которые не закрывает веб-платформа.
2. Сценарии вроде непрерывного отслеживания геолокации в фоне, требующие разрешений на уровне операционной системы.
3. Корпоративный заказчик настаивает на «настоящем приложении» в сторе, и это принципиальный вопрос репутации, не подлежащий обсуждению.
4. Требуемый потолок производительности выше того, что предлагает веб — например, тяжёлая графика или игровой движок.

Гибридный подход: поддержать PWA нативной оболочкой

Делать резкий выбор между двумя вариантами не обязательно. Распространённый средний путь — развивать основной продукт как PWA и добавлять тонкую нативную оболочку только для той функции оборудования, которая действительно нужна: например, всё приложение работает на веб-технологиях, а нативным модулем написан только экран сопряжения Bluetooth. Такой подход также упрощает соответствие пункту 4.2 App Store, потому что приложение перестаёт быть «обёрнутым сайтом» и становится продуктом с реальной нативной функцией.

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

Логика затрат

Точные цифры сильно зависят от объёма; общая структура такова:

Подход	Кодовая база	Процесс в сторе	Обновление
PWA	Единая	Нет (Play Store опционально)	Мгновенное, без действий пользователя
PWA + Android TWA	Единая + упаковка	Проверка в Play Console	Веб-часть — мгновенно, пакет обновляется редко
Нативное (iOS + Android)	Две отдельные (или общий фреймворк)	Проверка в обоих сторах	По версиям, требует обновления от пользователя

Чтобы понять, в какую колонку попадает ваш проект, посмотрите нашу услугу PWA или, если планируете более масштабный продукт, — веб-приложение; стартовые диапазоны — на странице цен.

Итог

У вопроса «PWA или нативное приложение» нет единственно верного ответа — правильный ответ зависит от того, к каким API оборудования вам действительно нужен доступ и насколько вы готовы зависеть от процесса модерации в сторе. Большинство контентных, дашборд- и e-commerce-проектов может начать с PWA и отложить решение о переходе на нативное приложение до появления реальных данных использования. Если потребность в оборудовании ясна с самого начала, начинать сразу с нативного приложения не будет потерей времени.

Если не уверены, к какой стороне относится ваш проект, напишите нам через страницу контактов — вместе разберём потребность. Мы также затронули эту тему в разделе вопросов и ответов: разница между нативным приложением и PWA, процесс публикации в сторе и работа офлайн.