Resolution Center de Apple: cómo responder a un rechazo

El Resolution Center ya no existe con ese nombre. Respondes a un rechazo en la sección App Review de tu app, con el botón Reply to App Review. Escribe en inglés y da tres datos: qué bloqueaba, qué cambió y cómo verificarlo. El App Review Board solo entra en juego después de esa respuesta, y únicamente si estás seguro de que tu app cumple la regla citada.

Escribí estas respuestas para mis propias apps en 2026: Solys, mi despertador con minijuegos, y TradaZen, mi simulador de trading. Aquí te cuento dónde responder hoy, qué escribir, cuándo adjuntar un video, cuándo apelar y qué no funciona. Para los motivos en sí, lee por qué Apple rechaza una app.

¿Dónde quedó el Resolution Center?

La ayuda oficial, Reply to App Review messages, ahora habla de la sección App Review. Ahí te comunicas con Apple, con archivos adjuntos incluidos, hasta que vuelvas a enviar tu solicitud. La ruta:

1. En Apps, abre tu app.
2. En la parte superior de la página, haz clic en el enlace de problemas sin resolver, llamado View App Review Issues & Messages en otra página de la ayuda.
3. En la parte In Progress, haz clic en Resolve junto al envío.
4. Haz clic en Reply to App Review y escribe en el campo Reply.
5. Para adjuntar una captura o un documento, haz clic en Attach File y luego en Reply.

Solo los roles Account Holder, Admin y App Manager pueden responder. La página App Review añade que puedes seguir el estado de tus envíos en App Store Connect o en su app para iPhone y iPad.

Antes de escribir: ¿qué mensaje recibiste?

La respuesta correcta depende del mensaje, no de tus ganas de defenderte. Esta es la tabla que aplico antes de abrir el campo de respuesta.

Lo que dice Apple	Lo que haces	Nuevo build
Information Needed	Responde la pregunta	No
Bug o pantalla con fallas	Corrige y luego responde	Sí
Ficha, enlaces, capturas	Corrige la ficha	No
App mal entendida	Explica, con pruebas	Según el caso
Desacuerdo persistente	Apelación al Board	No
Oferta Bug Fix Submissions	Acepta respondiendo	No

Tres precisiones lo cambian todo:

• Un rechazo por metadatos no requiere un nuevo build. La ayuda de Apple lo dice: corriges y vuelves a enviar el mismo build. Suele ser el caso de un rechazo 2.3.10, cuando la mención problemática está en la ficha.
• Un "Information Needed" no es un rechazo de fondo. El revisor te hace una pregunta. La guía sobre la guideline 2.1 explica la diferencia con un bug realmente detectado.
• Las Bug Fix Submissions son una oferta. Si tu app ya está publicada y el mensaje empieza con "Bug Fix Submissions: The issues we've identified below are eligible to be resolved on your next update", puedes pedir la aprobación de la actualización respondiendo al mensaje. No vuelvas a enviar la app en ese momento, o empezará una nueva revisión. Resuelves el problema en la siguiente versión.

Qué escribir: la plantilla en cuatro bloques

Apple publicó sus consejos para contactar a App Review. Lo que hay que hacer: ser preciso sobre lo que pides y dar la información que ayude a entender la app si crees que la malinterpretaron. Lo que hay que evitar: usar el campo de respuesta para apelar o pedir una revisión acelerada, o preguntar por el estado de las apps de otros desarrolladores.

Mi plantilla cabe en cuatro bloques. Escribe en inglés, sin adjetivos. Reemplaza todo lo que está entre corchetes y escribe solo lo que sea cierto en el build enviado.

Hello App Review team,

Thank you for your review and for the details on
Guideline [number].

What you reported: [one sentence that restates
Apple's message, in your own words].

What changed in build [version (build)]:
- [Screen or element]: [what it does now]
- [Screen or element]: [what it does now]

How to verify:
1. [Starting point, e.g. fresh install]
2. [Action]
3. [Expected result]

We tested this flow on [devices and iOS versions].
[Attached: a short screen recording of the fixed flow.]

If anything else is unclear, please tell us which
screen or wording, and we will change it.

Best regards,
[Your name]

Cada bloque tiene una función. El primero demuestra que leíste. El segundo nombra el build, porque el revisor prueba el binario, no tus intenciones. El tercero le ahorra tiempo. El último deja la puerta abierta sin alegar.

Las plantillas adaptadas a cada regla están en mis guías específicas, por ejemplo sobre la guideline 3.1.2 o la guideline 4.3. También hay un esquema de respuesta en mi plantilla de notas para App Review, que puedes descargar.

Lo que aprendí respondiendo por Solys y TradaZen

Solys, guideline 2.1. El revisor pedía una forma de saltarse el juego. Mi respuesta señalaba la pantalla que bloqueaba, la demo jugable del onboarding, y luego la causa real: en modo de compatibilidad en iPad, su obstáculo se volvía imposible de superar. Enumeraba dos correcciones numeradas, entre ellas un enlace para saltar la demo después de un fallo, y luego los simuladores probados, desde el iPhone SE hasta el iPhone más grande. También describía el botón de parada de emergencia de la alarma, pero solo después de releer el código que lo activa. No escribas nada sobre tu app que no hayas verificado en el build.

TradaZen, guideline 5.6. En octubre de 2026, Apple consideró que la app empujaba a compras dentro de la app no deseadas, sin señalar ningún elemento concreto. Busqué qué podía confundir: una cruz en la parte superior del paywall abría una oferta con descuento en lugar de cerrar la pantalla. Mi respuesta reconocía ese punto en una frase: fue mi error. Luego enumeraba cada cambio, pantalla por pantalla: la cruz reemplazada por un regalo, ninguna oferta que se vuelva a abrir sola, una notificación promocional eliminada. Recordaba lo que seguía cumpliendo las reglas: el precio cobrado como el más visible, la restauración de compras, los enlaces legales. Terminaba ofreciendo modificar cualquier pantalla que todavía se considerara ambigua. El nuevo build se envió junto con ella.

Las dos respuestas siguen la misma lógica: la causa real, la corrección visible, el camino para verla.

Cuándo adjuntar un video o una captura

La ayuda de Apple acepta capturas y documentos como adjuntos. Un video corto de la pantalla corregida es útil en tres casos:

• el problema depende de un dispositivo o de una condición, como un iPad en modo de compatibilidad o un permiso denegado;
• el camino hasta la pantalla es largo, por ejemplo al final del onboarding;
• la función es difícil de reproducir. La página App Review pide estar listo para dar un video de demostración cuando una función requiere un entorno difícil de recrear o un hardware específico.

Para una app vinculada a un accesorio, la ayuda sobre la revisión completa exige un video real filmado en un dispositivo Apple, no una grabación de pantalla. Para un texto del paywall o un botón renombrado, basta con una captura.

Pedir una llamada o una cita

Si lo escrito no alcanza, Apple ofrece dos opciones:

• Una llamada con un representante de Apple. La pides en la ventana Reply to App Review, después de una primera respuesta de App Review. Indica tu zona horaria y, si quieres, el idioma que prefieres. Antes, verifica tus datos de contacto en App Review Information. Apple indica que estas llamadas suelen hacerse en un plazo de tres a cinco días hábiles.
• Una cita de 30 minutos por videollamada con App Review, los martes o jueves, para hablar de las reglas. Es informativa: no acelera ni garantiza la revisión.

Apelar ante el App Review Board

La apelación es el último paso. Según la página Appeal to the App Review Board, procede si tu app fue rechazada aunque crees que cumple las reglas, o si consideras que te trataron de forma injusta.

Antes que nada, responde al mensaje en App Store Connect para aclarar. Si eso no basta, llena el formulario Submit an appeal to App Review. Las reglas:

• una sola apelación por app rechazada, que aborde todas las reglas citadas;
• cita la regla y explica punto por punto cómo la cumple tu app;
• no apeles si ya corregiste y volviste a enviar la app;
• no apeles por una simple solicitud de información.

Apple da dos ejemplos, que traduzco. Completo: "Mi app fue rechazada por la 2.1 por información incompleta. La cuenta demo y los pasos para probar la función están en App Review Information, con capturas que la muestran." Incompleto: "Esta app es importante para mi empresa y no debió ser rechazada."

El Board responde en App Store Connect y puede pedir información o proponer una llamada. Apple no publica ningún plazo para la apelación. En los foros de Apple, algunos desarrolladores cuentan esperas de más de dos semanas. Si la corrección es sencilla, enviar un build corregido suele ser más rápido.

Lo que funciona y lo que no

Ayuda	Perjudica
Retomar el motivo de Apple	Alegar a tu favor
Nombrar el build corregido	Prometer una corrección futura
Dar el camino a seguir	Citar una app de la competencia
Adjuntar una prueba	Apelar en Reply
Una respuesta completa	Reenviar sin corregir

"Mi pantalla ya había sido aceptada" tampoco funciona: cada versión vuelve a pasar por revisión, a veces con otro revisor. Las App Review Guidelines también advierten que una app rechazada varias veces por la misma regla tarda más en ser revisada. Para los plazos de revisión, lee plazo de aprobación en el App Store.

Haz que revisen tu respuesta antes de enviarla

El Review Kit contiene los mensajes reales que recibí en mis apps, las correcciones enviadas y skills de Claude Code que preparan tu respuesta si Apple te rechaza. Si quieres una mirada humana, reserva una hora conmigo: leemos el mensaje de Apple y escribimos la respuesta juntos. El proceso completo está en la página app rechazada por Apple.

¿Todavía no enviaste tu app? Haz tu diagnóstico gratuito: te envía mi checklist contra rechazos de Apple, para que no tengas que escribir esta respuesta.

Preguntas frecuentes

¿Dónde está el Resolution Center en App Store Connect?

Ahora se llama la sección App Review. Abre tu app, haz clic en el enlace de problemas sin resolver en la parte superior de la página y luego en Resolve junto al envío. El botón Reply to App Review abre el campo de respuesta y la opción para adjuntar archivos.

¿Cuánto tarda Apple en responder?

Apple no publica plazos para las respuestas escritas. Para la revisión, Apple anuncia que al menos el 50 % de los envíos se revisan en menos de 24 horas y el 90 % en menos de 48 horas. Una llamada solicitada a App Review suele hacerse en un plazo de tres a cinco días hábiles. No se anuncia ningún plazo para el App Review Board.

¿Se puede responder a App Review en francés?

La ayuda de Apple no fija ningún idioma para la respuesta escrita. Yo escribo en inglés, con frases cortas, para que me entiendan a la primera. Para una llamada, Apple permite indicar un idioma preferido, sin garantía.

¿Cuántas veces se puede apelar un rechazo?

Una vez por app rechazada. Si el mensaje cita varias reglas, tu apelación debe abordarlas todas. Apple también pide responder primero en App Store Connect y no apelar si ya enviaste un build corregido.

¿Hay que enviar un nuevo build antes de responder?

Sí, si el problema está en la app: corrige, envía el build y luego responde nombrando ese build. No, si el rechazo es por los metadatos, como la ficha o las capturas: corriges en App Store Connect y vuelves a enviar el mismo build.