В прошлой статье я собрал простое Android‑приложение из сайта с помощью конструктора. Мы убедились, что для лендинга или каталога зачастую достаточно одной WebView‑обертки. Во второй части возьмем тот же небольшой веб‑сервис, создадим под него URL и соберем полноценное приложение с пушами и доступом к системным функциям.
Разбираться в Swift, Kotlin или Flutter по‑прежнему не придется: вместо этого используем конструктор. На примере посмотрим, как сайт превращается в приложение, какие настройки важны, чтобы оно адекватно работало и выглядело хорошо на Android и iOS. И как довести этот результат до состояния, когда не стыдно использовать.
Конечно, если у команды есть ресурсы на разработку и нужна единая кодовая база для сложного приложения, логичнее смотреть в сторону Flutter или React Native. Но это уже полноценная кроссплатформенная разработка, а не конструктор. В этой серии статей такой сценарий я сознательно опускаю и фокусируюсь именно на подходе «из сайта в приложение без кода».
Что стоит рассмотреть
Для сложных продуктов с тяжелой графикой, офлайном и глубокой интеграцией с устройством по‑прежнему оправдана нативная разработка под каждую платформу. Будь то Swift/Objective‑C для iOS или Kotlin/Java для Android. Такой стек дает максимум контроля производительности и системных API. Но тут не обойтись без отдельной команды разработчиков, тестировщиков и долгого цикла релизов.
В этой статье нас интересует другой класс задач — когда веб‑версия уже есть, но нужно быстрее получить мобильное приложение. Без полноценного переписывания фронтенда под iOS и Android. Для таких кейсов подойдет решение на базе WebView и специальный конструктор. Технически он берет ваш существующий сайт, оборачивает его в нативную оболочку (которая по сути и есть встроенный браузер) и загружает страницу по HTTPS‑адресу. При этом добавляется доступ к системным функциям вроде пуш‑уведомлений и навигации по экрану. Если мобильная версия сверстана аккуратно, пользователь воспринимает это как обычное приложение: иконка, экран загрузки, навигация, страница контента.
Этот подход полностью повторять не будем — в первой части он уже разобран. Здесь важен другой шаг: как подготовить сайт к такой обертке, какие ограничения есть у конструктора и как пройти весь путь до готового приложения на примере нового сервиса — app.buildnatively.com.
Чтобы конструктор приложений вообще смог работать с вашим сайтом, ему нужен URL, который открывается по HTTPS. В мире со сферическими конями в вакууме мы должны арендовать сервер в облаке, подключить белый IP для доступа из интернета, задеплоить сайт, зарегистрировать доменное имя и настроить DNS, чтобы сайт открывался по урлу. В общем-то, так и нужно будет сделать перед выкатыванием приложения на прод. А пока для теста и демонстрации подхода мне достаточно статического хостинга, который умеет отдавать HTML по HTTPS. Эту задачу хорошо решает GitHub Pages. Он специально создан для публикации статических сайтов прямо из репозитория, автоматически выдает HTTPS‑адрес и не требует администрирования.
Можно, конечно, использовать GitHub Pages, но тогда у вас будут ограничения по доступу или функционалу. А чтобы пользователи из интернета могли свободно заходить на ваш сайт, лучше развернуть собственный сервер, например, в облаке. Инструкция по регистрации домена есть в документации.
В таком варианте вы регистрируете и арендуете имя вроде example.ru. Домен настраивается так, чтобы указывать на ваш сервер, где размещены HTML, CSS, базы данных и прочее.
На сервере же вы настраиваете SSL-сертификат, чтобы сайт открывался по HTTPS. Это стандартный сценарий для коммерческих проектов, где домен участвует в брендинге, SEO и маркетинге, а мобильное приложение — всего лишь еще один способ дотянуться до того же «веб-ядра».
Подготовка мини-хостинга
Вы готовите простой index.html с демо‑страницей — например, возьмем мини‑лендинг кафе «Завтрак программиста» из прошлой статьи с кнопками и базовой логикой на JavaScript.
Зайдите на github.com и создайте новый репозиторий, нажав на плюс в меню в правом верхнем углу. В качестве имени удобно использовать что‑то вроде demo-app или programmer-breakfast, тип репозитория оставляем Public, остальные поля можно не трогать. После создания репозитория GitHub показывает пустой список файлов — это и есть «папка» будущего сайта в облаке.
Дальше в эту папку кладем сам index.html. Это можно сделать прямо через веб‑интерфейс: в шапке списка файлов есть кнопка Add file, из выпадающего меню выбираем вариант загрузки. Если файл уже сохранен у вас на диске, подойдет пункт Upload files — в открывшуюся область перетащите index.html и внизу страницы загрузите кнопкой коммит.
Если файла еще нет, можно создать его на месте через Add file → Create new file, вписать в поле имени index.html, вставить HTML‑код и сохранить изменения. В обоих случаях результат один и тот же: в корне репозитория лежит один файл index.html, который GitHub умеет отдавать как стартовую страницу сайта.
Чтобы это превратилось в сайт, нужно включить режим GitHub Pages. Делается это в настройках самого репозитория: в верхнем меню выбирается вкладка Settings, в боковом — пункт Pages. В разделе публикации в качестве источника выберите Deploy from a branch (сборка «из ветки»), при этом в качестве ветки укажите main, а путь пусть остается корневым. После чего сохраните настройки.
Дальше GitHub сам поднимает для вас мини‑хостинг и выдает URL вида: https://username.github.io/имя‑репозитория/.
Плюсы WebView. С точки зрения браузера и мобильного приложения, это полноценный сайт: он открывается по защищенному протоколу, доступен из любой точки мира и не завязан на ваш компьютер. По этой причине часто мобильные версии интернет-магазинов выглядят точно так же, как их официальные приложения: внутри просто стоит WebView и показывает ту же самую страницу.
Конструктору вроде buildnatively достаточно знать один начальный адрес, чтобы загрузить его внутрь WebView и собрать из него приложение. Именно этим займемся дальше.
Конструктор веб-приложений
Все конструкторы веб-приложений примерно одинаковы: вы указываете адрес сайта, настраиваете пару опций и через несколько минут получаете ссылку на готовый APK. Файл можно скачать на телефон или переслать кому угодно, никаких навыков программирования не требуется.
После того как у вас появился рабочий HTTPS‑адрес демо‑сайта, можно переходить к сборке приложения через бесплатный Natively. У него простой интерфейс, но он работает и делает все, что нам нужно.
У бесплатной версии есть два важных ограничения: в приложении может показываться реклама платформы и такую сборку нельзя напрямую опубликовать в Google Play. Для быстрой проверки идеи это не проблема, а если нужна публикация без брендинга, всегда можно перейти на платный план.
Открываете страницу конструктора в браузере и заходите в аккаунт. Дальше все стандартно: вводим свою почту, придумываем пароль и нажимаем кнопку Log in.
На стартовом экране виден список приложений и кнопка создания нового проекта. Выбираем базовые параметры: название приложения, начальный URL. В поле App Url вписываем тот самый адрес, который отдает ваш index.html на GitHub Pages.
Важно, чтобы он начинался с https:// и открывался без авторизации, иначе приложение либо не соберется, либо не пройдет проверки магазинов.
Дополнительно можно выбрать платформу. Этот пункт нужен, когда сайт собран на конкретном SaaS (Shopify, Webflow, WordPress и т. п). Тогда конструктор может добавить под них готовые настройки.
У меня статический сайт на чистом HTML, без CMS и фреймворка, поэтому формально он не попадает ни в одну из этих категорий. Я выбираю Others и нажимаю Create my app.
Интерфейс достаточно приятный. Слева — набор простых параметров, справа — живое превью на мокапе телефона. Так как это no-code приложение, мы будем собирать его с помощью уже готовых модулей. На первом шаге сервис предлагает создать или загрузить иконку приложения. Размер должен быть 1024 x 1024 в формате PNG и без прозрачного фона (Apple не разрешает иконки с прозрачным фоном). А так, настройки максимально базовые.
После иконки конструктор предлагает оформить экран загрузки приложения. Это тот самый первый экран, который пользователь видит при запуске, пока WebView подтягивает ваш сайт.
Можно задать цвет фона, добавить изображение и короткий текст вроде названия сервиса или приветственных слов. Главное — подобрать шрифт и оттенки так, чтобы заставка не выбивалась из цветовой схемы самого сайта и была вообще читаема. Размер должен быть 2048 x 2048.
На шаге Launch Screen оформляем заставку приложения. Здесь я выбираю иконку, похожую на ту, что будет в шапке сайта и приложения. В предпросмотре видно, как экран будет выглядеть при запуске на телефоне — просто кружка кофе. Никаких дополнительных настроек тут нет.
Теперь настроим ту страницу, которую пользователь увидит, если сайт по какой‑то причине не загрузится. Пропал интернет, бекэнд недоступен или сайт временно лежит. По умолчанию конструктор показывает свой нейтральный текст, но для вменяемого UX лучше заменить его на что‑то «осмысленное».
Я думаю такая надпись и картинка, помимо того что в тему, так еще и скрасит возникшую ошибку 🙂 Фактически мы ставим заглушку. Только не пытайтесь впихнуть туда сложный постер: картинка должна нормально смотреться в центре экрана и не обрезаться по краям.
Дальше оформляем заставку и другие настройки при запуске. Сверху можно выбрать цвета фона (App Background Color) и индикатора загрузки (Loader Color).
Ниже идут всякие переключатели. Здесь настраивается, можно ли листать экран жестами или только кнопками, нужен ли жест pull to refresh, разрешен ли поворот экрана, будет ли поверх сайта показываться нижняя панель и можно ли не давать устройству гасить экран во время работы приложения и еще парочка функций. Выставьте флажки и проверьте результат сначала в превью.
В разделе Bottom Bar добавляем до пяти вкладок в панель навигации. Для каждой вкладки задается метка (название), порядок отображения (нуля до пяти), URL (тот адрес внутри вашего сайта, куда ведет вкладка) и SVG-иконка.
Все поля обязательны: если пропустить хотя бы одно, вкладка не появится на панели. После заполнения не забудьте сохранить вкладку.
Вот и все. Осталось отсканировать QR-код и установить Natively Preview из App Store или Google Play, чтобы запустить приложение. А чтобы опубликовать приложение в магазин, придется раскошелиться или оформить 14-дневный бесплатный период.
Также в конструкторе интегрированы пуш-уведомления через OneSignal. Так что вы можете без проблем подключить их и отправлять целевые обновления, предложения и оповещения на устройства пользователей.
После установки и входа мы получаем такую картинку:
Однако у конструктора есть естественные ограничения. Я выбирал в рамках типовых шаблонов и готовых блоков, глубокой кастомизации интерфейса и бизнес-логики здесь не добиться. Еще нет доступа к низкоуровневым функциям устройства — невозможно реализовать сложные сценарии с доступом к аппаратным API, интеграцией с CRM, собственными формами оплаты или нестандартными workflow.
Иногда элементы интерфейса масштабируются не очень аккуратно, а дополнительные скрипты, заложенные в платформе, могут замедлять загрузку. Именно поэтому итоговый файл обязательно нужно тестировать.
Чтобы освоить системный подход, научиться избегать этих и других ошибок, а также эффективно решать подобные задачи, вы можете повторить мой опыт с GitHub Pages или попрактиковаться на реальных устройствах в мобильной ферме.
Минимальный чек-лист остается таким же: запуск и вход, навигация по ключевым разделам, работа форм и кнопок, спящий режим и возврат из него. Выдает ли картинку 404 при потере сети и восстановлении и корректно ли открываются ссылки и приходят пуш‑уведомления.
А чтобы глубоко погрузиться во все это, есть смысл записаться на наш курс по мобильному тестированию. Но чего только не сделаешь ради знаний и опыта :))
Что мы имеем в итоге
Это был еще один быстрый способ превратить обычный сайт в «почти нативное» приложение и проверить гипотезу без команды мобильных разработчиков. Дальше у продукта два пути: либо жить в рамках конструктора и постепенно обрастать контентом, либо при успешной проверке идей перерасти в полноценный нативный или кроссплатформенный проект, где у команды будет полный контроль кода, архитектуры и пользовательского опыта.
