I nuovi articoli di App Review Help di Apple, letti da un maker di app per Mac

Risposta breve

Nella sua nota Hello Developer del novembre 2026, Apple ha indirizzato gli sviluppatori a nuovi articoli di aiuto su App Review. Mettono per iscritto cose che la maggior parte di noi aveva imparato dai rifiuti: Apple punta a rivedere il 50% degli invii in meno di 24 ore e il 90% in meno di 48; i login demo devono funzionare ancora quando inizia la revisione; bisogna rispondere in App Store Connect invece di reinviare per rispondere a una domanda; un rifiuto che inizia con "Bug Fix Submissions:" ti permette di pubblicare la correzione e occuparti del problema la volta dopo; più della metà degli screenshot deve mostrare l'app in uso; e ogni permesso richiede la sua purpose string chiara. Solo un articolo nomina il Mac, ma ogni regola vale per un invio al Mac App Store.

Gran parte di ciò che so su App Review l'ho imparata dalle email di rifiuto. Così, quando Hello Developer del novembre 2026 di Apple ha detto “Scopri i nuovi articoli di aiuto su App Review”, li ho letti tutti. Ora stanno in un unico posto, App Review Help, e dicono ad alta voce tante cose che prima erano folklore.

Ecco cosa contengono di importante per un'app per Mac, e cosa cambierei prima del mio prossimo invio.

Prima di tutto, a chi serve

App Review esamina solo ciò che passa da App Store Connect: il Mac App Store, TestFlight, In-App Purchases e il resto. Se vendi la tua app per Mac dal tuo sito con un Developer ID, nessuno in Apple la rivede. Passa dalla notarizzazione, che è un controllo automatico. Quindi, se distribuisci solo in modo diretto, dai una scorsa e tieni questo articolo per il giorno in cui aggiungerai una versione per il Mac App Store.

Quanto dura una revisione

L'articolo sullo stato della revisione dà l'obiettivo dichiarato da Apple: rivedere almeno il 50% degli invii in meno di 24 ore e il 90% in meno di 48 ore. Dice anche cosa rallenta una revisione, come una cronologia di revisioni limitata, documenti che servono ad Apple o problemi complessi o nuovi.

Cosa farei: pianificare un giorno di lancio con due giorni liberi prima, di più per una prima app. E inviare in anticipo con rilascio manuale, così puoi scegliere il minuto in cui va online.

Le revisioni si vincono nel campo Notes

L'articolo sulla revisione completa è schietto: “Gli invii incompleti verranno rifiutati.” I dettagli che contano:

I login demo devono funzionare quando inizia la revisione, non solo quando invii. Un account di prova che scade o cambia nel frattempo può farti respingere.
Se il login richiede un codice, mettilo in Notes. Senza, Apple potrebbe dover telefonare, e le chiamate di solito si fanno entro tre-cinque giorni lavorativi. È una settimana persa.
Gli abbonamenti richiedono un account demo con un abbonamento scaduto, così chi fa la revisione può vedere tutto il flusso di acquisto.

Cosa farei: scrivere il campo Notes come un breve how-to per un estraneo. Dove cliccare per primo, quale account usare e cosa fa l'icona nella barra dei menu se la tua app non ha finestre. Quest'ultima è molto Mac.

Quando viene rifiutata

Questa è la parte che avrei voluto avere per iscritto anni fa.

Non reinviare per rispondere a una domanda. Se App Review chiede informazioni, rispondi in App Store Connect. Reinvia solo per una correzione nella build, e solo dopo aver sistemato ogni problema indicato.
Cerca "Bug Fix Submissions:" in cima. Se un rifiuto inizia con quella nota, l'articolo su Bug Fix Submissions dice che puoi rispondere accettandolo e risolvere il problema nel prossimo aggiornamento. Non reinviare. Funziona solo per app già approvate in precedenza, mai per problemi legali o di sicurezza, e un problema non si può rimandare due volte.
Chiedi l'accelerazione solo se serve davvero. Apple dice che le richieste accelerate vanno “riservate a questioni di reale urgenza”, e solo per build già inviate in revisione. Per un lancio legato a un evento, scrivi l'evento e la sua data in Notes.
Il ricorso per ultimo. Prima rispondi al rifiuto e spiega. Se non funziona, l'App Review Board accetta un solo ricorso per app, e una volta reinviata l'app non puoi più fare ricorso contro quel rifiuto.

Quattro regole, con i numeri

Gli articoli sulle linee guida sono brevi e concreti.

Screenshot, 2.3.3. Più della metà dei tuoi screenshot deve mostrare l'app in uso, contati per tipo di dispositivo. Con tre screenshot, due devono mostrare l'app. Una schermata iniziale o una scheda con il titolo vanno bene finché sono la minoranza. Il controllo screenshot di MacPip verifica le dimensioni, e il resto puoi contarlo tu.
Imitazioni, 4.1. Non inserire nomi di app popolari o termini con marchio registrato in nessun campo dei metadati. Vale anche per le parole chiave, dove il nome di un concorrente è lo scivolone classico. Il controllo parole chiave dell'App Store conta i tuoi campi così puoi vedere cosa contengono.
Purpose string, 5.1.1(ii). Ogni risorsa protetta richiede la propria purpose string chiara, localizzata se lo è la tua app. L'esempio negativo di Apple è "To use location." E sei responsabile anche di ciò che chiedono i tuoi SDK. Incolla il tuo Info.plist nella spiegazione di Info.plist e ti segnala quelle vuote e vaghe.
Eliminazione dell'account, 5.1.1(v). Se nella tua app si può creare un account, le persone devono poter avviare l'eliminazione dall'app. Disattivare non basta, e non puoi costringerle a telefonarti. Se hanno un abbonamento, spiega che la fatturazione prosegue tramite Apple finché non lo annullano.

L'unica riga sul Mac

Solo l'articolo sui dispositivi compatibili nomina il Mac. Dice che le app compatibili per iPhone e iPad possono girare senza modifiche sui Mac con Apple silicon, e che le app che si appoggiano a un tocco impossibile da fare con la tastiera non sono adatte a macOS. Se fai un'app per iPad, controlla se compare sul Mac App Store e disattiva l'opzione se non funziona bene con tastiera e trackpad. La stessa pagina dice che TestFlight accetta fino a 100 tester interni e 10.000 esterni, e che anche la prima build data ai tester esterni passa da App Review.

Conta anche What's New

Un'altra cosa viene dalle linee guida, non dai nuovi articoli. La Guideline 2.3.12 dice che il testo di What's New deve descrivere nuove funzioni e modifiche, e solo semplici correzioni di bug e lavoro sulle prestazioni possono cavarsela con una riga generica. "Bug fixes and improvements" su una versione con una nuova funzione è un invito a ricevere una domanda.

Quindi il nuovo strumento gratuito di oggi è il formattatore di note di rilascio. Incolla note grezze o le righe di git log --oneline. Le divide in Novità, Miglioramenti e Correzioni, elimina le righe chore, ci e merge, segnala numeri di ticket e nomi di file, controlla il limite di 4000 caratteri e ti dà tre copie: testo semplice per App Store Connect, HTML per il tuo appcast Sparkle e Markdown per GitHub. Le tue note restano nel tuo browser. Il controllo appcast Sparkle è qui accanto, per il feed in cui vanno.

La mia lista breve

Due giorni liberi prima del giorno del lancio, e rilascio manuale.
Un campo Notes che un estraneo possa seguire, con un account demo funzionante.
Rispondi, non reinviare, quando ti fanno solo una domanda.
Conta gli screenshot, leggi ogni purpose string e tieni i nomi di altre app fuori dalle parole chiave.
What's New che dice cosa è cambiato.

E una volta pubblicata, inserirla su MacPip è gratis, che sia sul Mac App Store o no. Le schede vengono analizzate automaticamente quando vengono inviate, e una spunta blu significa solo che una persona ha provato l'app in una certa data.

Fonti

Continua a leggere

Invia la tua app Strumenti gratuiti per i creatori

Apple ha messo per iscritto come funziona App Review. Ecco cosa cambierei prima di inviare