Как сделать приложение из сайта: PWA, обёртка WebView или отдельное приложение — что пропустят магазины

Короткий ответ: из готового сайта приложение делают тремя путями. PWA — тот же сайт, который ставится на экран телефона без магазинов. Обёртка WebView — сайт внутри приложения: дёшево, но App Store часто отклоняет её по правилу 4.2, если в ней нет ничего сверх сайта. Приложение на API сайта — новые экраны поверх того же сервера, каталога и заказов: у нас от 200 000 ₽ и от 2 недель за базовый объём.

Ниже — как устроен каждый путь, где он ломается, что из сайта идёт в дело, а что делается заново, что говорят правила App Store и Google Play и когда приложение из сайта вам не нужно вовсе. Правила магазинов сверены с официальными документами Apple и Google на 31 октября 2026 года.

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

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

• PWA (прогрессивное веб-приложение). Сайту добавляют манифест, иконку и сервис-воркер. Пользователь ставит его на экран «Домой», и он открывается без адресной строки, как приложение. В App Store его нет.
• Обёртка WebView. Пишут маленькое приложение, внутри которого на весь экран открыт ваш сайт. Его можно отправить в магазины, но проверку проходит не каждая обёртка.
• Приложение на API сайта. Экраны делают заново под телефон, а каталог, цены, остатки, заказы и личный кабинет берут из того же сервера через программный интерфейс. Сайт и приложение живут на одной базе.

Есть и промежуточный вариант: общий веб-код, собранный в нативные приложения через Capacitor или похожий инструмент, с настоящими push, камерой и хранением данных. Так устроено наше приложение знакомств Twin: общий код на React, сборки под iOS и Android, push-уведомления и чат в реальном времени. Но это уже не «сайт в обёртке», а приложение, которое писали как приложение.

Путь	Цена и срок у нас	App Store и Google Play	Push и работа без сети
PWA — сайт ставится на экран «Домой»	Отдельной цены в прайсе нет: дешевле и быстрее приложения, смета после брифа	Нет; в Google Play можно выпустить через Trusted Web Activity	Push на Android, на iPhone — с iOS 16.4 и только с экрана «Домой»; офлайн — то, что закэшировали
Обёртка WebView — сайт внутри приложения	Смета после брифа; дёшево, только если сайт уже хорошо работает на телефоне	Голая обёртка — высокий риск отказа в App Store по правилу 4.2	Push и офлайн есть, только если их дописали в нативной части
Приложение на API сайта	От 200 000 ₽ и от 2 недель за базовый объём до 6–8 экранов	Да, обычная публикация под вашими аккаунтами	Push на обеих платформах, офлайн — по ТЗ

PWA: как сайт становится приложением без магазинов?

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

Что важно знать до старта:

• Установку делает пользователь. На Android браузер сам предложит установить сайт. На iPhone нужно открыть меню «Поделиться» в Safari и выбрать «На экран „Домой“» — подсказку об этом придётся показывать на сайте.
• Push на iPhone ограничены. По данным WebKit, веб-push работает с iOS и iPadOS 16.4 и только у сайта, добавленного на экран «Домой». Разрешение можно спросить лишь в ответ на нажатие кнопки.
• Офлайн — не автоматически. Без сети откроется только то, что сервис-воркер сохранил: последний каталог, список заказов, карточка клиента. Оформить заказ без сети PWA не сможет, если это не запрограммировали отдельно.
• Google Play — можно. Через Trusted Web Activity PWA упаковывают в Android-приложение: сайт открывается на весь экран в браузере пользователя. По документации Chrome приложение и сайт должны быть одного владельца — это подтверждается файлом Digital Asset Links на сайте.

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

Обёртка WebView: что это и почему её дешевизна обманчива?

Обёртка — нативное приложение, единственный экран которого показывает ваш сайт. Её собирают быстро, потому что весь интерфейс уже есть. Но дальше всплывают проверка App Store, вход, оплата и push, и экономия часто уходит на доработки, которых не было в смете.

Где обёртка ломается на практике:

• Проверка Apple. Голый сайт в иконке — классический повод для отказа по правилу 4.2. Подробно о нём — ниже.
• Вход и сессия. Внутри WebView свои cookie. Пользователя может выбрасывать из кабинета, а вход через внешнего провайдера открывает отдельное окно, из которого надо корректно вернуться в приложение.
• Ссылки и файлы. PDF-счёт, ссылка на карту, звонок по номеру, переход в мессенджер — каждую такую ссылку надо обработать, иначе она откроется внутри обёртки и пользователь застрянет.
• Оплата. Если на сайте продаются подписки или цифровой контент, на iOS их нельзя просто оставить в веб-форме — об этом в разделе про правила.
• Push и офлайн. Сам WebView их не даёт. Их пишут в нативной части, и это уже работа программиста, а не настройка.

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

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

Пропустит ли App Store и Google Play приложение-сайт?

App Store — только если приложение даёт больше, чем сайт. Правило 4.2 требует функций, контента и интерфейса, которые поднимают его над «перепакованным сайтом». Google Play строже к чужим сайтам: запрещено приложение, главная цель которого — показать сайт без разрешения владельца.

Что прямо написано у Apple:

• В App Store Review Guidelines правило 4.2 требует, чтобы приложение было полезным и похожим на приложение; 4.2.2 — чтобы, кроме каталогов, оно не было в основном рекламой, вырезками из сайтов или набором ссылок.
• На странице App Review Apple пишет, что сайты, показанные внутри iOS-приложения, и веб-контент, не подогнанный под iOS, не делают приложение качественным.
• Правило 2.5.6: приложения, которые открывают веб, должны использовать WebKit — то есть сама технология WebView не запрещена. Отклоняют пустоту.

У Google в разделе Spam запрещены приложения, основная цель которых — показать webview сайта без разрешения его владельца, а правило о минимальной функциональности не пускает статичные приложения без своих функций и приложения, которые зависают или не грузятся. Свой сайт с подтверждённым владением через Trusted Web Activity — нормальный путь в Google Play.

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

Приложение на API сайта: что это значит на практике?

Это отдельное приложение, у которого общий с сайтом сервер. Экраны рисуют и программируют заново под телефон, а данные — каталог, цены, остатки, клиенты, заказы, бонусы — приложение получает с сайта через API. Заказ из приложения попадает в ту же админку и ту же 1С, что и заказ с сайта.

Как выглядит работа:

1. Аудит сайта. Смотрим, есть ли у сайта API и что он отдаёт. Если сайт на конструкторе без программного доступа к данным, придётся сначала решить, откуда приложение возьмёт каталог.
2. API для приложения. Чаще всего его дописывают на стороне сайта: вход по телефону или почте, каталог с фильтрами, корзина, заказы, профиль, адрес для push-токенов. Для связки с 1С или CRM, если её ещё нет, — отдельная интеграция, у нас от 32 000 ₽.
3. Экраны. Прототип и дизайн под телефон: нижнее меню, крупные кнопки, повтор заказа в одно касание. Это не копия сайта, а сценарий частого клиента.
4. Нативные функции. Push, сохранённый вход, камера, геолокация, офлайн-режим — то, ради чего приложение ставят.
5. Публикация. Сборки для App Store и Google Play под вашими аккаунтами.

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

Что из сайта переиспользуется, а что делается заново?

Переиспользуется всё, что за экраном: сервер, база, каталог, заказы, админка, обмен с 1С и CRM. Делаются заново экраны, хранение входа, push и всё, что работает с телефоном. Чем больше у сайта готовой логики и чем удобнее она доступна через API, тем меньше работы на стороне приложения.

Частые сюрпризы, которые стоит проверить заранее:

• Логика зашита в вёрстку. Если скидки или расчёт доставки считаются в браузере, а не на сервере, приложению их придётся дублировать или переносить на сервер.
• Нет ролей и токенов. Сайт пускает по cookie, а приложению нужен вход с токеном, который живёт неделями.
• Админка не умеет push. Рассылку и уведомления о статусе заказа надо добавить в ту же админку, где менеджеры работают с сайтом.

Часть сайта	PWA	Обёртка WebView	Приложение на API
Сервер, база, каталог, заказы	Целиком	Целиком	Целиком, через API
Вёрстка и экраны	Целиком, плюс доработка под установку	Целиком	Нет, экраны делаются заново
Вход и личный кабинет	Как на сайте	Как на сайте, но сессию надо проверить в WebView	Логика та же, экраны и хранение входа новые
Оплата	Как на сайте	Как на сайте; для цифрового контента на iOS — встроенные покупки	Эквайринг или встроенные покупки по правилам магазинов
Админка и 1С	Без изменений	Без изменений	Без изменений, плюс рассылка push из админки

Сколько стоит и сколько делается каждый путь?

Приложение для iOS и Android на API сайта — от 200 000 ₽ и от 2 недель за базовый объём до 6–8 экранов. PWA по прайсу обходится дешевле и делается быстрее приложения, но отдельной цены у неё нет. Обёртку и гибрид считаем после брифа: итог зависит от того, сколько нативного поверх сайта.

В базовый объём мобильного приложения входят регистрация и вход, push и базовая аналитика, оплаты, подключение к вашему API или простой сервер на нашей стороне, иконка, заставка и оформление карточек в магазинах, публикация в App Store и Google Play. Отдельно оплачиваются аккаунты разработчика Apple и Google Play — по тарифам магазинов, оформляются на вас, — а также сложная логика, чаты и карты. Подробно — на странице разработки мобильных приложений и в прайсе.

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

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

• Главная и каталог открываются быстро на мобильном интернете, без всплывающих окон на весь экран.
• Кнопки и поля удобны пальцем, заказ или запись оформляются без увеличения экрана.
• Вход в кабинет держится: после закрытия браузера не надо входить заново.
• Есть API или хотя бы понятно, откуда приложению брать каталог, заказы и профиль.
• Понятно, что продаётся: физические товары и услуги или подписки и цифровой контент — от этого зависит способ оплаты в приложении.
• Есть политика конфиденциальности, и в кабинете можно удалить аккаунт — правило 5.1.1(v) App Store требует удаления внутри приложения, если в нём можно создать аккаунт.
• Есть хотя бы один повод для push: статус заказа, напоминание о записи, возврат товара в наличие.

Про оплату — коротко. По правилу 3.1.1 подписки и платный контент, который открывается внутри приложения на iOS, продают через встроенные покупки. По правилу 3.1.3(e) физические товары и услуги вне приложения, наоборот, оплачивают обычной картой или эквайрингом. Подробнее — в статье об оплате в мобильном приложении.

Когда приложение из сайта не нужно?

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

• Сайт-визитка или сайт услуг. Каталог услуг, контакты и форма заявки в иконке — ровно то, что Apple называет перепакованным сайтом.
• Нет повода для возврата. Нет повторных покупок, записи, бонусов, статусов — нечего показывать и не о чем уведомлять.
• Сайт медленный на телефоне. Обёртка унаследует все его проблемы. Сначала исправьте сайт.
• Нужна только рассылка и приём заявок. Для этого хватит Telegram-бота: у нас от 16 000 ₽ и 1–2 дня.
• Работа в основном за компьютером. Таблицы, отчёты и выгрузки удобнее в веб-приложении, от 160 000 ₽.

Какие ошибки делают чаще всего?

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

1. Отправить голую обёртку в App Store и потерять недели на отказах и переделке.
2. Перенести в приложение весь сайт: блог, вакансии, реквизиты. Приложению нужны 5–8 экранов частого сценария, остальное — ссылкой на сайт.
3. Выпустить приложение на аккаунте сервиса-генератора или подрядчика. Аккаунты разработчика оформляйте на свою компанию с первого дня.
4. Забыть об обновлениях. Новые версии iOS и Android, сертификаты push и правила магазинов меняются — приложению нужна поддержка, у нас от 7 900 ₽ в месяц.
5. Не продумать push. Без поводов для уведомлений приложение ничем не напоминает о себе и его удаляют. Как работают push на разных платформах — в отдельной статье.

Как мы делаем приложение из сайта?

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

По договору оплата идёт 50 % до старта и 50 % по акту, на приёмку у вас 5 рабочих дней, гарантия на ошибки по нашей вине — 30 календарных дней с даты акта. После публикации мобильного приложения 14 дней бесплатно правим мелочи, дальше — абонентская поддержка или почасово. Исходный код приложения лежит в вашем репозитории: исключительное право на код остаётся у исполнителя, а вы получаете лицензию на весь срок действия права — можете держать код у себя, ставить на любой сервер и привлекать любых подрядчиков. Подробности тарифа — на странице мобильных приложений.

Короткие ответы на частые вопросы

Можно ли просто завернуть сайт в приложение и выложить в App Store?

Технически да, но обёртку без собственных функций App Store часто отклоняет по правилу 4.2: Apple ждёт от приложения больше, чем перепакованный сайт. Шансы растут, если в приложении есть push, вход с сохранённой сессией, работа без сети или функции телефона.

Пропустит ли Google Play приложение-сайт?

Google Play запрещает приложения, основная цель которых — показать чужой сайт без разрешения владельца, и приложения без собственной функциональности. Свой сайт можно выпустить через Trusted Web Activity: приложение и сайт связываются через Digital Asset Links.

Сколько стоит приложение, если сайт уже есть?

Приложение для iOS и Android на API сайта у нас стоит от 200 000 ₽ и делается от 2 недель за базовый объём. Экономия от готового сайта — в сервере, базе, каталоге и админке: их не пишут заново. PWA и обёртку считаем после брифа.

Подойдут ли онлайн-сервисы, которые делают приложение из сайта за минуту?

Они собирают ту же обёртку WebView. Для внутреннего теста этого хватит, но в App Store правило 4.2.6 отклоняет приложения из шаблонов и генераторов, если их отправляет не владелец контента. Проверьте, на чей аккаунт выйдет приложение.

Услуги и кейсы по теме: мобильные приложения · кейс Twin · цены и сроки