Jak opublikować aplikację Lovable w App Store: PWA, Capacitor czy przebudowa i jak uniknąć 4.2 (2026)

Jeśli szukasz sposobu na opublikowanie aplikacji Lovable w App Store, najpierw musisz wiedzieć, że Lovable nie zrobi tego za Ciebie. Dokumentacja publikacji Lovable mówi, że „Lovable tworzy aplikacje webowe, a publikacja zawsze oznacza wdrożenie pod adresem URL”, oraz że nie ma „wbudowanej ścieżki, która pakuje i wysyła projekt do App Store lub Google Play”. Poniżej znajdziesz trzy realne opcje, ich koszty i kroki, dzięki którym opakowana aplikacja Lovable ominie problemy z wytyczną 4.2.

Czy można opublikować aplikację Lovable bezpośrednio w App Store?

Nie. Według stanu na październik 2026 Lovable publikuje projekt w subdomenie lovable.app lub we własnej domenie, a trafienie do sklepu oznacza spakowanie aplikacji poza Lovable i wysłanie jej z własnego konta deweloperskiego.

Dokumentacja Lovable podsuwa dwa obejścia: zamienić opublikowaną stronę w instalowalne PWA albo „opakować opublikowany adres URL w natywną powłokę za pomocą Capacitor poza Lovable” i samodzielnie wysłać tę powłokę. Dokumentacja wyjaśnia też dwie rzeczy. Lovable nie generuje projektów React Native, a aplikacja mobilna Lovable służy tylko do budowania projektów z telefonu. „Nie zamienia projektu w natywną aplikację dla użytkowników końcowych”.

PWA, nakładka Capacitor czy przebudowa: którą drogę wybrać?

Wybierz PWA, jeśli nie potrzebujesz wpisu w sklepie, Capacitor, jeśli potrzebujesz wpisu i możesz dodać prawdziwe funkcje natywne, a natywną przebudowę, jeśli aplikacja ma wyglądać i działać jak produkt projektowany przede wszystkim na telefon.

Opłaty pochodzą ze strony rejestracji w Apple Developer Program („99 USD za rok członkostwa. Ceny mogą się różnić w zależności od regionu”) oraz z Pomocy Google Play Console („jednorazowa opłata rejestracyjna w wysokości 25 USD”). W Google Play nowe konta osobiste muszą też przeprowadzić test zamknięty z 12 testerami przez 14 dni, zanim otrzymają dostęp do wersji produkcyjnej. Ten krok opisuje nasz poradnik o testach zamkniętych.

Jak opakować aplikację Lovable za pomocą Capacitor?

Wyeksportuj kod z Lovable do GitHuba, zbuduj go lokalnie, dodaj Capacitor i wskaż w webDir katalog z wynikiem builda. Następnie otwórz projekty natywne w Xcode i Android Studio i zarchiwizuj je.

1. W Lovable połącz konto GitHub. Synchronizacja działa w obie strony i zawsze tworzy nowe prywatne repozytorium, więc możesz dalej edytować projekt w Lovable, pracując lokalnie nad natywną powłoką.
2. Sklonuj repozytorium, uruchom npm install, a potem npm run build. Sprawdź, gdzie Vite zapisuje wynik builda – zwykle jest to dist. Capacitor wymaga w tym katalogu głównym pliku index.html ze znacznikiem <head>.
3. Zainstaluj Capacitor i platformy poleceniami z bloku kodu poniżej, zaczerpniętymi z dokumentacji Capacitor dla początkujących.
4. W capacitor.config ustaw webDir na dist. Nie ustawiaj server.url na swoją działającą domenę Lovable: dokumentacja konfiguracji Capacitor mówi, że ta opcja „nie jest przeznaczona do użytku produkcyjnego”.
5. Dodaj wtyczki natywne (push, haptyka, udostępnianie, biometria, powiadomienia lokalne) oraz natywne ikony aplikacji i ekrany startowe.
6. Po każdym buildzie webowym uruchamiaj npx cap sync, a następnie zarchiwizuj aplikację w Xcode i prześlij ją do App Store Connect. Resztę opisuje nasza lista kontrolna wysyłki do 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

Wysyłaj aplikację z własnego konta Apple. Wytyczna 4.2.6 odrzuca aplikacje zbudowane w serwisach generujących aplikacje, chyba że zostały „wysłane bezpośrednio przez dostawcę treści aplikacji”. Nasz poradnik o wytycznych 4.3 i 4.2.6 wyjaśnia, jak dotyczy to aplikacji tworzonych przez AI.

Jak uniknąć odrzucenia opakowanej aplikacji Lovable na podstawie wytycznej 4.2?

Spraw, by aplikacja robiła rzeczy, których strona internetowa nie potrafi. Wytyczna 4.2 wymaga „funkcji, treści i interfejsu, które wynoszą ją ponad przepakowaną stronę internetową”, a 4.2.2 wyklucza aplikacje będące głównie „wycinkami stron, agregatorami treści lub zbiorem linków”.

Przed wysłaniem przejdź przez tę listę kontrolną:

• Build webowy jest dołączony do pliku binarnego i uruchamia się bez połączenia z siecią, pokazując dane z pamięci podręcznej lub porządny ekran offline.
• Nawigacja korzysta z dolnego paska kart zamiast menu typu hamburger i nie ma stopek ani banerów cookies typowych dla stron WWW.
• Logowanie, rejestracja i reset hasła odbywają się w całości w aplikacji. Nic nie przekierowuje użytkownika do Safari.
• Co najmniej jeden kluczowy przepływ opiera się na urządzeniu, np. robienie zdjęć aparatem, powiadomienia lokalne powiązane z danymi użytkownika, widżety lub biometria.
• Zewnętrzne linki do stron z darowiznami, sklepów czy mediów społecznościowych są usunięte lub ograniczone do minimum.
• Notatki dla App Review wyjaśniają, dlaczego aplikacja jest przydatna na telefonie, i zawierają dane logowania do konta demo.

Co się działo, gdy inne aplikacje webowe były odrzucane na podstawie 4.2?

Publiczne wątki pokazują ten sam schemat: recenzenci odrzucają interfejs przypominający stronę WWW i linki prowadzące do Safari, a samo dodanie drobnych funkcji natywnych nie zmienia ich decyzji.

W grudniu 2020 roku deweloper na Ionic Forum otrzymał odrzucenie aplikacji członkowskiej dla klubu z uzasadnieniem „Twoja aplikacja zapewnia ograniczone doświadczenie użytkownika, ponieważ nie różni się wystarczająco od przeglądania w przeglądarce mobilnej”, a dalej: „większość treści aplikacji prowadzi do Safari”. Usunięcie InAppBrowser i poprawa obsługi offline nie wystarczyły – drugie zgłoszenie również zostało odrzucone. Trzecia próba została zatwierdzona, gdy deweloper przebudował ekran główny z natywnymi listami i kartami ze zdjęciami, dodał więcej aktualności w aplikacji i usunął większość linków zewnętrznych.

W styczniu 2026 roku deweloper na Apple Developer Forums zgłosił odrzucenie aplikacji do planowania jako „niewystarczająco różniącej się od przeglądania stron internetowych”, mimo że korzystała już z powiadomień push, Core Location i dostępu do kontaktów. Planował dodać haptykę, szybkie akcje i głębszą integrację z kalendarzem i pytał, co właściwie oznacza „bardziej natywnie”. W chwili pisania tego tekstu wątek nie ma odpowiedzi ani potwierdzonego rozstrzygnięcia.

Porównanie: pierwszy deweloper przeszedł weryfikację, zmieniając to, czym aplikacja jest (treści w aplikacji, natywne układy, brak linków na zewnątrz). Drugi dodał jedynie API urządzenia i nadal nie miał pewności. Włóż wysiłek w kluczowe doświadczenie, a nie w dłuższą listę uprawnień.

Kiedy lepiej przebudować aplikację, niż ją opakowywać?

Przebuduj aplikację natywnie, gdy jej główną wartością są treści webowe albo gdy masz już za sobą dwa odrzucenia 4.2 za ten sam interfejs.

Przykład: narzędzie do rezerwacji zbudowane w Lovable dla studia jogi pokazuje listę zajęć, formularz rezerwacji i link do płatności Stripe. Opakowane bez zmian trafia we wszystkie trzy sygnały ostrzegawcze 4.2: webowy interfejs, link na zewnątrz i brak działania offline. Jako PWA może trafić do użytkowników już dziś bez dodatkowych kosztów. Aby zdobyć wpis w sklepie, zachowaj backend z Lovable, przebuduj listę zajęć i przepływ rezerwacji na natywnych ekranach, dodaj lokalne przypomnienia przed każdymi zajęciami i obsłuż płatności zgodnie z wytyczną App Review 3.1. Backend i model danych przenosisz bez zmian. Przepisujesz interfejs.

Jeśli chcesz poznać drugą opinię na temat tego, która droga pasuje do Twojego projektu Lovable, usługi The App Guy obejmują opakowywanie, przebudowę i wysyłkę do sklepów. Możesz też napisać na adres yagyeshsrbobde@gmail.com.