Så publicerar du en Lovable-app i App Store: PWA, Capacitor eller ombyggnad – och undvik 4.2 (2026)

Om du letar efter hur du publicerar en Lovable-app i App Store är det första du behöver veta att Lovable inte kan göra det åt dig. Lovables publiceringsdokumentation säger att ”Lovable bygger webbappar och publicering driftsätter alltid till en webbadress” och att det inte finns något ”inbyggt flöde som paketerar och skickar in ditt projekt till App Store eller Google Play”. Nedan går vi igenom de tre faktiska alternativen, vad vart och ett kostar och de steg som håller en paketerad Lovable-app borta från riktlinje 4.2.

Kan du publicera en Lovable-app direkt i App Store?

Nej. I oktober 2026 publicerar Lovable till en underdomän på lovable.app eller till en egen domän, och för att komma in i en appbutik måste du paketera appen utanför Lovable och skicka in den från ditt eget utvecklarkonto.

Lovables dokumentation föreslår två lösningar: gör den publicerade webbplatsen till en installerbar PWA, eller ”paketera din publicerade URL i ett native-skal med Capacitor utanför Lovable” och skicka in skalet själv. Dokumentationen klargör också två saker. Lovable genererar inte React Native-projekt, och Lovables mobilapp är bara till för att bygga projekt från telefonen. Den ”gör inte ditt projekt till en native-app för slutanvändare”.

PWA, Capacitor-wrapper eller ombyggnad: vilken väg ska du välja?

Välj en PWA om du inte behöver en butikssida, Capacitor om du behöver en butikssida och kan lägga till riktiga native-funktioner, och en native-ombyggnad om appen måste kännas och bete sig som en mobil-först-produkt.

Avgifterna kommer från Apple Developer Programs registreringssida (”99 USD per medlemsår. Priserna kan variera beroende på region”) och Google Play Console-hjälpen (”en engångsavgift för registrering på 25 USD”). På Google Play måste nya personliga konton dessutom köra ett slutet test med 12 testare i 14 dagar innan de får produktionsåtkomst. Vår guide till slutna tester går igenom det steget.

Hur paketerar du en Lovable-app med Capacitor?

Exportera Lovable-koden till GitHub, bygg den lokalt, lägg till Capacitor och peka webDir mot byggutdata. Öppna sedan de native-projekten i Xcode och Android Studio och arkivera dem.

1. Anslut GitHub i Lovable. Synkroniseringen går åt båda hållen och skapar alltid ett nytt privat repository, så du kan fortsätta redigera i Lovable medan du arbetar med native-skalet lokalt.
2. Klona repot, kör npm install och sedan npm run build. Kontrollera var Vite skriver utdata, vanligtvis i dist. Capacitor behöver en index.html med en <head>-tagg i den roten.
3. Installera Capacitor och plattformarna med kommandona i kodblocket nedan, hämtade från Capacitors kom igång-dokumentation.
4. Sätt webDir till dist i capacitor.config. Sätt inte server.url till din live-domän på Lovable: Capacitors konfigurationsreferens säger att den ”inte är avsedd för användning i produktion”.
5. Lägg till native-plugins (push, haptik, delning, biometri, lokala notiser) samt native-appikoner och startskärmar.
6. Kör npx cap sync efter varje webbygge, arkivera sedan i Xcode och ladda upp till App Store Connect. Vår checklista för inskickning till App Store täcker resten.

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

Skicka in från ditt eget Apple-konto. Riktlinje 4.2.6 avvisar appar som byggts med en appgenereringstjänst om de inte ”skickas in direkt av leverantören av appens innehåll”. Vår guide till riktlinje 4.3 och 4.2.6 förklarar hur det gäller AI-byggda appar.

Hur undviker du avslag enligt riktlinje 4.2 med en paketerad Lovable-app?

Låt appen göra saker som webbplatsen inte kan. Riktlinje 4.2 kräver ”funktioner, innehåll och gränssnitt som lyfter den över en ompaketerad webbplats”, och 4.2.2 utesluter appar som främst är ”webbklipp, innehållsaggregatorer eller en samling länkar”.

Gå igenom den här checklistan innan du skickar in:

• Webbygget är buntat i binären och öppnas utan nätverksanslutning, med cachad data eller en ordentlig offlineskärm.
• Navigeringen använder en flikrad längst ned i stället för en hamburgermeny, och det finns inga sidfötter eller cookiebanners som bara hör hemma på webben.
• Inloggning, registrering och återställning av lösenord sker helt i appen. Ingenting skickar användaren vidare till Safari.
• Minst ett centralt arbetsflöde bygger på enheten, till exempel kamerafångst, lokala notiser kopplade till användarens egen data, widgetar eller biometri.
• Externa länkar till donationssidor, butiker eller sociala medier är borttagna eller hålls till ett minimum.
• Anteckningarna till App Review förklarar varför appen är användbar på en telefon och innehåller en demoinloggning.

Vad hände när andra webbaserade appar fick avslag enligt 4.2?

Offentliga trådar visar samma mönster: granskarna avvisar gränssnitt som känns som webben och länkar ut till Safari, och att bara lägga till små native-funktioner ändrar inte deras beslut.

I december 2020 fick en utvecklare på Ionic Forum avslag på en medlemsapp för en klubb med motiveringen ”Din app ger en begränsad användarupplevelse eftersom den inte skiljer sig tillräckligt från en mobil webbupplevelse”, följt av ”det mesta av appens innehåll länkar ut till Safari”. Att ta bort InAppBrowser och förbättra offlinestödet räckte inte, och även den andra inskickningen avvisades. Det tredje försöket godkändes efter att utvecklaren byggt om startskärmen med listor och bildkort i native-stil, lagt till mer nyhetsinnehåll i appen och tagit bort de flesta externa länkar.

I januari 2026 rapporterade en utvecklare på Apple Developer Forums att en schemaläggningsapp avvisats som ”inte tillräckligt annorlunda än en webbupplevelse”, trots att den redan använde pushnotiser, Core Location och åtkomst till kontakter. Utvecklaren planerade att lägga till haptik, snabbåtgärder och djupare kalenderintegration och frågade vad som räknas som ”mer native”. I skrivande stund har tråden inga svar och inget bekräftat utfall.

Jämförelsen: den första utvecklaren kom igenom genom att ändra vad appen är (innehåll i appen, native-layouter, inga utgående länkar). Den andra lade bara till enhets-API:er och var fortfarande osäker. Lägg din energi på kärnupplevelsen, inte på en längre lista med behörigheter.

När ska du bygga om i stället för att paketera?

Bygg om native när appens huvudsakliga värde är webbinnehåll, eller när du redan har fått två avslag enligt 4.2 för samma gränssnitt.

Konkret exempel: ett bokningsverktyg byggt i Lovable för en yogastudio visar en klasslista, ett bokningsformulär och en betalningslänk till Stripe. Paketerat som det är träffar det alla tre varningssignalerna för 4.2: webbgränssnitt, en utgående länk och ingen offlineanvändning. Som PWA kan det lanseras i dag utan extra kostnad. För att få en butikssida behåller du Lovable-backenden, bygger om klasslistan och bokningsflödet med native-skärmar, lägger till lokala påminnelser före varje klass och hanterar betalningen inom ramarna för App Review-riktlinje 3.1. Din backend och datamodell följer med. Det du skriver om är gränssnittet.

Om du vill ha en andra åsikt om vilken väg som passar ditt Lovable-projekt täcker The App Guys tjänster paketering, ombyggnad och inskickning till appbutikerna, eller mejla yagyeshsrbobde@gmail.com.