Come pubblicare un'app Lovable sull'App Store: PWA, Capacitor o riscrittura, ed evitare la 4.2 (2026)

Se stai cercando come pubblicare un'app Lovable sull'App Store, la prima cosa da sapere è che Lovable non può farlo al posto tuo. La documentazione di Lovable sulla pubblicazione dice che "Lovable crea web app e la pubblicazione effettua sempre il deploy su un URL web" e che non esiste "alcun flusso integrato che impacchetta e invia il tuo progetto all'App Store o a Google Play." Di seguito trovi le tre opzioni reali, quanto costa ciascuna e i passaggi che tengono un'app Lovable impacchettata al riparo dalla Guideline 4.2.

Si può pubblicare un'app Lovable direttamente sull'App Store?

No. A ottobre 2026 Lovable pubblica su un sottodominio lovable.app o su un dominio personalizzato, e per arrivare su uno store devi impacchettare l'app fuori da Lovable e inviarla dal tuo account sviluppatore.

La documentazione di Lovable suggerisce due alternative: rendere il sito pubblicato una PWA installabile, oppure "racchiudere l'URL pubblicato in una shell nativa con Capacitor al di fuori di Lovable" e inviare tu stesso quella shell. La documentazione chiarisce anche due cose. Lovable non genera progetti React Native, e l'app mobile di Lovable serve solo a creare progetti dal telefono: "non trasforma il tuo progetto in un'app nativa per gli utenti finali."

PWA, wrapper Capacitor o riscrittura: quale strada scegliere?

Scegli una PWA se non ti serve una scheda sullo store, Capacitor se ti serve una scheda e puoi aggiungere funzionalità native reali, e una riscrittura nativa se la tua app deve sembrare e comportarsi come un prodotto pensato per lo smartphone.

Le quote provengono dalla pagina di iscrizione all'Apple Developer Program ("99 USD per anno di iscrizione. I prezzi possono variare in base alla regione") e dalla Guida di Google Play Console ("una quota di registrazione una tantum di 25 USD"). Su Google Play, inoltre, i nuovi account personali devono eseguire un test chiuso con 12 tester per 14 giorni prima di ottenere l'accesso alla produzione. La nostra guida al test chiuso copre questo passaggio.

Come si impacchetta un'app Lovable con Capacitor?

Esporta il codice Lovable su GitHub, compilalo in locale, aggiungi Capacitor e punta webDir all'output della build. Poi apri i progetti nativi in Xcode e Android Studio e crea gli archivi.

1. In Lovable, collega GitHub. La sincronizzazione è bidirezionale e crea sempre un nuovo repository privato, quindi puoi continuare a modificare in Lovable mentre lavori in locale sulla shell nativa.
2. Clona il repository, esegui npm install e poi npm run build. Controlla dove Vite scrive l'output, di solito dist. Capacitor ha bisogno di un index.html con un tag <head> in quella cartella radice.
3. Installa Capacitor e le piattaforme con i comandi nel blocco di codice qui sotto, tratti dalla documentazione introduttiva di Capacitor.
4. In capacitor.config, imposta webDir su dist. Non impostare server.url sul tuo dominio Lovable live: il riferimento alla configurazione di Capacitor dice che "non è pensato per l'uso in produzione."
5. Aggiungi plugin nativi (push, feedback aptico, condivisione, biometria, notifiche locali) e icone e schermate di avvio native.
6. Esegui npx cap sync dopo ogni build web, poi crea l'archivio in Xcode e caricalo su App Store Connect. La nostra checklist per l'invio all'App Store copre il resto.

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

Invia l'app dal tuo account Apple. La Guideline 4.2.6 rifiuta le app create con un servizio di generazione di app a meno che non siano "inviate direttamente dal fornitore dei contenuti dell'app." La nostra guida alle Guideline 4.3 e 4.2.6 spiega come si applica alle app create con l'IA.

Come evitare un rifiuto per la Guideline 4.2 con un'app Lovable impacchettata?

Fai in modo che l'app faccia cose che il sito web non può fare. La Guideline 4.2 chiede "funzionalità, contenuti e UI che la elevino oltre un sito web reimpacchettato", e la 4.2.2 esclude le app che sono principalmente "ritagli web, aggregatori di contenuti o raccolte di link."

Usa questa checklist prima dell'invio:

• La build web è inclusa nel binario e si apre senza connessione di rete, mostrando dati in cache o una schermata offline adeguata.
• La navigazione usa una barra a schede in basso invece di un menu hamburger, e non ci sono footer da sito web o banner dei cookie.
• Login, registrazione e reimpostazione della password avvengono tutti dentro l'app. Niente rimanda l'utente a Safari.
• Almeno un flusso principale si basa sul dispositivo, ad esempio acquisizione dalla fotocamera, notifiche locali legate ai dati dell'utente, widget o biometria.
• I link esterni a pagine di donazione, negozi o social media sono rimossi o ridotti al minimo.
• Le note per l'App Review spiegano perché l'app è utile su un telefono e includono un login demo.

Cosa è successo ad altre app basate sul web rifiutate per la 4.2?

Le discussioni pubbliche mostrano lo stesso schema: i revisori rifiutano UI che sembrano web e link che portano a Safari, e aggiungere piccole funzionalità native da solo non cambia la loro decisione.

A dicembre 2020, uno sviluppatore sull'Ionic Forum si è visto rifiutare un'app per i soci di un club con la motivazione "La tua app offre un'esperienza utente limitata perché non è sufficientemente diversa da un'esperienza di navigazione mobile", seguita da "la maggior parte dei contenuti dell'app rimanda a Safari." Rimuovere InAppBrowser e migliorare il supporto offline non è bastato, e anche il secondo invio è stato rifiutato. Il terzo tentativo è stato approvato dopo che lo sviluppatore ha ricostruito la schermata principale con elenchi e schede immagine in stile nativo, ha aggiunto più notizie dentro l'app e ha rimosso la maggior parte dei link esterni.

A gennaio 2026, uno sviluppatore sugli Apple Developer Forums ha segnalato un'app di pianificazione rifiutata perché "non sufficientemente diversa da un'esperienza di navigazione web", nonostante usasse già notifiche push, Core Location e accesso ai contatti. Pensava di aggiungere feedback aptico, azioni rapide e un'integrazione più profonda con il calendario, e chiedeva cosa conti come "più nativo". Al momento in cui scriviamo la discussione non ha risposte né un esito confermato.

Il confronto: il primo sviluppatore è passato cambiando ciò che l'app è (contenuti in-app, layout nativi, nessun link verso l'esterno). Il secondo ha solo aggiunto API del dispositivo ed era ancora incerto. Concentra i tuoi sforzi sull'esperienza principale, non su un elenco più lungo di permessi.

Quando conviene riscrivere invece di impacchettare?

Riscrivi in nativo quando il valore principale della tua app sono i contenuti web, o quando hai già ricevuto due rifiuti 4.2 per la stessa UI.

Esempio concreto: uno strumento di prenotazione creato con Lovable per uno studio di yoga mostra un elenco di lezioni, un modulo di prenotazione e un link di pagamento Stripe. Impacchettato così com'è, fa scattare tutti e tre i campanelli d'allarme della 4.2: UI web, un link verso l'esterno e nessun uso offline. Come PWA può uscire oggi senza costi aggiuntivi. Per ottenere una scheda sullo store, mantieni il backend Lovable, ricostruisci l'elenco delle lezioni e il flusso di prenotazione con schermate native, aggiungi promemoria locali prima di ogni lezione e gestisci il pagamento nel rispetto della Guideline 3.1 dell'App Review. Backend e modello dei dati restano gli stessi. Quello che riscrivi è la UI.

Se vuoi un secondo parere su quale strada si adatta al tuo progetto Lovable, i servizi di The App Guy coprono impacchettamento, riscrittura e invio agli store, oppure scrivi a yagyeshsrbobde@gmail.com.