Een Lovable-app publiceren in de App Store: PWA, Capacitor of herbouwen, en richtlijn 4.2 vermijden (2026)

Als je zoekt hoe je een Lovable-app in de App Store publiceert, is het eerste wat je moet weten dat Lovable dat niet voor je kan doen. De publicatiedocumentatie van Lovable zegt dat "Lovable webapps bouwt en publiceren altijd naar een web-URL deployt" en dat er "geen ingebouwde flow is die je project verpakt en indient bij de App Store of Google Play." Hieronder vind je de drie echte opties, wat elke optie kost en de stappen waarmee een verpakte Lovable-app buiten schot blijft van richtlijn 4.2.

Kun je een Lovable-app rechtstreeks in de App Store publiceren?

Nee. Per oktober 2026 publiceert Lovable naar een lovable.app-subdomein of een eigen domein. Om in een store te komen, moet je de app buiten Lovable verpakken en vanuit je eigen developeraccount indienen.

De documentatie van Lovable noemt twee omwegen: maak van de gepubliceerde site een installeerbare PWA, of "verpak je gepubliceerde URL buiten Lovable in een native shell met Capacitor" en dien die shell zelf in. De documentatie maakt ook twee dingen duidelijk. Lovable genereert geen React Native-projecten, en de mobiele app van Lovable is alleen bedoeld om vanaf je telefoon projecten te bouwen. Die "maakt van je project geen native app voor eindgebruikers."

PWA, Capacitor-wrapper of herbouwen: welke route kies je?

Kies een PWA als je geen store-vermelding nodig hebt, Capacitor als je een vermelding wilt en echte native functies kunt toevoegen, en een native herbouw als je app moet aanvoelen en werken als een product dat voor de telefoon is gemaakt.

De kosten komen van de inschrijvingspagina van het Apple Developer Program ("99 USD per lidmaatschapsjaar. Prijzen kunnen per regio verschillen") en de Google Play Console Help ("eenmalige registratiekosten van US$25"). Op Google Play moeten nieuwe persoonlijke accounts bovendien een gesloten test draaien met 12 testers gedurende 14 dagen voordat ze productietoegang krijgen. Onze gids over gesloten testen behandelt die stap.

Hoe verpak je een Lovable-app met Capacitor?

Exporteer de Lovable-code naar GitHub, bouw hem lokaal, voeg Capacitor toe en laat webDir naar de build-output wijzen. Open daarna de native projecten in Xcode en Android Studio en archiveer ze.

1. Koppel GitHub in Lovable. De synchronisatie werkt in twee richtingen en maakt altijd een nieuwe privérepository aan, zodat je in Lovable kunt blijven bewerken terwijl je lokaal aan de native shell werkt.
2. Clone de repo, voer npm install uit en daarna npm run build. Controleer waar Vite de output wegschrijft, meestal dist. Capacitor heeft in die root een index.html met een <head>-tag nodig.
3. Installeer Capacitor en de platforms met de commando's in het codeblok hieronder, afkomstig uit de getting-started-documentatie van Capacitor.
4. Zet in capacitor.config webDir op dist. Stel server.url niet in op je live Lovable-domein: volgens de configuratiereferentie van Capacitor is dat "niet bedoeld voor gebruik in productie."
5. Voeg native plugins toe (push, haptics, delen, biometrie, lokale meldingen) en native app-iconen en splashscreens.
6. Voer na elke webbuild npx cap sync uit, archiveer dan in Xcode en upload naar App Store Connect. Onze checklist voor App Store-indiening behandelt de rest.

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

Dien in vanuit je eigen Apple-account. Richtlijn 4.2.6 wijst apps af die met een app-generatiedienst zijn gemaakt, tenzij ze "rechtstreeks zijn ingediend door de aanbieder van de content van de app." Onze gids over richtlijn 4.3 en 4.2.6 legt uit hoe dat geldt voor AI-gebouwde apps.

Hoe voorkom je een afwijzing onder richtlijn 4.2 met een verpakte Lovable-app?

Zorg dat de app dingen doet die de website niet kan. Richtlijn 4.2 vraagt om "functies, content en UI die de app verheffen boven een opnieuw verpakte website," en 4.2.2 sluit apps uit die vooral bestaan uit "web clippings, content-aggregators of een verzameling links."

Loop deze checklist door voordat je indient:

• De webbuild is gebundeld in de binary en opent zonder netwerkverbinding, met gecachte data of een fatsoenlijk offline-scherm.
• De navigatie gebruikt een tabbalk onderaan in plaats van een hamburgermenu, en er zijn geen web-only footers of cookiebanners.
• Inloggen, registreren en wachtwoord resetten gebeuren allemaal in de app. Niets stuurt de gebruiker naar Safari.
• Minstens één kernworkflow leunt op het apparaat, zoals foto's maken met de camera, lokale meldingen gekoppeld aan de eigen data van de gebruiker, widgets of biometrie.
• Externe links naar donatiepagina's, webshops of social media zijn verwijderd of tot een minimum beperkt.
• De notities voor App Review leggen uit waarom de app nuttig is op een telefoon en bevatten een demo-login.

Wat gebeurde er toen andere webgebaseerde apps onder 4.2 werden afgewezen?

Openbare threads laten hetzelfde patroon zien: reviewers wijzen UI af die aanvoelt als web en links die naar Safari leiden, en alleen kleine native functies toevoegen verandert hun beslissing niet.

In december 2020 kreeg een developer op het Ionic Forum een ledenapp voor een club afgewezen met "Je app biedt een beperkte gebruikerservaring omdat hij onvoldoende verschilt van een mobiele browse-ervaring," gevolgd door "de meeste content van de app linkt naar Safari." InAppBrowser verwijderen en de offline-ondersteuning verbeteren was niet genoeg, en ook de tweede indiening werd afgewezen. De derde poging werd goedgekeurd nadat de developer het startscherm had herbouwd met native-achtige lijsten en afbeeldingskaarten, meer nieuwscontent in de app had gezet en de meeste externe links had verwijderd.

In januari 2026 meldde een developer op de Apple Developer Forums dat een planningsapp was afgewezen als "onvoldoende verschillend van een web-browse-ervaring", terwijl de app al pushmeldingen, Core Location en toegang tot contacten gebruikte. De developer was van plan haptics, quick actions en een diepere agenda-integratie toe te voegen en vroeg wat als "meer native" telt. Op het moment van schrijven heeft de thread geen reacties en geen bevestigde uitkomst.

De vergelijking: de eerste developer kwam erdoor door te veranderen wat de app is (content in de app, native lay-outs, geen links naar buiten). De tweede voegde alleen apparaat-API's toe en twijfelde nog steeds. Steek je energie in de kernervaring, niet in een langere lijst met permissies.

Wanneer kun je beter herbouwen dan verpakken?

Bouw native opnieuw als de belangrijkste waarde van je app webcontent is, of als je al twee keer bent afgewezen onder 4.2 voor dezelfde UI.

Uitgewerkt voorbeeld: een Lovable-boekingstool voor een yogastudio toont een lessenlijst, een boekingsformulier en een Stripe-betaallink. Zoals hij is verpakt, raakt hij alle drie de rode vlaggen van 4.2: web-UI, een link naar buiten en geen offline gebruik. Als PWA kan hij vandaag live zonder extra kosten. Voor een store-vermelding behoud je de Lovable-backend, herbouw je de lessenlijst en de boekingsflow met native schermen, voeg je lokale herinneringen vóór elke les toe en regel je de betaling binnen de regels van App Review-richtlijn 3.1. Je backend en datamodel neem je mee. Wat je herschrijft, is de UI.

Wil je een second opinion over welke route bij je Lovable-project past? De diensten van The App Guy omvatten verpakken, herbouwen en store-indiening, of mail naar yagyeshsrbobde@gmail.com.