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

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

2 сентября 2026 Разработка 14 мин чтения

---

Что значит «сделать приложение из сайта» — простыми словами

Запрос звучит как задача на конвертацию: есть работающий интернет-магазин, нужно получить из него приложение для iOS и Android. На практике конвертируется только часть продукта, и важно с самого начала понимать, какая именно.

Любой интернет-магазин состоит из двух частей. Первая — серверная (бэкенд): база товаров, цены и остатки, заказы, личные кабинеты, обмен с учётной системой, оплата. Вторая — интерфейс: экраны, которые видит покупатель. Приложение переиспользует первую часть почти целиком и не переиспользует вторую: вёрстка сайта построена на HTML и CSS, а мобильное приложение рисует экраны собственными средствами системы.

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

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

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

Шесть вариантов: от PWA до единой кодовой базы

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

Вариант 1. PWA — сайт, который ставится на домашний экран

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

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

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

Вариант 2. Обёртка сайта в приложение

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

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

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

Вариант 3. Онлайн-конструктор приложений

Сервисы-конструкторы подключаются к каталогу интернет-магазина и собирают приложение по своему шаблону: витрина, категории, карточка, корзина, личный кабинет. Абонентская плата начинается примерно от 30 000 ₽ в месяц. В плату включены шаблонные экраны, подключение к каталогу, размещение в магазинах приложений и обновления сервиса; не входит фирменный дизайн за пределами настроек, уникальные сценарии и доступ к исходному коду. Первая версия появляется за несколько дней.

Плата за скорость — рамки шаблона. Внешний вид меняется в пределах настроек: цвета, логотип, порядок блоков. Уникальный сценарий — конструктор образа, подбор размера, бонусная механика с уровнями, оформление заказа на юридическое лицо — добавить нельзя, потому что дорожную карту продукта задаёт владелец сервиса, а не магазин. Когда бизнесу становится тесно, накопленную базу пользователей приходится переносить в собственный продукт — задача решаемая, но это отдельный проект. Как выглядит такой переход, видно на кейсе DAISYKNIT: по данным страницы кейса, при переходе с коробочного решения на собственное приложение клиентская база сохранилась на 100%.

Вариант 4. Нативная разработка под iOS и Android

Классический путь: два отдельных приложения, написанных средствами каждой системы — Swift для iOS и Kotlin для Android. Это даёт максимальную глубину работы с платформой: самые свежие возможности системы появляются здесь раньше, чем в кроссплатформенных решениях, а нестандартная графика и работа с оборудованием реализуются без ограничений.

Цена этой глубины — три параллельных продукта: сайт, приложение iOS, приложение Android. Три команды, три очереди задач, три графика выпусков. Рыночный ориентир для полностью заказной разработки с нуля — от 5 000 000 ₽ до 10 000 000 ₽ на старте и 6–12 месяцев до первого выпуска. В сумму включены исследование, дизайн, разработка двух приложений, тестирование и публикация; не входит сопровождение после выпуска и развитие продукта — дальше нужна собственная команда, ориентир по рынку около 400 000 ₽ в месяц. Вариант оправдан, когда мобильный продукт и есть основной бизнес, а сценарии в нём принципиально не типовые. Подробное сравнение подходов — в статье «Flutter или нативная разработка».

Вариант 5. Кроссплатформенное приложение поверх того же сервера

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

Это разумная середина для магазина, у которого сайт менять не планируют: он приносит поисковый трафик, недавно переделан или связан с внешними сервисами. Ограничение остаётся одно — витрина, баннеры и акции по-прежнему настраиваются в двух системах, и рассинхрон цен между сайтом и приложением случается ровно там. Как устроен такой проект, описано на странице мобильных приложений для e-commerce и в разборе кроссплатформенной разработки на Flutter.

Вариант 6. Единая кодовая база: сайт и приложение из одного кода

Шестой вариант меняет постановку задачи: не «сделать приложение к сайту», а собрать оба канала из одного исходного кода. Flutter собирает из общего кода приложения для iOS и Android и веб-версию, а вместе с ними — сборки для RuStore, Aurora OS и мини-приложения в Telegram.

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

Что переезжает с сайта, а что делается заново

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

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

Строка про дизайн — та, которую чаще всего недооценивают в смете. Мобильный сайт и мобильное приложение выглядят похоже, но собираются по разным правилам: в приложении есть постоянная нижняя навигация, свайпы, состояния загрузки без перезагрузки страницы, поведение при потере сети. Что входит в эту работу, описано на странице UX/UI-дизайна приложения и сайта; проверить текущие экраны перед стартом помогает аудит UX/UI.

Подводные камни: семь мест, где спотыкается проект

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

1. Отклонение при проверке за повтор сайта

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

2. Оплата и правила магазинов приложений

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

3. Публикация в российских магазинах приложений

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

4. Рассинхрон контента и цен между сайтом и приложением

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

5. Тройная стоимость доработок

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

6. Расчёт на «перенесём аудиторию сайта»

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

7. Поддержка после выпуска не заложена в план

Выпуск версии — не конец проекта. iOS и Android обновляются ежегодно, вместе с ними меняются требования магазинов к сборкам; библиотеки требуют обновлений безопасности. Без регулярного сопровождения приложение через год перестаёт собираться под новые версии систем. Кто это делает и по какой модели, фиксируется до старта: своя команда, подрядчик по технической поддержке приложений или платформа, где сопровождение включено в лицензионные платежи.

Порядок работ: семь шагов от аудита сайта до публикации

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

Шаг 1. Аудит сайта, данных и обмена (2–4 рабочих дня)

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

Шаг 2. Выбор варианта и состав первой версии (3–5 рабочих дней)

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

Шаг 3. Проектирование экранов под мобильные сценарии (5–8 рабочих дней)

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

Шаг 4. Подготовка серверной части и обмена (5–10 рабочих дней)

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

Шаг 5. Сборка приложения и подключение модулей (10–15 рабочих дней)

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

Шаг 6. Тестирование на устройствах и подготовка к публикации (4–7 рабочих дней)

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

Шаг 7. Публикация и первые обновления (3–7 рабочих дней)

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

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

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

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

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

Сколько стоит и от чего зависит смета

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

Все цены указаны с учётом НДС; действующие значения по трём направлениям и трём пакетам опубликованы на странице тарифов.

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

Смету при переносе сайта в приложение двигают шесть факторов:

1. Состояние серверной части. Если сервер уже отдаёт данные для внешних систем, шаг подготовки короткий; если каталог живёт внутри шаблонов сайта, его придётся выносить.
2. Число и глубина интеграций. 1С, CRM, служба доставки, эквайринг, маркетплейсы — каждая добавляет свою карту данных и свои проверки.
3. Уникальные сценарии. Подбор размера, конструктор образа, заказ на юридическое лицо, колеровка, распил — то, чего нет в типовом магазине.
4. Глубина фирменного стиля. Настройка палитры и шрифтов входит в интеграцию; полностью авторские экраны — отдельные работы.
5. Число целевых платформ. App Store, Google Play, RuStore, Aurora OS, мини-приложение Telegram — из одной кодовой базы это настройка сборок, а не отдельные проекты.
6. Кто делает интеграции. В пакете ПРО их подключает ваша команда или ваш подрядчик, в ПРО+ — команда исполнителя, без работы с вашей стороны.

Кейсы: как это выглядело на практике

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

Итог: перенос сайта в приложение на одной странице

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

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

Что делать дальше:

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

Часто задаваемые вопросы

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

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

Отклонят ли приложение в App Store, если оно повторяет сайт?

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

Нужно ли выключать сайт после запуска приложения?

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

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

Зависит от выбранного варианта. Подписка на конструктор начинается примерно от 30 000 ₽ в месяц, но ограничена шаблоном. Заказная разработка с нуля на рынке начинается от 5 000 000 ₽ и требует собственной команды сопровождения. На модульной платформе интеграция под бренд для одного направления — от 525 000 ₽ единоразово и от 150 000 ₽ в месяц лицензионных платежей с включённой поддержкой; для приложения и сайта на одной кодовой базе — от 735 000 ₽ и от 250 000 ₽ в месяц. Все цены с учётом НДС, действующие значения опубликованы на странице тарифов.

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

Сумма минимальных длительностей семи шагов — 32 рабочих дня, но по календарю проект укладывается в срок до 30 рабочих дней. Подготовительные шаги идут одновременно на разных ролях: аналитик разбирает обмен данными, дизайнер собирает экраны, разработчик готовит серверную часть. Тестирование ведётся параллельно с разработкой, а модули каталога, корзины, оплаты и лояльности уже написаны и не создаются под каждый проект заново. Для полностью заказной разработки ориентир другой — 6–12 месяцев до первого выпуска.

Что такое PWA и когда её достаточно вместо приложения?

PWA (Progressive Web Application, прогрессивное веб-приложение) — это сайт, который можно установить на домашний экран: появляется иконка, скрывается адресная строка, часть страниц открывается без сети. Собирается на существующем коде сайта, магазины приложений не участвуют. Её достаточно, когда нужно проверить спрос на мобильный канал без отдельного бюджета. Ограничения: продукт не найти поиском в магазине приложений, доступ к возможностям системы ограничен браузером, а уведомления на iOS работают только после того, как пользователь сам добавил PWA на домашний экран.

Что значит «приложение и сайт на одной кодовой базе»?

Это означает, что оба канала собираются из одного исходного кода: Flutter выпускает из общего кода приложения для iOS и Android, веб-версию, а также сборки для RuStore, Aurora OS и мини-приложение в Telegram. Практическая разница видна в ежедневной работе: товар заводится один раз и появляется везде, цена меняется в одном месте, акция запускается синхронно, доработка делается один раз вместо трёх. Ограничение тоже есть — сайт при этом собирается заново на общей основе, поэтому вариант подходит компаниям, которые и так планировали обновление сайта.

Что происходит с приложением после выпуска и кто его сопровождает?

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

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.