erberkk/review-readiness

Preparación para la revisión

Propósito

Envíe una vez y pase. La mayoría de los rechazos no se deben a la idea de la aplicación; son un revisor que no pudo iniciar sesión, no pudo comprar, vio un marcador de posición o encontró una contradicción entre los metadatos y la aplicación.

Requisitos previos

• La compilación exacta a enviar está en TestFlight / una pista de pruebas de Play.
• El punto de control suscripciones-y-pagos se ha superado (una compra real desbloqueó premium en ambas plataformas).
• Se completó privacidad-y-declaraciones; el validador de listado-y-aso está limpio; las capturas de pantalla están subidas.

Piense como un revisor sin conocimiento previo

Suponga que el revisor instala una compilación limpia en un dispositivo que usted no probó (una aplicación solo para iPhone puede ser revisada en un iPad en modo de compatibilidad), con una cuenta de tienda nueva, y tiene tiempo limitado. Leen sus notas, intentan iniciar sesión, buscan la compra y comparan las capturas de pantalla con la aplicación. Un solo rechazo puede combinar varias capas: estado de la cuenta, comportamiento del backend y metadatos.

Procedimiento

1. Cuenta demo

• Las credenciales van a App Store Connect › Información de revisión de la aplicación ("Se requiere inicio de sesión") y Play › Contenido de la aplicación › Acceso a la aplicación. Nunca en el repositorio.
• La cuenta inicia sesión con correo electrónico + contraseña. Si su inicio de sesión normal es un código único por correo electrónico o un enlace mágico, el revisor no puede recibirlo. Agregue una ruta de contraseña solo para la dirección de revisión (lista blanca del lado del servidor) o un código de prueba fijo que solo funcione para esa dirección.
• Llena de datos: perfil completo, algunos días de historial, cada pantalla principal poblada. Una cuenta vacía oculta funciones e invita a "no pudimos localizar la función X".
• Premium desbloqueado mediante un permiso manual del lado del servidor (sin caducidad durante la revisión), para que los revisores vean las funciones de pago sin comprar.
• Por separado, asegúrese de que un usuario nuevo pueda llegar al muro de pago y comprar con la cuenta de pruebas del revisor (también probarán la compra).
• No cambie, elimine ni vuelva a sembrar esta cuenta mientras una revisión esté abierta.

2. Compras (2.1(b) y 3.1.x)

• Las suscripciones de la primera versión están adjuntas a la versión en App Store Connect (sección "Compras dentro de la aplicación y suscripciones") y tienen una captura de pantalla y notas de revisión. En la interfaz de usuario más reciente de App Store Connect, puede que no haya dicha sección en la página de la versión: abra el grupo de suscripciones y cada suscripción y use Añadir para revisión → Envío de borrador; la versión en sí se añade desde su propia página. El borrador debe listar la versión, el grupo y cada suscripción antes de presionar Enviar para revisión.
• Cada suscripción necesita al menos una localización de nombre + descripción y una captura de pantalla de revisión; sin ellas, "Añadir para revisión" falla ("Debe añadir al menos una localización de suscripción / una captura de pantalla de Información de revisión").
• La captura de pantalla de revisión debe mostrar el muro de pago real con precios reales y la redacción correcta de la tienda. Si la renderiza desde un widget/prueba de interfaz de usuario, fuerce la plataforma iOS (de lo contrario dice "Google Play") e introduzca precios de tienda realistas; un estado de "precios no disponibles" no es aceptable.
• La cadena de versión de App Store debe ser igual a la versión de marketing de las compilaciones (CFBundleShortVersionString). Una versión nombrada 1.0 no ofrecerá compilaciones subidas como 1.0.0; la sección Compilación solo dice "Sube tus compilaciones" sin botón Añadir compilación. Renombre la versión para que coincida.
• En TestFlight con una nueva cuenta de Apple de pruebas (no vinculada a ninguna de sus cuentas de aplicación): los productos se cargan, la compra funciona, la restauración funciona.
• El estado de error del muro de pago muestra reintento, nunca un "Próximamente" deshabilitado.
• Si no se puede acceder a una compra dentro de la aplicación (por ejemplo, solo para una región), explique por qué en las notas de revisión.
• Restaurar compras, enlaces de Términos y Privacidad, y enlace de gestionar suscripción presentes.

3. Dispositivos y compilaciones

• Inicio en frío sin red, red lenta y modo avión activado: sin fallos, sin spinner infinito.
• iPad: incluso una aplicación solo para iPhone se ejecuta en iPad en modo de compatibilidad y puede ser revisada allí. Ejecute el flujo completo en un simulador de iPad: inicio de sesión (incluyendo Iniciar sesión con Apple), desplazamiento por el muro de pago, hoja de compra, teclado sobre formularios, indicaciones de permisos, rotación. Si HealthKit u otra API no está disponible allí, muestre un mensaje cortés, no un fallo.
• Teléfono más pequeño compatible y tamaño de texto más grande: sin botones recortados en el muro de pago o pantallas de consentimiento.
• Compilación de lanzamiento, no de depuración: sin banner de depuración, sin menús de prueba, análisis/informes de fallos activados en configuración de producción.
• Recorra todo el ciclo de vida de la cuenta en un dispositivo físico con la compilación exacta que envía: instalar, registrarse, funciones principales, compra con pruebas, eliminación de cuenta, y lo que la aplicación muestra después de la eliminación.

4. Contenido y metadatos

• Busque en las cadenas y listados de la aplicación: TODO, lorem, próximamente, beta, test, [PRECIO], imágenes de marcador de posición. Ninguno debe renderizarse.
• La compilación y los metadatos de iOS no contienen redacción de Android / Google Play; Play no contiene redacción exclusiva de Apple (2.3.10). Incluye cadenas dentro de la aplicación como "Cancelar en App Store o Google Play" — seleccione el texto de la plataforma en tiempo de ejecución.
• Cada captura de pantalla coincide con la interfaz de usuario actual; cada número en la descripción coincide con la aplicación.
• Las URLs de política de privacidad, términos, soporte y eliminación de cuenta cargan sin inicio de sesión, mencionan la aplicación y coinciden con los formularios de privacidad.
• Clasificación por edad coherente con los Términos.

5. Backend

• El backend está activo y en un plan que no alcanzará límites durante la revisión (los niveles gratuitos que pausan o limitan la velocidad = rechazo).
• Sin despliegues de cambios drásticos durante la revisión. API compatible hacia atrás para la compilación en revisión.
• Las alertas están activas (operaciones-post-lanzamiento) para que note una interrupción durante la revisión.

6. Notas de revisión

Complete plantillas/notas-de-revision.md. Manténgalo fáctico: dónde están las funciones, cómo iniciar sesión, cómo probar la compra, cómo se manejan los datos de IA y salud, dónde está la eliminación de cuenta.

Apple puede responder con Directriz 2.1 "Información necesaria" en lugar de revisar. En un caso observado, pidió los seis elementos siguientes; responderlos de antemano en el primer envío evita un viaje de ida y vuelta:

1. Una grabación de pantalla de un dispositivo físico con el sistema operativo más reciente, comenzando desde el inicio de la aplicación y mostrando el flujo típico: registro, inicio de sesión, eliminación de cuenta, cualquier contenido generado por el usuario con funcionalidad de reporte/bloqueo, y acceso al contenido de pago. Grábelo con la compilación enviada; adjunte el archivo a la respuesta en los Mensajes de la aplicación (o enlácelo) y menciónelo en las Notas. Nunca use la cuenta demo de revisión para la parte de eliminación: cree una cuenta nueva en la grabación.
2. El propósito y la audiencia objetivo de la aplicación: el problema que resuelve y su valor.
3. Instrucciones de configuración y acceso para las funciones principales, con credenciales demo y rutas de menú.
4. Cada servicio externo detrás de las funciones principales: autenticación/base de datos, pagos (StoreKit + cualquier envoltorio), proveedores de IA, fuentes de datos (por ejemplo, APIs de mapas), correo electrónico, frameworks de salud.
5. Diferencias regionales, o una declaración de que las funciones son las mismas en todas partes.
6. Para áreas reguladas o contenido protegido por terceros: documentación o una declaración de que ninguna aplica (por ejemplo, "bienestar general, no un dispositivo médico").

7. Informe de aprobación/rechazo

Complete plantillas/informe-de-aprobacion-rechazo.md con evidencia para cada línea (captura de pantalla, número de compilación, salida de comando). Cualquier No en una línea bloqueante significa que no se envía.

8. Enviar (APROBACIÓN)

Solicite al titular de la cuenta la aprobación explícita con el informe adjunto. En iOS elija liberación manual para que la aprobación no se publique inmediatamente. En Play, el acceso de producción (nuevas cuentas personales) necesita la prueba cerrada de 14 días completada y la solicitud de acceso de producción primero.

Después de un rechazo

Consulte referencias/manual-de-rechazo.md: lea la directriz exacta, reproduzca, corrija la causa raíz (a menudo más de una capa), responda en el Centro de Resolución con detalles, vuelva a enviar; apele solo cuando el revisor haya malinterpretado un hecho que pueda probar.

Puntos de decisión que requieren aprobación humana

Enviar, elegir el método de liberación, responder a un rechazo (tono y compromisos), presentar una apelación, conceder premium a la cuenta de revisión.

Verificación

El informe de aprobación/rechazo está completo con evidencia, y alguien que no construyó la función siguió las notas de revisión en un dispositivo limpio y tuvo éxito.

Errores comunes

• La cuenta demo depende de un código de correo electrónico que el revisor no puede leer.
• La cuenta demo está vacía, congelada o eliminada por un trabajo de limpieza.
• Productos en "Metadatos faltantes" (sin captura de pantalla de revisión), por lo que nunca se cargan en la revisión.
• Eliminar una versión de la revisión ("Rechazada por el desarrollador") también elimina las suscripciones del borrador; vuelva a agregar el grupo y cada suscripción antes de volver a enviar, o la versión va sola.
• Los activos de la página del producto están bloqueados mientras la versión está "Esperando revisión" (por ejemplo, el nuevo activo de encabezado). Agregue todo antes de enviar; de lo contrario, debe eliminar la versión de la revisión, editar y volver a enviar (pierde su lugar en la cola).
• La verificación de "Añadir para revisión" de Apple pasa, pero no significa que los activos opcionales estén configurados: un activo de encabezado vacío está permitido, así que decida sobre él antes de enviar.
• Una cuenta nueva de Apple del revisor entra en conflicto con sus reglas de restauración/transferencia y la compra "falla".
• Backend en un plan que se pausa después de inactividad o limita la velocidad al revisor.
• "Próximamente" en cualquier parte de la compilación.
• Texto dentro de la aplicación que menciona la otra tienda.
• Notas de revisión que solo explican el inicio de sesión demo (sin grabación, propósito, servicios o regiones).