Как опубликовать приложение Lovable в App Store: PWA, Capacitor или переписывание и как избежать 4.2 (2026)

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

Можно ли опубликовать приложение Lovable в App Store напрямую?

Нет. По состоянию на октябрь 2026 года Lovable публикует проект на поддомене lovable.app или на собственном домене, а чтобы попасть в стор, приложение нужно упаковать вне Lovable и отправить со своего аккаунта разработчика.

Документация Lovable предлагает два обходных пути: превратить опубликованный сайт в устанавливаемое PWA или «обернуть опубликованный URL в нативную оболочку с помощью Capacitor вне Lovable» и самостоятельно отправить эту оболочку. Документация также проясняет два момента. Lovable не генерирует проекты React Native, а мобильное приложение Lovable предназначено только для работы над проектами с телефона. Оно «не превращает ваш проект в нативное приложение для конечных пользователей».

PWA, обёртка Capacitor или переписывание: какой путь выбрать?

Выбирайте PWA, если страница в сторе вам не нужна; Capacitor — если она нужна и вы можете добавить настоящие нативные функции; нативное переписывание — если приложение должно выглядеть и работать как продукт, изначально созданный для телефона.

Сборы указаны по странице регистрации в Apple Developer Program («99 USD за год членства. Цены могут различаться в зависимости от региона») и справке Google Play Console («разовый регистрационный взнос US$25»). В Google Play новые личные аккаунты также должны провести закрытое тестирование с 12 тестировщиками в течение 14 дней, прежде чем получат доступ к продакшену. Этот этап описан в нашем руководстве по закрытому тестированию.

Как обернуть приложение Lovable в Capacitor?

Экспортируйте код Lovable в GitHub, соберите его локально, добавьте Capacitor и укажите в webDir папку со сборкой. Затем откройте нативные проекты в Xcode и Android Studio и создайте архивы.

1. В Lovable подключите GitHub. Синхронизация двусторонняя и всегда создаёт новый приватный репозиторий, так что вы можете продолжать редактировать проект в Lovable, параллельно работая над нативной оболочкой локально.
2. Клонируйте репозиторий, выполните npm install, затем npm run build. Проверьте, куда Vite записывает результат — обычно это dist. Capacitor нужен index.html с тегом <head> в корне этой папки.
3. Установите Capacitor и платформы командами из блока кода ниже, взятыми из документации Capacitor по началу работы.
4. В capacitor.config задайте webDir равным dist. Не указывайте в server.url свой рабочий домен Lovable: в справочнике по конфигурации Capacitor сказано, что он «не предназначен для использования в продакшене».
5. Добавьте нативные плагины (push-уведомления, тактильный отклик, «Поделиться», биометрию, локальные уведомления), а также нативные иконки приложения и экраны заставки.
6. После каждой веб-сборки выполняйте npx cap sync, затем создайте архив в Xcode и загрузите его в App Store Connect. Остальное описано в нашем чек-листе отправки в App Store.

npm i @capacitor/core
npm i -D @capacitor/cli
npx cap init
npm i @capacitor/android @capacitor/ios
npx cap add android
npx cap add ios
npm run build && npx cap sync
npx cap open ios

Отправляйте приложение со своего аккаунта Apple. Guideline 4.2.6 отклоняет приложения, созданные с помощью сервисов генерации приложений, если они не «отправлены непосредственно владельцем контента приложения». В нашем руководстве по Guideline 4.3 и 4.2.6 объясняется, как это относится к приложениям, созданным с помощью ИИ.

Как избежать отказа по Guideline 4.2 для обёрнутого приложения Lovable?

Сделайте так, чтобы приложение умело то, чего не может сайт. Guideline 4.2 требует «функций, контента и интерфейса, которые поднимают его выше уровня переупакованного сайта», а 4.2.2 исключает приложения, которые в основном представляют собой «веб-вырезки, агрегаторы контента или набор ссылок».

Перед отправкой пройдитесь по этому чек-листу:

• Веб-сборка встроена в бинарник и открывается без подключения к сети, показывая кэшированные данные или нормальный офлайн-экран.
• Навигация построена на нижней панели вкладок, а не на меню-«гамбургере», и в приложении нет чисто веб-футеров и баннеров о cookie.
• Вход, регистрация и сброс пароля происходят внутри приложения. Ничто не отправляет пользователя в Safari.
• Как минимум один ключевой сценарий опирается на возможности устройства: съёмку камерой, локальные уведомления, связанные с данными самого пользователя, виджеты или биометрию.
• Внешние ссылки на страницы пожертвований, магазины или соцсети удалены или сведены к минимуму.
• В заметках для App Review объяснено, чем приложение полезно на телефоне, и указаны демо-данные для входа.

Что происходило, когда другие веб-приложения отклоняли по 4.2?

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

В декабре 2020 года разработчик на Ionic Forum получил отказ для приложения клуба по членству с формулировкой «Ваше приложение предоставляет ограниченный пользовательский опыт, так как недостаточно отличается от мобильного веб-браузинга», а затем «большая часть контента приложения ведёт по ссылкам в Safari». Удаления InAppBrowser и улучшения офлайн-поддержки оказалось недостаточно, и вторую отправку тоже отклонили. Третья попытка была одобрена после того, как разработчик переделал главный экран с нативными списками и карточками с изображениями, добавил больше новостного контента внутри приложения и убрал большую часть внешних ссылок.

В январе 2026 года разработчик на Apple Developer Forums сообщил, что приложение для планирования отклонили как «недостаточно отличающееся от веб-браузинга», хотя в нём уже использовались push-уведомления, Core Location и доступ к контактам. Он планировал добавить тактильный отклик, быстрые действия и более глубокую интеграцию с календарём и спрашивал, что считается «более нативным». На момент написания в теме нет ответов и подтверждённого результата.

Сравнение: первый разработчик прошёл ревью, изменив саму суть приложения (контент внутри приложения, нативная вёрстка, никаких ссылок наружу). Второй лишь добавил API устройства и так и не был уверен в результате. Вкладывайте силы в основной пользовательский опыт, а не в более длинный список разрешений.

Когда лучше переписать приложение, а не оборачивать его?

Переписывайте нативно, если основная ценность приложения — веб-контент или если вы уже получили два отказа по 4.2 за один и тот же интерфейс.

Разберём пример: инструмент бронирования для йога-студии, сделанный в Lovable, показывает список занятий, форму бронирования и ссылку на оплату через Stripe. Если обернуть его как есть, он попадает под все три тревожных признака 4.2: веб-интерфейс, ссылка наружу и отсутствие офлайн-режима. Как PWA его можно выпустить уже сегодня без дополнительных затрат. Чтобы получить страницу в сторе, сохраните бэкенд Lovable, переделайте список занятий и процесс бронирования на нативных экранах, добавьте локальные напоминания перед каждым занятием и организуйте оплату в соответствии с правилами App Review Guideline 3.1. Бэкенд и модель данных переносятся без изменений. Переписывать нужно интерфейс.

Если вам нужно второе мнение о том, какой путь подходит вашему проекту на Lovable, услуги The App Guy охватывают обёртку, переписывание и отправку в сторы, или напишите на yagyeshsrbobde@gmail.com.