Как сделать приложение из сайта: PWA, WebView или нативная разработка

По данным StatCounter, в октябре 2026 года на смартфоны приходилось 59,9 % мирового веб-трафика, на десктопы — 38,5 %. Пользователь уже пришёл на сайт с телефона, и логичный следующий шаг — дать ему иконку на экране, push-уведомления и вход в один тап. Простого «завернуть сайт в приложение» для этого часто не хватает: в правилах App Store прямо сказано, что приложение должно быть чем-то большим, чем перепакованный сайт. А у Google есть свои критерии установки PWA, без которых браузер не предложит «Установить».

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

Ниже разберём четыре способа сделать приложение из сайта, покажем, что из сайта реально переиспользуется, какие требования предъявляют Google Play, App Store и RuStore, сколько это занимает по времени и деньгам. В конце — чек-лист выбора, типичные ошибки и ответы на частые вопросы.

Зачем делать приложение из сайта и когда оно не нужно

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

Когда приложение окупается

• Повторные покупки и заказы. Доставка, аптека, маркетплейс, запись к врачу: клиент возвращается раз в неделю, и иконка на экране экономит ему путь через поиск.
• Push как канал удержания. Статус заказа, напоминание о записи, персональная акция. Уведомление дешевле повторного клика из рекламы.
• Работа без сети. Каталог, документы, чек-листы для выездных сотрудников, которые нужны в метро, на складе или на объекте.
• Доступ к «железу». Камера для сканирования, геолокация в фоне, NFC, биометрия, Bluetooth-устройства. Браузер даёт к ним ограниченный доступ, а на iOS ещё и неполный.
• Присутствие в сторах. Для части аудитории «есть в App Store / RuStore» — сигнал доверия и ещё один канал привлечения через поиск в магазине.
• Лояльность. Бонусная карта, история заказов, персональные предложения удобнее живут в приложении, чем в кабинете на сайте.

Когда хватит адаптивного сайта

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

Приложение и мобильный сайт: в чём разница

Критерий	Мобильный сайт	Приложение
Установка	Не нужна, открывается по ссылке	Из стора или с главного экрана (PWA)
Push-уведомления	Только Web Push, на iOS — после установки на экран «Домой»	Полноценные, на обеих платформах
Офлайн	Нет, если не настроен service worker	Да, при правильной архитектуре
Доступ к железу	Частичный, зависит от браузера	Полный в нативе и гибриде
Поиск и SEO	Индексируется поисковиками	ASO в сторе; PWA остаётся сайтом и индексируется
Обновления	Мгновенно, на сервере	Через модерацию стора (кроме PWA и веб-части)
Стоимость	Уже есть	От небольших доработок до отдельного проекта

Какие есть способы превратить сайт в приложение

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

Подход	Что переиспользуется	Сторы	Срок (ориентир рынка)
PWA	Весь сайт: вёрстка, код, бэкенд	Не нужны; установка из браузера	2–6 недель
Упаковка в стор (TWA / WebView)	Весь сайт или готовая PWA	Google Play, RuStore; App Store — с большим риском отказа	от 1–7 дней
Гибрид (Capacitor, Ionic, Flutter, React Native)	Бэкенд и API, частично веб-код (Capacitor)	Все сторы	2–4 месяца
Натив (Swift, Kotlin)	Бэкенд, API, дизайн-система, контент	Все сторы	3–6 месяцев

Здесь мы не повторяем теорию о плюсах и минусах каждого формата: если вы ещё выбираете между веб-технологиями и нативом, начните с нашего подробного сравнения PWA и нативного приложения. Дальше — практика: как пройти каждый путь, если сайт уже есть.

Как сделать PWA из сайта: пошаговая инструкция

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

1. Переведите сайт на HTTPS и адаптивную вёрстку. Без HTTPS service worker не зарегистрируется, а без мета-тега viewport и мобильной сетки «приложение» будет выглядеть как уменьшенный десктоп.
2. Добавьте web app manifest. Это JSON-файл с именем приложения (name или short_name), иконками 192 и 512 пикселей, стартовым адресом start_url, режимом отображения display и цветом темы. Подключается тегом <link rel="manifest"> в <head>.
3. Зарегистрируйте service worker и выберите стратегию кэша. Минимум — закэшировать «оболочку» приложения (app shell) и офлайн-страницу, чтобы без сети пользователь видел интерфейс, а не ошибку браузера.
4. Подготовьте иконки, splash-экран и мета-теги для iOS. Safari берёт иконку из apple-touch-icon, поэтому её стоит указать отдельно, вместе с цветом статус-бара.
5. Сделайте свою кнопку установки. В Chromium-браузерах событие beforeinstallprompt позволяет показать «Установить приложение» в удобный момент, например после оформления заказа, а не при первом входе.
6. Подключите push-уведомления. Web Push работает на Android и десктопе, а на iPhone, по данным WebKit, — с iOS 16.4 и только после того, как пользователь добавил сайт на экран «Домой» и сам нажал кнопку подписки.
7. Проверьте результат. В Chrome DevTools на вкладке Application видно, распознан ли манифест и активен ли service worker. Lighthouse покажет, чего не хватает для установки.

Минимальный манифест выглядит так:

{
  "name": "Магазин Пример",
  "short_name": "Пример",
  "start_url": "/?source=pwa",
  "display": "standalone",
  "theme_color": "#0f172a",
  "background_color": "#0f172a",
  "icons": [
    { "src": "/icons/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

А регистрация service worker укладывается в несколько строк:

if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/sw.js');
  });
}

По критериям web.dev Chrome предлагает установку, когда сайт открыт по HTTPS, в манифесте есть имя, иконки 192 и 512 px, start_url и display со значением fullscreen, standalone, minimal-ui или window-controls-overlay, а поле prefer_related_applications отсутствует или равно false. Ещё одно условие — пользователь хотя бы раз кликнул по странице и провёл на ней не меньше 30 секунд.

Ограничения PWA

• iOS отстаёт от Android. Нет системного баннера установки: пользователь добавляет сайт на экран вручную через меню «Поделиться». Push работает только после этого шага.
• Нет в App Store. Сама по себе PWA в магазин Apple не попадает, а упаковка в обёртку упирается в правило 4.2 (о нём ниже).
• Ограниченный доступ к железу. NFC, Bluetooth, фоновая геолокация, работа с контактами доступны частично или только в отдельных браузерах.
• Фоновые задачи. Синхронизация в фоне и периодические обновления на iOS практически недоступны.
• Хранилище. Браузер может очистить кэш и локальные данные, если приложением долго не пользовались, поэтому критичные данные должны жить на сервере.

Как опубликовать сайт в Google Play: TWA и WebView-обёртка

Trusted Web Activity (TWA) — это способ открыть PWA внутри Android-приложения так, что страницу рендерит сам браузер (Chrome или другой с поддержкой протокола), а не встроенный WebView. По документации Chrome for Developers, TWA построен на протоколе Custom Tabs, а доверие между приложением и сайтом подтверждается через Digital Asset Links. На устаревших версиях Chrome приложение откатывается к обычной Custom Tab.

Порядок публикации сайта в Google Play через TWA:

1. Доведите сайт до рабочей PWA. Манифест, service worker и офлайн-страница обязательны: без них приложение в сторе будет вести себя как ярлык на сайт.
2. Сгенерируйте Android-проект. Командная утилита Bubblewrap на Node.js делает это по манифесту: bubblewrap init --manifest https://example.ru/manifest.json, затем bubblewrap build. Альтернатива без командной строки — PWABuilder.
3. Подпишите сборку и пропишите отпечаток. SHA-256 отпечаток ключа подписи кладётся в файл /.well-known/assetlinks.json на вашем домене. Если используете подпись Google Play, берите отпечаток из Play Console.
4. Загрузите AAB в Google Play Console. Дальше — обычная публикация: карточка, скриншоты, политика конфиденциальности, модерация. Подробности — в статье о том, как опубликовать приложение в Google Play.

Файл assetlinks.json выглядит так:

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "ru.example.app",
    "sha256_cert_fingerprints": ["AB:CD:...:EF"]
  }
}]

Если отпечаток не совпал, приложение запустится, но сверху появится адресная строка браузера — первый признак того, что Digital Asset Links не прошёл проверку.

WebView-обёртка: когда она нужна и чем рискованна

WebView-обёртка — это нативное приложение-оболочка, внутри которого сайт открывается во встроенном браузерном компоненте. Её выбирают, когда нужен JS-мост к нативу: доступ к файлам, нативным платёжным SDK, push-сервисам или когда сайт не тянет на полноценную PWA. Как устроены веб-приложения в целом, мы разбирали в статье что такое веб-приложения и зачем они нужны.

Риски WebView-обёртки, о которых стоит знать до старта:

• Безопасность. Открытый JS-мост без ограничений даёт любой загруженной странице доступ к нативным функциям.
• Скорость. Тяжёлый сайт во WebView работает медленнее, чем в Chrome, особенно на бюджетных Android-смартфонах.
• Авторизация и cookie. Сессии могут теряться между запусками, а вход через сторонние сервисы (OAuth) часто ломается внутри WebView.
• Внешние ссылки и загрузки. Переходы на другие домены, скачивание и загрузка файлов, открытие PDF требуют отдельной обработки, иначе пользователь застревает.

RuStore

RuStore принимает APK и AAB, поэтому собранное через TWA или WebView Android-приложение можно выложить и туда. Учтите, что TWA зависит от браузера на устройстве, и протестируйте сборку на смартфонах без сервисов Google. Пошагово процесс описан в статье о том, как опубликовать приложение в RuStore.

Почему App Store отклоняет «сайт в обёртке» и как пройти модерацию

App Store отклоняет «сайт в обёртке», потому что пункт 4.2 App Review Guidelines требует от приложения функций, контента и интерфейса, которые поднимают его над перепакованным сайтом. Если приложение не особенно полезное, не уникальное и не «похоже на приложение», ему не место в App Store. Пункт 4.2.2 отдельно уточняет: приложение не должно быть в основном веб-вырезкой, агрегатором контента или набором ссылок.

На практике это значит, что WebView с вашим сайтом внутри модерацию, скорее всего, не пройдёт. Чтобы приложение выглядело «app-like», добавьте:

• Нативную навигацию. Таб-бар, системные жесты «назад», нативные заголовки экранов вместо меню-бургера сайта.
• Push-уведомления с понятной пользой: статус заказа, напоминания, персональные предложения.
• Офлайн-режим для ключевых сценариев: история заказов, избранное, сохранённые материалы.
• Биометрию и Sign in with Apple. Вход по Face ID, а если в приложении есть вход через сторонние сервисы — ещё и вход через Apple.
• Нативные экраны для главных сценариев: каталог, корзина, профиль. Вспомогательные разделы можно оставить веб-страницами.
• Никаких браузерных артефактов. Без адресной строки, всплывающих cookie-баннеров сайта, футера с картой сайта и ссылок, уводящих в Safari.

Совет из практики: под iOS почти всегда нужен как минимум гибрид. Дешёвая обёртка, отклонённая два-три раза, в итоге обходится дороже, чем сразу сделанное нормальное приложение. Требования к аккаунту и карточке разобраны в статье про публикацию в App Store.

Гибридное приложение: как переиспользовать код и API сайта

Гибридное приложение — это одна кодовая база, которая собирается под iOS и Android и работает с тем же бэкендом, что и сайт. Есть два лагеря: Capacitor и Ionic оставляют веб-код (HTML, CSS, JS-фреймворк) и добавляют нативные плагины, а Flutter и React Native рисуют новый нативный интерфейс, но ходят в те же API.

Чем гибрид отличается от WebView-обёртки:

Критерий	WebView-обёртка	Гибрид
Откуда контент	Загружается с живого сайта	Интерфейс внутри приложения, с сервера приходят только данные
Интерфейс	Как на сайте	Спроектирован под мобильные сценарии
Нативные функции	Через самописный JS-мост	Через готовые плагины и SDK
Шансы в App Store	Низкие	Обычные, как у любого приложения

Если фронтенд сайта написан на React, Vue или Angular и аккуратно разбит на компоненты, Capacitor позволяет переиспользовать заметную часть кода. Если же нужен быстрый и «родной» интерфейс, выгоднее кроссплатформенная разработка на Flutter или React Native: UI пишется заново, но бэкенд, API и бизнес-логика сайта остаются. О подходах и фреймворках подробнее — в статье что такое кроссплатформенная разработка.

Нативное приложение на базе сайта: что переиспользуется

Нативное приложение на базе сайта — это отдельные приложения на Swift для iOS и Kotlin для Android, которые используют серверную часть сайта как готовый фундамент. Интерфейс создаётся с нуля, но самая дорогая часть продукта — данные и бизнес-логика — уже есть.

Что берём с сайта:

• бэкенд и базу данных: каталог, заказы, пользователи;
• API (REST или GraphQL), если оно уже обслуживает фронтенд;
• дизайн-систему: цвета, шрифты, иконки, тон текстов;
• контент: тексты, изображения, справку;
• авторизацию и учётные записи пользователей.

Что делаем заново: мобильный интерфейс, офлайн-логику и синхронизацию, инфраструктуру push-уведомлений, аналитику и crash-репортинг внутри приложения.

Готов ли API сайта к мобильному клиенту

Сайт и приложение предъявляют к серверу разные требования, и API, которое отлично обслуживает браузер, часто приходится дорабатывать:

• Версионирование. Старые версии приложения живут у пользователей месяцами, поэтому изменения API не должны их ломать: нужны /v1, /v2 или аналог.
• Токены вместо cookie-сессий. Мобильному клиенту удобнее access- и refresh-токены, чем серверная сессия в cookie.
• Пагинация и лёгкие ответы. Не отдавайте весь каталог одним запросом и не тащите в ответ поля, которые экран не показывает.
• Ограничение частоты запросов и обработка ошибок. Понятные коды и тексты ошибок, rate limits, корректная работа при плохой сети.

Подробный разбор — в статье API для мобильного приложения.

Сравнение подходов: PWA, TWA/WebView, гибрид, натив

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

Критерий	PWA	TWA / WebView	Гибрид	Натив
Срок запуска	2–6 недель	от 1–7 дней (при готовом сайте)	2–4 месяца	3–6 месяцев
Бюджет (ориентир рынка)	Низкий	Самый низкий	Средний	Высокий, две кодовые базы
Google Play	Через TWA	Да	Да	Да
App Store	Нет	Высокий риск отказа по 4.2	Да	Да
RuStore	Через TWA-сборку	Да	Да	Да
Push на Android / iOS	Да / с iOS 16.4 после установки на «Домой»	Да / зависит от обёртки	Да / да	Да / да
Офлайн	Через service worker	Ограниченно	Да	Да
Доступ к железу	Частичный	Через JS-мост	Через плагины, почти полный	Полный
Производительность	Как у сайта	Как у сайта или ниже	Близка к нативу	Максимальная
Поддержка	Одна кодовая база — сайт	Сайт + оболочка	Сайт + одно приложение	Сайт + два приложения
Переиспользование сайта	Полное	Полное	Бэкенд, частично фронтенд	Бэкенд и API

Сколько стоит и сколько занимает сделать приложение из сайта

Стоимость приложения из сайта определяется выбранным подходом: от нескольких дней работы на WebView-обёртку до полугода на два нативных приложения. По открытым данным рынка, WebView-обёртку делают от 1–7 дней, PWA — за 2–6 недель, гибрид — за 2–4 месяца, натив — за 3–6 месяцев. Это ориентир рынка: точная оценка возможна только после ТЗ и аудита сайта и API.

Что влияет на стоимость

• Число платформ. Только Android, iOS и Android или ещё и веб-версия.
• Готовность API. Есть ли документированное API или логика зашита в шаблоны сайта и её придётся выносить.
• Авторизация и платежи. Вход по телефону, через сторонние сервисы, оплата картой, подписки внутри приложения.
• Офлайн-режим. Простой кэш или полноценная синхронизация с разрешением конфликтов, как в подходе offline-first.
• Push-уведомления. Транзакционные или с сегментацией и маркетинговыми сценариями.
• Дизайн. Перенос стиля сайта или отдельное проектирование мобильных сценариев.
• Интеграции. CRM, 1С, системы лояльности, аналитика.

Скрытые расходы

• Взносы сторов. Apple Developer Program — $99 в год, аккаунт разработчика Google Play — $25 один раз.
• Поддержка. На рынке её закладывают на уровне примерно 15–25 % от бюджета разработки в год.
• Обновления под новые iOS и Android. Каждый крупный релиз ОС требует проверки, а иногда и доработок.
• Модерация. Повторные отправки после отказа съедают время команды.
• ASO. Карточка в сторе, скриншоты, тексты и работа с отзывами — отдельная задача после релиза.

Как выбрать способ: чек-лист из 7 вопросов

Выбрать способ сделать приложение из сайта проще всего последовательными вопросами: каждый ответ отсекает часть вариантов. Пройдите их по порядку.

1. Нужно ли присутствие в App Store? Если да — PWA и простая обёртка отпадают, остаются гибрид и натив.
2. Нужен ли глубокий доступ к железу? NFC, Bluetooth, фоновая геолокация, сложная работа с камерой — это аргумент за натив или гибрид с плагинами.
3. Должно ли приложение работать без сети? Офлайн с синхронизацией тянет к гибриду или нативу; простой кэш умеет и PWA.
4. Насколько важны push-уведомления на iPhone? Если это главный канал удержания, PWA с её условием «сначала на экран Домой» может не хватить.
5. Какие у вас бюджет и срок? Нужно проверить гипотезу за месяц — начните с PWA или TWA. Есть бюджет на продукт — сразу гибрид.
6. Готово ли API сайта? Если логика зашита в шаблоны, заложите время на API — оно понадобится для любого пути, кроме PWA и обёртки.
7. Кто будет поддерживать приложение? Одна веб-команда потянет PWA и Capacitor, для натива нужны iOS- и Android-разработчики.

Итог в виде короткого дерева решений:

• Нужно быстро и только Android → PWA + TWA в Google Play и RuStore.
• Сторы не важны, важна иконка и push на Android → PWA.
• Нужны обе платформы, App Store и разумный бюджет → гибрид на Flutter, React Native или Capacitor.
• Сложные сценарии, железо, максимальная производительность → натив на API сайта.

Типичные ошибки при переносе сайта в приложение

Типичные ошибки при переносе сайта в приложение связаны с ожиданием, что приложение — это тот же сайт, только в другой упаковке. Чаще всего встречаются шесть:

• «Обернём в WebView — и в App Store». Самый частый сценарий отказа по пункту 4.2: время на модерацию потрачено, а приложения в сторе нет.
• Копия сайта один в один. Длинные страницы, формы на весь экран и подвал с картой сайта в приложении выглядят чужеродно.
• Десктопная навигация. Меню-бургер с тремя уровнями вложенности вместо таб-бара с 4–5 главными разделами.
• API «как есть» с cookie-сессиями. Пользователей разлогинивает, старые версии приложения ломаются после обновления сервера.
• Нет аналитики и crash-репортинга. Команда не знает, где пользователи бросают сценарий и почему приложение падает.
• «Запустили и забыли». Через год без обновлений приложение начинает сбоить на новых версиях ОС и проигрывает конкурентам в рейтинге стора.

Частые вопросы о том, как сделать приложение из сайта

Можно ли бесплатно сделать приложение из сайта?

Технически да: PWA делается на открытых веб-стандартах, и платить за лицензии не нужно, но понадобится работа разработчика. Онлайн-конструкторы, которые превращают сайт в приложение, обычно работают по подписке и создают WebView-обёртку со всеми её ограничениями. Для Google Play нужен ещё разовый взнос $25, для App Store — $99 в год.

Примут ли PWA в Google Play?

Да. PWA публикуется в Google Play через Trusted Web Activity: Bubblewrap или PWABuilder собирают Android-приложение, а связь с сайтом подтверждается файлом assetlinks.json по протоколу Digital Asset Links. Важно, чтобы PWA соответствовала критериям установки и работала без сети хотя бы на уровне офлайн-страницы.

Можно ли опубликовать сайт в App Store?

Только если приложение получится «app-like». Пункт 4.2 правил Apple требует функций и интерфейса, которые выходят за рамки перепакованного сайта, а пункт 4.2.2 запрещает приложения, которые в основном являются веб-вырезкой или набором ссылок. Нативная навигация, push, офлайн и нативные экраны ключевых сценариев сильно повышают шансы.

Работают ли push-уведомления в PWA на iPhone?

Да, начиная с iOS и iPadOS 16.4. Но подписаться можно только после того, как пользователь добавил сайт на экран «Домой», и только по его действию — например, по нажатию кнопки «Подписаться». В обычной вкладке Safari Web Push не работает.

Сколько времени занимает сделать приложение из сайта?

По рыночным ориентирам WebView-обёртка занимает от 1–7 дней, PWA — 2–6 недель, гибридное приложение — 2–4 месяца, нативные приложения — 3–6 месяцев. Срок сильно зависит от готовности API сайта, числа платформ и сложности сценариев.

Нужно ли переделывать сайт?

Для PWA сайт должен работать по HTTPS, хорошо выглядеть на смартфоне и получить манифест и service worker. Для гибрида и натива главное — API: если логика зашита в шаблоны страниц, её нужно вынести в API с версионированием и токенной авторизацией.

Влияет ли приложение на SEO сайта?

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