# Guideline 2.3.1: funzioni nascoste e aggiornamenti OTA > Guideline 2.3.1: Apple rifiuta ogni funzione nascosta, dormiente o assente dalle note di revisione. Cosa puoi cambiare da remoto e cosa richiede una build. Pagina originale: [Guideline 2.3.1: funzioni nascoste e aggiornamenti OTA](https://devoria.fr/it/blog/guideline-2-3-1-funzioni-nascoste-aggiornamenti-ota) Autore: [Mehdi Azizi](https://devoria.fr/it/mehdi-azizi) Pubblicazione: 2026-11-04 Ultima revisione dei contenuti: 2026-11-04 La guideline 2.3.1 vieta le funzioni nascoste, dormienti o non documentate: tutto quello che fa la tua app deve essere visibile all'utente e al reviewer. Ogni novità va descritta con precisione nelle note di revisione. **Un aggiornamento da remoto può correggere quello che Apple ha visto, mai aggiungere quello che Apple non ha visto.** Pubblico le mie app iOS con Expo, e ognuna include EAS Update fin dalla prima build per distribuire correzioni. La mia regola: nessun aggiornamento da remoto mentre una versione è in revisione. Questa guida si basa sul testo di Apple, sulla sua licenza, sulla documentazione di Expo e su rifiuti pubblicati. ## Cosa dice la guideline 2.3.1? La 2.3.1 apre la parte 2.3 "Accurate Metadata" delle [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#2.3.1), nella sezione 2 "Performance". Il testo inizia così: "Don't include any hidden, dormant, or undocumented features in your app; your app's functionality should be clear to end users and App Review." Tradotto: niente di nascosto, dormiente o non documentato. Il seguito riguarda ogni invio: "All new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected) and accessible for review." **Ogni novità deve essere descritta con precisione nelle note di revisione, e accessibile al reviewer.** "Correzioni di bug e miglioramenti" quindi non basta. Lo stesso paragrafo colpisce il marketing ingannevole: promettere un contenuto o un servizio che non c'è, o mostrare un prezzo falso, sull'App Store o altrove. Questa parte mi è servita su Nolera. Rileggendo la scheda prima dell'uscita, ho trovato due frasi non verificabili: "interfaccia solo in francese", diventata falsa, e "il pacchetto più scelto", per un'app mai pubblicata. Anche le note per il reviewer descrivevano uno stato superato del prodotto. È esattamente quello che colpisce questa parte. La [2.3.10](https://devoria.fr/it/blog/guideline-2-3-10-app-rifiutata-metadati), invece, riguarda soprattutto la scheda. ## Cosa significa il messaggio di rifiuto 2.3.1? Il rifiuto si intitola "Guideline 2.3.1 - Performance", a volte seguito da "Hidden Features". Due messaggi pubblicati da sviluppatori React Native: - **Marzo 2024**, in una [issue GitHub di CodePush](https://github.com/microsoft/react-native-code-push/issues/2680): "The app contains hidden features.", senza altri dettagli. Lo sviluppatore chiede chiarimenti e riceve un'integrazione a titolo della 2.5.2: "Your app, extension, or linked framework appears to contain code designed explicitly with the capability to change the app's behavior or functionality after App Review approval." La issue non dice se poi l'app sia passata. - **Febbraio 2023**, in un'[altra issue](https://github.com/microsoft/react-native-code-push/issues/2434), Apple prende di mira il "CodePush-related remote code downloading/updating support" del binario. La mia lettura: **il reviewer non vede i tuoi aggiornamenti, vede il codice capace di riceverli.** Questi due casi riguardano CodePush. Non ho trovato rifiuti pubblici recenti su EAS Update, il che non prova nulla. ## Aggiornamenti da remoto: cosa permettono la 2.5.2 e la licenza La [regola 2.5.2](https://developer.apple.com/app-store/review/guidelines/#2.5.2), di cui parlo anche nella guida sulle [modalità in background](https://devoria.fr/it/blog/guideline-2-5-4-background-mode-rifiutato-apple), vieta all'app di "download, install, or execute code which introduces or changes features or functionality of the app". L'articolo 3.3.1(B) dell'[Apple Developer Program License Agreement](https://developer.apple.com/support/terms/apple-developer-program-license-agreement/#b331) vieta il codice eseguibile scaricato, ma precisa: "Interpreted code may be downloaded to an Application". A tre condizioni: quel codice non cambia lo scopo principale dell'app, non aggira né la firma, né la sandbox, né le protezioni del sistema, e non crea uno store di altre app. Il JavaScript di un'app Expo è codice interpretato: secondo me EAS Update rientra in questo quadro. La sua [documentazione](https://docs.expo.dev/eas-update/introduction/) ricorda che gli aggiornamenti seguono le regole dell'App Store, e che "changes to your app's behavior need to be reviewed". Per un bug critico, Expo propone la correzione da remoto, poi un nuovo invio che la include. **La mia linea: correggere e sistemare ciò che esiste, sì. Cambiare ciò che l'app è o ciò che vende, no.** ## Cosa puoi cambiare da remoto e cosa richiede una nuova build La griglia che applico, ricavata dalle pagine di Apple e di Expo citate qui. La riga "gratis che diventa a pagamento" e le ultime due sono una mia interpretazione. | Modifica | Via | Perché | | --------------------------------- | --------------------------- | --------------------------- | | Bug JavaScript | Aggiornamento da remoto | Uso previsto da Expo | | Testo, traduzione, stile | Aggiornamento da remoto | Uso previsto da Expo | | Prezzo di un abbonamento | App Store Connect | Nessun codice modificato | | Testo promozionale | App Store Connect | Senza nuovo invio | | Acquisto di un tipo già approvato | Revisione del solo acquisto | Regola di App Store Connect | | Primo acquisto di un tipo | Nuova versione | Regola di App Store Connect | | Nuova funzione | Nuova versione | 2.3.1 e 2.5.2 | | Gratis che diventa a pagamento | Nuova versione | Scheda e note da rivedere | | Permesso, Info.plist | Nuova build | File del binario | | Modulo nativo, SDK Expo | Nuova build | Codice nativo cambiato | | Interruttore che disattiva | Configurazione remota | Tollerato se temporaneo | | Interruttore che rivela | Vietato | Funzione mai revisionata | Il testo promozionale si cambia "without requiring an updated submission", secondo la pagina di Apple sulle [informazioni di versione](https://developer.apple.com/help/app-store-connect/reference/app-information/platform-version-information). Il primo acquisto di ogni tipo parte con una nuova versione, i successivi da soli, secondo l'aiuto sull'[invio degli acquisti](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/submit-an-in-app-purchase). Expo mette codice nativo, permessi e versione dell'SDK tra le cose che richiedono un nuovo binario, come per [ITMS-90683](https://devoria.fr/it/blog/itms-90683-missing-purpose-string-expo). Un interruttore che disattiva una funzione guasta non aggiunge nulla di nuovo, purché non tolga ciò che gli abbonati hanno pagato. ## Interruttori da remoto senza rifiuti Un interruttore da remoto, o feature flag, non è vietato di per sé: tutto dipende da cosa nasconde. Le mie regole: - **Tutto ciò che un interruttore può mostrare è presente e attivo per il reviewer**, e nominato nelle note di revisione. - Un test A/B confronta due varianti che il reviewer può vedere, mai una variante revisionata e una inedita. - **Nessun codice rileva la revisione per comportarsi diversamente.** È la definizione stessa di funzione nascosta. - Un paywall gestito da remoto mostra solo prodotti approvati, e ogni variante rispetta la [regola 3.1.2](https://devoria.fr/it/blog/guideline-3-1-2-app-rifiutata-abbonamento). ## Modalità demo e account di test La [guideline 2.1](https://devoria.fr/it/blog/guideline-2-1-app-store-rifiuto) richiede un account demo se la tua app ha un login, con il server acceso. Se obblighi legali o di sicurezza ti impediscono di fornirne uno, una modalità demo integrata può sostituirlo, ma solo "with prior approval by Apple", e deve mostrare tutte le funzioni. La pagina di Apple sulle informazioni di versione aggiunge: l'account non scade, e gli account aggiuntivi vanno nelle note, limitate a 4.000 byte. Il legame con la 2.3.1: **una modalità demo o un account di test che apre schermate altrimenti invisibili va descritto.** Un gesto segreto, un codice o un account speciale non segnalato è una funzione nascosta. Nomina ogni accesso speciale nelle note, con quello che apre. ## La mia regola: nessun aggiornamento da remoto durante una revisione Perché uso EAS Update ovunque: su Solys, la mia sveglia, un bug JavaScript rendeva l'app muta appena un effetto sonoro falliva una volta. La correzione stava in tre righe, ma serviva una build completa e una revisione per distribuirla. Da allora tutte le mie app includono expo-updates fin dalla prima build: è un modulo nativo, un binario compilato senza non riceverà mai niente. La mia configurazione, in `app.json`: ```json { "expo": { "runtimeVersion": { "policy": "fingerprint" }, "updates": { "fallbackToCacheTimeout": 0, "checkAutomatically": "ON_LOAD" } } } ``` Con `fingerprint`, un aggiornamento raggiunge solo i binari il cui codice nativo corrisponde ([versioni di runtime](https://docs.expo.dev/eas-update/runtime-versions/)). Ma mentre una versione è in attesa o in revisione, non pubblico nulla. Due motivi. 1. **Il reviewer non vedrebbe la correzione.** Con `fallbackToCacheTimeout` a 0, una nuova installazione parte dal codice incluso e applica l'aggiornamento all'avvio successivo ([documentazione di expo-updates](https://docs.expo.dev/versions/latest/sdk/updates/)). Il reviewer installa, avvia una volta e testa il binario. Nolera è stata rifiutata con una correzione già distribuita da remoto: lo racconto nella guida sulla 2.1. 2. **Quello che il reviewer testa deve restare quello che ricevono gli utenti.** Cambiare il comportamento durante la revisione crea uno scarto tra la versione vista e quella distribuita. ## Note di revisione precise La 2.3.1 rifiuta le descrizioni generiche. Il modello che userei, in inglese: ```text What's new in this version: - [Feature]: [where to find it, how to test it]. Remote configuration: - "[flag]" controls [feature]. It is ON for review. Over-the-air updates: - The app uses expo-updates for bug fixes only. No update will be published during this review. Demo account: see Sign-in information. It never expires. ``` ## Come rispondere a un rifiuto 2.3.1? Rispondi in App Store Connect, dove puoi [rispondere al messaggio di App Review](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/reply-to-app-review-messages/). - **Il messaggio resta vago**: chiedi quale funzione è in questione, come lo sviluppatore della issue del 2024. - **Una funzione reale è descritta male**: dai il percorso esatto e un breve video, poi completa le note. - **Un interruttore rivela qualcosa di inedito**: rimuovilo, oppure attivalo e descrivilo, poi rifai una build. - **Il problema è il codice di aggiornamento**: spiega che serve per le correzioni, nel quadro dell'articolo 3.3.1(B). Nella issue del 2023, Apple chiedeva di rimuoverlo. ## La checklist 2.3.1 prima dell'invio - Ogni novità della versione è descritta nelle note, con il suo percorso. - Ogni interruttore da remoto è attivo per la revisione e nominato nelle note. - Nessun codice cambia comportamento per il reviewer. - Gli accessi speciali sono descritti: modalità demo, account di test, gesto. - La scheda e il paywall non promettono nulla che la build non faccia. - Nessun aggiornamento da remoto viene pubblicato durante la revisione. ## Controllare il tuo pacchetto prima dell'invio Il [Review Kit](https://devoria.fr/it/kits/app-review) raccoglie la mia checklist prima dell'invio, modelli di note per il tester e skill di Claude Code che rileggono il tuo progetto. Per uno sguardo umano, [prenota un'ora con me](https://devoria.fr/it/coaching): rileggiamo insieme le tue note di revisione e la configurazione degli aggiornamenti, in videochiamata. Il percorso completo è nella pagina [app rifiutata da Apple](https://devoria.fr/it/expertise/app-rifiutata-da-apple). Stai preparando la tua prima uscita? [Fai la tua diagnosi gratuita](https://devoria.fr/it/diagnostic): rimette in ordine i passaggi e ti invia la mia checklist anti-rifiuto Apple. ## Domande frequenti ### Cosa significa "Guideline 2.3.1 - Performance - Hidden Features"? Apple ritiene che la tua app contenga una funzione nascosta, dormiente o assente dalle note di revisione. Il messaggio può riguardare anche un codice capace di cambiare l'app dopo la revisione, a volte con un rifiuto 2.5.2. ### EAS Update è consentito da Apple? La licenza consente il codice interpretato scaricato purché non cambi lo scopo principale dell'app. Correggere, sì. Aggiungere una funzione non revisionata, no. ### Si possono usare feature flag in un'app iOS? Sì, se tutto ciò che possono mostrare è stato revisionato. Attiva ogni interruttore per la revisione e descrivilo nelle note. ### Bisogna segnalare una modalità demo al reviewer? Sì. Una modalità demo integrata richiede l'approvazione preventiva di Apple e deve mostrare tutte le funzioni. ### Si può pubblicare un aggiornamento da remoto durante la revisione? Nulla lo vieta nero su bianco. Ma il reviewer non lo vedrebbe al primo avvio, e crea uno scarto con la versione revisionata. Io me ne astengo sempre. ## Il tuo progetto [Review Kit](https://devoria.fr/it/kits/app-review): La mia checklist per la review dell'App Store, i rifiuti di Apple che ho risolto, quella di Google Play e tre skill per Claude Code. 49 €. [iOS & Android Kit](https://devoria.fr/it/kits/ios): Crea la tua app iPhone e Android con Claude Code: il codice di partenza delle mie app, il percorso fino agli store e tutti i kit. 99 €. [Diagnosi: cosa ti separa dalla tua app per iPhone](https://devoria.fr/it/diagnostic): 7 domande, 60 secondi: scopri cosa ti blocca davvero nel pubblicare la tua app per iPhone, il tuo percorso in 4 tappe e il kit giusto per te.