Come pubblicare un'app web su App Store in 11 passaggi

Per mettere un'app web sullo Store App e Google Play, avvolgere la tua app web costruita in un progetto nativo con Capacitor, aggiungere alcune funzionalità native, creare account sviluppatori Apple e Google, firmare e costruire i binari iOS e Android, testarli con utenti reali, preparare le liste dei negozi e inviarle per la revisione. Il tuo HTML, CSS e JavaScript esistenti continua a funzionare all'interno di un WebView nativo, quindi non devi ri scrivere l'app.

Ecco i 11 passaggi in ordine che evita di aspettare, con comandi per Capacitor 8 e le regole dei negozi che si applicano in ottobre 2026.

Cosa ti serve

• A un'app web che si costruisce in file statici (React, Vue, Angular, Svelte, Next.js static export, Nuxt generate, HTML puro o un'app creata con un costruttore di AI come Lovable o Bolt).
• Node.js 22 o successivo (Capacitor 8 richiesta) e Bun o un altro gestore di pacchetti.
• Android Studio per le costruzioni Android.
• Xcode 26 su macOS per le costruzioni iOS, o un servizio di costruzione cloud se non hai un Mac.
• 99 USD all'anno per Apple e 25 USD una volta per Google.

Linea di tempo realistica

Passo 1: Iscriviti oggi al programma di sviluppatore

La verifica dell'account è il passo che non puoi accelerare, quindi fai prima di iniziare a codificare.

• Programma di sviluppatore Apple: 99 USD all'anno. Gli individui hanno bisogno di un account Apple con due fattori di autenticazione e il loro nome legale. Le organizzazioni hanno anche bisogno di un numero D-U-N-S, un sito web aziendale e un indirizzo email di lavoro su quel dominio.
• Console di Gioco PlayCosto: 25 USD una volta. Le organizzazioni richiedono un numero D-U-N-S. Si prevede la verifica dell'identità.

Se si iscrive su Google Play come individuo, il proprio account è soggetto alla regola di testing chiuso (Step 9). Guida completa: come creare gli account di sviluppatore Apple e Google Play.

Passo 2: Prepara l'app web per un telefono

Capacitor esegue l'app in un WebView. Le cose che funzionano bene in una scheda del browser sembrano sbagliate in un'app:

• Output di costruzione statica. Capacitor carica file dal bundle dell'applicazione. La rendering server-side non si esegue sul telefono. Utilizza l'output statico del tuo framework (next build con output: 'export', nuxt generate, Vite build). API chiama il backend con HTTPS come prima.
• Routing client-side che funziona da un'origine file. Utilizza la routing con storia (Capacitor serve l'applicazione da https://localhost su Android e capacitor://localhost su iOS, quindi funziona) e assicurati che le URL profonde cadano indietro su index.html.
• CORS. Aggiungi le origini Capacitor alle origini consentite del tuo API: capacitor://localhost (iOS) e https://localhost (Android).
• Tocca, non muovi il puntatore. Rimuovi menu a soqquadro. Assicurati che i bersagli di tocco abbiano almeno 44 x 44 punti.
• Zone sicure. Aggiungi viewport-fit=cover al tag meta viewport e aggiungi padding ai titoli e alle barre inferiori con env(safe-area-inset-top) e env(safe-area-inset-bottom).
• Offline e reti lente. Mostra uno stato appropriato al posto di uno schermo vuoto. I revisori testano su Wi-Fi instabile.
• Nessun banner di download dell'applicazione e nessun link che invii gli utenti al tuo sito web per eseguire compiti principali.

<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />

Step 3: Add Capacitor

Dalla radice del tuo progetto web:

bun add @capacitor/core
bun add -d @capacitor/cli
bunx cap init "My App" com.example.myapp --web-dir dist
bun add @capacitor/ios @capacitor/android
bun run build
bunx cap add ios
bunx cap add android

Usa la cartella di output reale per --web-dir: dist per Vite out per l'esportazione statica di Next.js .output/public per Nuxt generate build per Create React App dist/<project>/browser per Angular

L'ID del bundle (com.example.myapp) è permanente una volta che l'app è sulle store. Utilizza un dominio inverso che controlli.

Il tuo capacitor.config.ts ora assomiglia a:

import type { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  appId: 'com.example.myapp',
  appName: 'My App',
  webDir: 'dist',
};

export default config;

Capacitor 8 crea il progetto iOS con Swift Package Manager di default, quindi non hai bisogno di CocoaPods. Ogni volta che cambi il web code:

bun run build
bunx cap sync

Esegui:

bunx cap run ios
bunx cap run android

Committe: ios/ Ecco android/ folder. Sono le risorse code che modificherai (permessi, icone, firma). Per ulteriori informazioni, vedi come è facile trasformare un'app web in un'app mobile con Capacitore se hai costruito con uno strumento di AI, il nostro Guida per rendere amichevole l'app mobile.

Passo 4: Aggiungi funzionalità native che giustificano l'app

Apple rifiuta le app che sono solo un sito web in una shell (linee guida 4.2 - Minimo funzionale). Non hai bisogno di decine di funzionalità native, ma l'app deve comportarsi come un'app. Aggiunte comuni e utili:

Esempio: mostrare la condivisione nativa al posto di un pulsante "copia link"

import { Share } from '@capacitor/share';
import { Capacitor } from '@capacitor/core';

export async function shareLink(url: string, title: string) {
  if (Capacitor.isNativePlatform()) {
    await Share.share({ title, url });
  } else {
    await navigator.clipboard.writeText(url);
  }
}

Se vendi contenuti digitali o abbonamenti, pianifica i pagamenti ora. Apple e Google richiedono i loro sistemi di acquisto in-app per beni digitali in molti casi. Nella App Store statunitense, gli app possono anche collegarsi a un controllo di cassa web esterno dopo la sentenza della corte del 2025; altre regioni hanno le loro regole. I beni e i servizi fisici (consegne, trasporti) possono utilizzare Stripe o qualsiasi provider di pagamento. Vedi acquisti in-app con Capacitor.

Il catalogo completo dei plugin Capgo è sul pagina dei plugin.

Passo 5: Icone, schermata di benvenuto e stringhe di autorizzazione

Generate all icon and splash sizes from two source images:

bun add -d @capacitor/assets
# assets/icon.png 1024x1024, assets/splash.png 2732x2732
bunx capacitor-assets generate

Su iOS, ogni autorizzazione che utilizzi richiede una descrizione di utilizzo nella ios/App/App/Info.plisto l'app si blocca quando chiede e Apple la rifiuta:

<key>NSCameraUsageDescription</key>
<string>Take a photo of your receipt to attach it to an expense.</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>Choose receipt photos from your library.</string>

Scrivi motivazioni specifiche. "Questa app richiede la fotocamera" viene rifiutata.

Su Android, i plugin aggiungono la maggior parte delle autorizzazioni al manifesto. Elimina le autorizzazioni che non utilizzi; Google ti chiede di giustificare quelle sensibili.

Aggiungi anche un manifesto di privacy (PrivacyInfo.xcprivacySe il tuo code utilizza API richiesti per motivi. privacy manifest guide for Capacitor.

Passo 6: Configura la firma

iOS. Avrai bisogno di un certificato di distribuzione Apple (con la sua chiave privata, solitamente esportata come .p12) e di un profilo di provisioning App Store Connect per il tuo ID bundle. Xcode può crearli automaticamente, oppure puoi crearli da solo, anche senza un Mac. Leggi Certificati iOS e profili di provisioning spiegati; the Generatore di certificato iOS gestisce lo step di generazione del CSR nel browser.

Android. Creare un keystore di caricamento e mantenerlo in backup. Google Play utilizza Play App Signing, quindi Google tiene la chiave di firma finale e tu firmerai le caricamenti con la tua.

keytool -genkeypair -v -keystore upload-keystore.jks -alias upload \
  -keyalg RSA -keysize 2048 -validity 10000

O utilizza il generatore di keystore Android.

Passo 7: Costruisci i binari di rilascio

Localmente

IOS (con un Mac con Xcode 26, richiesto per le pubblicazioni sullo Store dal 2026 in poi):

1. bunx cap open ios
2. Scegli il App target, imposta la versione e il numero di build, seleziona il tuo team sotto Signing & Capabilities.
3. Scegli Qualsiasi dispositivo iOS (arm64), quindi Prodotto > Archivia.
4. In Organizzatore, Distribuisci App > App Store Connect > Carica.

Android:

bun run build
bunx cap sync android
cd android
./gradlew bundleRelease

L'AAB è in android/app/build/outputs/bundle/release/. Configura signingConfigs in android/app/build.gradle con il tuo keystore, caricando le password dalle variabili di ambiente.

Sicuro targetSdkVersion è 36. Dal 31 agosto 2026, Google Play richiede che le nuove app e gli aggiornamenti puntino a Android 16 (API 36), che è il Capacitor 8 predefinito.

Nella cloud

Se non hai un Mac, o vuoi che i build siano riproducibili da CI, Capgo Build costruisce entrambe le piattaforme su macchine ospitate e può caricare direttamente su TestFlight e Google Play:

bunx @capgo/cli@latest build credentials save --appId com.example.myapp --platform ios
bunx @capgo/cli@latest build credentials save --appId com.example.myapp --platform android
bunx @capgo/cli@latest build request com.example.myapp --platform ios --path .
bunx @capgo/cli@latest build request com.example.myapp --platform android --path .

Le credenziali vengono utilizzate solo per la costruzione e non sono memorizzate sui server Capgo. Consultate i Capgo Build docs.

Passo 8: Distribuisci ai tester

Mettilo in produzione su dispositivi reali prima che qualcuno a Apple o Google lo veda.

• iOS: caricalo su TestFlight. I tester interni (fino a 100 membri del team) lo ricevono subito dopo il trattamento; i tester esterni (fino a 10.000) dopo una breve revisione Beta App.
• AndroidCrea una versione di test interna nel console di Play e condividi il link di opt-in.

Verifica registrazione e accesso, pagamenti nel sandbox, notifiche push, comportamento offline, il tasto tastiera che copre gli input e il comportamento del pulsante indietro su Android. Dettagli per ogni opzione: come distribuire app iOS e Android ai tester.

Passo 9: Esegui il test chiuso di Google Play (nuovi account personali)

Se il tuo account Play è stato creato dopo il 13 novembre 2023, non puoi pubblicare in produzione fino a quando non hai eseguito un} test chiuso con almeno 12 tester che hanno scelto di partecipare per 14 giorni consecutiviQuindi si richiede l'accesso alla produzione nel pannello di controllo di Play Console, che Google solitamente esamina entro una settimana.

Inizia questo processo non appena hai una build Android funzionale. Utilizza un gruppo di Google come lista dei tester in modo che le persone possano unirsi da sole. Invia aggiornamenti durante i 14 giorni e raccogli le recensioni, poiché Google chiede cosa hai imparato. Gli account di organizzazione sono esenti.

Passo 10: Prepara le liste dei negozi e invia

You need for both stores: app name, descriptions, screenshots in the accepted sizes, icon, privacy policy URL, privacy disclosures (Apple App Privacy and Google Data safety), age rating questionnaire, support contact, and a demo account if the app has a login. Google also needs a 1024 x 500 feature graphic. Specs and limits: Come preparare la tua lista di pubblicazione per l'App Store e Google Play.

Invio su iOS: in App Store Connect, crea la versione, seleziona la build di TestFlight, completa le informazioni di valutazione App (account demo, note) e clicca Aggiungi per Revisione, then Quindi.

Invio su Android: creare una versione di produzione con l'AAB (o promuovere quella testata da una track di testing), completare ogni Contenuto dell'app La dichiarazione del contenuto dell'app

I rifiuti che colpiscono più spesso le app web sono:

1. 4.2 Funzionalità MinimaL'app è solo il tuo sito web. Aggiungi valore nativo e elimina l'interfaccia utente del browser.
2. Login required but no demo account, o l'account non funziona.
3. Opzione di accesso senza privacy quando offri il login con Google o Facebook su iOS. La linea guida 4.8 richiede un'opzione equivalente che limita la raccolta dei dati; il solito è Sign in with Apple.
4. Nessuna cancellazione dell'account all'interno dell'app quando gli utenti possono creare account.
5. Acquisti digitali tramite Stripe ove è richiesta l'acquisto in-app.
6. Layout iPad rotto perché il progetto supporta iPad di default.
7. Stringhe di permessi mancanti o vaghe.

Nostra guida di revisione dell'app per primi tempi e guida di sottoscrizione dell'app iOS passa a ogni punto in dettaglio.

Passo 11: Invia aggiornamenti senza attendere la revisione

Dopo il lancio, la maggior parte delle tue modifiche sarà ancora nel web code. Invece di un nuovo build del negozio per ogni correzione, aggiungi aggiornamenti in tempo reale. L'Capgo aggiornatore scarica nuovi pacchetti web da Capgo e li applica al prossimo avvio, con rollback automatico se il nuovo pacchetto non riesce a partire.

bun add @capgo/capacitor-updater
bunx cap sync
bunx @capgo/cli@latest init

Chiama notifyAppReady() quando il tuo app è stata avviata affinché l'aggiornatore sappia che il pacchetto è sano:

import { CapacitorUpdater } from '@capgo/capacitor-updater';

CapacitorUpdater.notifyAppReady();

Poi ogni rilascio di web code è un comando:

bun run build
bunx @capgo/cli@latest bundle upload --channel production

Entrambi i negozi consentono questo per l'interpretazione code a patto che l'aggiornamento non cambi lo scopo principale dell'app o evadi le loro regole di pagamento. Le modifiche native (nuovi plugin, nuove autorizzazioni, Capacitor aggiornamenti) passano ancora attraverso i negozi. Leggi di più su Capgo aggiornamenti live e documentazione dell'aggiornatore.

Aggiungi il plugin prima della tua prima sottoscrizione al negozio. Deve essere presente nel binario che gli utenti installano, altrimenti il tuo primo live update può raggiungere gli utenti solo dopo una seconda rilascio del negozio.

Infine, automatizza: costruisci e carica su ogni tag da GitHub Actions o GitLab CI, pubblica gli aggiornamenti live su ogni merge a maine mantieni i rilasci nativi per le modifiche native.

Elenco di controllo pre-lancio

• Conti Apple e Google approvati, accordi accettati
• Funziona l'applicazione anche offline o mostra uno stato offline chiaro
• Zone sicure, tastiera e pulsante di ritorno di Android gestiti
• Almeno alcune funzionalità native che un sito web non può offrire
• Icône, splash, stringhe di autorizzazione, manifesto di privacy
• Certificato di distribuzione, profilo di App Store, keystore caricato
• Target SDK 36 su Android, costruito con Xcode 26 su iOS
• TestFlight e Play testing interno eseguito su dispositivi reali
• Test chiuso su Google Play (contenuti personali)
• Elenco completo su entrambi i negozi, account demo aggiunto
• Eliminazione dell'account in-app se gli utenti possono iscriversi
• Plugin di aggiornamenti in tempo reale incluso nel primo binario

Troubleshooting

Schermo bianco al lancio. webDir si riferisce alla cartella sbagliata o hai dimenticato bunx cap sync dopo aver costruito. Controlla ios/App/App/public e android/app/src/main/assets/public contiene index.html.

API le chiamate falliscono solo nell'app. CORS: consenti capacitor://localhost e https://localhost. Controlla anche di non chiamare http:// URL, che iOS blocca di default.

Le rotte 404 dopo il refresh o il link profondo. Utilizza un router che ricade su index.htmlo hash routing per vecchi impianti.

Errori di firma Xcode. Vedi l'elenco degli errori in Spiegazione dei certificati e dei profili di provisioning iOS.

Il build Gradle fallisce dopo l'aggiornamento. Capacitor 8 richiede Android Studio Otter (2025.2.1) o successivo e JDK 21, come elencato nella Capacitor 8 guida all'aggiornamento. Per altri errori di compilazione con Gradle, vedi come risolvere gli errori di compilazione Android in Capacitor.

Google Play rifiutato per il target SDK. Impostare targetSdkVersion = 36 context android/variables.gradle.