Devoria
Guideline 2.3.1: funcions ocultes i actualitzacions OTA
Per Mehdi Azizi
Publicat el , 9 min
Guideline 2.3.1: Apple rebutja qualsevol funció oculta, latent o absent de les notes de revisió. Què pots canviar a distància i què exigeix un build nou.
La guideline 2.3.1 prohibeix les funcions ocultes, latents o no documentades: tot el que fa la teva app ha de ser visible per a l'usuari i per al revisor. Cada novetat s'ha de descriure amb precisió a les notes de revisió. Una actualització a distància pot corregir el que Apple ha vist, mai afegir el que Apple no ha vist.
Publico les meves apps iOS amb Expo, i totes porten EAS Update des del primer build per enviar correccions. La meva regla: cap actualització a distància mentre una versió està en revisió. Aquesta guia es basa en el text d'Apple, la seva llicència, la documentació d'Expo i rebuigs publicats.
Què diu la guideline 2.3.1?
La 2.3.1 obre l'apartat 2.3 «Accurate Metadata» de les App Review Guidelines, dins la secció 2 «Performance». El text comença així: «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.» En resum: res d'amagat, d'adormit o de no documentat.
La continuació afecta cada enviament: «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.» Cada novetat s'ha de descriure amb precisió a les notes de revisió, i ha de ser accessible per al revisor. Per tant, «Correccions d'errors i millores» no n'hi ha prou.
El mateix paràgraf apunta al màrqueting enganyós: prometre un contingut o un servei que no existeix, o mostrar un preu fals, a l'App Store o a qualsevol altre lloc.
Aquesta part em va servir amb Nolera. Rellegint-ne la fitxa abans del llançament, hi vaig trobar dues frases impossibles de verificar: «interfície només en francès», que ja era falsa, i «el pack més triat», per a una app que mai s'havia publicat. Les notes per al revisor també descrivien un estat del producte desfasat. És exactament el que vol evitar aquesta part. La 2.3.10, en canvi, apunta sobretot a la fitxa.
Què vol dir el missatge de rebuig 2.3.1?
El rebuig es titula «Guideline 2.3.1 - Performance», de vegades seguit de «Hidden Features». Dos missatges publicats per desenvolupadors de React Native:
- Març del 2024, en un tiquet de GitHub de CodePush: «The app contains hidden features.», sense cap altra precisió. El desenvolupador demana aclariments i rep un complement en nom de la 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.» El tiquet no diu si l'app va passar després.
- Febrer del 2023, en un altre tiquet, Apple apunta al «CodePush-related remote code downloading/updating support» del binari.
La meva lectura: el revisor no veu les teves actualitzacions, veu el codi capaç de rebre'n. Aquests dos casos apunten a CodePush. No he trobat cap rebuig públic recent sobre EAS Update, cosa que no demostra res.
Actualitzacions a distància: què permeten la 2.5.2 i la llicència
La regla 2.5.2, que també tracto a la guia dels modes en segon pla, prohibeix que l'app pugui «download, install, or execute code which introduces or changes features or functionality of the app».
L'article 3.3.1(B) de l'Apple Developer Program License Agreement prohibeix el codi executable descarregat, però precisa: «Interpreted code may be downloaded to an Application». Amb tres condicions: aquest codi no canvia el propòsit principal de l'app, no se salta ni la signatura, ni el sandbox, ni les proteccions del sistema, i no crea una botiga d'altres apps.
El JavaScript d'una app Expo és codi interpretat: al meu entendre, EAS Update entra dins aquest marc. La seva documentació recorda que les actualitzacions segueixen les normes de l'App Store, i que «changes to your app's behavior need to be reviewed». Per a un error crític, Expo proposa la correcció a distància i després un nou enviament que la inclogui.
La meva línia: corregir i ajustar el que ja existeix, sí. Canviar el que l'app és o el que ven, no.
Què pots canviar a distància i què exigeix un build nou
La graella que aplico, treta de les pàgines d'Apple i d'Expo citades aquí. La fila «gratuït que passa a ser de pagament» i les dues últimes són interpretació meva.
| Canvi | Via | Per què |
|---|---|---|
| Error de JavaScript | Actualització a distància | Ús previst per Expo |
| Text, traducció, estil | Actualització a distància | Ús previst per Expo |
| Preu d'una subscripció | App Store Connect | Cap codi modificat |
| Text promocional | App Store Connect | Sense nou enviament |
| Compra d'un tipus ja validat | Revisió només de la compra | Regla d'App Store Connect |
| Primera compra d'un tipus | Versió nova | Regla d'App Store Connect |
| Funció nova | Versió nova | 2.3.1 i 2.5.2 |
| Gratuït que passa a ser de pagament | Versió nova | Fitxa i notes per revisar |
| Permís, Info.plist | Build nou | Fitxer del binari |
| Mòdul natiu, SDK d'Expo | Build nou | Codi natiu canviat |
| Interruptor que desactiva | Configuració remota | Tolerat si és temporal |
| Interruptor que revela | Prohibit | Funció mai revisada |
El text promocional es pot canviar «without requiring an updated submission», segons la pàgina d'Apple sobre la informació de la versió. La primera compra de cada tipus s'envia amb una versió nova, les següents soles, segons l'ajuda sobre l'enviament de compres. Expo inclou el codi natiu, els permisos i la versió de l'SDK entre el que demana un binari nou, com en el cas d'ITMS-90683. Un interruptor que desactiva una funció avariada no afegeix res de nou, sempre que no tregui el que els subscriptors han pagat.
Interruptors a distància sense rebuig
Un interruptor a distància, o feature flag, no està prohibit per si mateix: tot depèn del que amagui. Les meves regles:
- Tot el que un interruptor pot mostrar és present i activat per al revisor, i esmentat a les notes de revisió.
- Un test A/B compara dues variants que el revisor pot veure, mai una variant revisada i una d'inèdita.
- Cap codi detecta la revisió per comportar-se d'una altra manera. És la definició mateixa d'una funció oculta.
- Un paywall controlat a distància només mostra productes validats, i cada variant respecta la regla 3.1.2.
Mode demo i comptes de prova
La guideline 2.1 demana un compte de demostració si la teva app té inici de sessió, amb el servidor en marxa. Si obligacions legals o de seguretat t'impedeixen donar-ne un, un mode demo integrat el pot substituir, però només «with prior approval by Apple», i ha de mostrar totes les funcions. La pàgina d'Apple sobre la informació de la versió hi afegeix: el compte no caduca, i els comptes addicionals van a les notes, limitades a 4.000 bytes.
La relació amb la 2.3.1: un mode demo o un compte de prova que obre pantalles invisibles d'una altra manera s'ha de descriure. Un gest secret, un codi o un compte especial no indicat és una funció oculta. Anomena cada accés especial a les notes, amb el que obre.
La meva regla: cap actualització a distància durant una revisió
Per què tinc EAS Update a tot arreu: a Solys, el meu despertador, un error de JavaScript deixava l'app muda tan bon punt un efecte de so fallava una vegada. La correcció eren tres línies, però calia un build complet i una revisió per enviar-la. Des d'aleshores, totes les meves apps porten expo-updates des del primer build: és un mòdul natiu, i un binari compilat sense ell no rebrà mai res. La meva configuració, a app.json:
{
"expo": {
"runtimeVersion": { "policy": "fingerprint" },
"updates": { "fallbackToCacheTimeout": 0, "checkAutomatically": "ON_LOAD" }
}
}
Amb fingerprint, una actualització només arriba als binaris amb el codi natiu corresponent (versions d'execució). Però mentre una versió espera o passa la revisió, no publico res. Per dos motius.
- El revisor no veuria la correcció. Amb
fallbackToCacheTimeouta 0, una instal·lació nova arrenca amb el codi inclòs i aplica l'actualització a l'obertura següent (documentació d'expo-updates). El revisor instal·la, obre l'app una vegada i prova el binari. Nolera va ser rebutjada amb una correcció ja enviada a distància: ho explico a la guia de la 2.1. - El que prova el revisor ha de ser el que reben els usuaris. Canviar el comportament durant la revisió crea una diferència entre la versió vista i la versió entregada.
Unes notes de revisió precises
La 2.3.1 rebutja les descripcions genèriques. La plantilla que faria servir, en anglès:
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.
Com respondre a un rebuig 2.3.1?
Respon a App Store Connect, on pots respondre al missatge d'App Review.
- El missatge és vague: pregunta quina funció és la problemàtica, com el desenvolupador del tiquet del 2024.
- Una funció real està mal descrita: dona el camí exacte i un vídeo curt, i després completa les notes.
- Un interruptor revela una cosa inèdita: treu-lo, o activa'l i descriu-lo, i després torna a fer un build.
- El problema és el codi d'actualització: explica que serveix per a correccions, dins el marc de l'article 3.3.1(B). Al tiquet del 2023, Apple demanava treure'l.
La checklist 2.3.1 abans d'enviar
- Cada novetat de la versió està descrita a les notes, amb el seu camí.
- Cada interruptor a distància està activat per a la revisió i esmentat a les notes.
- Cap codi canvia de comportament per al revisor.
- Els accessos especials estan descrits: mode demo, compte de prova, gest.
- La fitxa i el paywall no prometen res que el build no faci.
- No es publica cap actualització a distància durant la revisió.
Revisa el teu expedient abans d'enviar-lo
El Review Kit reuneix la meva checklist abans d'enviar, plantilles de notes per al revisor i skills de Claude Code que revisen el teu projecte. Si vols una mirada humana, reserva una hora amb mi: revisem junts les teves notes de revisió i la configuració d'actualitzacions, per videotrucada. Tot el procés és a la pàgina app rebutjada per Apple.
Prepares el teu primer llançament? Fes el teu diagnòstic gratuït: posa les etapes en ordre i t'envia la meva checklist antirebuig d'Apple.
Preguntes freqüents
Què vol dir «Guideline 2.3.1 - Performance - Hidden Features»?
Apple considera que la teva app conté una funció oculta, latent o absent de les notes de revisió. El missatge també pot apuntar a un codi capaç de canviar l'app després de la revisió, de vegades amb un rebuig 2.5.2.
Apple permet EAS Update?
La llicència permet el codi interpretat descarregat sempre que no canviï el propòsit principal de l'app. Corregir, sí. Afegir una funció no revisada, no.
Es poden fer servir feature flags en una app iOS?
Sí, si tot el que poden mostrar s'ha revisat. Activa cada interruptor per a la revisió i descriu-lo a les notes.
Cal informar el revisor d'un mode demo?
Sí. Un mode demo integrat necessita l'aprovació prèvia d'Apple i ha de mostrar totes les funcions.
Es pot publicar una actualització a distància durant la revisió?
Res no ho prohibeix explícitament. Però el revisor no la veuria a la primera obertura, i crea una diferència amb la versió revisada. Jo sempre me n'abstinc.
