Cuánto cuesta a los equipos la revisión de la App Store

Mostrando las 114 historias.

1. 

   4.3(a) Spam iOS Directriz 4.3

   Un portafolio entero marcado de golpe

   Qué sucedió

   Un desarrollador con varias apps creadas a partir del mismo proyecto inicial recibió el aviso 4.3 idéntico en cada una de ellas: las apps compartían un binario, metadatos o concepto similares con solo diferencias mínimas. Decidió revisar las apps una por una.

   Resolución

   Aún en proceso al momento de publicar.

   Lección

   4.3(a) también cubre el solapamiento entre tus propias apps. Si varias apps derivan de una misma plantilla, cada una necesita un núcleo realmente distinto, no solo un icono y un nombre nuevos.

2. 

   4.3(a) Spam iOS Directriz 4.3

   La misma carta dos veces en una semana

   Qué sucedió

   Una app auxiliar de fotografía pequeña y de un solo propósito fue rechazada por la 4.3(a) en plena madrugada, una semana después de recibir exactamente el mismo texto de rechazo para una build anterior.

   Resolución

   No especificado.

   Lección

   Reenviar con cambios cosméticos rara vez cambia un rechazo por la regla 4.3. Cambia el concepto o explica claramente en las notas de revisión qué hace diferente a tu app.

3. 

   4.3 Diseño / Spam iOS Directriz 4.3

   Desarrollando en una categoría saturada

   Qué sucedió

   Un desarrollador en solitario que documentaba un reto de builds diarios recibió un rechazo por la 4.3 Design / Spam el cuarto día y empezó a cuestionarse si haber elegido una categoría saturada había sido un error.

   Resolución

   No especificado.

   Lección

   Las categorías que Apple considera saturadas reciben más escrutinio. Valida qué hace única a tu app antes de buildear, no después de la revisión.

5. 

   2.1 Información necesaria iOS Directriz 2.1

   Siete preguntas para una cuenta nueva

   Qué sucedió

   El primer envío de un equipo volvió con un rechazo bajo 2.1 Información necesaria: siete preguntas, una solicitud de grabación de pantalla y una cuenta demo. Responder con sinceridad sacó a la luz cuatro cosas que se les habían pasado por alto.

   Resolución

   Corrigieron los problemas y respondieron.

   Lección

   Las cuentas de desarrollador nuevas deberían esperar esto. Prepara una cuenta demo, una grabación y notas de revisión claras antes de enviar.

6. 

   2.1 Integridad de la app iOS Directriz 2.1

   El revisor no pudo entender la app

   Qué sucedió

   Un desarrollador primerizo fue rechazado dos veces antes de publicar. El primer rechazo, bajo la norma 2.1, se debió a que el revisor no lograba entender cómo debía usarse la app.

   Resolución

   Aprobada tras añadir un video demo grabado en un dispositivo real y notas de revisión paso a paso.

   Lección

   Los revisores tienen minutos, no contexto. Diles exactamente qué tocar y qué deberían ver.

7. 

   Configuración de metadatos y compras in-app iOS Metadatos e IAP

   Dos rechazos por checkboxes que ya conocía

   Qué sucedió

   Un desarrollador indie fue rechazado dos veces por cosas que ya conocía. Primero, el build se envió sin sus compras in-app vinculadas y la descripción no enlazaba los términos de uso. Semanas después, una captura de pantalla describía la app como gratuita.

   Resolución

   Corregido y reenviado cada vez.

   Lección

   Ten una checklist previa al envío para metadatos, suscripciones y enlaces legales. La mayoría de los rechazos de metadatos se pueden evitar.

8. 

   Tiempos de la cola de revisión iOS Revisión interminable

   9 días de espera, luego 8 en revisión

   Qué sucedió

   Un desarrollador esperó nueve días para que el estado pasara de «En espera de revisión» a «En revisión», y luego estuvo ocho días más en revisión sin novedades.

   Resolución

   Ninguno al momento de la publicación.

   Lección

   Los tiempos de revisión no están garantizados. Nunca vincules una fecha de lanzamiento, prensa o campaña de creadores a una fecha de aprobación prevista.

9. 

   Tiempos de la cola de revisión iOS Revisión interminable

   20 días en el bucle de rechazo, fix y espera

   Qué sucedió

   Durante más de 20 días, un desarrollador pasó por rechazo, fix, Waiting for Review, rechazo, fix, y seguía esperando cuando se publicó.

   Resolución

   Pendiente.

   Lección

   Cada ida y vuelta puede costar días. Agrupa todos los fixes de una nota de rechazo en un solo build.

10. 

    Terminación de cuenta iOS Terminación de cuenta

    Cerrada antes de la primera revisión

    Qué sucedió

    Un desarrollador con diez años de experiencia vio cómo le terminaban la cuenta de desarrollador, con una acusación de fraude que no decía qué había hecho, mientras un juego para aprender idiomas seguía esperando su primera revisión. Sus apps existentes desaparecieron y los clientes empezaron a preguntar por qué.

    Resolución

    Ninguno reportado.

    Lección

    La terminación de una cuenta elimina todas tus apps a la vez. Mantén tu propio canal con los usuarios (email, web) para poder contactarlos si la tienda desaparece.

11. 

    Aviso de terminación de cuenta iOS Terminación de cuenta

    Demasiadas versiones rechazadas

    Qué sucedió

    Un desarrollador indie muy prolífico recibió un aviso de que su cuenta se cancelaría en diez días. Apple señaló que el número de versiones rechazadas era parte de la razón. Tras la atención pública y una apelación, la cuenta no se canceló.

    Resolución

    La cuenta se mantuvo tras la apelación.

    Lección

    Las rechazos se acumulan. Evita volver a enviar cambios mínimos el mismo día o subir clones casi idénticos de tus propias apps.

12. 

    Requisito de login (sin número de directriz) iOS Requisito de login

    Registro obligatorio: no eres una app tan grande

    Qué sucedió

    La app social de un desarrollador fue rechazada porque exigía crear una cuenta antes de acceder al feed principal. Cuando el desarrollador explicó que cada usuario necesita un handle para que la app funcione y citó a una gran red social de fotos que hace lo mismo, el revisor respondió, básicamente, que su app no era esa red social.

    Resolución

    No especificado.

    Lección

    Lo que las apps grandes se permiten no es un precedente que puedas citar. Si exiges registro, explica en las notas de revisión por qué la función principal no puede funcionar sin una cuenta y considera dejar que revisores o invitados vean algo de contenido antes.

13. 

    4.3 Spam iOS Directriz 4.3

    De cero revisiones a casi todo rechazado

    Qué sucedió

    Un desarrollador pasó días sin que se revisara ninguna de sus apps. Durante aproximadamente una semana, mientras esperaba, creó más envíos. Cuando la revisión por fin avanzó, casi todos volvieron rechazados por la directriz 4.3 sobre spam.

    Resolución

    No especificado.

    Lección

    Una cola atascada no es señal para enviar más. Acumular envíos mientras no se revisa nada puede hacer que tu cuenta parezca un patrón de spam cuando un revisor por fin los vea todos juntos.

14. 

    4.3 Spam iOS Directriz 4.3

    Apps no relacionadas rechazadas juntas

    Qué sucedió

    Un desarrollador tenía varias apps, creadas durante meses y sin relación entre sí, que fueron rechazadas como spam al mismo tiempo. Preguntó públicamente si esto era normal.

    Resolución

    No especificado.

    Lección

    El error 4.3 puede aplicarse a nivel de cuenta, no app por app. Si se rechazan varias apps a la vez, responde a cada una por separado y detalla en las notas de revisión qué hace que cada app sea distinta.

15. 

    Tiempos de la cola de revisión iOS Revisión interminable

    Un rechazo y dos meses de silencio

    Qué sucedió

    Tras un solo rechazo, la app de un desarrollador estuvo en revisión unos dos meses, y cada ciclo de revisión duraba aproximadamente un mes. Sospechaba que los ciclos largos se habían convertido en una forma de dejar fuera a las nuevas apps.

    Resolución

    Sigue bloqueada al momento de publicar.

    Lección

    Tras un rechazo, el siguiente ciclo puede ser mucho más lento que el primero. Asegúrate de que tu reenvío esté completo y bien documentado para no perder otro mes en una segunda vuelta.

16. 

    Contenido inapropiado iOS Contenido inapropiado

    Rechazado por reenviar sin corregir

    Qué sucedió

    Una app de edición de fotos con IA fue rechazada porque se reenvió varias veces sin corregir el problema que Apple señaló: contenido inapropiado.

    Resolución

    Rechazado.

    Lección

    Reenviar el mismo build esperando un revisor distinto puede perjudicarte. Corrige el error señalado o pide aclaraciones en el Resolution Center antes de volver a enviarlo. Para funciones de IA generativa, añade filtros para el contenido que Apple considere inapropiado.

17. 

    4.3 Spam iOS Directriz 4.3

    Rechazado al instante de iniciar la revisión

    Qué sucedió

    Un desarrollador pasó semanas creando una app y fue rechazada por 4.3 Spam en el mismo minuto en que entró en revisión. Creía que el revisor había juzgado el nicho, no la app.

    Resolución

    No especificado.

    Lección

    En nichos saturados, un 4.3 rápido puede llegar antes de que alguien mire de cerca. Abre tus notas de revisión con lo que hace única a tu app y señálaselo directamente al revisor.

18. 

    4.2.6 Plantilla iOS Directriz 4.2.6

    Marcado por una plantilla que nunca se usó

    Qué sucedió

    Un equipo fue rechazado bajo la directriz 4.2.6, que cubre las apps creadas a partir de una plantilla comercializada o un servicio de generación de apps, aunque no usaron ninguna plantilla ni servicio de generación.

    Resolución

    No especificado.

    Lección

    La 4.2.6 puede dar un falso positivo. Responde en el Resolution Center indicando claramente que la app está hecha a medida y quién la construyó, y ofrece mostrar el código fuente o el historial de desarrollo.

19. 

    3.1.2 Suscripciones iOS Directriz 3.1.2

    El precio mensual era mayor que el precio facturado.

    Qué sucedió

    El paywall de un desarrollador fue rechazado porque mostraba el precio mensual calculado de una suscripción de mayor duración de forma más prominente que el monto realmente facturado. El mismo paywall había pasado revisiones anteriores sin comentarios. Estaban de acuerdo con la regla, pero les frustró que se señalara solo ahora, así que rediseñaron el paywall para que el monto facturado apareciera primero.

    Resolución

    Reenviado con el nuevo diseño.

    Lección

    Un paywall que pasó antes puede ser rechazado después. Haz que el monto y el periodo facturados sean siempre la información de precio más destacada; muestra cualquier desglose mensual más pequeño y como información secundaria.

20. 

    Inscripción (no es una guía de App Review) Programa de desarrolladores de Apple Registro y cuenta

    Dos meses, y luego una negativa sin motivo

    Qué sucedió

    Un desarrollador pasó más de dos meses intentando inscribirse, con múltiples llamadas y correos al soporte, verificación de identidad, datos del dispositivo e incluso pruebas en video. Apple rechazó la inscripción sin dar un motivo concreto.

    Resolución

    Ninguno al momento de la publicación.

    Lección

    La inscripción puede tardar mucho más que desarrollar la app. Empieza la inscripción pronto, antes de que tu plan de lanzamiento dependa de ella, y guarda un registro de cada comunicación con soporte.

21. 

    5.1.2 Uso y compartición de datos iOS Directriz 5.1.2

    Un rechazo por App Tracking Transparency que amenazó a una startup

    Qué sucedió

    Tras unos meses de lanzamientos rápidos y buen feedback de los usuarios, la app de una startup fue rechazada a finales de otoño por la App Tracking Transparency, la regla de privacidad de iOS que exige permiso del usuario antes de rastrearlo entre apps y webs. El fundador lo describió después como un rechazo que puso en riesgo a toda la empresa.

    Resolución

    No se menciona en el post.

    Lección

    Audita cada SDK de tu app en busca de tracking antes de enviar la versión. Si algo vincula los datos del usuario con datos de otras empresas, necesitas el prompt de permiso de tracking y las etiquetas de privacidad correspondientes, aunque el tracking provenga de una librería de terceros.

22. 

    Login (número de directriz no especificado) iOS Login

    El revisor no pudo iniciar sesión con Apple o Google

    Qué sucedió

    Para evitar registros de bots, un desarrollador eliminó el inicio de sesión por correo y contraseña, dejando solo Sign in with Apple y Google sign in. Funcionaba en su propio iPhone y iPad, e incluso para el revisor anterior, que había rechazado la app por otra razón. El siguiente revisor la rechazó porque no podía iniciar sesión.

    Resolución

    No especificado.

    Lección

    Si tu app solo ofrece social login, los revisores pueden quedarse atascados. Indica en las notas de revisión una vía funcional, como una cuenta demo o un login solo para revisión, y prueba el inicio de sesión en un dispositivo y cuenta nuevos antes de cada envío.

23. 

    Apuestas simuladas (sin número de directriz) iOS Apuestas simuladas

    Una función de staking dentro del juego en una cuenta individual

    Qué sucedió

    Un juego fue rechazado por incluir apuestas simuladas: los jugadores podían apostar objetos del juego entre sí, una mecánica habitual en los RPG online clásicos. Como el desarrollador publicó con una cuenta individual en lugar de una empresa, decidió retirar la función por ahora.

    Resolución

    Eliminar la función y volver a enviar.

    Lección

    Las mecánicas tipo apuesta reciben más escrutinio incluso sin dinero real, y parte de lo que Apple permite depende de tu tipo de cuenta y de tu documentación. Revisa las normas sobre apuestas antes de implementar funciones de staking, loot o apuestas, y elige el tipo de cuenta de desarrollador en consecuencia.

24. 

    Documentos falsos (sin número de directriz) iOS Documentos falsos

    Un editor de PDF culpado por lo que los usuarios podrían hacer

    Qué sucedió

    Rechazaron una app de edición de PDF porque Apple dijo que permitía a los usuarios crear identificaciones y documentos falsos. El desarrollador argumentó que, con esa misma lógica, cualquier app bancaria o de mensajería podría ser rechazada por lo que actores malintencionados hicieran con ella.

    Resolución

    No especificado.

    Lección

    Las herramientas de propósito general pueden ser juzgadas por su peor uso posible. Evita plantillas o marketing que parezcan identificaciones o certificados oficiales, y explica en las notas de revisión para qué sirve la app y qué no admite.

25. 

    Compartir datos con IA (sin número de directriz) iOS Compartir datos con IA

    Sin pantalla de consentimiento para compartir datos con IA de terceros

    Qué sucedió

    Un equipo recibió su primer rechazo por compartir datos de usuarios con un proveedor de IA externo. Apple exigió el permiso explícito de los usuarios y una divulgación clara de qué datos se envían y a qué proveedor de IA. La preocupación del equipo era crear una pantalla de consentimiento que pasara la revisión sin afectar la conversión.

    Resolución

    En progreso.

    Lección

    Si tu app envía contenido de usuario a un servicio de IA externo, pide consentimiento antes de la primera petición e indica el proveedor y los datos involucrados. Implementa esa pantalla antes del envío, no después del rechazo.

26. 

    Entitlement de Family Controls (sin número de guideline claro) iOS Metadatos e IAP

    Cinco rechazos por una casilla sin marcar

    Qué sucedió

    Un desarrollador que publicaba una app tipo Screen Time recibió cinco rechazos. Las notas de revisión eran tan vagas que le hicieron pensar que el problema era el diseño. La causa real era un solo ajuste de Family Controls sin marcar en su configuración de desarrollador. Al marcarlo, la app fue aprobada.

    Resolución

    Aprobada tras habilitar el ajuste de Family Controls y volver a enviarla.

    Lección

    Si las notas de rechazo son vagas, audita tus entitlements y certificados antes de rediseñar el producto. Las apps de Screen Time y Family Controls necesitan la capability correspondiente activada en el portal de desarrolladores, no solo en Xcode.

27. 

    Directriz 5.1.1(v) iOS Directriz 5.1.1 Requisito de login

    Se requiere una cuenta para una función de pago que se ejecuta en el dispositivo

    Qué sucedió

    A un desarrollador que venía de apps web le rechazaron la app por la directriz 5.1.1(v). En la web, siempre vinculaban las compras a una cuenta. En iOS, Apple es el dueño de la compra, así que los compradores pueden pagar sin registrarse. Su plan de pago desbloqueaba filtros en el dispositivo que solo se ejecutaban en el teléfono, pero tanto desbloquear ese plan como Restaurar compras seguían obligando a crear una cuenta primero.

    Resolución

    Reestructurando para que una compra hecha sin cuenta siga vinculada a su dueño tras un registro opcional. En curso al momento de publicar.

    Lección

    Si una función de pago se ejecuta en el dispositivo y no necesita una identidad de servidor, permite comprarla y restaurarla sin cuenta. Reserva el registro solo para las funciones que de verdad lo necesiten, como el backup en la nube.

28. 

    Directriz 1.4.2 Daño físico iOS Directriz 1.4.2

    Apps de cálculo de dosis Live sacadas por una oleada de restricciones

    Qué sucedió

    Un desarrollador se despertó y descubrió que dos de sus apps habían sido marcadas bajo la directriz 1.4.2, aunque ninguna estaba en revisión. Ambas ya estaban en vivo: una calculadora de dosis de péptidos independiente y un rastreador con la misma calculadora integrada, que juntas se habían convertido en su primer éxito real de ingresos. Otros desarrolladores del mismo nicho informaron la misma notificación al mismo tiempo. Decía que las apps que calculan dosis de medicamentos, incluidas las de dosis y reconstitución de péptidos, deben ser publicadas por el fabricante del fármaco o una institución reconocida, como un hospital, aseguradora, farmacia o universidad.

    Resolución

    Ninguna. El desarrollador dijo que entendía la preocupación de seguridad y lo consideró el final de esas apps.

    Lección

    La aprobación no es permanente. Apple puede reevaluar una app ya publicada cuando endurece una regla. Si tu app calcula dosis o da orientación de salud que podría perjudicar a alguien, lee la directriz 1.4 antes de desarrollarla y planea publicar a través de una institución cualificada o deja fuera el cálculo.

29. 

    Directrices 4.3 Spam y 4.2.6 Servicios de generación de apps iOS Directriz 4.3 Directriz 4.2.6

    Una app de ticketing offline llamada spam, otra vez

    Qué sucedió

    Un desarrollador creó una app pequeña que convierte una hoja de cálculo en un sistema de ticketing y check-in que funciona totalmente offline, sin cuenta ni suscripción. Ya había gestionado el acceso en un evento local con cientos de asistentes durante el verano. Apple la rechazó de nuevo con una notificación combinada de las reglas 4.3 y 4.2.6, alegando que podría duplicar apps ya existentes en la tienda, ser una variante oportunista de una categoría saturada o provenir de una plantilla o servicio de generación de apps. El desarrollador afirmó que no conocía ninguna otra app que hiciera lo mismo, y la versión de Android llevaba una semana publicada.

    Resolución

    Sigue rechazada al momento de publicar. El desarrollador comentó que, de todos modos, no intentaba ganar dinero con la App Store.

    Lección

    Un revisor de la regla 4.3 ve tu ficha y unos minutos de la app, no a tus usuarios reales. Si la app es genuinamente distinta, explica exactamente cómo en las notas de revisión y en las primeras capturas, menciona su uso en el mundo real y deja claro que no usaste una plantilla ni un generador de apps.

30. 

    Directriz 5.6.4 App Quality Programa de desarrolladores de Apple Directriz 5.6.4

    Pagos congelados por el aumento de la tasa de reembolsos

    Qué sucedió

    Un desarrollador de una app de suscripción de rápido crecimiento se despertó con una advertencia de Apple que decía que su cuenta de desarrollador había infringido el Code de Conducta para desarrolladores según la directriz 5.6.4, App Quality. El aviso apuntaba a un exceso de solicitudes de reembolso y quejas de clientes, advertía de que la cuenta podía cancelarse y decía que todos los pagos de ganancias estaban en pausa y las transferencias de apps, deshabilitadas. La tasa de reembolsos se había duplicado aproximadamente en los dos meses anteriores. Al profundizar en los datos, la mayoría de las solicitudes de reembolso estaban etiquetadas como compras accidentales, que, según el desarrollador, venían sobre todo de personas que olvidaban cancelar una prueba gratuita de 3 días que se convertía en un plan anual. La advertencia llegó cuando ya se estaba probando un gran rediseño de la app.

    Resolución

    Sigue abierto al momento de publicar. El desarrollador añadió más recordatorios durante el periodo de prueba, hizo más evidente el próximo cargo, añadió una forma de gestionar y cancelar la suscripción dentro de la app, terminó el rediseño con más pruebas y pausó todo el marketing de pago con creadores mientras esperaba.

    Lección

    Apple analiza las tasas de reembolso y las quejas, no solo tu binario. Una prueba gratuita que se convierte sin avisar en un cargo anual puede acabar generando problemas de compras no deseadas a gran escala. Avisa a los usuarios antes de que termine la prueba, muestra el precio real con claridad, facilita la cancelación y trata el aumento de la tasa de reembolsos como un riesgo para tu cuenta mucho antes de que lo haga Apple.

31. 

    Configuración de metadatos y compras in-app iOS Metadatos e IAP

    Rechazado tres veces por una imagen que la consola no dejaba borrar

    Qué sucedió

    Un desarrollador añadió una imagen promocional a una suscripción en App Store Connect y, por error, acabó con la misma imagen añadida dos veces. A partir de ahí, no pudo borrar ni reemplazar la imagen; cada intento fallaba con un error genérico que pedía intentarlo de nuevo más tarde. La app fue rechazada tres veces por esa configuración de suscripción. En cada ocasión, el desarrollador respondió con una grabación de pantalla del intento de borrado y del error, y cada vez sintió que el revisor lo ignoraba. El desarrollador creía que la causa raíz era un bug en el propio App Store Connect.

    Resolución

    Sigue bloqueado en el momento de publicar, sin solución por parte de Apple.

    Lección

    Cuando App Store Connect bloquea la corrección, una respuesta en el hilo de rechazo puede no llegar a nadie que pueda resolverlo. Sube las imágenes de la suscripción con cuidado y solo una vez, y si la consola falla, contacta por separado al soporte de desarrolladores de Apple sobre el error mientras respondes a App Review.

32. 

    Directriz 4.3 Spam iOS Directriz 4.3

    Tres rechazos para una app creada para gestionar un gimnasio

    Qué sucedió

    Un desarrollador creó una app de iOS para gestionar su propio gimnasio, con aproximadamente 176 commits de trabajo. Apple la rechazó el 29 de septiembre, la rechazó de nuevo el 7 de octubre y, el 13 de octubre, la rechazó bajo la directriz 4.3 Spam. Ese mismo día respondieron a las nueve preguntas que App Review les envió. Seis días después, el 19 de octubre, no habían recibido respuesta. La lista de aplicaciones de App Store Connect mostraba que varias otras apps de la misma cuenta también estaban en estado de rechazadas al mismo tiempo, tanto en iOS como en macOS.

    Resolución

    Aún abierto al momento de publicar, sin respuesta de App Review después de enviar las respuestas.

    Lección

    El esfuerzo y el número de commits no son lo que mide la directriz 4.3. Si una app está realmente hecha para un solo negocio, una app no listada puede quedar fuera de las búsquedas y seguir siendo accesible para cualquiera que tenga su enlace directo; la distribución de Custom App limita la disponibilidad a organizaciones concretas. Elige la opción que encaje con el control de acceso necesario. Para un listado público, deja claro en las primeras pantallas, capturas y notas de revisión qué la diferencia de las apps existentes.

33. 

    Directrices 5.6 Developer Code of Conduct y 2.5.19 Funciones ocultas iOS Directriz 5.6 Developer Code of Conduct Directriz 2.5.19 Funciones ocultas

    Rechazada por fraude por switches de prueba residuales

    Qué sucedió

    En septiembre de 2026, a un desarrollador le rechazaron una app de iOS bajo la directriz 5.6 del Code de Conducta para Desarrolladores. Apple dijo haber detectado un patrón de comportamiento asociado al fraude, en concreto funciones que parecían haber sido ocultadas a propósito durante la revisión. El desarrollador lo rastreó hasta tres switches de prueba que dejó en el release build: un modo para hacer screenshots de la tienda, un switch que simulaba una comprobación lenta de entitlements y otro que desbloqueaba compras simuladas. Ninguno era accesible para los usuarios normales de la versión de la App Store. En la actualización de las App Review Guidelines de Apple del 16 de octubre, las funciones ocultas, inactivas o no documentadas pasaron a tener su propia directriz, la 2.5.19, y Apple advierte que infringirla puede poner en riesgo toda la cuenta de desarrollador.

    Resolución

    Ahora el desarrollador inspecciona los strings de cada release archive antes de subirlo. No se indicó si ese build en concreto se aprobó después.

    Lección

    Mantén los code de solo prueba fuera de los release builds en tiempo de compilación, por ejemplo con flags DEBUG, en lugar de detrás de un check en runtime. Revisa qué se incluye realmente en el binario archivado y detalla en las notas de App Review cualquier switch que se quede.

34. 

    2.1 Información necesaria iOS Directriz 2.1

    Revisión en pausa hasta que Apple supo para quién era la app

    Qué sucedió

    Un desarrollador envió la versión 1.0 de una app para iPad y la revisión se detuvo bajo la Guía 2.1, Información necesaria. No hubo crash reports, ni funciones rotas, ni se pidió ningún fix del binario. Apple solo quería una respuesta detallada a una pregunta antes de seguir: quién usaría esta app.

    Resolución

    Apple solicitó una explicación sobre el usuario objetivo antes de continuar con la revisión.

    Lección

    Trata a la audiencia y al caso de uso como inputs de revisión, no como copy de marketing para rellenar después. Redacta una respuesta clara sobre el usuario objetivo antes de enviar la primera versión.

35. 

    4.3 Diseño / Spam iOS Directriz 4.3

    No se diferencia lo suficiente en una categoría saturada de apps de sonido

    Qué sucedió

    Una app de sonidos de entretenimiento fue rechazada bajo la Guía 4.3(b). Apple dijo que la tienda ya tenía suficientes apps similares y trató el producto como contenido duplicado en una categoría saturada, aun cuando el equipo creía que sus funciones extra la diferenciaban.

    Resolución

    Rechazada bajo la 4.3(b) por falta de diferenciación en una categoría saturada.

    Lección

    En categorías que Apple considera saturadas, la novedad tiene que ser obvia desde el primer minuto de revisión. Empieza por lo que es único, no por un truco que los revisores ya hayan visto mil veces.

36. 

    Metadatos y copy de la ficha iOS Metadatos e IAP Revisión interminable

    El bucle de metadatos que devoró la semana de lanzamiento

    Qué sucedió

    Un equipo de productividad para consumidores publicó un build limpio y luego pasó más de nueve días lidiando con objeciones de metadatos. Cada reenvío respondía a la nota anterior, pero la siguiente respuesta se centraba en otra frase, captura o explicación. Nada de code cambió mientras los planes de lanzamiento, prensa y adquisición de pago esperaban el copy de revisión.

    Resolución

    Aprobado tras reescribir capturas, subtítulos y notas de revisión sin cambiar el binario.

    Lección

    Cierra el copy de la ficha, las capturas y las notas de revisión de una vez antes de fijar una fecha de lanzamiento. Los rechazos de metadatos pueden acumularse aunque el binario no se mueva.

37. 

    Cumplimiento de exportación (App Store Connect) iOS Metadatos e IAP

    Aprobado y luego bloqueado por otra pregunta de cumplimiento

    Qué sucedió

    Un build de la app companion de dashboard B2B llegó a la aprobación, pero el lanzamiento siguió bloqueado cuando reapareció un prompt de cumplimiento después de que el equipo creyera que las preguntas de exportación ya estaban respondidas. El responsable del release detuvo el rollout, reunió el texto legal, actualizó la respuesta en App Store Connect y esperó otra pasada de revisión mientras los clientes veían el anuncio antes de que la app estuviera disponible.

    Resolución

    Publicado tras volver a responder el cumplimiento de exportación y esperar la siguiente pasada de revisión.

    Lección

    Trata el cumplimiento de exportación como un release gate, no como un checkbox que se marca una vez. Confirma que App Store Connect muestre un estado publicable antes de anunciar una fecha de lanzamiento.

38. 

    Permisos de Google Play y revisión de políticas Google Play Metadatos e IAP Revisión interminable

    Políticas de permisos: pérdida de tiempo

    Qué sucedió

    Una app Android de operaciones de campo provocó una revisión exhaustiva de políticas por un permiso de alcance limitado usado en una sola pantalla. El equipo documentó la función, añadió instrucciones para el revisor y grabó una demo, pero aun así tuvo que eliminar el permiso del release principal para desbloquear a los clientes tras trece días.

    Resolución

    Aprobada tras eliminar el permiso, grabar una nueva demo y reescribir la declaración de la tienda.

    Lección

    Limita los permisos sensibles a la superficie mínima que puedas lanzar primero. Un solo permiso puede acabar en una revisión completa de políticas en Google Play.

39. 

    Tiempos de la cola de revisión de Google Play Google Play Revisión interminable

    El hotfix que esperó en una cola de políticas

    Qué sucedió

    Un equipo de ecommerce necesitaba un fix rápido para un bug en el checkout, pero el release de la tienda estuvo en revisión seis días en el peor momento. Los tickets de soporte se acumulaban mientras el estado seguía pendiente. Primero mitigaron del lado del servidor y luego vieron llegar la aprobación del binario, cuando la emergencia ya se había comido un fin de semana entero.

    Resolución

    El fix nativo de la tienda llegó cuando el equipo ya había mitigado el incidente por otros medios.

    Lección

    La revisión de la tienda no es un canal de respuesta ante incidentes. Mantén una vía de mitigación fuera de la tienda para errores urgentes en producción mientras el binario espera en cola.

40. 

    Directrices 3.1.1 In-App Purchase y 3.1.3(f) Free Stand-alone Apps iOS Directriz 3.1.1 Directriz 3.1.3

    Una app complementaria rechazada porque su prueba termina

    Qué sucedió

    Un desarrollador lanzó una app gratuita para iOS como complemento de su servicio de email de pago basado en web. La app no vendía nada en su interior. Señaló a App Review la excepción 3.1.3(f) para apps complementarias gratuitas e independientes, pero la app fue rechazada cuatro veces. Recurrió, y el App Review Board confirmó el rechazo. El motivo era que el servicio ofrecía una prueba gratuita de 14 días, así que para un usuario de iOS la app dejaba de ser útil tras ese periodo y no era una experiencia independiente real. Apple ofreció dos salidas: dar a la app suficiente contenido y funciones gratuitas para que se sostenga por sí sola, o permitir que los clientes de la App Store compren el servicio con In-App Purchase. El desarrollador señaló que una conocida app de email parecía hacer lo mismo con un límite de 14 días.

    Resolución

    Sigue sin resolverse al momento de publicar. El desarrollador perdió la apelación y estaba sopesando un nivel gratuito mínimo frente a añadir In-App Purchase.

    Lección

    La excepción 3.1.3(f) para apps complementarias se interpreta de forma restrictiva. Si tu servicio web tiene una prueba con límite de tiempo, Apple puede tratar la app como un paywall encubierto una vez que la prueba termina. Antes de enviar tu app, decide qué puede seguir haciendo alguien en la app de forma gratuita después de la prueba, o ten previsto usar In-App Purchase. Señalar otras apps que parecen hacer lo mismo rara vez gana una apelación.

41. 

    Directriz 3.1.1 In-App Purchase iOS Directriz 3.1.1

    Usa tu propia clave API, tratada como un pago fuera de la App Store

    Qué sucedió

    Un desarrollador independiente que estaba creando un asistente de IA para iPhone permitió a los usuarios pegar su propia clave API de un agregador de modelos de terceros para ejecutar modelos grandes en la nube. En la cuarta ronda de revisión, App Review rechazó la app bajo la directriz 3.1.1, tratando la opción de usar tu propia clave como una forma de pagar funciones fuera de la App Store. Según entendió el desarrollador el rechazo, una clave comprada en otro lugar solo puede desbloquear funciones de pago en la app si ese vendedor ofrece In-App Purchase en su propia app para iOS, y este proveedor no tiene app para iOS. El desarrollador no apeló.

    Resolución

    Eliminaron por completo la función de usar tu propia clave, rehicieron la siguiente versión para ejecutar los modelos completamente en el dispositivo y planearon volver a traer modelos en la nube más adelante como créditos dentro de la app vendidos mediante In-App Purchase. El resultado de ese nuevo envío no se conocía en el momento de escribir esto.

    Lección

    Si las funciones de pago de tu app se desbloquean con credenciales compradas en otro lugar, verifica antes de hacer el build si ese vendedor ofrece In-App Purchase en su propia app para iOS. Si no es así, planifica tu propio flujo de In-App Purchase o un modo que funcione sin él.

42. 

    Directriz 1.2 iOS Directriz 1.2

    Una comparación de outfits rechazada por coronar a un ganador

    Qué sucedió

    Un desarrollador en solitario lanzó una app de IA que compara dos outfits. Tras la comparación, la app anunciaba un look ganador. App Review la rechazó bajo la directriz 1.2, interpretando el resultado como una clasificación de personas en lugar de ropa. El desarrollador coincidió con la observación.

    Resolución

    Eliminaron cualquier mención de ganador, la insignia de ganador y cualquier puntuación mayor o color de resaltado en cualquiera de las dos opciones, así que ahora ambos looks tienen el mismo peso visual, cada uno recibe su propio feedback y el usuario decide. No se compartió si el build corregido fue aprobado.

    Lección

    Apple juzga cómo se siente una pantalla, no solo lo que hace. Si tu app puntúa algo relacionado con la apariencia de las personas, presenta el feedback sin ranking y asume la lectura más estricta.

43. 

    Categoría Kids, directriz 3.1.2 y preguntas de privacidad iOS Categoría Niños Directriz 3.1.2 Revisión interminable

    Una app de cuentos para niños sigue esperando tras un mes de rechazos

    Qué sucedió

    Un desarrollador en solitario creó una app de cuentos para niños de 4 a 10 años, donde pueden escuchar historias y pausarlas para hacer preguntas. Ya llevaba semanas publicada en Android. La envió a la App Store el 19 de septiembre de 2026. Tras varias rondas de rechazo y reenvío, un mes después seguía sin ser aprobada. En la última ronda, Apple pidió dos cosas: como la app vende suscripciones semanales, mensuales y anuales, la página de la App Store necesitaba un enlace funcional a los Términos de Uso; y como la app está en la categoría Niños, la revisión no podía continuar hasta que el desarrollador respondiera cuatro preguntas sobre analíticas de terceros, anuncios de terceros, si se comparten datos con terceros y dónde se almacenan, y si se recopila cualquier otro dato de usuario o dispositivo y para qué.

    Resolución

    El desarrollador solucionó ambos problemas y volvió a enviarlos. El resultado aún estaba pendiente al momento de publicar.

    Lección

    Para apps para niños, salud, finanzas o educación, averigua cuanto antes qué te pedirán las leyes de privacidad locales y las tiendas; por ejemplo, el consentimiento de los padres antes de recopilar datos de un menor, y ten preparados el enlace a los Términos de Uso y una respuesta por escrito sobre los datos antes del primer envío.

44. 

    Directrices 5.1.1(v) y 3.1.2 iOS Directriz 5.1.1 Directriz 3.1.2

    La versión 1.0 fue rechazada por los flujos de inicio de sesión, compra y borrado

    Qué sucedió

    La versión 1.0 de un desarrollador fue rechazada por tres motivos a la vez, ninguno relacionado con la idea de la app. Tras usar Sign in with Apple, la app volvía a pedir un nombre que Sign in with Apple ya había proporcionado. El borrado de cuenta debía poder iniciarse desde la app. La pantalla de suscripción y soporte debía mostrar el precio, los términos de renovación y un enlace a los Términos. La conclusión del desarrollador fue que los tres tenían que ver con iniciar sesión, comprar y borrar.

    Resolución

    No especificado.

    Lección

    Antes del primer envío, revisa los flujos de inicio de sesión, compra y borrado de cuenta como si fueras un revisor. Esos tres flujos causan muchos rechazos iniciales.

45. 

    Directriz 5.2.3 Descarga de Audio/Video iOS Directriz 5.2.3 Descarga de Audio/Video

    Radio vintage en internet rechazada por derechos de audio de terceros

    Qué sucedió

    La app de radio online de un desarrollador independiente, con estética vintage y versión 1.0 en su quinto build, fue rechazada bajo la directriz 5.2.3. Esta norma aplica a apps que reproducen o descargan audio y video de fuentes de terceros y exige pruebas de que el desarrollador tiene los derechos de ese contenido. Al día siguiente, el desarrollador respondió en el Resolution Center con una explicación sobre los derechos del contenido.

    Resolución

    Resultado aún desconocido en el momento de la publicación.

    Lección

    Si tu app transmite estaciones o contenido que no te pertenece, consigue una autorización o usa fuentes cuyos términos permitan explícitamente la reproducción en apps; adjunta esa documentación en las notas de revisión antes de enviar.

46. 

    Directriz 4.3 (Spam) iOS Directriz 4.3

    Seis rechazos, luego una etiqueta de spam 4.3 y dos semanas de espera para una llamada

    Qué sucedió

    Un desarrollador independiente pasó meses en su primera app, una herramienta para iniciar conversaciones en contextos sociales. Fue rechazada seis veces, la última bajo la Directriz 4.3 por spam, aunque el desarrollador sentía que su app ofrecía más que las similares ya en la tienda. Pidió a App Review una llamada individual. Pasó una semana sin respuesta, y la llamada finalmente ocurrió unas dos semanas después del rechazo 4.3. El desarrollador salió de la llamada con la impresión de que la 4.3 se usa ahora para marcar apps que parecen clones de bajo esfuerzo generados por IA, algo que él afirmó que su app no era.

    Resolución

    El desarrollador presentó una apelación. Seguía pendiente al momento de escribir esto.

    Lección

    En una categoría saturada, el revisor juzga lo que muestran las capturas, la descripción y la primera sesión. Haz evidente la diferencia con las apps existentes ahí, y solicita la llamada de App Review temprano, porque conseguirla puede tardar una semana o más.

47. 

    Acuerdo no aceptado (sin directriz citada) iOS Registro y cuenta

    Una semana en cola, rechazado por un acuerdo sin firmar, y otra semana más

    Qué sucedió

    Una app esperó cerca de una semana para la revisión y luego fue rechazada sin que hubiera nada malo dentro de la app. La cuenta todavía no había aceptado un acuerdo recién publicado en App Store Connect. El desarrollador lo aceptó y la reenvió, y el envío volvió a la cola por aproximadamente otra semana. El soporte para desarrolladores solo respondió que todo iba por buen camino.

    Resolución

    Al momento de escribir esto, sigue esperando revisión.

    Lección

    Antes de cada envío, revisa App Store Connect en busca de acuerdos pendientes de aceptar. Un clic olvidado puede costarte una pasada completa por la cola de revisión.

48. 

    Crash durante la revisión (no se indica la guideline) macOS Directriz 2.1

    Rechazado por un crash en una versión de macOS que el desarrollador no tenía instalada

    Qué sucedió

    Una app de Mac fue rechazada porque se crasheaba en macOS 27, una versión que el desarrollador aún no usaba y no quería instalar en su equipo principal. Buscando cómo reproducir el crash, descubrió que el framework Virtualization de Apple permite ejecutar una máquina virtual de macOS en Apple silicon gratis, y montó una para probar en la nueva versión.

    Resolución

    No se indica nada más allá de reproducir el crash en una máquina virtual.

    Lección

    App Review prueba en el OS más reciente. Ten lista una máquina virtual con el último macOS para poder reproducir los crashes de la revisión sin actualizar tu equipo del día a día.

49. 

    Retraso en la revisión (sin directriz citada) iOS Revisión interminable

    Doce días en Waiting for Review tras dos solicitudes de expedite

    Qué sucedió

    Un desarrollador que ya tenía apps aprobadas en la tienda envió la versión 1.0 de una nueva app junto con un grupo de suscripción de cinco suscripciones. Doce días después seguía en Waiting for Review, contra la expectativa habitual de menos de 48 horas. Solicitó una revisión acelerada dos veces, contactó con soporte sin obtener respuesta e intentó agendar una cita de App Review, que fue denegada.

    Resolución

    Aún esperando al momento de escribir esto.

    Lección

    No planifiques una fecha de lanzamiento basándote en el promedio de 48 horas. Deja semanas de margen para una primera versión con suscripciones, y trata las solicitudes de expedite y las citas como posibles, no garantizadas.

50. 

    Prompt de permisos + metadatos de capturas (reglas citadas habitualmente como 5.1.1 y 2.3.7) iOS Directriz 5.1.1 Directriz 2.3.7

    Semana de lanzamiento: pantalla 'Permitir' personalizada y precios en screenshots

    Qué sucedió

    Durante la semana de lanzamiento, la app fue rechazada dos veces. La primera vez mostró su propia pantalla con un botón 'Permitir' justo antes del prompt del sistema, algo que Apple no acepta. Tras corregirlo, el segundo rechazo se debió a que los screenshots de la App Store mostraban precios. Ambas correcciones fueron pequeñas, pero cada reenvío costó cerca de un día en la cola de revisión.

    Resolución

    El desarrollador solucionó ambos problemas y ahora tiene ambas reglas documentadas en el proyecto para que no vuelva a ocurrir.

    Lección

    Una pantalla previa al permiso puede explicar por qué necesitas acceso, pero deja que la única opción de 'Permitir' sea el prompt del sistema. Evita incluir precios en los screenshots y sigue un checklist rápido antes de cada envío.

51. 

    Retraso en la revisión (sin directriz citada) iOS Revisión interminable

    Diez días estancado en revisión, luego aprobado media hora después de reenviar

    Qué sucedió

    La app estuvo en revisión más de diez días sin avanzar. El desarrollador la reenvió.

    Resolución

    Se aprobó unos 30 minutos después de reenviarla.

    Lección

    Una revisión estancada no siempre es un veredicto sobre tu app. Si se queda bloqueada mucho más de lo habitual, reenviarla o solicitar una revisión acelerada puede valer la pena, pero ninguna de las dos está garantizada.

52. 

    4.3(a) Spam iOS Directriz 4.3

    Siete apps de plantilla rechazadas por 4.3 en el mismo minuto

    Qué sucedió

    Un equipo pequeño envió siete apps basadas en la misma plantilla a revisión en la misma semana. Las siete recibieron el mismo rechazo por spam de 4.3(a) en el mismo minuto, incluidas dos apps que nunca habían sido rechazadas. El equipo concluyó que Apple evaluó el lote en lugar de cada app.

    Resolución

    Ahora el equipo envía una app a la vez.

    Lección

    Las apps que comparten codebase pueden interpretarse como un patrón de spam si se envían juntas. Espacia los envíos y haz que cada app sea claramente distinta en funciones, diseño y metadatos.

53. 

    Directriz 2.3.6 iOS Directriz 2.3.6

    Rechazo por clasificación de edad cuando Connect ya coincidía

    Qué sucedió

    Una app fue rechazada por su clasificación de edad. El desarrollador abrió el cuestionario de clasificación de edad en App Store Connect y vio que todas las respuestas ya coincidían con lo que pedía el mensaje de rechazo.

    Resolución

    No cambió nada en Connect, respondió al revisor que la configuración ya coincidía y volvió a enviarla. La app fue aprobada pocas horas después.

    Lección

    Una nota sobre la 2.3.6 puede estar equivocada respecto a tu configuración actual. Revisa App Store Connect antes de cambiar nada y, si ya coincide, dilo claramente en tu respuesta en lugar de intentar adivinar una solución.

54. 

    Directriz 2.1 Información necesaria iOS Directriz 2.1

    Historial de revisión limitado: grabación en dispositivo y recorrido de funciones premium

    Qué sucedió

    Una app que ya había superado la revisión de Google Play fue devuelta bajo la sección 2.1 Información necesaria. Apple indicó que la cuenta de desarrollador tenía un historial de revisiones limitado y solicitó una grabación de pantalla en un dispositivo real, un recorrido por las funciones de pago y una descripción escrita de lo que hace la app y de qué servicios externos depende.

    Resolución

    El desarrollador estaba preparando la grabación y las respuestas al momento de publicar. Resultado desconocido.

    Lección

    Aprobar la revisión de Google Play no dice nada sobre Apple. Si tu cuenta de desarrollador es nueva o tiene pocos envíos anteriores, prepara una grabación en un dispositivo real, un recorrido por las funciones de pago y una lista de servicios de terceros antes de enviar.

55. 

    Directrices 2.1, 2.3.2 y 5.2.3 iOS Directriz 2.1 Directriz 2.3.2 Directriz 5.2.3 Descarga de Audio/Video Revisión interminable

    Primer envío: 2.1, luego 2.3.2 y después 5.2.3 en un mes

    Qué sucedió

    El primer envío de un desarrollador estuvo seis días esperando y lo rechazaron por la 2.1. Respondieron ese mismo día. Doce días después lo rechazaron otra vez, esta vez por la 2.3.2. Volvió a enviarlo y, nueve días después, lo rechazaron por la 5.2.3. Respondieron de nuevo ese mismo día y, dos días después, seguían esperando. Cada ronda alegaba una directriz distinta de la anterior.

    Resolución

    Sigo esperando, más de un mes después del primer envío.

    Lección

    Cada ida y vuelta puede sacar a la luz una nueva directriz, y cada una puede costar una semana o más. Antes del primer envío, lee las reglas de metadatos (2.3) y las reglas de derechos de contenido que te apliquen (5.2), no solo las de integridad (2.1), y arregla todo lo que puedas encontrar en un solo build.

56. 

    Directriz 4.2 Funcionalidad mínima iOS Directriz 4.2

    App de oración rechazada por ser básicamente un libro (4.2)

    Qué sucedió

    Una app de oración y devoción religiosa fue rechazada bajo la 4.2 con el argumento de que era principalmente un libro. El desarrollador señaló funciones interactivas como un calendario, un contador de oraciones, un temporizador de meditación, colecciones para compartir, widgets en la pantalla de inicio y búsqueda por voz.

    Resolución

    No especificado.

    Lección

    Si el revisor percibe tu app como contenido estático, las funciones interactivas podrían no verse en los primeros minutos de revisión. Muéstralas en las primeras pantallas y capturas, y lístalas en las notas de revisión con los pasos para acceder a cada una.

57. 

    Directriz 2.3.10 iOS Directriz 2.3.10

    Trece días en cola, rechazado en siete minutos por Android

    Qué sucedió

    Un desarrollador esperó trece días en la cola de revisión, consultando App Store Connect y su email a diario y enviando dos tickets de soporte. Cuando la revisión por fin comenzó, la app fue rechazada unos siete minutos después porque la descripción de la App Store decía que el producto funcionaba en cualquier navegador en iPhone o Android.

    Resolución

    Eliminaron la mención de la otra plataforma, un cambio de una sola línea, y lo volvieron a enviar. Aún no se conoce el resultado.

    Lección

    Apple rechaza los metadatos que mencionan otras plataformas móviles. Revisa tu descripción, capturas y texto promocional antes de enviar, porque un pequeño error de redacción puede costarte una espera completa en la cola.

58. 

    Directriz 5 (Legal) iOS Directriz 5 (Legal)

    Rechazo según la Directriz 5 por OpenAI en metadatos para China

    Qué sucedió

    Una app de IA fue rechazada según la Directriz 5 (Legal) porque sus metadatos mencionaban OpenAI. Apple explicó que China exige una licencia gubernamental para servicios de IA generativa y síntesis profunda, que ChatGPT no cuenta con ese permiso, y que el desarrollador debe eliminar la funcionalidad de IA y toda referencia a OpenAI o ChatGPT del nombre, subtítulo, texto promocional, descripción y capturas de pantalla para la tienda de China, o dejar de distribuirla en China continental.

    Resolución

    Se recomienda desmarcar la tienda de China continental en Disponibilidad antes de enviar una app que mencione esos servicios; así te ahorras un ciclo de revisión.

    Lección

    Si tu app usa un proveedor de IA generativa, decide la disponibilidad en China desde el principio. El rechazo es por la tienda y los metadatos, no solo por tu code.

59. 

    Directriz 3.1.2 iOS Directriz 3.1.2

    Enlace a los Términos en la app pero falta en la descripción

    Qué sucedió

    La primera versión de una app de suscripción fue rechazada dos días después del envío porque el enlace a los Términos de Uso no estaba en la descripción de la App Store. Ya aparecía dentro de la app en el paywall y en ajustes, pero faltaba en ese campo de metadatos.

    Resolución

    El arreglo tomó cinco minutos, pero tras reenviarlo, el build se quedó en "Waiting for Review" durante más de diez días sin respuesta. Ninguno reportado aún.

    Lección

    Para suscripciones autorrenovables, incluye los enlaces a los Términos de uso (EULA) y la Política de privacidad tanto en los metadatos de App Store como en la app antes del primer envío, porque un fix rápido puede costar una segunda espera larga.

60. 

    Terminación de cuenta iOS Terminación de cuenta

    Cuenta terminada según la 3.2(f), ganancias pendientes sin pagar

    Qué sucedió

    La cuenta de Apple Developer de un desarrollador fue cancelada en virtud de la sección 3.2(f) del Developer Program License Agreement. Casi tres meses después, sus ganancias pendientes seguían sin pagarse y preguntaba a otros desarrolladores si alguien había recibido alguna vez ganancias retenidas tras una terminación.

    Resolución

    Ninguno reportado.

    Lección

    Una terminación puede congelar ingresos que ya ganaste, no solo ventas futuras. Mantén un colchón de efectivo, registros de tus pagos y tu propio canal hacia los usuarios para que una decisión de cuenta no acabe con el negocio.

61. 

    Directrices 2.1 y 5.1.2 iOS Directriz 2.1 Directriz 5.1.2 Revisión interminable

    Veinticinco días en revisión, y luego 2.1 y 5.1.2 a la vez

    Qué sucedió

    Un desarrollador indie envió la primera versión, 1.0, de una app iOS. Tras unos diecisiete días, el build seguía en revisión. Después de unos veinticinco días en total, App Review la rechazó bajo la directriz 2.1 App Completeness y la 5.1.2 Data Use and Sharing en la misma decisión. App Store Connect bloqueó entonces todos los demás ítems del envío hasta que se corrigiera la versión rechazada. El desarrollador dijo que los problemas citados eran fáciles de arreglar; lo doloroso era esperar otras dos o tres semanas para el reenvío.

    Resolución

    Corrigieron ambos problemas y volvieron a enviar la app. No se informó el resultado de la siguiente revisión.

    Lección

    Cuando las colas son tan largas, cada rechazo puede costar semanas. Antes de enviar, haz una pasada completa de completitud: sin flujos rotos, con una cuenta demo que funcione, sin placeholders, y asegúrate de que las respuestas de privacidad y cualquier uso compartido de datos de SDK coincidan con lo que la app hace realmente.

62. 

    Directriz 2.3.1(a) iOS Directriz 2.3.1 Metadatos e IAP

    Apuestas con dinero real rechazadas por ocultas bajo la 2.3.1(a)

    Qué sucedió

    Un desarrollador creó un rastreador de hábitos y disciplina donde los usuarios podían apostar dinero y perderlo si no cumplían sus metas. A mediados de octubre de 2026, App Review lo rechazó bajo la directriz 2.3.1(a), indicando que la app contenía funciones ocultas, específicamente apuestas monetarias y pérdida de apuestas que no se describían en los metadatos. La carta también incluía una notificación de Revisión Extendida advirtiendo que los envíos repetidos con estos problemas conducen a tiempos de revisión más largos y que las cuentas que siguen incumpliendo las reglas pueden ser eliminadas del Apple Developer Program. La app pasó por cinco rechazos en total; otro citó un crash durante la revisión en iPad. El desarrollador, que había construido con herramientas de codificación con IA, resumió las lecciones: leer las directrices, alinear los metadatos con la app, nunca ocultar funciones o recopilación de datos, revisar el code generado y probar en diferentes dispositivos.

    Resolución

    No se especificó más allá de rehacer la app tras cinco rechazos. No se reportó aprobación.

    Lección

    Cualquier función que mueva dinero real, incluidas apuestas o pérdidas, debe ser clara en la descripción y en las notas de App Review. Prueba en iPad aunque tu objetivo sea iPhone, porque los revisores lo hacen.

63. 

    Directriz 4.3(a) iOS Directriz 4.3

    Nuevas funciones, nuevas capturas de pantalla y un 4.3(a) en tres minutos con una advertencia

    Qué sucedió

    Un desarrollador que había pasado unos dos meses construyendo una app desde cero ya había sido rechazado bajo la directriz 4.3 por spam. Para la siguiente ronda, añadió nuevas funciones, reemplazó todas las capturas de pantalla, optimizó la app para más tamaños de dispositivo y volvió a enviarla con notas de revisión y una cuenta de prueba premium. Tres minutos después de que la app entrara en revisión, fue rechazada de nuevo bajo la directriz 4.3(a). Esta vez, el mensaje terminaba con un aviso de revisión extendida: los envíos repetidos con estos problemas conducirían a tiempos de revisión más largos, y las cuentas que sigan enviando apps así se enfrentan a la expulsión del Apple Developer Program. Temeroso de que otro reenvío pudiera costarle toda la cuenta, el desarrollador estaba decidiendo si descartar la app o pedir una llamada a App Review.

    Resolución

    Sin resolver al momento de la publicación.

    Lección

    Una vez que aparece el aviso de revisión extendida, reenviar rápidamente es la jugada más arriesgada. Pide primero una llamada con App Review y reenvía solo cuando sepas qué consideran demasiado similar.

64. 

    Directriz 4.3(b) iOS Directriz 4.3

    Rechazada en tres minutos, luego tres semanas de silencio en la apelación

    Qué sucedió

    La app de un desarrollador fue rechazada bajo la directriz 4.3(b) unos tres minutos después de entrar en revisión. Apeló ante el Comité de Revisión de Apps. Tres semanas después aún no tenía respuesta, ni cambio de estado, ni mensaje de ningún tipo.

    Resolución

    Sin resolver.

    Lección

    Una apelación puede quedarse semanas sin feedback. Trabaja en paralelo en lo que hace única a la app frente a la categoría saturada, para no quedarte atascado esperando solo la apelación.

65. 

    Terminación de cuenta iOS Terminación de cuenta

    Una app parecía un sitio web, y decenas de apps desaparecieron

    Qué sucedió

    Un estudio que había publicado aplicaciones durante más de una década, más de 80 en total, tuvo su cuenta de desarrollador marcada para su terminación. Según el estudio, la razón fue que una de sus aplicaciones podía considerarse similar a un sitio web existente. No hubo advertencia ni opción para eliminar solo esa aplicación. Todas sus aplicaciones fueron retiradas de la App Store, incluidas aplicaciones licenciadas no relacionadas creadas para clientes, y se bloquearon las actualizaciones.

    Resolución

    Sin resolver. El estudio discrepó públicamente con la decisión.

    Lección

    Una cuenta de desarrollador es un único punto de fallo. Si creas aplicaciones para clientes, publícalas bajo la cuenta de desarrollador del propio cliente para que una disputa sobre una de tus aplicaciones no afecte también a las suyas.

66. 

    Sección 3.2(f) (Developer Program License Agreement) iOS Terminación de cuenta

    A title update, then a 3.2(f) termination notice

    Qué sucedió

    Un desarrollador indie envió un simple cambio de título para una app y recibió una notificación de terminación bajo la sección 3.2(f). Todas sus apps fueron eliminadas de la tienda. Presentó apelaciones oficiales y, 15 días después, no había recibido respuesta de una persona.

    Resolución

    Sin resolver.

    Lección

    La actualización que activa una notificación 3.2(f) puede no ser lo que Apple está penalizando. Antes de apelar, reúne pruebas claras de quién es dueño y opera cada app, y espera que las respuestas tarden semanas.

67. 

    Sección 3.2(f) (Developer Program License Agreement) iOS Terminación de cuenta

    Una corrección del paywall y, una semana después, una notificación de terminación 3.2(f)

    Qué sucedió

    La app de un desarrollador indie fue rechazada una vez por cómo se mostraban los precios semanales y anuales en su paywall. El paywall venía de una plantilla que había copiado un asistente de código con IA. Lo arregló en code, envió un nuevo build y esperó alrededor de una semana. En vez de recibir un resultado de revisión, se despertó con un aviso de terminación pendiente bajo la sección 3.2(f). Toda su membresía de desarrollador quedó marcada, todas las apps que había creado durante varios años fueron retiradas de la App Store y los pagos quedaron congelados. El desarrollador afirmó que no había cambiado nada en la app después de enviarla, que tenía logs que lo respaldaban y preguntó públicamente si alguien había logrado recuperar una cuenta.

    Resolución

    Sin resolver al momento de la publicación.

    Lección

    Toma un rechazo por el paywall o por los precios como una advertencia, no como un trámite. Revisa cualquier plantilla o paywall generado en code para ver cómo se muestran los precios y las condiciones de prueba antes del primer envío, y mantén logs de build y de cambios para documentar exactamente qué enviaste si alguna vez cuestionan tu cuenta.

68. 

    Directriz 3.1.1 In-App Purchase macOS Directriz 3.1.1

    Un cliente de cloud gaming gratuito rechazado bajo la 3.1.1 por compras dentro de juegos en streaming

    Qué sucedió

    Un desarrollador creó una app gratuita de juego remoto para el servicio de cloud gaming de un gran fabricante de consolas y la envió a la App Store. La versión de Mac fue rechazada bajo la directriz 3.1.1. App Review indicó que algunos juegos en streaming podrían llevar a los usuarios a comprar contenido digital fuera de la App Store. Según el desarrollador, el servicio de gaming no permite completar pagos durante una sesión de streaming: algunos juegos muestran opciones de compra, pero el pago no se puede procesar mientras se transmite. Señaló que varias apps de streaming similares ya estaban en la tienda y presentó una apelación.

    Resolución

    Apelación pendiente al momento de la publicación.

    Lección

    Para apps de streaming y apps cliente, App Review evalúa lo que los usuarios ven dentro del contenido transmitido, no solo tu propio code. Explica en las notas de revisión exactamente cómo funcionan las compras dentro del stream, con capturas de pantalla, antes del primer envío en lugar de dejarlo para la apelación.

69. 

    Login en iPad (sin número de directriz) iOS Login

    Tercer rechazo porque el login falló en iPad durante una caída del backend

    Qué sucedió

    Un pequeño equipo que desarrollaba una app de fitness vio su app de iOS rechazada por tercera vez porque el revisor no pudo iniciar sesión en un iPad. La causa no estaba en el code de la app: su proveedor de backend tenía problemas de autenticación justo cuando el revisor lo intentó, así que el login simplemente falló. El equipo había facilitado una cuenta demo con email y contraseña, pero según su versión el revisor no lo intentó de nuevo más tarde. No tenían un iPad ni un Mac para probar. En cuanto el backend se recuperó, volvieron a enviarla. Apple les había dicho que la app seguiría en revisión acelerada aunque la rechazaran de nuevo, pero tres días hábiles después seguía pendiente de revisión.

    Resolución

    Reenviada, aún pendiente de revisión al momento de publicar.

    Lección

    Los revisores suelen probar en iPad y normalmente solo intentan el login una vez. Vigila el estado de tu backend y de tu proveedor de auth mientras un build está en revisión, prueba la cuenta demo en una pantalla del tamaño de un iPad antes de enviar e indica en las notas de revisión a quién contactar si el login falla.

70. 

    Guidelines 5.1.1(i) y 5.1.2(i) iOS Directriz 5.1.1 Directriz 5.1.2 Compartir datos con IA

    El consentimiento de IA escondido en los términos no bastó para 5.1.1(i) y 5.1.2(i)

    Qué sucedió

    La app de diario de un desarrollador fue rechazada en iOS bajo las directrices 5.1.1(i) y 5.1.2(i), ambas sobre compartir datos de usuario con servicios de IA. El consentimiento para ese procesamiento ya estaba incluido en los términos de la app, pero App Review no lo aceptó. El desarrollador movió el consentimiento a una pantalla explícita dentro de la app, que se muestra primero, antes de que ningún modelo lea una sola entrada. Luego mapeó cada ruta code donde las entradas llegan a un modelo y condicionó cada una a ese consentimiento, para que no se construya ni una sola petición sin un sí. Los background jobs ahora omiten las cuentas que no han aceptado y esperan en lugar de fallar, y un release check falla si la app llama a un host de IA que la pantalla de consentimiento no menciona.

    Resolución

    Corregido y reenviado. El veredicto de Apple seguía sin conocerse en el momento de publicar.

    Lección

    Una línea en tus términos no es consentimiento para compartir datos con IA. Pregunta dentro de la app antes de la primera petición, indica el proveedor y los datos, y asegúrate de que cada ruta code que envíe contenido de usuario verifique esa respuesta.

71. 

    Sección 3.2(f) (Developer Program License Agreement), tras repetidos rechazos de metadatos iOS Terminación de cuenta Metadatos e IAP

    Una librería nueva, ocho rechazos, una app renombrada y luego un aviso de terminación

    Qué sucedió

    Un desarrollador indie tenía una app iOS de casi tres años, había generado ingresos de seis cifras y había lanzado muchas actualizaciones con una tasa de reembolsos baja. Hace más de seis meses, envió una pequeña actualización cuyo único cambio era una librería nueva. App Review la rechazó más de ocho veces, cada vez por metadatos: palabras clave que llevaban más de un año activas, un subtítulo en una localización, luego las capturas de pantalla, luego los mismos puntos otra vez y, finalmente, el nombre de la app, que era de donde venía la mayor parte de su tráfico de búsqueda. Pidió una llamada con App Review y el revisor le dijo que el nombre era el último problema pendiente. Cambió el nombre de toda la app y la reenvió. Tres días después, llegó un rechazo genérico con los problemas del subtítulo y las capturas de pantalla otra vez. Decidió que no necesitaba la actualización y la descartó. Meses después, llegó un aviso de terminación pendiente en ese mismo hilo de revisión antiguo. Decía que la cuenta había violado repetidamente las directrices en un intento de evadir el proceso de revisión y que los problemas de mensajes anteriores seguían sin resolverse. La app fue eliminada de la tienda y toda la cuenta fue marcada para su eliminación.

    Resolución

    Recurso presentado ante el App Review Board, pendiente a la fecha de publicación.

    Lección

    Un envío abandonado aún puede contar en tu cuenta. Si el ciclo de revisión se prolonga, confirma por escrito en el hilo de revisión todos los problemas pendientes, no solo en una llamada. Si decides descartar una actualización, responde en el hilo para indicarlo y retira el build de la revisión en lugar de dejar la rechazo sin resolver.

72. 

    Directriz 1.1 Seguridad: Contenido Ofensivo, seguida de la Sección 3.2(f) iOS Contenido inapropiado Terminación de cuenta

    Dos rechazos por 1.1, una pregunta sobre qué imagen, y luego una notificación de terminación

    Qué sucedió

    La app iOS de un desarrollador, que generaba fotos de parejas con IA, fue rechazada bajo la directriz 1.1 por contenido ofensivo. El rechazo no especificaba qué imagen era el problema. El desarrollador suavizó las imágenes de muestra, eliminando gestos de contacto o cercanía, y volvió a enviarla unos cinco días después. Cuatro días más tarde, fue rechazada de nuevo por la misma razón. En lugar de enviar otro build, escribió a Apple preguntando qué imagen era la causante. Pasaron unos diez días sin respuesta, hasta que la app fue retirada de la tienda y el desarrollador recibió una notificación de terminación pendiente. Según su interpretación, Apple consideró el ciclo repetido de corrección y reenvío como un intento de evadir la revisión. Los pagos se pausaron y todas las apps de la cuenta estuvieron en riesgo, con 30 días para apelar. Al leer hilos de foros de otros desarrolladores con la misma notificación, descubrió que la mayoría de las apelaciones se quedaban semanas sin respuesta, y que la única reinstalación que encontraron ocurrió tras una segunda apelación que nombraba la causa real y revelaba todo lo demás.

    Resolución

    Preparando una apelación en el momento de la publicación.

    Lección

    Dos rechazos bajo la misma directriz pueden ser suficientes para poner en riesgo una cuenta. Cuando un rechazo por contenido es vago, pide a App Review que señale la pantalla o el recurso exacto antes de reenviar, mantén un registro de cada cambio y trata el segundo rechazo como una señal para pausar, no para intentarlo de nuevo.

73. 

    Directrices 2.3.7, 5.2.5 y 4.8 iOS Directriz 2.3.7 Metadatos e IAP Requisito de login

    Aprobada en Mac, pero rechazada en iPhone por 2.3.7, 5.2.5 y 4.8 en la misma app

    Qué sucedió

    Un desarrollador que creaba un cliente de calendario para un servicio de calendario de terceros importante lanzó primero la versión de Mac. La versión de Mac ya había requerido una apelación formal solo para indicar en su ficha que funcionaba con ese servicio, y ya le habían explicado a App Review por qué no necesitaba Sign in with Apple. Cuando añadieron la versión de iPhone, con el mismo bundle y el mismo App ID que la app de Mac, fue rechazada por tres directrices a la vez: 2.3.7 por precios mostrados en un evento in-app, 5.2.5 por una línea que decía que la app era para iPhone, iPad y Mac, y 4.8 por no ofrecer Sign in with Apple junto al login del propio servicio de calendario. La directriz 4.8 tiene una excepción para apps que son clientes de un servicio de terceros específico, que es justo el caso de esta app, pero la explicación dada para la versión de Mac no se trasladó. Cada target de plataforma se revisó desde cero.

    Resolución

    No se especificó al publicar.

    Lección

    Una nueva plataforma implica una nueva revisión, incluso dentro del mismo App ID. Copia en las notas de revisión de cada plataforma cada explicación y excepción que ya hayas conseguido, y revisa los eventos in-app y las descripciones para verificar precios y nombres de dispositivos Apple antes de enviar.

74. 

    Directriz 3.1.2(c), luego marca de Apple en el texto de Siri (sin número de directriz) iOS Directriz 3.1.2 Revisión interminable

    Nueve días de espera, un rechazo por paywall 3.1.2(c) y un binario rechazado en 42 segundos por un texto de Siri

    Qué sucedió

    Un desarrollador con una cuenta nueva envió la primera versión de una app de hábitos de escritura y esperó unos nueve días hasta que pasó a En revisión. Cincuenta minutos después la rechazaron por la directriz 3.1.2(c): en el plan anual, el precio mensual calculado se mostraba con un tamaño de letra mayor que el precio anual que se cobraba realmente. Corrigieron los tamaños de fuente del paywall y subieron un nuevo build. Ese build fue rechazado automáticamente en 42 segundos porque el texto de ayuda de un atajo de Siri mencionaba una app de Apple por su nombre de marca, y el texto de los Siri intents no puede usar la palabra Apple. Lo reformularon para referirse a la app de notas de forma genérica y volvieron a subir el build.

    Resolución

    Reenviado, resultado desconocido al momento de la publicación.

    Lección

    Antes del primer envío, haz que el importe facturado sea el precio más destacado en cada plan y busca todas las marcas de Apple en las cadenas visibles para el usuario, incluidas Siri, Shortcuts y el texto de los widgets. Las comprobaciones automatizadas detectan esto en segundos, pero cada ronda te cuesta un lugar en la cola.

75. 

    Sección 3.2(f) (Acuerdo de licencia del programa de desarrolladores), citando un rechazo por nombre antiguo iOS Terminación de cuenta Metadatos e IAP

    Un rechazo por nombre corregido y aprobado, y casi un año después, una notificación de cierre por fraude

    Qué sucedió

    Un desarrollador independiente que llevaba una cuenta de empresa pequeña había creado ocho apps activas en aproximadamente un año y medio. Casi un año antes, una de esas apps había sido rechazada porque Apple objetó una palabra de su nombre. El desarrollador cambió el nombre, la app se revisó y se aprobó, y una actualización posterior también se aprobó. El historial de revisiones que compartieron muestra la versión 1.0 rechazada dos días consecutivos y aprobada al día siguiente, y luego una actualización aprobada al primer intento unos dos meses después. Después de eso, la app quedó sin cambios durante unos nueve meses. Entonces se rechazó una nueva app de la misma cuenta y llegó un aviso de terminación pendiente que citaba actividad deshonesta o fraudulenta según la sección 3.2(f): los envíos habían violado repetidamente las directrices en un intento de evadir la revisión, y los problemas de mensajes anteriores seguían sin resolverse. No mencionaba ningún problema nuevo y llegó sin advertencia ni pregunta previa. Se pausaron los ingresos de todas las apps, incluidas las que nunca habían tenido problemas, y el aviso advertía de que una cuenta nueva también podría ser terminada. La única forma de responder era un formulario web limitado a 2,000 caracteres, que devolvía un acuse de recibo automático y luego silencio. El desarrollador aceptó la eliminación de las apps señaladas, apagó sus servidores ese mismo día, pausó todos los envíos y envió una apelación completa el primer día.

    Resolución

    Apelación enviada el primer día; al momento de publicar, solo un acuse de recibo automático.

    Lección

    Un rechazo que corregiste y que acabó aprobándose puede citarse meses después como parte de un patrón. Guarda cada mensaje de rechazo, el cambio exacto que hiciste y la aprobación posterior, para poder mostrar el historial completo en un breve formulario de apelación, y no esperes un plazo definido una vez enviado.

76. 

    Directrices 4.3 Spam y 4.2.6 iOS Directriz 4.3 Directriz 4.2.6

    Un juego hecho en solitario rechazado dos veces por spam y por plantilla; nueve respuestas enviadas, sin respuesta

    Qué sucedió

    Un desarrollador que hace juegos solo por las noches envió un juego original y lo rechazaron dos veces, con cuatro días de diferencia a principios de octubre, según la directriz 4.3 por spam y la 4.2.6, que cubre apps creadas con plantillas comerciales o servicios de generación de apps. No se usó ninguna plantilla y el desarrollador escribió cada línea de código. Ambos rechazos llegaron con el mismo texto de plantilla y ninguno mencionaba la app a la que supuestamente se parecía el juego. Apple envió entonces nueve preguntas sobre cómo se hizo el juego, y el desarrollador las respondió todas con detalle al día siguiente del segundo rechazo. No hubo respuesta. Unos nueve días después apeló ante el App Review Board, y una semana después seguía esperando. Su teoría era que publicar varios juegos en pocos meses parece una fábrica de apps para el revisor. Mientras tanto, hizo que el juego se pudiera jugar gratis en un navegador web.

    Resolución

    Apelación ante el App Review Board pendiente en el momento de publicar, unas tres semanas después del primer rechazo.

    Lección

    Las reglas 4.3 y 4.2.6 pueden evaluarse en toda tu cuenta, no en un solo binario. Si publicas varios títulos en poco tiempo, muestra qué hace original a cada uno desde el primer envío, con notas de revisión sobre cómo se construyó y un video corto de gameplay, porque cuando el texto de rechazo es una plantilla, las respuestas detalladas pueden quedar sin leer durante semanas.

77. 

    Guideline 2.1 App Completeness, luego Guideline 5 Legal (disponibilidad en China) iOS Directriz 2.1 Directriz 5 (Legal) Revisión interminable

    Una licencia gratuita para el revisor ocultó el paywall; luego, seis días en cola y un rechazo por IA de China

    Qué sucedió

    Un desarrollador envió su primera app para iOS, una herramienta de finanzas personales para llevar un registro de pagos recurrentes, y fue rechazada bajo la directriz 2.1 Completitud de la app. La causa fue un favor que salió mal: le dieron al revisor una licencia de pago por correo, así que el revisor omitió el paywall y nunca vio el flujo de compra. El desarrollador escribió una guía PDF paso a paso con capturas de pantalla para el revisor y volvió a enviarla, esta vez enviando las versiones para iOS y Mac juntas. La nueva solicitud esperó seis días antes de pasar a In Review, y luego fue rechazada de nuevo, esta vez por una mención a ChatGPT mientras la app estaba disponible en China continental.

    Resolución

    Aún rechazada al momento de publicar, mientras que una build más reciente se ofrecía a los testers a través de TestFlight.

    Lección

    Deja que App Review vea exactamente lo que ve un usuario nuevo, incluido el paywall. Da al revisor una demo o cuenta de sandbox funcional y notas claras, en lugar de una licencia gratuita que oculte el flujo de compra. Si la app o su listing menciona un proveedor de IA como ChatGPT, verifica si China continental está en tu disponibilidad antes de enviar, ya que cada nueva ronda puede costar días en la cola.

78. 

    Directriz 2.3.10 Metadatos precisos iOS Directriz 2.3.10 Metadatos e IAP Revisión interminable

    Diez días hasta la primera revisión, una mención a Google Play y luego dos semanas más de espera

    Qué sucedió

    Un desarrollador con una cuenta nueva envió una app nueva a principios de octubre. Es una app donde los usuarios pueden subir públicamente sus propias imágenes, lo que el desarrollador esperaba que atrajera más escrutinio de moderación de contenido. La primera revisión llegó diez días después, en un iPad, y terminó en un rechazo bajo la directriz 2.3.10 Metadatos precisos: la app o sus metadatos mencionaban una plataforma de terceros, y el siguiente paso era eliminar las referencias a Google Play. El desarrollador rastreó la mención hasta el texto que describía una compra dentro de la app. Después de la corrección, la app volvió a la cola, y dos semanas después seguía esperando revisión, 24 días después del primer envío y aún no estaba en vivo.

    Resolución

    Aún esperando revisión al momento de publicar, 24 días después del primer envío.

    Lección

    Busca en cada campo de texto que envíes, incluidas las descripciones de compras dentro de la app, los nombres de otras tiendas y plataformas antes del primer envío. En una cuenta nueva, cada ida y vuelta puede costar una semana o más en la cola, por lo que una mención de una sola palabra puede retrasar el lanzamiento durante semanas.

79. 

    Directriz 2.1 Completitud de la app (Información necesaria) iOS Directriz 2.1 Revisión interminable

    24 días en cola y luego un rechazo por la regla 2.1 pidiendo un screen recording completo

    Qué sucedió

    Un desarrollador envió la versión 1.0.0 de una nueva app iOS junto con un grupo de suscripciones y dos suscripciones, anual y mensual. Tras 24 días de espera, Apple la revisó y la rechazó bajo la directriz 2.1 App Completeness, lo que dejó confundido al desarrollador. Como la versión de la app fue rechazada, las suscripciones enviadas con ella tampoco pudieron aprobarse y se quedaron en Ready for Review. El mensaje del rechazo era una solicitud 2.1 Information Needed, la primera que recibía el desarrollador. Pedía un screen recording en un dispositivo físico con el último sistema operativo, desde el inicio y mostrando el flujo típico del usuario: registro, login y eliminación de cuenta, cualquier contenido generado por el usuario con sus herramientas de reporte y bloqueo, y el acceso a contenido de pago. También pedía una descripción del propósito y el público objetivo, instrucciones de configuración con credenciales de acceso, una lista de los servicios externos de los que depende la app, incluidos los servicios de IA, cualquier diferencia regional y documentación para industrias reguladas o material protegido de terceros. Las respuestas también debían añadirse a las review notes de App Store Connect para futuros envíos.

    Resolución

    El desarrollador estaba de nuevo preparando la grabación y las respuestas al momento de publicar. No se conoce el resultado.

    Lección

    Una solicitud de información necesaria tras semanas en la cola cuesta otro viaje completo. Graba esa demostración en un dispositivo real y escribe esas respuestas en las notas de revisión antes de enviar una nueva app, especialmente una con suscripciones, cuentas o contenido de usuario, ya que una versión rechazada también retiene todo lo enviado con ella.

80. 

    Sección 3.2(f) (Developer Program License Agreement) Programa de desarrolladores de Apple Terminación de cuenta Revisión interminable

    Seis actualizaciones aprobadas seguidas, luego una actualización rutinaria y una terminación 3.2(f)

    Qué sucedió

    Un desarrollador indie tuvo seis actualizaciones aprobadas seguidas. El historial de revisiones que compartió muestra el último envío In Review y todos los anteriores marcados como Review Completed. Luego envió una actualización rutinaria a mediados de octubre, y se quedó atascada en revisión. En lugar de un resultado de revisión, toda la cuenta del desarrollador fue terminada bajo la sección 3.2(f). En App Store Connect, un mensaje fechado el día de ese envío estaba adjunto a múltiples versiones y marcado como problemas sin resolver. El desarrollador describió sus apps como nativas, con un historial limpio de actualizaciones aprobadas, y dijo que el soporte de Apple estaba investigando su apelación.

    Resolución

    Apelación bajo investigación en el momento de la publicación.

    Lección

    Una racha de aprobaciones sin problemas no te protege de una terminación por la 3.2(f). Mantén un registro fechado de cada envío, mensaje de revisión y aprobación, y revisa la sección Messages de App Store Connect después de cada revisión, para poder enviar el historial completo en cuanto sea posible apelar.

81. 

    Solicitud de información de App Review (cuenta demo y grabación de pantalla) iOS Login

    La cuenta de demo se borró cinco minutos después del envío, luego una solicitud de grabación evitó un segundo rechazo

    Qué sucedió

    Una agencia envió la app de un cliente con una cuenta demo para App Review. Cinco minutos después del envío, App Review había borrado esa cuenta demo. Apple solicitó entonces una grabación de pantalla de la app. Mientras hacían la grabación, el equipo detectó un texto de ventas dentro de la app que habían pasado por alto y que habría provocado otro rechazo.

    Resolución

    Resultado final no compartido en el momento de la publicación.

    Lección

    Un revisor puede eliminar la cuenta de demostración que proporciones, por ejemplo, mientras comprueba que la eliminación de la cuenta funciona, así que asegúrate de poder recrearla o proporciona más de una. Graba tu propio recorrido de revisión antes de enviar: ver la app como lo haría un revisor es una forma barata de detectar textos que provocarían el siguiente rechazo.

82. 

    Sección 3.2(f) (Developer Program License Agreement) Programa de desarrolladores de Apple Terminación de cuenta Metadatos e IAP

    Cinco rechazos iniciales, cuatro actualizaciones aprobadas y luego un aviso 3.2(f) más de un año después

    Qué sucedió

    Un desarrollador independiente de iOS con casi diez años de apps a sus espaldas presentó una nueva app de IA para convertir imágenes en video en abril de 2025. Los usuarios subían sus propias fotos, recibían su primera generación gratis y luego podían comprar créditos mediante compras in-app de pago único, sin suscripciones. La primera presentación fue rechazada cinco veces, principalmente por las capturas de pantalla y los metadatos: las capturas se consideraron demasiado orientadas a marketing, y tanto una captura de una pareja besándose como la que la reemplazó, con una propuesta de matrimonio, fueron marcadas bajo la directriz de Contenido objetable. Tras cambiar las capturas, el texto y el build, la app fue aprobada, y siguieron cuatro actualizaciones sin un solo rechazo, la última en agosto de 2025. No se presentó ninguna actualización después. Más de catorce meses después llegó un aviso de terminación pendiente que decía que los envíos de la cuenta habían violado repetidamente las directrices en un intento de evadir la revisión, con infracciones aún sin resolver tras múltiples reenvíos, y se adjuntó a las cinco versiones. El desarrollador dijo que App Store Connect ya no mostraba suficiente detalle para reconstruir los rechazos anteriores. Apeló unos 30 minutos después de que llegara el aviso, cerca de la medianoche, con un límite de 2.000 caracteres, y después lamentó no haber esperado para redactarla con más claridad.

    Resolución

    Apelación pendiente al momento de la publicación.

    Lección

    Una aprobación no cierra el expediente. Guarda tu propia copia de cada mensaje de rechazo, la directriz citada, qué cambiaste y la fecha en que se aprobó, porque puede que App Store Connect no muestre los detalles antiguos más adelante. Si recibes un aviso, tómate el tiempo de redactar una apelación clara que respete el límite de caracteres en vez de enviarla en la primera hora.

83. 

    Sección 3.2(f) (Developer Program License Agreement) Programa de desarrolladores de Apple Terminación de cuenta Metadatos e IAP

    Una palabra clave en el título, una terminación 3.2(f) y una apelación que aludía a referencias de streaming

    Qué sucedió

    A un desarrollador indie le cerraron toda su cuenta de desarrollador bajo la sección 3.2(f). Según su relato, ocurrió sin aviso previo ni rechazo previo de metadatos, y creía que la causa fue un error de keyword en el título de una app. Apeló. El App Review Board respondió que su investigación confirmó violaciones de las directrices: una de las apps del desarrollador incluía referencias engañosas que hacían creer a los usuarios que ofrecía servicios de streaming, algo que Apple calificó de grave. La carta describía un patrón de comportamiento manipulador o engañoso, mantenía en pausa los pagos de ingresos y señalaba que, una vez formalizada la terminación, el desarrollador podría solicitar la reinstalación ante el App Review Board, explicando los motivos y las mejoras planificadas.

    Resolución

    Recurso denegado. Es posible presentar una solicitud de reinstalación tras la terminación formal.

    Lección

    Palabras en el título o en las palabras clave que sugieran un servicio que la app no ofrece, como streaming, pueden interpretarse como engañosas en lugar de un simple error de metadatos, lo que puede llevar directamente a la terminación sin una denegación previa. Revisa cada título, subtítulo y palabra clave contra lo que la app realmente hace antes de enviarla.

84. 

    Directriz 4.1(a) Copias iOS Revisión interminable

    15 días en revisión, luego 4.1(a) Copias por pósters de películas de un API público

    Qué sucedió

    Un desarrollador creó una app de iOS que ayuda a las personas a elegir una película. Muestra títulos y pósters obtenidos de una base de datos de películas pública API, con crédito dentro de la app, y su botón de ver abre la app de streaming oficial en lugar de reproducir contenido por sí misma. Después de 15 días en revisión, Apple la rechazó bajo la directriz 4.1(a) Copias, tratando los pósters como contenido de terceros y pidiendo prueba de los derechos para usarlos, o su eliminación. La misma app con los mismos pósters había sido aprobada en Android y en una tienda de apps para dispositivos de TV.

    Resolución

    Sin resolver en el momento de la publicación. El desarrollador preguntaba a otros desarrolladores si los términos de API se habían aceptado como prueba o si había que retirar los carteles.

    Lección

    Los créditos dentro de la app y la aprobación en otras tiendas no cuentan como derechos para App Review. Si tu app muestra carteles, ilustraciones o logos de un API, ten preparada una prueba escrita de que puedes mostrarlos antes de enviarla, o planifica una versión sin ellos.

85. 

    Rechazo de metadatos (palabra clave localizada) iOS Metadatos e IAP

    La IA tradujo la app a cinco idiomas y coló una palabra clave que provocó su rechazo

    Qué sucedió

    Un desarrollador usó un modelo de IA para traducir su app a cinco idiomas más. En uno de ellos, la traducción añadió una palabra clave que se podía malinterpretar y le rechazaron el envío por eso. Una semana después seguía esperando una respuesta y, tras una semana de casos de terminación 3.2(f) de otros desarrolladores, temía que incluso una corrección aprobada pudiera acabar pesando en contra de la cuenta.

    Resolución

    Al momento de publicar, aún estamos esperando respuesta de Apple.

    Lección

    Pide a alguien que domine cada idioma que revise cada keyword, título y subtítulo localizado antes de enviar. La traducción automática es rápida, pero App Review evalúa las palabras de cada locale como si las hubieras elegido tú mismo.

86. 

    Metadatos de App preview (referencia de precio) iOS Metadatos e IAP

    Una App preview decía que había una prueba gratuita y rechazaron la actualización

    Qué sucedió

    Un desarrollador indie envió una actualización cuyo video de App preview incluía las palabras free trial available. Apple rechazó la actualización, considerando cualquier mención de 'free' en el preview como una referencia de precio. El desarrollador volvió a editar el video y lo envió de nuevo.

    Resolución

    Vídeo recortado y reenviado. El resultado final no se compartió al momento de la publicación.

    Lección

    Mantén los precios y la palabra «gratis» fuera de las vistas previas de la app, incluso si la prueba es real. Muestra los términos de la prueba dentro de la app, en el paywall.

87. 

    Directriz 2.5.1 Requisitos de software (HealthKit) iOS Revisión interminable

    Seis días de espera, luego 2.5.1 porque la sincronización con Health no tenía la insignia de Apple Health

    Qué sucedió

    Un desarrollador indie envió una actualización importante que añadía sincronización con Apple Health por primera vez. Quedó en «Esperando revisión» durante seis días. Solo entonces notó un nuevo acuerdo de desarrollador pendiente de firma en su cuenta. Lo firmó y la actualización entró en revisión esa misma tarde, aunque no pudo decir si estaban relacionados. La actualización fue rechazada bajo la directriz 2.5.1 porque la función de Health no se identificaba claramente en la interfaz de la app. El desarrollador no sabía nada de la insignia de Apple Health.

    Resolución

    Añadí la insignia Works with Apple Health junto al interruptor de sincronización, una nota para la revisión y una grabación de pantalla hecha en un dispositivo real. Se aprobó en el siguiente envío.

    Lección

    Si tu app lee o escribe datos de salud, muéstralo claramente en la interfaz con la insignia de Apple Health desde el primer envío. Y cuando una revisión se quede estancada durante días, revisa App Store Connect por si hay un acuerdo sin firmar antes que nada.

88. 

    Directriz 1.1 Contenido objetable iOS Contenido inapropiado

    Publicada durante más de un año sin rechazos y luego retirada por la 1.1 sin aviso

    Qué sucedió

    Un desarrollador indie tenía una app en el App Store desde hacía más de un año. Nunca había sido rechazada y le generaba unos modestos ingresos mensuales por suscripción. Sin previo aviso, Apple envió un mensaje diciendo que la app había sido retirada de la tienda por infringir la directriz 1.1 Contenido objetable.

    Resolución

    El desarrollador le dijo a Apple que no volvería a enviarla, abandonó la app y todo el nicho porque no quería poner en riesgo su cuenta de desarrollador.

    Lección

    Un historial de revisión limpio no protege una app de que la retiren más adelante, y las reglas de contenido pueden aplicarse a una app que estuvo aprobada mucho tiempo. Si tu app está en un nicho sensible, revisa ahora su contenido y capturas de pantalla conforme a la directriz 1.1, no después de un aviso de retirada.

89. 

    Rechazo por bug (guía no especificada) iOS Revisión interminable

    Un timeout de matchmaking de 100 segundos se reportó como bug, y luego seis días esperando una respuesta

    Qué sucedió

    Un desarrollador envió un juego multijugador. El revisor lo rechazó por un bug, pero lo que encontró no fue un crash: el juego deja de buscar tras esperar 100 segundos para emparejar al jugador con un oponente, y el revisor vio ese timeout como un fallo. El desarrollador respondió al revisor explicando cómo funciona el matchmaking y también eliminó el timeout del juego. Seis días después, seguía esperando una sola respuesta.

    Resolución

    Se explicó en una respuesta y se eliminó el timeout. Al momento de publicar, seguimos esperando respuesta.

    Lección

    Un revisor suele jugar solo y a una hora rara, así que es probable que la cola de matchmaking esté vacía. Dale al equipo de revisión una forma de llegar a una partida real, como un oponente bot o un modo demo, y explícalo en las notas de revisión antes de enviar.

90. 

    Rechazo por metadatos (enlaces de Términos y Privacidad) iOS Metadatos e IAP

    Code reutilizado de otra app, y los enlaces de Términos y Privacidad aún apuntaban a la anterior

    Qué sucedió

    Un desarrollador creó una nueva app reutilizando partes de una anterior. Los enlaces de Términos de Uso y Política de Privacidad seguían apuntando a la app anterior, y App Review rechazó el envío por eso. El desarrollador dijo que el mensaje de rechazo detallaba exactamente qué había que cambiar.

    Resolución

    Corregí los enlaces y volví a enviarlo. El desarrollador dijo que una revisión acelerada suele tardar un día, pero que debe usarse con moderación.

    Lección

    Antes de enviar una app creada desde un proyecto antiguo, revisa cada enlace, nombre de bundle y página legal que se herede. Lee el mensaje de rechazo con atención, porque a menudo indica exactamente qué corregir.

91. 

    Directriz 2.1 Información necesaria iOS Directriz 2.1

    Sin bugs en el informe, solo 2.1 Información Necesaria, respondido con una grabación de 89 segundos

    Qué sucedió

    Un desarrollador envió su segunda app y fue rechazada bajo la directriz 2.1 Información Necesaria, sin ningún bug listado. App Review pidió una grabación de pantalla y respuestas sobre para quién es la app, cómo se usa, qué servicios externos utiliza y en qué regiones está disponible. El desarrollador grabó 89 segundos en el simulador, desde el lanzamiento hasta un uso completo de la función principal hasta el paywall, respondió todas las preguntas en las notas y volvió a enviarla el mismo día.

    Resolución

    Grabación y respuestas enviadas el mismo día. El resultado final no se compartió al momento de publicar.

    Lección

    Para una app nueva, espera una solicitud de información 2.1 y prepárate. Ten preparada una grabación corta del flujo principal y respuestas escritas sobre audiencia, uso, servicios externos y regiones en las notas de revisión antes de enviar, para que la primera revisión no se detenga por dudas.

92. 

    Directriz 2.5.4 Software Requirements (background modes) iOS Revisión interminable

    Rechazado por un checkbox olvidado, el audio background mode, y luego diez días para la siguiente actualización

    Qué sucedió

    Un equipo pequeño envió una actualización para una app que ya estaba publicada. App Review la rechazó bajo la directriz 2.5.4 por un solo ajuste: el audio background mode estaba activado y la app no lo necesitaba. El equipo eliminó el background mode y la volvió a enviar el mismo día, lo que les costó aproximadamente un día. Su siguiente actualización se quedó en revisión unos diez días.

    Resolución

    Eliminé el modo de fondo de audio y volví a enviarlo el mismo día. La siguiente actualización esperó unos diez días en revisión.

    Lección

    Los modos en segundo plano solo están permitidos para su propósito previsto. Antes de cada envío, abre la capacidad Background Modes y elimina todo lo que la app no use realmente, porque una casilla olvidada basta para un rechazo, y no puedes predecir cuánto durará la próxima revisión.

93. 

    Directriz 4.3(a) Spam iOS Directriz 4.3

    Una web app en un wrapper recibió spam 4.3(a), así que el desarrollador la reconstruyó como app nativa

    Qué sucedió

    Un desarrollador envió la primera versión de su app como una web app dentro de un wrapper nativo. App Review la rechazó bajo la directriz 4.3(a), la regla de spam. El desarrollador admitió que Apple tenía razón. Reconstruyó la app como una app nativa real, movió su backend a un servidor relay que él mismo opera y publicó el código fuente code.

    Resolución

    Reconstruida como una app nativa con un servidor relay autoalojado. El resultado de la versión reconstruida no se compartió en la publicación.

    Lección

    Un wrapper fino alrededor de un sitio web es fácil que App Review lo lea como spam. Si publicas en la App Store, da a la app un valor nativo real desde el primer envío, en lugar de esperar que un sitio envuelto pase la revisión.

94. 

    Rechazo por contenido ofensivo (capturas de pantalla, luego subtítulo) iOS Contenido inapropiado Metadatos e IAP

    Capturas de pantalla marcadas como ofensivas, luego el subtítulo, para un juego sin nada adulto

    Qué sucedió

    Un pequeño estudio crea juegos de historia simples para iOS, sin temas adultos, apuestas ni cripto. Un juego, donde el jugador es una celebridad intentando triunfar en Hollywood, fue rechazado por contenido ofensivo en sus capturas de pantalla. Las capturas solo mostraban personajes completamente vestidos del juego. El estudio reemplazó cada captura y volvió a enviarlo. El siguiente rechazo fue por contenido ofensivo en el subtítulo, que simplemente describía el juego como juegos de vida y drama de celebridades. Cada revisión tomó semanas.

    Resolución

    La app se envió por primera vez en septiembre y a finales de octubre seguía sin aprobarse.

    Lección

    Si App Review marca los metadatos como objetables sin decir por qué, pregunta en App Store Connect qué elemento exacto es el problema y por qué antes de rehacerlo todo. Revisa capturas, subtítulo y keywords juntos antes de reenviar, porque arreglar uno puede destapar el siguiente.

95. 

    Directriz 5.2.5 Legal, Propiedad Intelectual iOS Directriz 5 (Legal) Metadatos e IAP

    Rechazado por la 5.2.5 porque las capturas mostraban un dispositivo que parecía un iPhone

    Qué sucedió

    Un desarrollador fue rechazado bajo la directriz 5.2.5. App Review indicó que los metadatos contenían imágenes similares a un iPhone en las capturas, lo que podía confundir a los usuarios con productos de Apple. Los dispositivos mostrados no eran de Apple, solo parecidos, y el desarrollador se sorprendió porque otra de sus apps ya había sido aprobada con el mismo tipo de imágenes de dispositivos.

    Resolución

    El resultado final no se compartió al momento de la publicación. Otro desarrollador comentó que App Review también puede objetar marcos de dispositivos que no coincidan con la plataforma o renders que se vean distintos a los iPhones reales.

    Lección

    La aprobación de una app no sienta precedente para la siguiente. Los mockups de dispositivos que parecen casi un iPhone pueden considerarse confusamente similares a los productos de Apple. Usa capturas de pantalla simples, o solo los marcos de dispositivos que Apple proporciona para marketing, y asegúrate de que coincidan con la plataforma.

96. 

    Directriz 2.1 Información necesaria iOS Directriz 2.1

    La primera app iOS recibió una solicitud de información 2.1 y se arregló haciendo todo fácil de encontrar

    Qué sucedió

    Un desarrollador independiente, cuya versión de Android ya estaba publicada en Google Play, envió su primera app para iOS. Tenía tres compras in-app y contenido generado por usuarios. App Review no la rechazó de plano, sino que envió una solicitud de información según la directriz 2.1. El desarrollador releyó la directriz 2.1, que exige que cada compra in-app sea visible y funcional para el revisor, y también revisó las reglas para contenido generado por usuarios (1.2) y eliminación de cuenta (5.1.1(v)). Al día siguiente, reenvió un nuevo build con una opción visible para reportar y bloquear en cada contenido de usuario, reglas de la comunidad que los usuarios aceptan antes de publicar, opciones para cerrar sesión y cambiar de cuenta, y una grabación de pantalla que muestra dónde están las compras, las herramientas de seguridad y los controles de cuenta.

    Resolución

    Nuevo build enviado el día siguiente a la solicitud. Resultado desconocido al momento de la publicación.

    Lección

    Trata la revisión como una prueba de usabilidad con un desconocido y poco tiempo. Cada compra, cada opción de reporte y bloqueo, y cada control de cuenta deben ser fáciles de encontrar en segundos, y una grabación en las notas de revisión debe indicar dónde encontrar cada uno. Estar publicado en Google Play no dice nada sobre pasar App Review.

97. 

    Directriz 4.3(a) Diseño, Spam iOS Directriz 4.3 Revisión interminable

    Veintisiete días en la cola para una app nueva y luego un rechazo por spam 4.3(a)

    Qué sucedió

    Un desarrollador envió una app totalmente nueva y esperó 27 días a que App Review la revisara. Cuando el resultado por fin apareció en App Store Connect, era un rechazo por la directriz 4.3(a), Diseño, Spam. El desarrollador preguntó entonces a otros desarrolladores si alguien había logrado superar un rechazo por la 4.3(a).

    Resolución

    No se compartió ninguna solución en el momento de la publicación. El desarrollador buscaba consejos de otros que ya hubieran pasado por la 4.3(a).

    Lección

    Una espera larga no es señal de que la app esté a salvo. Con colas de revisión tan lentas, un rechazo por la 4.3(a) tras semanas cuesta un mes entero. Antes de enviar una app nueva, sé honesto sobre qué la hace diferente de las apps que ya están en su categoría y dilo claramente en las notas de revisión y en los metadatos.

98. 

    Directriz 4.3(a) Diseño, Spam macOS Directriz 4.3

    La app para iPhone ya estaba publicada, pero luego su versión para Mac fue rechazada por spam

    Qué sucedió

    Un desarrollador tenía una app de iPhone ya publicada en la App Store y creó una versión nativa de escritorio de la misma app para Mac. App Review rechazó la app de Mac bajo la directriz 4.3(a). El mensaje decía que la app compartía un binario, unos metadatos o un concepto similares con apps enviadas por otros desarrolladores, con solo diferencias menores, y sugería enviar una app única con contenido y funcionalidad distintos. El desarrollador preguntó a la comunidad qué les había funcionado a otros que se enfrentaron al 4.3.

    Resolución

    No se compartió ninguna resolución en el momento de la publicación.

    Lección

    Cada plataforma recibe su propia revisión, y una app de iPhone aprobada no se traslada a Mac. Un mensaje 4.3(a) compara tu app con apps de otros desarrolladores, así que al responder, explica concretamente qué hace tu app que las similares no hacen, y señala las funciones que solo tiene la tuya.

99. 

    Revisión interminable iOS Revisión interminable

    Más de catorce días en revisión acabaron en un rechazo, y el reenvío esperó dos semanas más

    Qué sucedió

    Un desarrollador contó que su revisión anterior tardó más de catorce días y terminó en un rechazo. Reenvió la solicitud el 21 de octubre y, casi dos semanas después, el envío seguía en "Esperando revisión", mientras que Apple indica que la mayoría de las revisiones tardan de 24 a 48 horas.

    Resolución

    Aún en espera de revisión al momento de publicar.

    Lección

    Los tiempos de revisión promedio no describen el peor caso, y un rechazo te devuelve al final de una cola lenta. Planifica los lanzamientos con semanas de margen y haz que el primer envío sea lo más completo posible para que un rechazo no duplique la espera.

100. 

     Requisito de eliminación de cuenta (directriz 5.1.1(v)) iOS Directriz 5.1.1

     Rechazado por falta de eliminación de cuenta, después de que el primer revisor eliminara varias cuentas

     Qué sucedió

     Un desarrollador con una app basada en contenido generado por usuarios públicos fue rechazada en su segunda revisión por falta de eliminación de cuenta. Sus logs mostraban que, durante la primera revisión, el revisor había creado y eliminado varias cuentas sin ningún problema. El desarrollador sintió que el rechazo tenía más que ver con la categoría estricta que con la funcionalidad que realmente faltaba.

     Resolución

     No se compartió ninguna resolución en el momento de la publicación.

     Lección

     Incluso cuando una funcionalidad funciona, el revisor debe encontrarla rápidamente. Coloca la ruta de eliminación de cuenta en las notas de revisión con las pantallas exactas a tocar, y adjunta una grabación corta. Para apps con contenido generado por usuarios, muestra también el reporte, bloqueo y moderación, porque esas categorías reciben la revisión más cercana.

101. 

     Directriz 2.1(a) Completitud de la App macOS Directriz 2.1

     Una app para Mac rechazada bajo 2.1(a) por leer el keychain de inicio de sesión, y las notas de rechazo antiguas desaparecieron

     Qué sucedió

     Un desarrollador envió una app para Mac y App Review la rechazó bajo la directriz 2.1(a) porque la app leía del keychain de inicio de sesión. La corrección tomó una sola actualización. Lo que tomó al desarrollador por sorpresa fue App Store Connect: solo muestra las últimas diez envíos, por lo que los mensajes de rechazo antiguos desaparecen silenciosamente del historial.

     Resolución

     Corregido en una sola actualización. El desarrollador ahora copia cada mensaje de rechazo en el commit que lo corrige.

     Lección

     No confíes en App Store Connect como tu registro de rechazos pasados, porque los envíos antiguos salen de la vista. Guarda el texto completo del rechazo junto con la corrección, en el commit, el ticket o tus release notes, para que tengas la redacción exacta si el mismo problema vuelve a aparecer.

102. 

     Directriz 1.4.1 Daño Físico (salud y médico) iOS Revisión interminable

     Diez días en revisión para una app de salud, luego un rechazo 1.4.1 corregido con una página de fuentes en una sola tarde

     Qué sucedió

     Un desarrollador indie que creaba una app de salud esperó más de diez días en la revisión de App Store. El veredicto fue un rechazo bajo la directriz 1.4.1, que cubre apps de salud y médicas. La solución fue pequeña: el desarrollador añadió una página de fuentes citando de dónde provenía la información de salud en la app, y tardó una sola tarde en construirla.

     Resolución

     Añadió una página de fuentes con citas, lo que tardó una tarde. No se compartió en la publicación si la reenvío fue aprobado.

     Lección

     Las apps de salud se evalúan con un estándar más alto, y una espera larga puede terminar con una solicitud que podrías haber cumplido antes de enviar. Si tu app muestra información de salud o médica, añade citas claras en la app antes del primer envío. Un desarrollador que respondió señaló que un recordatorio visible para consultar con un médico es otra solicitud común.

103. 

     Compra in-app demasiado difícil de alcanzar para el revisor (número de directriz no especificado) iOS Metadatos e IAP

     Una actualización de juego rechazada porque el paywall estaba demasiado profundo, y aprobada en 26 horas tras mover el desbloqueo a la pantalla de título

     Qué sucedió

     Un desarrollador indie necesitó 33 días y dos rechazos para que se aprobara la versión 1.0 de su juego de iOS. La primera actualización, 1.0.1, también fue rechazada porque el paywall estaba demasiado profundo en el juego para que el revisor pudiera alcanzarlo. El desarrollador añadió un botón de desbloqueo en la pantalla de título y volvió a enviarlo. Esta vez, todo el proceso tardó unas 26 horas, con solo unos 12 minutos en revisión real.

     Resolución

     Añadió un botón de desbloqueo en la pantalla de título. La actualización se aprobó unas 26 horas después de reenviarla.

     Lección

     Un revisor no va a jugar a tu juego durante veinte minutos para encontrar lo que vendes. Coloca cada compra donde se pueda acceder en segundos, o describe la ruta exacta en las notas de revisión para que el revisor pueda probarla sin buscar.

104. 

     Desajuste de metadatos de compra in-app (número de directriz no especificado) iOS Metadatos e IAP

     Rechazado porque el paywall decía 1 mes gratis mientras Apple mostraba el cargo anual

     Qué sucedió

     Un desarrollador pasó de semanas en TestFlight a un lanzamiento público en la App Store y tuvo un build rechazado por el paywall. El paywall decía 1 mes gratis, pero la pantalla de compra de Apple mostraba el cargo anual comenzando ese mismo día. El revisor tampoco pudo encontrar el plan semanal. El desarrollador corrigió el texto del paywall y la visibilidad de los planes, envió otro build y esperó la revisión de nuevo.

     Resolución

     Corrigió el paywall para que la redacción de la prueba gratuita coincidiera con la hoja de compra y el plan semanal fuera accesible. La app luego se lanzó en la App Store.

     Lección

     Lo que tu paywall promete debe coincidir con lo que muestra la hoja de compra de Apple, incluida la duración de la prueba y cuándo comienza la facturación. Coloca cada plan que el revisor necesita probar donde pueda acceder en un par de toques, y verifica esa ruta en una instalación nueva antes de enviar.

105. 

     Directriz 2.1 Completitud de la App (crash al iniciar) iOS Directriz 2.1

     Un reenvío con correcciones de rendimiento adicionales causó un crash al iniciar y costó un día completo

     Qué sucedió

     Tras un primer rechazo de la App Store que solo pedía más información, el desarrollador decidió incluir correcciones de rendimiento en el mismo reenvío. Estaba tan seguro de sí mismo que también eliminó una restricción de hardware destinada a dispositivos de gama alta para juegos. App Review rechazó el build de nuevo porque se cerraba al iniciar, sin logs de crash, solo un mensaje automatizado. El desarrollador asumió que era un kill por memoria, restauró la restricción y pasó el día reduciendo assets, retrasando cargas y liberando recursos sin perder rendimiento.

     Resolución

     Restauró la restricción de hardware, redujo la huella de memoria y preparó un tercer envío para el día siguiente. El resultado final tras la tercera ronda no se compartió en la publicación.

     Lección

     No acumules correcciones no relacionadas en un reenvío destinado a responder a una pregunta de revisión. Publica el cambio más pequeño que responda al rechazo, mantén las restricciones de estabilidad activas para el dispositivo más bajo que declares como compatible, y realiza un cold start en ese dispositivo antes de volver a subir el build.

106. 

     Directriz 4.3(a) Design Spam iOS Directriz 4.3

     Varios juegos pequeños enviados juntos chocaron con la 4.3(a), y luego dos apelaciones fueron revocadas

     Qué sucedió

     Un desarrollador envió varios juegos pequeños a la App Store casi al mismo tiempo. Todos fueron rechazados bajo la directriz 4.3(a) por spam. Después de esa oleada, cambió su proceso y ahora solo envía un juego a la vez. Dos de esos rechazos se revocaron posteriormente tras una apelación ante el App Review Board.

     Resolución

     Pasó a hacer un envío a la vez. Dos de los rechazos por 4.3(a) se revocaron tras apelar ante el App Review Board.

     Lección

     Agrupar apps similares en la misma ventana de revisión invita a que se marque todo el conjunto como spam. Envía una a la vez y, si un rechazo por 4.3(a) parece incorrecto, apela ante el App Review Board con argumentos claros sobre por qué cada app es distinta.

107. 

     Directriz 1.1 Seguridad, contenido objetable (metadatos de la app) iOS Contenido inapropiado Metadatos e IAP

     Una app de recuperación fue rechazada bajo la directriz 1.1 porque su marketing nombraba el hábito que ayuda a dejar

     Qué sucedió

     Una app diseñada para ayudar a las personas a superar la pornografía y la lujuria fue rechazada bajo la directriz 1.1. App Review indicó que el marketing de la app hacía referencia a contenido ofensivo en sus metadatos, incluyendo la descripción, las capturas de pantalla y las palabras clave. Cuando el desarrollador pidió detalles, App Review nombró una palabra clave, porn, dijo que esa lista no era exhaustiva, advirtió que la app recibiría una revisión completa al reenviarla y afirmó que reenviar con el mismo marketing, o como una app nueva con el mismo concepto, traería las mismas o más violaciones. El desarrollador señaló que apps similares ya en la tienda promocionan abiertamente ayuda con la tentación sexual.

     Resolución

     No resuelto al momento de la publicación. App Review pidió que se eliminara toda referencia a contenido ofensivo de los metadatos antes de una nueva revisión completa, y el desarrollador cuestionó públicamente por qué se trataba de manera diferente a apps similares.

     Lección

     Las apps que ayudan a las personas a dejar algo adulto se juzgan por las palabras de su propio marketing, no por su intención. Describe el objetivo, como recuperación o autocontrol, en lugar de nombrar el vicio en palabras clave, descripción y capturas de pantalla, y pregunta a App Review qué términos exactos provocaron el rechazo antes de reenviar, porque el próximo envío recibirá una revisión completa.

108. 

     Icono de la app marcado como ofensivo (sin especificar la directriz) iOS Contenido inapropiado Metadatos e IAP

     Un icono de app ya aprobado fue rechazado por mostrar demasiada piel

     Qué sucedió

     Una app de IA usó un personaje ilustrado como icono, con un top corto que mostraba parte del pecho y el abdomen. Ese mismo icono había pasado la revisión de la app antes. En una posterior, Apple lo rechazó porque el pecho y el vientre estaban demasiado expuestos. El desarrollador redibujó el personaje con una prenda completa que cubría ambas zonas y volvió a enviarlo.

     Resolución

     Redibujó el icono para que la prenda cubriera el pecho y el abdomen. La publicación no indicó cuánto tardó la nueva revisión.

     Lección

     Una aprobación anterior no garantiza tu icono ni tus capturas, ya que cada envío puede evaluarse de nuevo. Si un personaje en tu arte muestra piel, asume que un revisor más estricto podría marcarlo y ten lista una variante más cubierta para que la corrección sea un cambio, no un rediseño.

109. 

     Flujo de cancelación de suscripción (número de directriz no especificado) iOS Metadatos e IAP

     Rechazado por un paso extra de confirmación al cancelar, una semana antes de que Apple lanzara los mensajes de retención

     Qué sucedió

     Una app de suscripción mostraba su propia pantalla de confirmación cuando los usuarios intentaban cancelar. App Review rechazó la app por ello. Menos de una semana después, App Store Connect anunció los mensajes de retención, que permiten a los desarrolladores mostrar a los suscriptores un mensaje, con una imagen opcional o una oferta de retención, cuando intentan cancelar su suscripción.

     Resolución

     La publicación no detalló cómo se resolvió el rechazo. La nueva función de App Store Connect ahora ofrece una forma aprobada por Apple para mostrar un mensaje en el momento de la cancelación.

     Lección

     No añadas fricción propia antes de la cancelación de suscripción. Deja que los usuarios accedan directamente al flujo de cancelación y, si quieres una última oportunidad de retenerlos, usa los mensajes y ofertas de retención de Apple en lugar de una pantalla personalizada.

110. 

     Directrices 5.6 Developer Code of Conduct y 2.5.19 Funciones ocultas iOS Directriz 5.6 Developer Code of Conduct Directriz 2.5.19 Funciones ocultas

     Rechazado por 5.6 por funciones ocultas que resultaron ser code de pago incrustado en una suscripción SDK

     Qué sucedió

     Un desarrollador independiente tuvo su app de seguimiento de objetivos para iOS rechazada siete veces antes del lanzamiento. Un rechazo anterior fue por apuestas con dinero real. El último llegó bajo el Código Code de Conducta: App Review dijo que la app tenía funcionalidad oculta o engañosa y pidió eliminar todas las funciones ocultas, sin especificar cuál. La app no tenía banderas de función remotas, no descargaba code y no tenía comportamiento especial para revisores. En lugar de adivinar, el desarrollador escaneó su propio binario de lanzamiento y encontró code de pago web de un proveedor de pagos que nunca había escrito. Venía incrustado dentro de su SDK de suscripción para esa plataforma web SDK, y la app de iOS nunca lo usó. Dado el rechazo anterior por apuestas con dinero, el desarrollador sospechó que parecía una ruta de pago oculta.

     Resolución

     Sin cambiar ninguna línea de code, el desarrollador respondió a App Review con hechos concretos: qué hace y qué no hace la app, que no hay dinero real en juego, de dónde venía el code de checkout, que se eliminarían el SDK web de code sin usar y el permiso de biblioteca de fotos no utilizado en la próxima build, y una solicitud para que nombraran la pantalla señalada. Nueve horas después, App Review indicó que continuaría la revisión y la app se publicó.

     Lección

     Conoce todo lo que tu binario incluye, incluidos los code que tus SDKs traen para otras plataformas, porque App Review juzga lo que hay en la build, no lo que tú llamas. Tras un rechazo 5.6, no adivines y resubmitas. Responde con calma, con detalles específicos y pregunta qué pantalla o comportamiento fue señalado.

111. 

     Directriz 2.3.4 Metadatos Precisos (Vistas previas de la app) iOS Metadatos e IAP

     Una App Preview que pasó la revisión en octubre fue rechazada por su encuadre bajo la norma 2.3.4 un mes después

     Qué sucedió

     Un desarrollador envió una actualización a su app de iOS y fue rechazada bajo la directriz 2.3.4. App Review dijo que el video de la vista previa de la app tenía un encuadre alrededor de la captura de pantalla. El mismo video había pasado la revisión el mes anterior. El desarrollador señaló que otras apps en la tienda, incluida una muy conocida cuya vista previa muestra a una persona en lugar de la app, usan vistas previas con poco o ningún material de la propia app.

     Resolución

     El desarrollador eliminó por completo el video de App Preview y volvió a enviar la actualización. La publicación no indica cómo fue la nueva revisión.

     Lección

     Un App Preview que pasó una vez aún puede ser rechazado en una actualización posterior, ya que cada envío se revisa de nuevo. Mantén las vistas previas como capturas de pantalla simples de la app, sin marcos decorativos alrededor de la captura, y si una es marcada, eliminarla es la forma más rápida de desbloquear la actualización mientras la rehaces.

112. 

     Sección 3.2(f) (Developer Program License Agreement) macOS Terminación de cuenta Revisión interminable

     Una actualización de macOS que corrigió un problema de icono estuvo en revisión durante unos 45 días, luego llegó un aviso de 3.2(f)

     Qué sucedió

     Un desarrollador independiente tenía una app de macOS que App Review había marcado por problemas de marca. El 15 de septiembre de 2026, envió una actualización que abordaba el feedback, incluido un icono de app completamente rediseñado. La actualización luego permaneció In Review durante unos 45 días sin decisión, y el desarrollador envió dos solicitudes de revisión acelerada a través de los canales oficiales. El 30 de octubre de 2026, mientras esa actualización corregida aún esperaba, llegó un Aviso de Terminación Pendiente de la Cuenta de Desarrollador bajo la sección 3.2(f).

     Resolución

     Recurso pendiente al momento de la publicación. El desarrollador presentó un recurso formal y contactó por separado al Soporte para Desarrolladores, sin haber recibido una respuesta sustancial.

     Lección

     Una corrección en espera no pausa la aplicación de las normas a envíos anteriores. Mantén un registro fechado de cada rechazo, cada cambio realizado en respuesta y cada solicitud de aceleración, para que el recurso muestre exactamente qué corregiste y cuándo.

113. 

     Directriz 3.2.2 Modelos de negocio inaceptables iOS Directriz 3.2.2

     Una app de retos de pago fue rechazada por la 3.2.2, y una llamada con App Review confirmó que todo el modelo estaba fuera

     Qué sucedió

     Un equipo que ya operaba una app de fitness con miles de usuarios creó una segunda app de iOS centrada en retos de pasos de pago: los usuarios pagan una tarifa para unirse a un reto de caminata, el mismo modelo básico que varias apps de fitness ya en la tienda. App Review la rechazó bajo la directriz 3.2.2. La explicación fue que cualquier modelo basado en penalizaciones no está permitido, ya sea que los usuarios paguen antes de que comience el reto o se les cobre después de no cumplir una meta. El equipo se reunió con el equipo de App Review para preguntar qué cambiar, y se les dijo que el concepto en sí no estaba permitido, no una pantalla o paso específico del flujo.

     Resolución

     El equipo decidió no apelar porque no quería poner en riesgo su cuenta de desarrollador. En el momento de publicar, la app no estaba en la tienda, y aún no entendían por qué otras apps con el mismo modelo siguen activas.

     Lección

     Las apps similares ya en la tienda no son un precedente que App Review aceptará, ya que tu build se evalúa según cómo se interpreta la directriz hoy. Si el dinero cambia de manos según si un usuario alcanza una meta, verifica ese modelo contra la 3.2.2 antes de construir todo el producto en torno a él, por ejemplo, preguntando directamente a App Review.

114. 

     Directriz 5.6 Developer Code of Conduct iOS Directriz 5.6 Developer Code of Conduct

     Una actualización rechazada bajo la 5.6 por funciones ocultas recibió exactamente el mismo rechazo tras una segunda revisión que duró casi tres semanas

     Qué sucedió

     Un desarrollador envió una actualización de su app iOS y fue rechazada bajo el Código de Conducta para Desarrolladores Code. La notificación decía que App Review había visto un patrón de comportamiento inusual asociado comúnmente con actividad fraudulenta, en concreto funciones que parecían haberse ocultado intencionalmente durante la revisión. El desarrollador dijo que no había nada oculto en la app y que no usaba trucos ni comportamientos engañosos. Volvió a subir la app con una explicación de exactamente qué hace, y luego esperó casi tres semanas para la segunda revisión. Recibió el mismo rechazo exacto, todavía sin que se nombrara ninguna función ni pantalla.

     Resolución

     Sin resolver en el momento de la publicación. El desarrollador dijo que presentaría una apelación.

     Lección

     Una notificación genérica de la 5.6 que no menciona ninguna función rara vez se resuelve con el mismo build más una explicación. Pregunta a App Review en el hilo qué pantalla o comportamiento se marcó, revisa qué SDK incluye tu binario y usa la apelación formal cuando las respuestas no lleven a ningún lado.

115. 

     Directriz 4.3(a) Spam iOS Directriz 4.3

     Un nuevo juego de una serie indie fue rechazado bajo la 4.3(a) por ser demasiado similar a juegos anteriores del propio desarrollador

     Qué sucedió

     Un desarrollador independiente estaba preparando el lanzamiento en iOS de un nuevo juego de su propia serie, mientras lo traducía a más idiomas. App Review rechazó la versión de iOS por spam bajo la directriz 4.3(a), alegando que era demasiado similar a los juegos anteriores del desarrollador. Este había rediseñado significativamente el sistema de combate principal, pero admitió que partes heredadas de la serie, como la interfaz básica, los iconos y el logo, seguían pareciéndose mucho a los títulos anteriores. App Review solo envió el mensaje de rechazo estándar, y una semana después de pedir más detalles, el desarrollador no había recibido respuesta.

     Resolución

     Sin resolver al momento de la publicación. El desarrollador estaba explicando a App Review qué hace que el nuevo juego sea diferente de los títulos anteriores, y dijo que no podía decir cuándo o si la versión de iOS se lanzaría.

     Lección

     Bajo 4.3(a), tu propio catálogo anterior cuenta como la comparación, por lo que una secuela que reutilice la interfaz, los iconos y la marca de juegos anteriores puede interpretarse como un duplicado incluso si el gameplay cambió. Haz que las partes nuevas sean evidentes en el build y en las capturas de pantalla, y enuméralas para el revisor en las notas antes de enviar.

Esta página no constituye asesoramiento legal ni predice lo que Apple hará con tu próximo envío.