Як опублікувати застосунок 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 вимагає «функцій, контенту та UI, які виводять його за межі перепакованого вебсайту», а 4.2.2 виключає застосунки, які є переважно «вебвирізками, агрегаторами контенту або набором посилань».

Перед поданням пройдіться цим чеклістом:

• Вебзбірку вбудовано в бінарний файл, і застосунок відкривається без мережевого з'єднання, показуючи кешовані дані або повноцінний офлайн-екран.
• Навігація використовує нижню панель вкладок, а не меню-гамбургер, і немає суто вебових футерів чи банерів про cookie.
• Вхід, реєстрація та скидання пароля відбуваються всередині застосунку. Ніщо не перенаправляє користувача в Safari.
• Принаймні один основний сценарій спирається на пристрій: зйомка камерою, локальні сповіщення, пов'язані з власними даними користувача, віджети або біометрія.
• Зовнішні посилання на сторінки пожертв, магазини чи соцмережі видалено або зведено до мінімуму.
• Нотатки для App Review пояснюють, чому застосунок корисний на телефоні, і містять демо-логін.

Що сталося, коли інші вебзастосунки відхилили за 4.2?

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

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

У січні 2026 року розробник на форумах Apple Developer повідомив, що застосунок для планування відхилили як «недостатньо відмінний від перегляду вебсторінок», хоча він уже використовував push-сповіщення, Core Location і доступ до контактів. Автор планував додати тактильний відгук, швидкі дії та глибшу інтеграцію з календарем і запитував, що вважається «більш нативним». На момент написання в темі немає відповідей і підтвердженого результату.

Порівняння: перший розробник пройшов перевірку, змінивши суть застосунку (контент усередині, нативні макети, жодних посилань назовні). Другий лише додав API пристрою і досі не впевнений. Вкладайте зусилля в основний досвід, а не в довший список дозволів.

Коли варто переписати застосунок, а не обгортати?

Переписуйте нативно, коли основна цінність вашого застосунку — вебконтент або коли ви вже отримали два відхилення за 4.2 через той самий UI.

Практичний приклад: інструмент бронювання на Lovable для студії йоги показує список занять, форму бронювання і посилання на оплату через Stripe. Обгорнутий як є, він потрапляє під усі три червоні прапорці 4.2: вебовий UI, посилання назовні та відсутність офлайн-режиму. Як PWA він може вийти вже сьогодні без додаткових витрат. Щоб отримати сторінку в магазині, збережіть бекенд Lovable, переробіть список занять і процес бронювання на нативних екранах, додайте локальні нагадування перед кожним заняттям і обробляйте оплату відповідно до правил App Review Guideline 3.1. Ваш бекенд і модель даних переносяться без змін. Переписувати доведеться UI.

Якщо вам потрібна друга думка щодо того, який шлях підходить вашому проєкту Lovable, послуги The App Guy охоплюють обгортання, переписування та подання в магазини; також можна написати на yagyeshsrbobde@gmail.com.