Nota, agosto de 2026: esta entrada es de una versión anterior y describe la estructura de niveles de aquel momento. AlcoLog fusionó el nivel Pro con Premium en la v1.2.0, así que ahora hay un único nivel de pago. No se perdió nada en la fusión, y quien tenía Pro pasó a Premium sin coste adicional.

Si estás a punto de publicar una v1.0 de iOS con suscripciones, compras dentro de la app, una app complementaria para el reloj, widgets o cualquier tipo de posicionamiento cercano a la salud, el proceso de App Review va a ser más duro de lo que sugiere la documentación. Esta entrada es la crónica de un ciclo de lanzamiento (cuatro rechazos en cinco días, cinco revisores, un solo binario) y de los patrones que hicieron el ciclo llevadero. La comparto porque esta experiencia es una de las partes menos documentadas de publicar una app indie seria, y la versión documentada (las sesiones de la WWDC, la página de las Review Guidelines, los foros de desarrollo) no coincide con la realidad del día a día.

Si estás a mitad del ciclo y buscas arreglos tácticos, salta directamente a “Lo que hay que arreglar antes de enviar” y “Patrones que conviene entender”. La cronología personal está en la segunda mitad si quieres contexto.

# Lo que hay que arreglar antes de enviar

Estos son los puntos que salieron a lo largo de cuatro rechazos. Si los arreglas de entrada, eliminas el grueso de la superficie de rechazo de una v1.0 con suscripciones en una categoría sensible.

# La jerarquía del precio en los muros de pago de suscripción

Las Human Interface Guidelines de Apple para suscripciones no dejan lugar a dudas sobre cómo presentar el precio. El importe que se cobra tiene que ser el elemento de precio más destacado. El instinto de marketing (hacer que el descuento parezca el premio) es el instinto equivocado aquí. El instinto de cumplimiento (hacer que el importe cobrado sea el héroe tipográfico) es el correcto.

Qué significa esto en la práctica: el precio normal debe ser el elemento más grande y más pesado. El precio introductorio o de descuento debe ser más pequeño, con una etiqueta explícita de “Primer periodo:”. Evita las insignias de porcentaje en marcadores pequeños (usa “OFERTA DE LANZAMIENTO” y no “25 % DE DESCUENTO”). La aplicación del punto 3.1.2© sobre pagos y suscripciones es constante entre revisores.

# Una vía explícita para borrar los datos

Aunque tu “cuenta” sea solo un identificador anónimo y voluntario, el 5.1.1(v) de Apple exige una vía de borrado etiquetada, visible e inmediata. Desactivar un interruptor como borrado implícito parece cumplir desde el lado de quien desarrolla, pero no satisface la exigencia actual.

Incorpora un botón explícito de “Borrar mis datos” en la pantalla de privacidad o de ajustes desde la primera compilación. Añade una alerta de confirmación. Asegúrate de que el texto que lo rodea describe el comportamiento real del borrado y no un plazo provisional que piensas revisar más adelante.

# Audita el Info.plist en busca de declaraciones vestigiales

Los modos en segundo plano, la descarga en segundo plano, los permisos de ubicación, las declaraciones de HealthKit y demás entradas del Info.plist pueden quedarse sin usar durante meses mientras el código evoluciona. Te las señalan cuando no se corresponden con una función real. La aplicación del 2.5.4 sobre requisitos de software es mecánica y no admite interpretación.

En concreto: cualquier entrada de UIBackgroundModes tiene que corresponderse con una función que la use de verdad. Si tu app declara “location” como modo en segundo plano pero nunca usas la ubicación continua en segundo plano y tienes allowsBackgroundLocationUpdates = false, elimina la declaración. La monitorización de regiones no la requiere. La auditoría lleva diez minutos y te ahorra un ciclo de rechazo.

# Un enlace funcional a los Términos de uso en los metadatos de la App Store

El campo de Política de privacidad de App Store Connect es de sobra conocido. El requisito de los Términos de uso lo es mucho menos. Si usas el EULA estándar de Apple, incluye un enlace a los Términos de uso en la descripción de la app. Si usas un EULA propio, añádelo en el campo de EULA personalizado de App Store Connect.

La propia página de términos debe revelar todos los productos de pago con la duración de la suscripción, el precio y la mecánica de renovación. La mayoría de los equipos tienen estos elementos repartidos por páginas distintas o enterrados en la política de privacidad. Consolídalos en una sola página de términos que quien revise pueda leer en dos minutos.

# Vídeos de App Preview: usa capturas de pantalla en crudo

Las maquetas 3D de teléfono, los marcos de dispositivo y las composiciones de marketing estilizadas son decisiones discrecionales de quien revisa bajo el 2.3.4 sobre metadatos exactos. La página pública de orientación no prohíbe de forma explícita los marcos de dispositivo, pero el material de formación interno con el que trabajan quienes revisan parece que sí. Las capturas de pantalla nativas y sin adornos son inequívocamente seguras.

Guarda los adornos de marketing para tu propia web, para las redes sociales y para Reddit. Pon capturas de pantalla en el hueco del App Preview. La diferencia de conversión entre una vista previa con maqueta pulida y una grabación de pantalla en crudo es pequeña. La reducción de riesgo es grande.

Quien revisa trabaja con presupuestos de tiempo de entre 5 y 15 minutos por app. No siempre encontrará todas las compras dentro de la app asociadas a la versión. Si tus compras se alcanzan por caminos distintos (muros de pago separados, tarjetas separadas, navegación más profunda), incluye migas de navegación toque a toque para cada una en las notas de App Review.

Un formato que funciona:

Suscripciones Premium y compra Lifetime: pestaña Ajustes > tarjeta Premium > botón Consigue Premium > hoja de mejora a Premium Suscripciones Pro y compra Lifetime: pestaña Ajustes > tarjeta Pro > botón Consigue Pro Artículos consumibles del bote de propinas: pestaña Ajustes > baja más allá de las tarjetas de nivel > tarjeta del bote de propinas > Mostrar opciones de propina

Suena excesivo. Evita un ciclo de rechazo concreto (Directriz 2.1(b), información necesaria) que si no te cuesta un día.

# Margen de calendario entre el envío y la fecha de lanzamiento comprometida

Para una v1.0 con suscripciones en una categoría sensible, cuenta con al menos siete días naturales entre el primer envío y la fecha de lanzamiento que hayas comprometido hacia fuera. Cada ciclo de rechazo dura unas 24 horas si respondes rápido. Cuatro ciclos de rechazo son un peor caso realista para una v1.0 de categoría sensible.

Si tu fecha de lanzamiento está comprometida hacia fuera (con la reserva configurada, un In-App Event programado, un empujón de marketing contratado, periodistas ya contactados), siete días de margen es el mínimo. Diez días es más cómodo. Con menos de siete te arriesgas a perder la fecha por un solo rechazo de trámite.

# Patrones que conviene entender

Unas cuantas observaciones desde dentro del ciclo que no se deducen de la documentación.

# Cada rechazo encuentra cosas distintas

Los cuatro rechazos volvieron señalando puntos que no se solapaban. Todos los revisores tenían acceso a todas las pantallas que el revisor anterior había dado por buenas. El primero señaló un enlace de EULA en los metadatos. El segundo señaló tres cosas distintas en el mismo binario (modo en segundo plano, presentación del precio, botón de borrado). El tercero señaló un recurso de marketing. El cuarto hizo una pregunta de navegación.

Esto no es un fallo. Es una consecuencia de cómo está estructurado App Review. Las revisiones parecen ser por incidencia, no por app. Quien revisa se detiene en el primer problema importante que detecta dentro de su presupuesto de tiempo. No está obligado a hacer auditorías exhaustivas, y el sistema no da un estado de “ya aprobado” a las superficies que un revisor anterior aceptó. La estructura favorece el rendimiento de la institución por encima de la experiencia de quien desarrolla.

La implicación: no puedes sacar una auditoría completa de ninguna pasada de revisión. Solo puedes sacar lo que ese revisor concreto detecte en su ventana de tiempo, y tienes que aceptar que el siguiente puede sacar por su cuenta cualquier otra cosa en la pasada siguiente.

# Cada rechazo suele tener menos alcance que el anterior

Es un patrón laxo, no una garantía. El primer rechazo suele ser sustantivo (un requisito que falta, un problema de arquitectura). El segundo sigue siendo sustantivo pero con más forma de lista de comprobación. El tercero se desvía hacia metadatos periféricos. El cuarto es a veces una pregunta de trámite más que un rechazo.

La razón no es que la app “vaya mejorando” con cada pasada. La razón es que la superficie revisable del binario y de los metadatos se encoge con cada pasada, a medida que lo señalado se arregla y lo ya aprobado deja de estar en juego. Quienes revisan van agotando de forma independiente la superficie disponible de la lista, así que las revisiones tardías tienen menos que encontrar.

Este patrón tranquiliza mientras estás dentro del ciclo, pero no apuestes por él. Un revisor de final de ciclo aún puede sacar algo sustantivo que los anteriores pasaron por alto.

# La minuciosidad varía muchísimo de un revisor a otro

A lo largo de cuatro revisiones del mismo binario, la variación de lo que cada revisor encontró fue enorme. Uno encontró tres cosas. Otro, una cosa periférica. Un tercero hizo una pregunta que se respondía tocando una tarjeta en la segunda pestaña de la app.

No tienes ninguna influencia sobre a qué revisor le toca tu envío en cada pasada. Cuenta con la variación. No des por hecho que la siguiente pasada será más minuciosa ni más indulgente que la anterior. Son muestras independientes de una distribución muy amplia.

# La aprobación de Beta App Review no predice la de App Review

Son dos circuitos con equipos distintos y criterios distintos. Que una compilación pase la Beta con las mismas funciones que luego se señalan en la revisión de producción no es una contradicción. Son dos procesos de revisión diferentes.

Si estás usando TestFlight para confirmar que estás listo para la revisión de producción, lo estás usando para la señal equivocada. TestFlight detecta problemas de validez de la compilación y de cumplimiento básico. App Review de producción detecta toda la superficie de exigencia. No son intercambiables.

# Los vectores de escrutinio de categoría sensible se acumulan

Las suscripciones, sobre todo con precios introductorios u ofertas de prueba, activan la exigencia del 3.1.2 de forma automática. Las categorías cercanas a la salud (alcohol, forma física, salud mental, sueño) llevan la atención de quien revisa al 1.4.1 y a las afirmaciones médicas. Las funciones sensibles para la privacidad (ubicación, HealthKit, identificadores anónimos) activan el escrutinio del 5.1.1. Los envíos de primera versión activan revisiones completas. Los In-App Events atados a fechas de lanzamiento activan el escrutinio de los metadatos.

Cada vector por separado es manejable. Se acumulan de forma multiplicativa. Un lanzamiento serio en una categoría sensible con suscripciones, varias plataformas y un In-App Event tiene todos los vectores activos a la vez. Una utilidad gratuita de una sola pantalla sin compras se despacha en 2 minutos. La dificultad de tu experiencia de revisión guarda relación con lo serio y lo amplio de tu lanzamiento, no con la calidad de tu app.

# La documentación y la exigencia no siempre coinciden del todo

Un rechazo puede citar una orientación que no aparece de forma explícita en la página pública enlazada. Quienes revisan trabajan con material de formación interno que se solapa con las Review Guidelines públicas pero no es idéntico. Si te encuentras un rechazo que no cuadra con la documentación pública, puedes replicar con educación. A veces se revierte y a veces no.

Cuando repliques, hazlo por escrito en el Resolution Center, en un párrafo estructurado que cite la orientación pública y pregunte por la cláusula concreta que se está aplicando. Evita la frustración en el lenguaje. Quien revisa lee tu respuesta con el reloj en la mano; la respuesta que se lee con atención es la que respeta ese reloj.

# Cómo responder a los rechazos de forma constructiva

Unas cuantas notas prácticas sobre el ida y vuelta en el Resolution Center.

# Responde el mismo día si puedes

La forma más rápida de salir del ciclo es mantener el ciclo en movimiento. El reloj de cada ciclo de rechazo se reinicia cuando respondes. Las respuestas en el día producen resoluciones en la semana; las respuestas de varios días alargan el ciclo en la misma proporción.

Esto exige que tu equipo esté montado para publicar arreglos deprisa. Para quien desarrolla en solitario, eso suele significar despejar el calendario los días posteriores al envío. La ventana del envío no se puede tratar como trabajo de fondo.

# Agrupa tus arreglos en un solo reenvío

Si un rechazo señala tres cosas, arregla las tres antes de reenviar. No mandes una respuesta de “he arreglado dos de tres, sigo con la tercera”. El siguiente revisor sacará cosas completamente distintas; la respuesta de arreglo parcial solo añade otro ciclo a la cola.

# Incluye grabaciones de pantalla que verifiquen el arreglo

Para cualquier arreglo que no sea trivial, adjunta una grabación de pantalla de 30 segundos que muestre el arreglo en funcionamiento. El flujo de borrado, la presentación corregida del precio, el nuevo camino de navegación. Quien revisa tiene más probabilidades de dar la incidencia por resuelta en la siguiente pasada si puede ver el arreglo sin tener que llegar hasta él por su cuenta.

# Pide una revisión completa en tu respuesta

Una petición educada de que cualquier preocupación pendiente se plantee toda junta en la pasada actual, en lugar de repartida en más ciclos, es razonable. No siempre funciona, pero de vez en cuando sí. La formulación importa: “Hemos atendido todas las incidencias planteadas hasta ahora con rapidez y de buena fe. Agradeceríamos una revisión completa frente a todas las directrices aplicables en esta pasada, para reducir al mínimo los ciclos adicionales”.

Esto deja a quien revisa en una posición en la que su siguiente respuesta o aprueba la app o saca a la luz todas las preocupaciones que quedan. Los dos resultados son mejores que otro rechazo de una sola incidencia.

# Trata cada pasada como independiente

La tentación es dar por hecho que el siguiente revisor ha leído las notas del anterior. Probablemente no lo ha hecho. Cada respuesta en el Resolution Center debería bastarse a sí misma, resumiendo el estado del envío para alguien que no ha visto la conversación previa.

Eso significa que cierta repetición entre ciclos es necesaria. Las notas detalladas de App Review que le funcionaron al primer revisor deberían reenviarse o repetirse para el tercero. No des por hecho que hay memoria institucional.

# La cronología personal

Como contexto, esto es lo que fueron aquellos cinco días.

Envié la compilación 22 un sábado por la tarde. El envío incluía 4 suscripciones de renovación automática, 2 compras no consumibles de por vida, 5 artículos consumibles del bote de propinas, la descripción de la app, las capturas, los vídeos de App Preview, un In-App Event atado a la semana del lanzamiento y la reserva configurada para la fecha de lanzamiento en 175 países.

Había pasado las seis semanas anteriores eliminando de forma sistemática todo problema que se me ocurrió anticipar. Las notas de App Review estaban redactadas con explicaciones amables para quien revisara sobre las partes de la app más susceptibles de atraer escrutinio. La información de comerciante de la DSA estaba aprobada desde la semana anterior. Las etiquetas nutricionales de privacidad estaban publicadas. Beta App Review había dado el visto bueno a varias compilaciones. Me sentía preparado.

Día 2, 05:15: primer rechazo. Directriz 3.1.2©. Falta un enlace funcional a los Términos de uso en los metadatos de la App Store. Arreglo enviado el mismo día (enlace a los Términos añadido en la hoja de mejora dentro de la app, página de términos ampliada para revelar todos los productos de pago, descripción de la app actualizada). Ciclo de un día.

Día 4, 16:03: segundo rechazo. Tres puntos en un solo mensaje. Directriz 2.5.4 (una entrada vestigial de “location” en UIBackgroundModes que no debería haber estado ahí). Directriz 3.1.2© (el precio introductorio se mostraba de forma más destacada que el importe cobrado). Directriz 5.1.1(v) (desactivar el identificador anónimo necesitaba un botón de borrado explícito y etiquetado). Arreglo enviado el mismo día (entrada del Info.plist eliminada, jerarquía del precio invertida, añadido un botón explícito de “Borrar datos anónimos” con alerta de confirmación). Ciclo de un día.

Día 5, 17:05: tercer rechazo. Directriz 2.3.4, metadatos exactos. Los vídeos de App Preview mostraban maquetas 3D de teléfono con las pantallas de la app. La nota del revisor citaba contenido que no muestra “suficientemente la app en uso” y señalaba en concreto los marcos de dispositivo.

El problema: la página pública de orientación en developer.apple.com/app-store/app-previews/ no prohíbe de forma explícita los marcos de dispositivo. La regla documentada más cercana es “quédate dentro de la app”, con ejemplos sobre planos por encima del hombro e interacción física con dispositivos. Ninguno aplicaba.

Con el lanzamiento a cuatro días y un retraso acumulado de cuatro días ya encima, tomé la decisión. Quité los vídeos de App Preview para desbloquear el reenvío. Pedí una reconsideración con educación por si había alguna cláusula concreta que se me hubiera escapado. Envié un párrafo educado y estructurado pidiendo que cualquier preocupación pendiente se planteara toda junta en esa pasada. La retirada del App Preview se mantuvo. La petición de reconsideración no recibió respuesta directa.

Día 6, 19:23: cuarto mensaje. Directriz 2.1(b), información necesaria. Técnicamente no era un rechazo. Era una pausa en la revisión para hacer una pregunta. El revisor no lograba localizar dos de las compras asociadas a la versión y preguntaba dónde encontrarlas.

La captura que adjuntaba mostraba el primer muro de pago correctamente. El segundo muro de pago estaba en esa misma pantalla de Ajustes, accesible tocando una tarjeta justo debajo de la primera a la que el revisor había llegado sin problema. Respondí con la navegación paso a paso explícita para las 11 compras, enviada en menos de una hora.

Día 7, 20:30: aprobación. Compilación aprobada. Reserva activada. La semana de lanzamiento queda fijada para el 11 de mayo.

Los cinco días fueron intensos. Ninguno era existencial, visto en retrospectiva, aunque a mitad del ciclo no lo pareciera. El retraso acumulado estuvo cerca de costar la fecha de lanzamiento, pero no lo hizo. El producto que se lanzó es exactamente el que estaba construido antes del envío. No se recortó, modificó ni aplazó nada para pasar la revisión.

# Lo que el ciclo no señala también dice mucho

A lo largo de cuatro revisiones, las superficies que más me habían preocupado no se señalaron nunca.

La función de puntuación de hábitos (una puntuación de 0 a 100 con factores que ayudan y que perjudican repartidos en seis pilares ponderados). La superficie de seguimiento de la medicación (solo registro, sin ninguna salida de tipo consejo). El modelo de privacidad (sin cuentas, datos en el dispositivo, compartición anónima voluntaria con borrado explícito). Las escrituras en HealthKit. Ninguna de estas superficies, las partes de la app con más probabilidad de activar preocupaciones sobre afirmaciones de salud o sobre privacidad, se señaló en ninguna de las cuatro revisiones. Cuatro revisores independientes las miraron y los cuatro decidieron no señalarlas.

Lo que implica para quien construye en una categoría sensible: el trabajo de divulgación proactiva sirve. Las notas de App Review que explican la metodología, los avisos legales dentro de la app, la elección cuidadosa de los nombres, el encuadre conservador en la descripción de la app. Nada de eso es glamuroso. Todo ello contribuyó a que cuatro revisores seguidos decidieran no señalar las superficies más discutibles. La clasificación por edad de 18+, la hoja de aviso legal que bloquea el primer arranque, el texto explícito de “no damos consejo médico” en las zonas pertinentes. Todo eso funcionó.

Lo que sí se señaló fue la superficie de trámite y mecánica. La jerarquía del precio. Las declaraciones de modos en segundo plano. La presencia de un enlace en los metadatos. Las composiciones de los recursos de marketing. La visibilidad de las compras dentro de la app. Las partes sustantivas de la app pasaron todas las pasadas.

# Notas finales para quien desarrolla en solitario

Unas cuantas observaciones que no encajaban del todo arriba.

Las apps baratas que ves en la App Store no reciben un trato más indulgente. Se aprobaron hace años, cuando el listón estaba más bajo, o no activan los vectores de escrutinio que activa tu lanzamiento serio. El sistema premia a las apps de poco esfuerzo y poco riesgo con poco escrutinio. Tu esfuerzo y tu cuidado son parte de por qué tu revisión es más dura. No es un juicio sobre la calidad de tu app.

El sistema no está dotado para darte la experiencia que quieres. App Review es una bolsa de personal externo. Quienes revisan atienden decenas de apps al día, a minutos por app. Están formados en las Review Guidelines como lista de comprobación, no en la experiencia de uso concreta de ninguna app individual. La brecha de empatía es estructural, no personal.

Documentar las experiencias indie acaba moviendo cosas. Apple ha mejorado App Review de forma apreciable en la última década. Parte de esa mejora se debe a que quienes desarrollan en solitario han documentado sus experiencias con constancia y la presión agregada ha ido creciendo. Tu rechazo concreto no va a hacer que se reforme a ningún revisor en particular. El agregado estructurado de las experiencias indie sí acaba moviendo la superficie institucional.

Lo más probable es que publiques el producto que construiste. Todas las funciones que temí que hubiera que recortar se publicaron intactas. El ciclo de cuatro rechazos parecía existencial mientras ocurría. El resultado real convergió en la aprobación mientras seguí respondiendo con claridad y mantuve el margen del plazo en la recámara.

Si ahora mismo estás a mitad de ciclo, pasando noches en vela en el Resolution Center: el lanzamiento llega. Sigue respondiendo. El sistema no va contigo. El producto es tuyo.

Esta entrada documenta el lanzamiento de AlcoLog, una app de iOS para hacer seguimiento del consumo de alcohol. AlcoLog se lanza en la App Store el 11 de mayo de 2026, después del ciclo descrito arriba. La app es gratuita con niveles Premium opcionales y se puede reservar ya en 175 países.

Si desarrollas para iOS y quieres comparar notas sobre experiencias con App Review, la comunidad indie de iOS en r/iOSProgramming y en Indie Hackers son buenos sitios por donde empezar. Cuanto más concreto sea lo que cada uno documenta de lo que se encontró, más útil resulta el agregado para la siguiente persona.