Modifiche alle linee guida App Review di ottobre 2026: cosa cambia con 1.2, 2.3.14, 2.5.19 e 3.1.1(a)

Le modifiche di ottobre 2026 alle App Review Guidelines sono state annunciate nel post di Apple Updated App Review Guidelines are now available del 16 ottobre 2026. Due linee guida sono nuove (2.3.14 e 2.5.19), tre passaggi sono stati riformulati (1.2, 3.1.1(a) e sezione 5) e le sezioni Before You Submit e After You Submit hanno ricevuto link a ulteriore documentazione. Qui sotto trovi ogni modifica spiegata in parole semplici, chi deve intervenire e una checklist per il tuo prossimo invio.

Cosa è cambiato nelle App Review Guidelines il 16 ottobre 2026?

Apple ha aggiunto la linea guida 2.3.14 per i creative asset e la 2.5.19 per le funzionalità nascoste. Ha anche chiarito la 1.2 (contenuti generati dagli utenti), la 3.1.1(a) (link di acquisto esterni) e la sezione 5 (Legal). Il changelog di Apple elenca le modifiche così:

Apple afferma che le traduzioni "saranno disponibili sul sito Apple Developer entro un mese". A ottobre 2026, consulta le App Review Guidelines in inglese ogni volta che una versione tradotta non coincide.

Cosa richiede la nuova linea guida 2.5.19 sulle funzionalità nascoste?

La linea guida 2.5.19 richiede che ogni funzionalità presente nel binario sia visibile e documentata sia per gli utenti sia per App Review. Nascondere funzionalità, anche tramite offuscamento, può portare alla rimozione dell'app e alla chiusura dell'account sviluppatore.

Il testo esatto: "Non includere nella tua app funzionalità nascoste, dormienti o non documentate; il funzionamento della tua app deve essere chiaro agli utenti finali e ad App Review. Tentare di nascondere funzionalità non documentate nel binario dell'app, ad esempio tramite offuscamento del codice o altri metodi, è motivo di rimozione dell'app dall'App Store e di chiusura del tuo account sviluppatore." Apple descrive questa policy come consolidata da tempo, ma prima si trovava nella 2.3.1. L'attuale 2.3.1(a) richiede ancora che le nuove funzionalità siano "descritte in modo specifico nella sezione Notes for Review". I rifiuti per funzionalità nascoste dovrebbero ora citare la 2.5.19.

In pratica, elenca nelle note per la revisione ogni funzionalità che può essere attivata da uno switch lato server, un codice invito, una scansione QR, una regione o un livello di account. Se un flag attiverà una funzionalità dopo l'approvazione, attivala già nella build revisionata oppure lascia fuori il codice fino alla versione che la rilascia.

Quali app sono interessate dalle modifiche alla linea guida 1.2?

La linea guida 1.2 ora copre qualsiasi app che consenta agli utenti di "creare, generare, caricare, condividere o contribuire in altro modo con contenuti", e cita espressamente social media, piattaforme UGC e app di creazione di contenuti con IA. Queste app devono filtrare i materiali discutibili, offrire un sistema di segnalazione con risposte tempestive, permettere di bloccare gli utenti molesti e pubblicare informazioni di contatto.

Il testo rivisto elenca le "immagini intime non consensuali" accanto alla violazione della proprietà intellettuale e al bullismo. E aggiunge: "Gli sviluppatori che non implementano tutele adeguate o non correggono le violazioni individuate dopo una segnalazione possono essere considerati in violazione del Developer Code of Conduct." Anche un'app di immagini o avatar con IA che genera contenuti solo per l'utente può ora rientrare nell'ambito. Filtri su prompt e output, segnalazioni e contatti pubblicati vanno inseriti nella build che invii, non in una roadmap.

Cosa dice la linea guida 2.3.14 sui creative asset?

La linea guida 2.3.14 stabilisce che i creative asset devono essere legati ai contenuti, alle funzionalità o al brand della tua app, rispettare le normali regole sui metadati ed essere adatti a tutti i pubblici. Vieta contenuti inappropriati, riferimenti fuorvianti ad altre app, affermazioni non verificabili e "informazioni su prezzi specifici o scontati".

I creative asset sono gli asset immagine e video introdotti da Apple il 5 ottobre 2026. Secondo le App Store asset best practices di Apple, compaiono "in iOS 27 e iPadOS 27 e versioni successive, inclusa la pagina prodotto, nei risultati di ricerca e quando la tua app è in evidenza". La stessa pagina va oltre la linea guida: indica di escludere URL di siti web, simboli di copyright, loghi di altre piattaforme e riconoscimenti Apple come "Editor's Choice". Precisa inoltre che gli asset "devono rispettare una classificazione per età 4+, anche se la classificazione della tua app è più alta". Un header con scritto "50% di sconto questa settimana" o "La app di budget n. 1" viola la 2.3.14.

Cosa è cambiato nella linea guida 3.1.1(a) sui link di acquisto esterni?

La linea guida 3.1.1(a) non ha più un punto separato per il Music Streaming Services Entitlement. Quell'entitlement ora rientra nel punto sugli StoreKit External Purchase Link Entitlements, e il testo specifica che i link possono portare a "una destinazione consentita". Le destinazioni approvate possono variare in base alla regione.

Le regole su dove i link sono ammessi non sono cambiate con questo aggiornamento. Gli entitlement restano limitati a storefront specifici. Lo storefront degli Stati Uniti resta l'eccezione in cui pulsanti, link esterni e altre call to action sono consentiti senza entitlement. Se usi già uno dei due entitlement, verifica che il tuo link porti ancora a una destinazione consentita in ogni storefront in cui distribuisci l'app.

Come risolvono in pratica gli sviluppatori i rifiuti per funzionalità nascoste e UGC?

I casi riportati pubblicamente mostrano che i rifiuti basati sulla vecchia formulazione della 2.3.1 sulle funzionalità nascoste e sulla 1.2 si risolvevano di solito rendendo ogni funzionalità e tutela facile da trovare per il revisore, oppure presentando ricorso. Le sole modifiche al codice raramente bastavano.

• A marzo 2026 uno sviluppatore sugli Apple Developer Forums ha riferito che un'app nativa di sveglia social era stata rifiutata per "Guideline 2.3.1(a) - Hidden Features" e per la 4.2. Ha spiegato che le WebView erano usate solo per privacy policy, termini e FAQ, e ha presentato ricorso. App Review ha risposto che l'App Review Board aveva dato riscontro. Lo sviluppatore ha poi chiesto quali schermate fossero coinvolte, e nessuna soluzione è stata pubblicata.
• In una issue GitHub di Flutter, diversi sviluppatori si sono sentiti dire "We discovered that your app contains hidden features" per app semplici. Un contributor di Flutter ha definito il framework "una falsa pista" e ha indicato come causa API non documentate nel codice dell'app o nei plugin. Due sviluppatori hanno riferito di aver ottenuto l'approvazione dopo il ricorso, senza modificare il codice.
• Uno sviluppatore sugli Apple Developer Forums è stato rifiutato per la 1.2 nonostante avesse EULA, filtri, segnalazioni e blocco. Gli è stato chiesto di far accettare termini con "tolleranza zero per i contenuti discutibili" e di "intervenire sulle segnalazioni di contenuti discutibili entro 24 ore". Un secondo rifiuto ha aggiunto la classificazione 18+, la rimozione immediata dei post e informazioni di contatto in-app. Lo sviluppatore ha risposto documentando ogni tutela e fornendo credenziali di amministratore nelle note per la revisione.

In sintesi: in tutti e tre i casi i revisori non riuscivano a vedere o verificare funzionalità che gli sviluppatori ritenevano evidenti. Con la 2.5.19 e la 1.2 più severa, le note per la revisione e l'account demo contano quanto il codice. La nostra guida all'account demo per la revisione App Store spiega come configurarli.

Cosa verificare prima del prossimo invio?

Prima della prossima build, confronta feature flag, tutele UGC, creative asset e link esterni con il nuovo testo, poi scrivi note per la revisione che indichino ciascun elemento. La checklist qui sotto copre le modifiche di ottobre 2026.

1. Elenca ogni flag controllato dal server, chiave di remote config e menu nascosto. Attivali tutti per il revisore oppure rimuovi il codice che controllano.
2. Descrivi in modo specifico ogni nuova funzionalità nelle Notes for Review, come richiede la 2.3.1(a), spiegando anche come raggiungere ciò che si trova dietro inviti, scansioni o piani a pagamento.
3. Se gli utenti possono pubblicare, chattare o generare contenuti, verifica che filtri, segnalazioni, blocco e contatti pubblicati siano tutti nella build, e metti per iscritto la tua procedura di gestione delle segnalazioni.
4. Per la generazione di immagini o video con IA, aggiungi filtri su prompt e output che blocchino immagini sessuali di persone reali, e offri agli utenti un modo per segnalare gli output.
5. Controlla ogni creative asset alla ricerca di prezzi, sconti, URL, premi dichiarati, loghi di altre piattaforme e qualsiasi elemento oltre la classificazione 4+.
6. Se usi un link di acquisto esterno o il Music Streaming entitlement, verifica che il link porti a una destinazione consentita in ogni storefront.
7. Rileggi in inglese le linee guida di ogni sezione su cui fai affidamento, perché le traduzioni possono arrivare fino a un mese dopo.

Esempio pratico: prendi un'app di avatar con IA con una galleria pubblica e un pacchetto di stili "Pro" attivato tramite remote config dopo il lancio. Con il nuovo testo servono moderazione e segnalazioni per la galleria (1.2). Il pacchetto Pro deve essere visibile nella build revisionata oppure rimandato a una versione successiva (2.5.19). L'asset header per iOS 27 non può riportare "Pro ora scontato del 40%" (2.3.14). Se stai già gestendo un rifiuto, la nostra guida alla risoluzione linea guida per linea guida spiega come rispondere in App Store Connect. Per un secondo parere prima dell'invio, scopri i nostri servizi.