Andy Garcia · dev freelance
FRENES
Volver al blog
Apple y cumplimiento

Apple añadió dos reglas a App Review el 16 de octubre. La 2.5.19 puede costarte tu cuenta de desarrollador

19 de octubre de 2026 10 min de lectura

El 16 de octubre, Apple publicó una nueva versión de sus App Review Guidelines, que sustituye a la del 8 de junio. El registro de cambios tiene siete entradas. Dos son reglas nuevas: la 2.3.14, sobre recursos creativos, y la 2.5.19, sobre funciones ocultas. Las demás aclaran qué apps entran en la 1.2 sobre contenido generado por usuarios, reescriben la viñeta de enlaces externos de la 3.1.1(a), añaden a la sección 5 la retirada de la App Store y el bloqueo de la distribución alternativa, y añaden enlaces a documentación antes y después del envío.

Apple presentó la actualización en una publicación complementaria sobre imágenes íntimas no consentidas y apps «bait-and-switch»: apps que pasan la revisión siendo una cosa y se convierten en otra tras la aprobación. La misma publicación indica que el año pasado (2025) Apple impidió que más de 150.000 apps con problemas de seguridad llegaran a los clientes y dio de baja más de 193.000 cuentas de desarrollador por fraude y abuso. TechCrunch, el 19 de octubre, leyó la actualización como una prohibición de las apps de «nudificación» que se hacen pasar por apps normales para superar la revisión.

Ese es el objetivo. Pero yo publico apps de iOS como desarrollador independiente, y las mismas frases se aplican a un desarrollador solo con un feature flag igual que a una red de fraude. Así que leí lado a lado las versiones del 8 de junio y del 16 de octubre. Esto es lo que cambió, regla por regla.

2.5.19: una prohibición antigua, una dirección nueva, una frase nueva

La prohibición en sí no es nueva. Hasta el 16 de octubre, la guideline 2.3.1(a) empezaba así: «No incluyas ninguna función oculta, latente o no documentada en tu app; la funcionalidad de tu app debe ser clara para los usuarios y para App Review» (traducción mía). Esa frase ha desaparecido de la 2.3.1(a). Ahora abre la 2.5.19, palabra por palabra, seguida de una nueva: «Intentar ocultar funciones no documentadas en el binario de tu app, por ejemplo mediante la ofuscación del código u otros métodos, es motivo para retirar tu app de la App Store y dar de baja tu cuenta de desarrollador.»

Se movieron dos cosas. La regla salió de la sección 2.3, Accurate Metadata, y pasó a la sección 2.5, Software Requirements: una función oculta se archiva ahora bajo el binario, no bajo la ficha de la tienda. Y la regla lleva su propia frase de sanción, con la ofuscación citada como ejemplo.

Lee bien esa frase. No prohíbe la ofuscación, que tiene usos legítimos, entre ellos el anti-tamper. Prohíbe usar la ofuscación, o cualquier otra cosa, para ocultar funciones no documentadas. La palabra que importa es «no documentadas».

La sanción en sí tampoco es nueva. En el texto de junio, la frase siguiente de la 2.3.1(a) convertía el marketing engañoso en un motivo «similar» de retirada y de baja de la cuenta de desarrollador, y la 2.3.1(b), que se mantiene, dice que un comportamiento flagrante o reiterado es motivo de expulsión del Apple Developer Program. En julio, Apple dijo a 9to5Mac que ya había dado de baja las cuentas de desarrollador detrás de 25 apps del tipo que se describe más abajo. Lo que cambia es que la frase de baja apunta ahora directamente a las funciones ocultas, en el binario, con la ofuscación nombrada.

La publicación complementaria de Apple describe la conducta que busca: añadir funciones que no estaban incluidas en la versión de la app enviada a App Review. Ni la guideline ni la publicación mencionan los feature flags, la configuración remota o los tests A/B. Mi lectura es que el riesgo está en un solo patrón: una ruta en el binario que la revisión nunca ve, activada después desde un servidor. 9to5Mac informó en julio de más de 60 apps construidas así: se comportaban como sus capturas de pantalla en casi todas partes salvo en Brasil, y mostraban plataformas de apuestas al abrirlas desde una dirección IP brasileña. Las instrucciones de compilación que encontró 9to5Mac preveían un enrutamiento controlado a distancia hacia la app local, una página web dentro de la app o un sitio externo.

Las apps honestas también activan funciones por región, cohorte o fecha. La línea que traza la 2.5.19 es si App Review lo sabía. Lo que queda de la 2.3.1(a) sigue diciendo que todas las funciones nuevas, y los cambios de producto, deben describirse «con precisión» en las Notes for Review, que las descripciones genéricas serán rechazadas, y que deben ser accesibles para la revisión.

2.3.14: los recursos creativos no pueden citar un precio

Los recursos creativos son imágenes y vídeos que, según la guía de Apple sobre recursos, aparecen por toda la App Store en iOS 27 y iPadOS 27 y posteriores: la cabecera de la página de producto, los resultados de búsqueda y las ubicaciones cuando tu app es destacada. La nueva regla dice que deben referirse al contenido y la funcionalidad de tu app o a su marca en conjunto, y no deben incluir contenido inapropiado, referencias a otras apps con intención de engañar, afirmaciones sobre el producto que no se puedan verificar, ni «información de precios específica o con descuento».

La página de buenas prácticas de Apple añade su propia lista: sin URL de sitios web, sin símbolos de copyright, sin referencias a otras plataformas, sin reconocimientos de Apple como Editor's Choice o App of the Day. Los recursos deben cumplir una clasificación de edad 4+ aunque la app tenga una más alta, y los juegos con violencia pueden usar imágenes de acción, pero deben evitar la sangre explícita y las armas apuntando directamente a una persona o al público.

La misma página sugiere recursos creativos para ofertas de temporada. Así que la regla en la práctica: promociona la temporada, no el precio. Una cabecera de «50 % de descuento» es exactamente lo que excluye la 2.3.14. Amplía una línea que ya estaba en la 2.3.7, que mantiene los precios fuera de los nombres de apps, los subtítulos, las capturas y las previews. También desarrollo un juego de estrategia, Doomsday: M.A.D., y la línea sobre imágenes violentas es la que pondría al principio de cualquier brief para el arte de la tienda.

1.2: las apps de creación con IA ya tienen nombre

La versión de junio de la 1.2 empezaba así: «Las apps con contenido generado por usuarios plantean desafíos particulares» (traducción mía). La de octubre empieza: «Las apps que permiten a los usuarios crear, generar, subir, compartir o contribuir de cualquier otra forma con contenido», incluye las imágenes íntimas no consentidas entre los desafíos y nombra tres tipos de apps: redes sociales, plataformas de contenido generado por usuarios y apps de creación de contenido con IA. Esas apps deben incluir un filtro para material censurable, una forma de denunciar contenido ofensivo con respuestas oportunas, una forma de bloquear a usuarios abusivos y datos de contacto publicados.

Luego una frase nueva: los desarrolladores que no implementen salvaguardas adecuadas, o no corrijan las infracciones identificadas tras recibir el aviso, «pueden ser considerados en infracción del Developer Code of Conduct». Sigue la referencia a la 5.6: «Tu cuenta del Developer Program será dada de baja si realizas actividades o acciones que no se ajusten al Developer Code of Conduct.» La publicación de Apple dice que los requisitos de moderación cubren ahora explícitamente las imágenes íntimas no consentidas, incluidas las generadas con herramientas de IA, que las apps de contenido deben prevenir y retirar de forma proactiva.

A principios de este año escribí sobre cómo construir una app de fondos de pantalla con IA. Con la redacción del 16 de octubre, una app así es una app de creación de contenido con IA en los términos de la propia 1.2. El texto no dice cómo se aplica «bloquear a usuarios abusivos» cuando nadie más ve lo que generas. No esperaría a que un revisor lo aclare: un paso de moderación sobre el prompt y sobre el resultado, un botón de denuncia en cada imagen generada y una dirección de contacto que alguien lea de verdad.

3.1.1(a), sección 5 y las ediciones que el registro omitió

La 3.1.1(a) permitía a los desarrolladores con entitlement enlazar a «un sitio web del que el desarrollador es propietario o del que se responsabiliza». Ahora dice «un destino permitido», y la viñeta de StoreKit añade: «Los destinos aprobados pueden variar según la región.» El Music Streaming Services Entitlement queda integrado en esa viñeta, y los entitlements se limitan a storefronts concretos «y solo en ciertas plataformas de cada uno de esos storefronts». El storefront de Estados Unidos sigue sin exigir entitlement para botones y enlaces externos. No leería «destino permitido» como «cualquier URL»: comprueba qué permite tu entitlement en tu región. El entitlement de las apps de lectura de la 3.1.3(a) sigue diciendo «un sitio web del que el desarrollador es propietario o del que se responsabiliza».

La sección 5 se detenía en avisar a las autoridades sobre apps que facilitaran la trata de personas o la explotación de menores. Ahora añade que esas apps serán retiradas de la App Store y bloqueadas de la distribución alternativa.

El registro también omite una pasada editorial: cada «e.g.» del texto de junio, 35 en total, ha desaparecido, sustituido por «such as» o «for example», igual que el único «i.e.». Esa última edición toca el dinero. La 3.1.3(f), la exención para apps complementarias gratuitas e independientes de una herramienta web de pago, decía «(i.e. VoIP, Cloud Storage, Email Services, Web Hosting)». Ahora dice «una herramienta web de pago para VoIP, Cloud Storage, Email Services o Web Hosting». Estrictamente, «i.e.» ya significaba «es decir», pero un paréntesis así se lee fácilmente como ejemplos. La frase nueva no deja margen: cuatro categorías. Si construyes una app complementaria gratuita para el SaaS de un cliente fuera de esas cuatro, esa exención no es tu vía.

Qué comprobaría antes del próximo envío

Oriento mi trabajo con Claude Code, y esta es la clase de auditoría que le encargaría primero, para verificarla luego a mano.

  1. Lista cada flag remoto, kill switch, experimento y restricción por región que lee el binario. Para cada uno, anota si su función es visible en la build que se revisa. Todo lo que sale en dormante y se activa después va en las Notes for Review, con la forma de llegar a ello.
  2. Asegúrate de que los menús de depuración e internos se eliminan al compilar las builds de release, y no quedan escondidos tras un gesto.
  3. Si ofuscas, prepárate para explicar por qué, y asegúrate de que nada de lo que hay detrás esté sin documentar.
  4. Si envías actualizaciones de JavaScript por aire en una app React Native, contrasta cada actualización con la descripción de la publicación complementaria: funciones que no estaban en la versión enviada a revisión.
  5. Da instrucciones a quien haga el arte de tu tienda: sin precios, sin descuentos, sin URL, sin premios que no puedas demostrar, imágenes aptas para 4+.
  6. Si los usuarios pueden generar cualquier cosa, entrega el filtro, el botón de denuncia, el bloqueo y una dirección de contacto antes de que lo pida el revisor.

Apple dice que las traducciones llegarán en el plazo de un mes. Hasta entonces, lee la página en inglés.

Nada de esto frena una publicación honesta. «El revisor no lo vio» nunca fue un atajo seguro; desde el 16 de octubre, la regla dice por escrito que es una responsabilidad que pesa sobre la cuenta, y el lugar más barato para arreglarlo son las notas de revisión, antes de pulsar Submit.

Fuentes

¿Un proyecto del mismo estilo?

Diseño y despliego productos como este. Hablemos.

Hablemos