Un rechazo de la App Store requiere una respuesta adecuada al problema citado. Empieza por el mensaje de revisión y comprueba qué ha fallado. Las indicaciones actuales de Apple permiten responder después de corregir la información, los metadatos o el acceso del lado del servidor. Una corrección del código de la compilación enviada requiere una nueva compilación. Si impugnas la decisión, aclárala antes de apelar.
Volver a enviar inmediatamente puede reiniciar un trabajo que podrías haber resuelto en la conversación.
Empezamos colocando el mensaje junto a la app enviada y registrando lo que podía ver la persona encargada de la revisión. Así tendrás una tarea concreta que comentar con el desarrollador, aunque no puedas cambiar el código por tu cuenta.
¿Qué dice realmente tu rechazo de la App Store?
Lee el estado y el elemento afectado antes de elegir una corrección. La referencia de estados de Apple distingue entre un envío que espera la revisión y una app rechazada o la información rechazada de una ficha. Un envío puede incluir varios elementos. Anota cuál presenta el problema, la directriz citada y la explicación de la persona encargada de la revisión. Una antigua insignia de rechazo no aporta por sí sola información suficiente para actuar.
Los metadatos son la información de la ficha, como las descripciones y las capturas de pantalla, situada fuera del paquete ejecutable de la app. Una compilación es la versión empaquetada que se envía para revisión. Las App Review Guidelines de Apple consideran que la integridad, la precisión de los metadatos y una funcionalidad suficiente de la app son requisitos distintos. Una descripción más clara no puede reparar un fallo, mientras que una función operativa puede seguir necesitando mejor información para la revisión.
Mantén un registro de tareas con estos campos: elemento afectado, directriz, problema observado, corrección propuesta, prueba, persona responsable y siguiente acción. Utiliza la preocupación real de la persona encargada de la revisión. Marca un campo como desconocido cuando el mensaje no lo explique y formula después una pregunta concreta.
Encuentra el problema que pudo reproducir la persona encargada de la revisión
Prueba la versión enviada empezando por el punto descrito en el mensaje. Es posible que tu cuenta habitual ya tenga acceso o haya completado una configuración que le falta a la persona encargada de la revisión. Las indicaciones de Apple para la preparación solicitan credenciales de demostración válidas y la información necesaria para llegar a las funciones de la app. Comprueba todo el recorrido antes de pedir al desarrollador una nueva versión.
- Haz coincidir la versión y el entorno. Pregunta al desarrollador qué compilación se envió y qué dispositivo y sistema operativo se probaron. La ayuda de Apple sobre pruebas en dispositivos pide realizar pruebas con dispositivos físicos, incluidos los modos de compatibilidad pertinentes. Anota cualquier cosa que no puedas reproducir en los dispositivos disponibles.
- Prueba la cuenta de revisión desde un inicio de sesión nuevo. Sigue los pasos facilitados hasta la función notificada. Comprueba los roles de la cuenta y las instrucciones sobre códigos de autenticación. La ayuda de Apple sobre la revisión completa pide estos datos de antemano. Las credenciales deben seguir funcionando cuando comience la revisión.
- Lee la ficha junto a la app. Compara las capturas de pantalla y la descripción con lo que hace realmente esa compilación. Si el rechazo se refiere a un mensaje de permiso, las indicaciones de Apple sobre las descripciones de uso exigen explicar de forma concreta cómo utiliza la app el recurso solicitado.
- Comprueba el comportamiento de privacidad citado. Si el problema afecta a la eliminación de cuentas, prueba el recorrido real. Las indicaciones de Apple exigen que las apps que permiten crear cuentas ofrezcan la posibilidad de iniciar su eliminación dentro de la app. La mera desactivación no basta. Las obligaciones de conservación y las excepciones para apps reguladas requieren una comprobación propia.
Utiliza una cuenta de prueba con datos de ejemplo seguros. Una grabación o un archivo adjunto debe mostrar el recorrido fallido o corregido sin exponer registros de clientes ni credenciales.
¿Responder, enviar una nueva compilación o apelar?
Elige la vía cuando sepas qué ha cambiado. La ayuda de Apple sobre el estado de revisión distingue entre las correcciones que pueden explicarse en una respuesta y los cambios que requieren otra revisión. La tabla ayuda a decidir ante un rechazo existente. Un aviso de retirada o una medida sobre una cuenta requiere su propio proceso.
| Situación | Siguiente acción admitida |
|---|---|
| Falta información, se han corregido los metadatos o el acceso del lado del servidor | Corregir el problema y responder en App Store Connect |
| Se ha corregido un defecto de la compilación enviada | Subir la compilación modificada y enviarla para una nueva revisión |
| Crees que la decisión aplica de forma incorrecta la norma citada | Aclararlo en la conversación y apelar después si no se resuelve |
Apple advierte de que un nuevo envío inicia una nueva revisión y pone fin a las respuestas al mensaje anterior. Volver a enviar durante una apelación cierra esa apelación. Consulta con la persona que gestiona la conversación antes de cambiar el envío.
Una oferta explícita de Bug Fix Submission es un caso distinto. La ayuda de Apple la limita a actualizaciones aptas de apps aprobadas previamente y sin problemas legales o de seguridad. Se acepta mediante una respuesta, con el compromiso de corregir los problemas en la siguiente actualización. Lee la oferta antes de utilizar la vía habitual de una nueva compilación.
Prepara conjuntamente la corrección y las pruebas
Asigna a cada problema una corrección y una forma de comprobarla. Mantenemos la tarea del desarrollador y la respuesta a la persona encargada de la revisión vinculadas al mismo registro, para que un cambio en la app quede reflejado en la información que se envía con ella. Empieza por las comprobaciones que puedas realizar por tu cuenta y asigna después al desarrollador los cambios de código.
- Elimina las carencias de acceso e información. Actualiza las notas de revisión con la finalidad de la app, las funciones modificadas, los servicios externos y las diferencias regionales cuando proceda, siguiendo la ayuda de Apple sobre la revisión completa. Vuelve a probar las credenciales después de modificarlas.
- Comprueba el sitio web vinculado. Abre en un teléfono las URL de soporte y privacidad indicadas en tu envío. Comprueba el destino y el texto comparándolos con la app que se está revisando. Esta verificación de coherencia puede formar parte del desarrollo web cuando un sitio da soporte a una app.
- Pide una corrección técnica demostrable. Si existe un problema con la compilación, pide al desarrollador que muestre el recorrido notificado después de corregirlo y que identifique la compilación que contiene la corrección. Este traspaso forma parte del desarrollo y la publicación de aplicaciones móviles, junto con la preparación para la revisión.
- Envía una respuesta concreta. Las instrucciones de Apple para responder utilizan el enlace de problemas sin resolver de la app y, después, In Progress, Resolve y Reply to App Review. Se requiere acceso como Account Holder, Admin o App Manager. Explica el problema, dónde está la corrección y cómo probarla. Adjunta pruebas pertinentes si resultan útiles y elige después Reply.
- Utiliza una apelación si persiste el desacuerdo. La ayuda de Apple sobre las apelaciones te pide que primero aclares la situación y después respondas con pruebas a los requisitos citados. Incluye en la apelación todas las infracciones de esa app. Una solicitud de actualización de estado o de revisión más rápida debe tramitarse por otra vía.
No incluyas contraseñas personales de Apple en el registro de tareas. Mantén la cuenta de desarrollador bajo el control de la empresa y utiliza el acceso adecuado para el trabajo de cada persona.
¿Cómo sabes si el problema está resuelto?
Distingue entre una corrección que has probado y la decisión de Apple. Repite el recorrido exacto después del cambio y conserva el resultado, la versión de la compilación o de la información y la respuesta enviada. Consulta después el estado actual en App Store Connect. Una prueba local satisfactoria solo informa sobre esa prueba. Apple sigue decidiendo sobre el envío.
Controla si cada problema citado cuenta con pruebas, si el acceso para la revisión sigue funcionando y si un mensaje posterior repite el mismo problema. Si ocurre, compara el nuevo mensaje con tu registro antes de realizar otro cambio. Una vez publicada la app, conseguir descargas para la app es una tarea aparte.
Cómo intervenimos
Empezamos por el mensaje de rechazo, la versión enviada y un recorrido reproducible por la app. Después podemos separar las correcciones de la ficha y del sitio web del trabajo de desarrollo y preparar la información para la persona encargada de la revisión. Lleva esos materiales a la persona responsable del lanzamiento, con las preguntas pendientes marcadas, antes de aceptar otra compilación.
