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

Соблазн понятный: сайт есть, кажется, что достаточно упаковать его в контейнер. На практике путь упирается в две стены.

Модерация. У Apple есть прямое правило — Guideline 4.2 (Minimum Functionality): приложение должно давать больше, чем перепакованный сайт, а пункт 4.2.2 нацелен на веб-клиппинги. К 2026 году Apple усилила проверку: ревьюеров стало больше, часть проверок автоматизирована, и тонкая оболочка вокруг сайта получает отказ почти гарантированно.

Расчёт «опубликуемся в российских сторах, там проще» тоже не работает. RuStore отклоняет приложения, которые представляют собой копию сайта в WebView без самостоятельной ценности, — формулировка отличается, суть та же.

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

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

У задачи есть четыре решения, и они отличаются по цене, качеству и рискам. Пятый путь — Telegram Mini App — стоит особняком, ему отведена отдельная глава ниже.

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

У Android есть механизм, которого нет на iOS. Trusted Web Activity позволяет положить PWA в Google Play как обычное приложение: пользователь скачивает его из магазина, а внутри работает ваш сайт в доверенном режиме, без адресной строки и браузерных элементов.

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

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

Этот вариант не попал в таблицу выше, потому что устроен иначе: приложение не устанавливается и не попадает в магазины. Mini App живёт внутри Telegram, не требует установки и публикации в сторах, открывается по ссылке или кнопке в боте и умеет принимать платежи.

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

Технически путь короткий: Mini App — это веб-приложение, которое открывается внутри Telegram и получает от него данные о пользователе и платежи. Если у сайта есть API, интерфейс собирается поверх него так же, как мобильный, только без публикации в сторах и без установки.

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

Главное заблуждение в формулировке «превратить сайт в приложение» — что переиспользуется сам сайт с его страницами и вёрсткой. Переиспользуется серверная часть.

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

При одном условии: у сайта есть нормальный API. Если логика свалена во фронтенд и данные отдаются вперемешку с вёрсткой, серверную часть сначала приводят в порядок, и это отдельный этап в плане и в смете.

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

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

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

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

Платежи. Веб-эквайринг с редиректом на страницу банка в приложении выглядит чужеродно и часто ломается. Мобильный платёж собирают заново — через платёжный SDK стора или собственный контур с картами и СБП.

Аналитика. Счётчики сайта в приложении не работают. Ставится мобильная аналитика со своими событиями, и сквозная картина «сайт плюс приложение» собирается отдельно.

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

Контент и админка. Если контентом управляют через CMS сайта, приложение должно получать его оттуда же. Иногда это простой запрос к готовому API, иногда — доработка админки под мобильные форматы: другие размеры картинок, короткие тексты, отдельные баннеры. Как устроена серверная часть веб-продукта, разбирали в материале про разработку веб-приложения.

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

Иногда переносить весь контент в нативный интерфейс дорого и бессмысленно — например, у вас тысячи страниц каталога или база знаний. Тогда гибрид оправдан, и задача сводится к тому, чтобы приложение перестало быть «сайтом в рамке».

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

• нативная навигация: таб-бар или боковое меню вместо браузерной кнопки «назад»;
• push-уведомления через систему платформы;
• разумное поведение без сети: сохранённые данные и понятное сообщение вместо белого экрана;
• работа с устройством там, где она уместна: камера, геолокация, биометрия, файлы;
• вход и профиль, реализованные средствами приложения.

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

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

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

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

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

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

Об этом не думают до релиза, а потом обнаруживают неприятные эффекты.

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

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

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

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

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

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

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

Тонкая обёртка вместо приложения. Завернуть сайт в WebView и отправить в стор — отказ по 4.2 и плохой опыт в придачу.

Ждать от обёртки нативного ощущения. Контейнер вокруг сайта не даст ни скорости, ни жестов, ни нормальной работы с устройством.

Игнорировать дешёвые пути. PWA и Mini App проверяют спрос за малые деньги; иногда после проверки выясняется, что полноценное приложение не нужно.

Рассчитывать на пуши PWA в iOS. Они есть, но доходимость до подписки низкая, и строить на этом канал коммуникации не стоит.

Считать, что переиспользуется витрина. Интерфейс собирают заново, а из сайта берут серверную часть. Если API нет, его готовят отдельно.

Забыть про диплинки и аналитику. Обе вещи дешевле сделать сразу, чем достраивать к работающему продукту.

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

• 1. Посмотрите в аналитике сайта, как часто возвращаются мобильные пользователи.
• 2. Решите, нужен ли полноценный продукт или задачу закроет PWA либо Mini App.
• 3. Проверьте, отдаёт ли ваш сайт данные через нормальный API.
• 4. Выпишите, что переезжает кроме данных: вход, платежи, аналитика, контент.
• 5. Определите один сценарий, который приложение должно закрыть лучше сайта.
• 6. Получите оценку выбранного пути и сравните её с ожидаемым эффектом.

Дальше это обычная разработка приложения под ключ — с той разницей, что серверная часть у вас уже есть.

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

Команда собрана внутри — аналитика, дизайн, мобильная разработка, бэкенд и тестирование. Цену и срок фиксируем до старта, а кликабельный прототип показываем на первой неделе, чтобы решение о полноценной разработке принималось на чём-то осязаемом.

Обсудить проект →