Cambios de octubre de 2026 en las App Review Guidelines: qué implican 1.2, 2.3.14, 2.5.19 y 3.1.1(a)

Los cambios de octubre de 2026 en las App Review Guidelines se anunciaron en la publicación de Apple Updated App Review Guidelines are now available del 16 de octubre de 2026. Hay dos directrices nuevas (2.3.14 y 2.5.19), tres pasajes reformulados (1.2, 3.1.1(a) y sección 5), y las secciones Before You Submit y After You Submit incorporan enlaces a más documentación. A continuación explicamos cada cambio en lenguaje claro, quién tiene que actuar y una checklist para tu próximo envío.

¿Qué cambió en las App Review Guidelines el 16 de octubre de 2026?

Apple añadió la directriz 2.3.14 para los recursos creativos y la directriz 2.5.19 para las funciones ocultas. También aclaró la 1.2 (contenido generado por usuarios), la 3.1.1(a) (enlaces de compra externa) y la sección 5 (Legal). El registro de cambios de Apple recoge las modificaciones así:

Apple indica que las traducciones "estarán disponibles en el sitio web de Apple Developer en el plazo de un mes". En octubre de 2026, consulta las App Review Guidelines en inglés siempre que una versión traducida no coincida con ellas.

¿Qué exige la nueva directriz 2.5.19 sobre funciones ocultas?

La directriz 2.5.19 exige que todas las funciones de tu binario sean visibles y estén documentadas tanto para los usuarios como para App Review. Ocultar funcionalidades, incluso mediante ofuscación, puede provocar la retirada de la app y la cancelación de la cuenta de desarrollador.

El texto exacto: "No incluyas en tu app funciones ocultas, latentes o no documentadas; la funcionalidad de tu app debe ser clara para los usuarios finales y para App Review. Intentar ocultar funciones no documentadas en el binario de tu app, por ejemplo mediante ofuscación de código u otros métodos, es motivo de retirada de tu app del App Store y de cancelación de tu cuenta de desarrollador." Apple describe esta política como de larga data, pero antes estaba en la 2.3.1. La 2.3.1(a) actual sigue exigiendo que las funciones nuevas se "describan de forma específica en la sección Notas para la revisión (Notes for Review)". Ahora los rechazos por funciones ocultas deberían citar la 2.5.19.

En la práctica, enumera en tus notas de revisión todas las funciones que pueda activar un interruptor en el servidor, un código de invitación, un escaneo de QR, una región o un nivel de cuenta. Si un flag va a activar una función después de la aprobación, actívala en la build revisada o deja ese código fuera hasta la versión que la lance.

¿Qué apps se ven afectadas por los cambios en la directriz 1.2?

La directriz 1.2 cubre ahora cualquier app que permita a los usuarios "crear, generar, subir, compartir o contribuir contenido de cualquier otra forma", y menciona expresamente las redes sociales, las plataformas de contenido generado por usuarios y las apps de creación de contenido con IA. Estas apps deben filtrar el material inapropiado, ofrecer un sistema de denuncias con respuestas oportunas, permitir bloquear a usuarios abusivos y publicar información de contacto.

El texto revisado incluye las "imágenes íntimas no consentidas" junto a la infracción de propiedad intelectual y el acoso. Y añade: "Los desarrolladores que no implementen las salvaguardas adecuadas o que no corrijan las infracciones identificadas tras recibir aviso podrán considerarse en infracción del Developer Code of Conduct." Aunque una app de imágenes o avatares con IA solo genere contenido para el propio usuario, ahora puede quedar incluida. El filtrado de prompts y resultados, las denuncias y los datos de contacto publicados tienen que estar en la build que envías, no en un roadmap.

¿Qué dice la directriz 2.3.14 sobre los recursos creativos?

La directriz 2.3.14 establece que los recursos creativos deben estar relacionados con el contenido, la funcionalidad o la marca de tu app, cumplir las reglas habituales de metadatos y ser aptos para todos los públicos. Prohíbe el contenido inapropiado, las referencias engañosas a otras apps, las afirmaciones no verificables y la "información de precios concretos o con descuento".

Los recursos creativos son los recursos de imagen y vídeo que Apple presentó el 5 de octubre de 2026. Según las App Store asset best practices de Apple, aparecen "en iOS 27 y iPadOS 27 y posteriores, incluida tu página de producto, en los resultados de búsqueda y cuando tu app aparece destacada". Esa misma página va más allá que la directriz. Recomienda no incluir URL de sitios web, símbolos de copyright, logotipos de otras plataformas ni reconocimientos de Apple como "Editor's Choice". También indica que los recursos "deben cumplir una clasificación por edad de 4+, aunque la clasificación de tu app sea superior". Una cabecera que diga "50 % de descuento esta semana" o "La app de presupuestos n.º 1" incumple la 2.3.14.

¿Qué cambió en la directriz 3.1.1(a) sobre enlaces de compra externa?

La directriz 3.1.1(a) ya no tiene un apartado separado para el Music Streaming Services Entitlement. Ese entitlement está ahora dentro del apartado de StoreKit External Purchase Link Entitlements, y el texto indica que los enlaces pueden llevar a "un destino permitido". Los destinos aprobados pueden variar según la región.

Esta actualización no cambia las reglas sobre dónde se permiten los enlaces. Los entitlements siguen limitados a storefronts concretos. El storefront de Estados Unidos sigue siendo la excepción en la que se permiten botones, enlaces externos y otras llamadas a la acción sin entitlement. Si ya usas alguno de los dos entitlements, comprueba que tu enlace sigue llevando a un destino permitido en cada storefront en el que publicas.

¿Cómo resuelven los desarrolladores en la práctica los rechazos por funciones ocultas y por contenido generado por usuarios?

Los casos publicados muestran que los rechazos bajo la antigua redacción de la 2.3.1 sobre funciones ocultas y bajo la 1.2 se resolvían normalmente haciendo que cada función y cada salvaguarda fueran fáciles de encontrar para el revisor, o apelando. Los cambios de código por sí solos rara vez los solucionaban.

• En marzo de 2026, un desarrollador contó en los Apple Developer Forums que una app nativa de alarmas sociales había sido rechazada por "Guideline 2.3.1(a) - Hidden Features" y por la 4.2. Explicó que solo usaba WebViews para la política de privacidad, los términos y las preguntas frecuentes, y apeló. App Review respondió que el App Review Board ya había contestado. El desarrollador pidió entonces qué pantallas concretas estaban implicadas, y no se publicó ninguna solución.
• En una issue de Flutter en GitHub, a varios desarrolladores con apps sencillas se les dijo "We discovered that your app contains hidden features". Un colaborador de Flutter calificó el framework de "pista falsa" y apuntó a APIs no documentadas en el código de la app o en los plugins. Dos desarrolladores informaron de que fueron aprobados tras apelar, sin cambiar su código.
• Un desarrollador en los Apple Developer Forums fue rechazado por la 1.2 pese a tener EULA, filtrado, denuncias y bloqueo. Se le pidió aceptar unos términos con "tolerancia cero hacia el contenido inapropiado" y "actuar sobre las denuncias de contenido inapropiado en un plazo de 24 horas". Un segundo rechazo añadió una clasificación por edad de 18+, la retirada inmediata de publicaciones e información de contacto dentro de la app. Respondió documentando cada salvaguarda y facilitando credenciales de administrador en las notas de revisión.

Conclusión: en los tres casos, los revisores no podían ver ni verificar funciones que los desarrolladores daban por evidentes. Con la 2.5.19 y una 1.2 más estricta, las notas de revisión y la cuenta demo pesan tanto como el código. Nuestra guía de cuentas demo para la revisión del App Store explica cómo configurarlas.

¿Qué deberías revisar antes de tu próximo envío?

Antes de tu próxima build, contrasta los feature flags, las salvaguardas de contenido generado por usuarios, los recursos creativos y los enlaces externos con el nuevo texto, y después redacta notas de revisión que señalen cada uno. Esta checklist cubre los cambios de octubre de 2026.

1. Enumera todos los flags controlados desde el servidor, las claves de configuración remota y los menús ocultos. Activa cada uno para el revisor o elimina el código que controla.
2. Describe cada función nueva de forma específica en Notas para la revisión, como exige la 2.3.1(a), incluido cómo acceder a todo lo que esté detrás de invitaciones, escaneos o niveles de pago.
3. Si los usuarios pueden publicar, chatear o generar contenido, confirma que el filtrado, las denuncias, el bloqueo y la información de contacto publicada están todos en la build, y documenta tu proceso para actuar sobre las denuncias.
4. Para la generación de imágenes o vídeo con IA, añade filtros de prompts y resultados que bloqueen imágenes sexuales de personas reales, y ofrece a los usuarios una forma de denunciar los resultados.
5. Revisa cada recurso creativo en busca de precios, descuentos, URL, afirmaciones sobre premios, logotipos de otras plataformas y cualquier cosa que supere la clasificación 4+.
6. Si usas un entitlement de enlace de compra externa o de streaming de música, confirma que el enlace lleva a un destino permitido en cada storefront.
7. Vuelve a leer en inglés las secciones de las directrices de las que dependas, porque las traducciones pueden tardar hasta un mes.

Ejemplo práctico: imagina una app de avatares con IA que tiene una galería pública y un paquete de estilos "Pro" que se activa por configuración remota después del lanzamiento. Con el nuevo texto, necesita moderación y denuncias en la galería (1.2). El paquete Pro debe ser visible en la build revisada o reservarse para una versión posterior (2.5.19). Su recurso de cabecera para iOS 27 no puede decir "Pro ahora con un 40 % de descuento" (2.3.14). Si ya estás lidiando con un rechazo, nuestra guía para resolver rechazos directriz por directriz explica cómo responder en App Store Connect. Si quieres una segunda opinión antes de enviar, consulta nuestros servicios.