Guideline 2.3.1: funzioni nascoste e aggiornamenti OTA

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, 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, 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: "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, 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, di cui parlo anche nella guida sulle modalità in background, 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 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 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. Il primo acquisto di ogni tipo parte con una nuova versione, i successivi da soli, secondo l'aiuto sull'invio degli acquisti. Expo mette codice nativo, permessi e versione dell'SDK tra le cose che richiedono un nuovo binario, come per ITMS-90683. 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.

Modalità demo e account di test

La guideline 2.1 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:

{
  "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). 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). 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:

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.

• 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 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: rileggiamo insieme le tue note di revisione e la configurazione degli aggiornamenti, in videochiamata. Il percorso completo è nella pagina app rifiutata da Apple.

Stai preparando la tua prima uscita? Fai la tua diagnosi gratuita: 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.