Checklist per l'invio su App Store (2026): dalla build con Xcode 26 a Submit for Review

Una checklist per l'invio su App Store è l'elenco di ciò che deve essere pronto tutto insieme prima di inviare: una build funzionante, una scheda accurata, risposte veritiere sulla privacy e abbastanza contesto perché un revisore possa usare la tua app. Una build che compila senza errori non basta. Le sei sezioni qui sotto seguono l'ordine in cui App Store Connect le richiede, e ognuna si apre con una risposta breve su cui puoi agire subito.

Cosa serve per un invio su App Store prima di premere Invia?

Un invio su App Store richiede una build elaborata e associata alla versione, i metadati obbligatori della versione, gli screenshot, una privacy policy, i contatti per App Review e, se l'app ha un login, credenziali demo funzionanti. L'elenco "Before You Submit" di Apple nelle App Review Guidelines aggiunge altri due punti: "Attiva i servizi di backend in modo che siano online e accessibili durante la revisione" e spiega nelle note per la revisione le funzionalità non evidenti.

Quali impostazioni dell'account e del record dell'app devono essere pronte?

Ti servono un'iscrizione attiva all'Apple Developer Program, un record dell'app il cui bundle ID corrisponda a quello della build firmata e qualcuno nel team con il ruolo Account Holder, Admin o App Manager. Sono i ruoli che la pagina Submit an app di Apple richiede per l'invio.

Quando crei il record, scegli nome, lingua principale e SKU. Lo SKU è interno e i clienti non lo vedono mai. Se vendi un'app a pagamento o acquisti in-app, completa prima gli accordi per le app a pagamento, i dati fiscali e quelli bancari. Un accordo non firmato può bloccare un lancio commerciale anche quando la build è a posto.

Quali requisiti di build valgono per i caricamenti su App Store nel 2026?

A ottobre 2026, la pagina dei requisiti in arrivo di Apple indica che "le app caricate su App Store Connect devono essere compilate con Xcode 26 o successivo usando un SDK per iOS 26, iPadOS 26, tvOS 26, visionOS 26 o watchOS 26" (dal 28 aprile 2026). Indica inoltre che le app iOS e iPadOS "devono avere come target iOS 13 o successivo" (dal 9 settembre 2026).

• Incrementa il numero di build a ogni caricamento e verifica che il numero di versione corrisponda alla release che intendi pubblicare.
• Aggiorna l'immagine Xcode nella CI (Codemagic, Expo EAS, GitHub Actions e simili) oltre che sulla tua macchina.
• Dopo l'elaborazione, rispondi all'eventuale richiesta sulla conformità all'esportazione e associa la build elaborata alla versione.
• Installa la build TestFlight su un dispositivo fisico. Prova onboarding, accesso, stati offline, acquisti e ripristino degli acquisti. Un'esecuzione riuscita nel simulatore non dimostra che la build distribuita funzioni.
• Leggi l'email che App Store Connect invia dopo il caricamento. Gli avvisi ITMS su privacy manifest o versioni dell'SDK diventano bloccanti se li ignori.

La linea guida 2.1(a) è esplicita su cosa succede altrimenti: "Rifiuteremo bundle e binari incompleti che vanno in crash o presentano evidenti problemi tecnici." Rimuovi schermate segnaposto, menu di debug e link non funzionanti prima di creare l'archivio. Il nostro piano di test della build di release per la 2.1 approfondisce questi controlli.

Quali screenshot e metadati richiede App Store Connect?

A ottobre 2026, le specifiche degli screenshot di Apple richiedono almeno uno screenshot per "iPhone con Dynamic Island (display medio)", ad esempio 1206 × 2622 o 1179 × 2556 in verticale. Le app che funzionano su iPad richiedono anche almeno uno screenshot per iPad 13 pollici, ad esempio 2064 × 2752 o 2048 × 2732.

Puoi "caricare fino a 10 screenshot per dimensione di dispositivo nei formati .jpeg, .jpg o .png" e "le immagini non possono includere canali alfa o trasparenze". Se l'interfaccia è identica su tutte le dimensioni, carica solo la risoluzione più alta richiesta e App Store Connect la ridimensiona. La linea guida 2.3.3 stabilisce che gli screenshot "devono mostrare l'app in uso, e non solo la grafica del titolo, la pagina di login o la schermata di avvio".

• Scrivi una descrizione che dica a chi è rivolta l'app e cosa si può fare già dalla prima sessione.
• Mantieni pertinenti nome, sottotitolo e parole chiave. Non ripetere le parole chiave e non usare nomi di concorrenti.
• Verifica che l'URL di supporto e quello della privacy policy si aprano senza login.
• Compila il questionario sulla classificazione per età in base a ciò che l'app contiene e permette di fare davvero.
• Mostra negli screenshot la build attuale, compreso l'eventuale paywall che l'utente incontrerà.

Come rendere le risposte sulla privacy coerenti con l'app?

Per rendere le risposte sulla privacy coerenti con l'app, elenca ogni SDK che distribuisci e i dati che raccoglie, poi usa quell'elenco per compilare App Privacy, scrivere la privacy policy e configurare il comportamento nell'app. La linea guida 2.3 stabilisce che i metadati, "comprese le informazioni sulla privacy", devono rispecchiare fedelmente l'app.

La linea guida 5.1.1(i) recita: "Tutte le app devono includere un link alla propria privacy policy nel campo dei metadati di App Store Connect e all'interno dell'app, in un punto facilmente accessibile." La linea guida 5.1.1(v) aggiunge: "Se la tua app consente la creazione di un account, devi offrire anche l'eliminazione dell'account all'interno dell'app." Gli SDK di analytics, crash reporting, pubblicità e login di solito cambiano le tue risposte, quindi verificali con il nostro audit degli SDK per le privacy label. Controlla anche che la tua app e ogni SDK incluso contengano un privacy manifest PrivacyInfo.xcprivacy che copra le API con motivazione obbligatoria (required-reason API) che utilizzano.

Cosa deve contenere App Review Information?

App Review Information deve contenere un contatto che risponda, credenziali demo funzionanti e senza scadenza, e note che portino il revisore direttamente alle funzionalità principali. La linea guida 2.1(a) chiede di "includere i dati di un account demo (e di attivare il servizio di backend!) se la tua app prevede un login"; una modalità demo integrata al posto di un account richiede l'approvazione preventiva di Apple.

Ecco un esempio concreto di note per la revisione: "Accedi con l'account di revisione fornito. Apri Libreria, scegli il progetto di esempio e tocca Esporta. L'account ha tutte le funzionalità premium sbloccate. Le funzioni di localizzazione usano una città simulata, quindi non serve spostarsi." Non mandare i revisori su un account vuoto, su un codice monouso che scade o su un flusso che funziona solo se sei online per approvarlo. La nostra guida alla configurazione dell'account demo spiega come creare un login per il revisore che regga.

Come si invia un'app in revisione su App Store Connect?

Per inviare un'app in revisione, associa la build alla versione, fai clic su Add for Review e poi su Submit for Review. Add for Review da solo non invia nulla ad Apple. La sequenza qui sotto segue la pagina Submit an app di Apple aggiornata a ottobre 2026.

1. In App, seleziona l'app, poi fai clic sulla versione dell'app nella barra laterale.
2. Scorri fino alla sezione Build e verifica che sia associata la build corretta.
3. Nella sezione App Store Version Release, scegli il rilascio manuale se vuoi controllare il giorno del lancio, poi fai clic su Save.
4. Fai clic su Add for Review e scegli una bozza di invio esistente o creane una nuova. Lo stato diventa Ready for Review.
5. Fai clic su Submit for Review. Quando la revisione inizia, lo stato diventa In Review.
6. Salva una copia dei metadati e delle note inviati e tieni d'occhio l'email del contatto per la revisione in caso di domande.

Se l'invio viene rifiutato, leggi il numero della linea guida e la spiegazione del revisore prima di modificare qualsiasi cosa. Alcune correzioni riguardano solo i metadati. Altre richiedono una nuova build. La nostra guida ai rifiuti su App Store spiega come capire in quale caso ti trovi.

Cosa è andato storto ad altri sviluppatori al momento dell'invio?

In entrambi i casi pubblici qui sotto, l'app funzionava per il suo sviluppatore e il problema è emerso solo nella build caricata o nella prima sessione del revisore.

Uno sviluppatore sul forum di Adalo ha ricevuto un rifiuto per la linea guida 2.1: "non siamo riusciti ad accedere con le credenziali dell'account demo che hai fornito". Le credenziali erano valide, ma il primo tocco sul pulsante di login non faceva nulla e funzionava solo il secondo, perché la navigazione condizionale partiva dal pulsante di login prima che la sessione utente fosse registrata. Ha risolto indirizzando il pulsante di login a una schermata di transizione vuota che conteneva le azioni condizionali, poi ha inviato di nuovo l'app.

Uno sviluppatore sul forum di JUCE ha ricevuto "ITMS-91053: Missing API declaration" dopo un caricamento, con l'indicazione che i nuovi caricamenti "devono includere un array NSPrivacyAccessedAPITypes nel privacy manifest dell'app". Le categorie segnalate erano SystemBootTime e FileTimestamp, e un altro utente ha segnalato UserDefaults. La soluzione è stata un file PrivacyInfo.xcprivacy con i codici di motivazione approvati, aggiunto come risorsa Xcode. Nella prima versione di un utente mancava una chiave di tipo, il che ha generato l'errore ITMS-91056 per manifest non valido finché non l'ha corretta.

Entrambi gli sviluppatori avevano testato solo sulla propria configurazione. Prima di premere Submit for Review, prova la build che Apple riceve davvero con un login da zero e leggi ogni email successiva al caricamento. Se vuoi un secondo parere sul pacchetto, scopri i nostri servizi di invio.