Guideline 2.3.1: funciones ocultas y actualizaciones OTA

La guideline 2.3.1 prohíbe las funciones ocultas, inactivas o no documentadas: todo lo que hace tu app debe ser visible para el usuario y para el revisor. Cada novedad se describe con precisión en las notas de revisión. Una actualización a distancia puede corregir lo que Apple vio, nunca agregar lo que Apple no vio.

Publico mis apps iOS con Expo, y cada una incluye EAS Update desde su primer build para entregar correcciones. Mi regla: ninguna actualización a distancia mientras una versión está en revisión. Esta guía se basa en el texto de Apple, su licencia, la documentación de Expo y rechazos publicados.

¿Qué dice la guideline 2.3.1?

La 2.3.1 abre el apartado 2.3 "Accurate Metadata" de las App Review Guidelines, en la sección 2 "Performance". El texto empieza así: "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 pocas palabras: nada oculto, dormido ni sin documentar.

Lo que sigue apunta a cada envío: "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 novedad debe describirse con precisión en las notas de revisión y ser accesible para el revisor. Así que "Corrección de errores y mejoras" no basta.

El mismo párrafo apunta al marketing engañoso: prometer un contenido o un servicio que no existe, o mostrar un precio falso, en el App Store o en otro lugar.

Esta parte me sirvió con Nolera. Al releer su ficha antes del lanzamiento, encontré dos frases imposibles de verificar: "interfaz solo en francés", que ya era falsa, y "el pack más elegido", para una app nunca publicada. Las notas para el revisor también describían un estado obsoleto del producto. Es justo lo que apunta esta parte. La 2.3.10, en cambio, apunta sobre todo a la ficha.

¿Qué significa el mensaje de rechazo 2.3.1?

El rechazo se titula "Guideline 2.3.1 - Performance", a veces seguido de "Hidden Features". Dos mensajes publicados por desarrolladores de React Native:

• Marzo de 2024, en un issue de GitHub de CodePush: "The app contains hidden features.", sin más detalle. El desarrollador pide aclaraciones y recibe un complemento bajo 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 issue no dice si la app fue aprobada después.
• Febrero de 2023, en otro issue, Apple señala el "CodePush-related remote code downloading/updating support" del binario.

Mi lectura: el revisor no ve tus actualizaciones, ve el código capaz de recibirlas. Estos dos casos apuntan a CodePush. No encontré ningún rechazo público reciente contra EAS Update, lo cual no prueba nada.

Actualizaciones a distancia: lo que permiten la 2.5.2 y la licencia

La regla 2.5.2, que también trato en la guía de los modos en segundo plano, prohíbe que la app pueda "download, install, or execute code which introduces or changes features or functionality of the app".

El artículo 3.3.1(B) del Apple Developer Program License Agreement prohíbe el código ejecutable descargado, pero precisa: "Interpreted code may be downloaded to an Application". Con tres condiciones: ese código no cambia el propósito principal de la app, no evade la firma, el sandbox ni las protecciones del sistema, y no crea una tienda de otras apps.

El JavaScript de una app Expo es código interpretado: en mi opinión, EAS Update entra en ese marco. Su documentación recuerda que las actualizaciones siguen las reglas del App Store, y que "changes to your app's behavior need to be reviewed". Para un bug crítico, Expo propone la corrección a distancia y luego un nuevo envío que la incluya.

Mi línea: corregir y ajustar lo que existe, sí. Cambiar lo que la app es o lo que vende, no.

Lo que puedes cambiar a distancia y lo que exige un nuevo build

La tabla que aplico, sacada de las páginas de Apple y de Expo citadas aquí. La fila "gratis que pasa a ser de pago" y las dos últimas son mi interpretación.

Cambio	Vía	Por qué
Bug de JavaScript	Actualización a distancia	Uso previsto por Expo
Texto, traducción, estilo	Actualización a distancia	Uso previsto por Expo
Precio de una suscripción	App Store Connect	No se modifica código
Texto promocional	App Store Connect	Sin nuevo envío
Compra de un tipo ya aprobado	Revisión solo de la compra	Regla de App Store Connect
Primera compra de un tipo	Nueva versión	Regla de App Store Connect
Nueva función	Nueva versión	2.3.1 y 2.5.2
Gratis que pasa a ser de pago	Nueva versión	Ficha y notas por revisar
Permiso, Info.plist	Nuevo build	Archivo del binario
Módulo nativo, SDK de Expo	Nuevo build	Código nativo modificado
Interruptor que desactiva	Configuración remota	Tolerado si es temporal
Interruptor que revela	Prohibido	Función nunca revisada

El texto promocional se cambia "without requiring an updated submission", según la página de Apple sobre la información de la versión. La primera compra de cada tipo se envía con una nueva versión, las siguientes por separado, según la ayuda sobre el envío de compras. Expo incluye el código nativo, los permisos y la versión del SDK entre lo que requiere un nuevo binario, como en el caso de ITMS-90683. Un interruptor que desactiva una función averiada no agrega nada nuevo, siempre que no quite lo que los suscriptores pagaron.

Interruptores a distancia sin rechazo

Un interruptor a distancia, o feature flag, no está prohibido en sí: todo depende de lo que oculta. Mis reglas:

• Todo lo que un interruptor puede mostrar está presente y activado para el revisor, y mencionado en las notas de revisión.
• Una prueba A/B compara dos variantes que el revisor puede ver, nunca una variante revisada y una inédita.
• Ningún código detecta la revisión para comportarse de otra forma. Es la definición misma de una función oculta.
• Un paywall controlado a distancia solo muestra productos aprobados, y cada variante respeta la regla 3.1.2.

Modo demo y cuentas de prueba

La guideline 2.1 exige una cuenta de demostración si tu app tiene inicio de sesión, con el servidor encendido. Si obligaciones legales o de seguridad te impiden dar una, un modo demo integrado puede reemplazarla, pero solo "with prior approval by Apple", y debe mostrar todas las funciones. La página de Apple sobre la información de la versión agrega: la cuenta no expira, y las cuentas adicionales van en las notas, limitadas a 4.000 bytes.

La relación con la 2.3.1: un modo demo o una cuenta de prueba que abre pantallas que de otro modo serían invisibles debe describirse. Un gesto secreto, un código o una cuenta especial sin declarar es una función oculta. Nombra cada acceso especial en las notas, con lo que abre.

Mi regla: ninguna actualización a distancia durante una revisión

Por qué uso EAS Update en todas mis apps: en Solys, mi despertador, un bug de JavaScript dejaba la app muda en cuanto un efecto de sonido fallaba una sola vez. La corrección eran tres líneas, pero hacía falta un build completo y una revisión para entregarla. Desde entonces, todas mis apps incluyen expo-updates desde su primer build: es un módulo nativo, y un binario compilado sin él nunca recibirá nada. Mi configuración, en app.json:

{
  "expo": {
    "runtimeVersion": { "policy": "fingerprint" },
    "updates": { "fallbackToCacheTimeout": 0, "checkAutomatically": "ON_LOAD" }
  }
}

Con fingerprint, una actualización solo llega a los binarios cuyo código nativo coincide (versiones de runtime). Pero mientras una versión espera o pasa la revisión, no publico nada. Por dos razones.

1. El revisor no vería la corrección. Con fallbackToCacheTimeout en 0, una instalación nueva arranca con el código incluido y aplica la actualización en el siguiente inicio (documentación de expo-updates). El revisor instala, abre la app una vez y prueba el binario. Nolera fue rechazada con una corrección ya entregada a distancia: lo cuento en la guía de la 2.1.
2. Lo que prueba el revisor debe seguir siendo lo que reciben los usuarios. Cambiar el comportamiento durante la revisión crea una diferencia entre la versión revisada y la versión entregada.

Notas de revisión precisas

La 2.3.1 rechaza las descripciones genéricas. La plantilla que usaría, en inglé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.

¿Cómo responder a un rechazo 2.3.1?

Responde en App Store Connect, donde puedes responder al mensaje de App Review.

• El mensaje es vago: pregunta qué función señalan, como el desarrollador del issue de 2024.
• Una función real está mal descrita: da la ruta exacta y un video corto, y luego completa las notas.
• Un interruptor revela algo inédito: quítalo, o actívalo y descríbelo, y luego haz un nuevo build.
• El problema es el código de actualización: explica que sirve para correcciones, dentro del marco del artículo 3.3.1(B). En el issue de 2023, Apple pedía quitarlo.

La checklist 2.3.1 antes del envío

• Cada novedad de la versión está descrita en las notas, con su ruta.
• Cada interruptor a distancia está activado para la revisión y mencionado en las notas.
• Ningún código cambia de comportamiento para el revisor.
• Los accesos especiales están descritos: modo demo, cuenta de prueba, gesto.
• La ficha y el paywall no prometen nada que el build no haga.
• No se publica ninguna actualización a distancia durante la revisión.

Revisa tu expediente antes del envío

El Review Kit reúne mi checklist previa al envío, plantillas de notas para el revisor y skills de Claude Code que revisan tu proyecto. Si quieres una mirada humana, reserva una hora conmigo: revisamos juntos tus notas de revisión y tu configuración de actualizaciones, por videollamada. El proceso completo está en la página app rechazada por Apple.

¿Preparas tu primer lanzamiento? Haz tu diagnóstico gratuito: pone los pasos en orden y te envía mi checklist contra los rechazos de Apple.

Preguntas frecuentes

¿Qué significa "Guideline 2.3.1 - Performance - Hidden Features"?

Apple considera que tu app contiene una función oculta, inactiva o ausente de las notas de revisión. El mensaje también puede apuntar a un código capaz de cambiar la app después de la revisión, a veces junto con un rechazo 2.5.2.

¿Apple permite EAS Update?

La licencia permite el código interpretado descargado mientras no cambie el propósito principal de la app. Corregir, sí. Agregar una función no revisada, no.

¿Se pueden usar feature flags en una app iOS?

Sí, si todo lo que pueden mostrar fue revisado. Activa cada interruptor para la revisión y descríbelo en las notas.

¿Hay que informar al revisor de un modo demo?

Sí. Un modo demo integrado requiere la aprobación previa de Apple y debe mostrar todas las funciones.

¿Se puede publicar una actualización a distancia durante la revisión?

Nada lo prohíbe de forma explícita. Pero el revisor no la vería en el primer inicio, y crea una diferencia con la versión revisada. Yo siempre me abstengo.