Cinco comprobaciones previas al envío que ayudan a una app individual a superar la revisión

Los revisores tocan primero tu estado más débil

Terminas una compilación, te sientes listo y entonces llega un rechazo con un número de directriz y sin disculpas. SameQ se lanzó en App Store el 24 de septiembre de 2026, tras cinco revisiones de App Store y cuatro rechazos. Los revisores de App Store y Google Play prueban el onboarding, los casos límite, los permisos, los pagos y el comportamiento poco claro. Una app que solo funciona en el camino feliz no superará la revisión.

La revisión de App Store de Apple es más manual y centrada en la experiencia, mientras que la revisión de Google Play es más orientada a políticas y basada en sistemas. Para abril de 2026, Apple parecía estar utilizando automatización para algunas revisiones y aprobaciones de apps. Una máquina puede aprobar algunas apps, pero no rescatará un estado de onboarding roto. Necesitas un recorrido breve y repetible antes del envío.

El SameQ de Keita Nakagawa tuvo su primer commit el 17 de agosto de 2026 y, para el lanzamiento, contenía 197 commits, 23 sprints, 23 migraciones de Supabase, unas 15.600 líneas de Swift y 53 archivos de pruebas. Una app individual puede tener muchas piezas en movimiento y aun así fallar por un pequeño estado. El binario archivado es el contrato. Si está desactualizado, el revisor verá el antiguo bug. Unos minutos haciendo explícito el archivo pueden ahorrarte el tipo de espera más costoso.

Cinco comprobaciones mantienen el archivo honesto

Cada comprobación apunta a una razón de rechazo que puede costar días, no a un nuevo ritual.

• Verifica el commit del archivo. Confirma que la compilación archivada coincide con la rama que acabas de probar y que la corrección del onboarding está presente en el binario. La primera compilación de App Store de SameQ, 1.0 (1), fue rechazada bajo la Directriz 2.1(a) porque el binario archivado era anterior a una corrección de un bug de onboarding por sesión expirada.
• Diseña para el día más vacío. Abre la pantalla principal sin respuestas, sin red y con una sesión desactualizada. SameQ añadió una función auto-reparadora de Postgres llamada ensure_official_answers() que inserta respuestas del operador cuando la pregunta de un día no tiene ninguna.
• Entrega la lista de verificación de cumplimiento completa en una sola compilación. Confirma que la privacidad, el inicio de sesión anónimo y los controles de reporte/bloqueo están todos en el mismo binario. SameQ traduce respuestas usando el marco de trabajo Translation de Apple en el dispositivo, y los cuerpos de las publicaciones no se envían a un servidor de traducción. SameQ permite cuentas anónimas sin exigir una dirección de correo electrónico ni un número de teléfono. Una actualización de SameQ movió los controles de Reportar y Bloquear directamente debajo de cada respuesta con una etiqueta e icono visibles.
• Escribe notas de revisión a partir del código. Lista las pantallas cambiadas, los permisos y los flujos de datos del diff enviado. Las notas deben describir la compilación enviada, no el próximo sprint.
• Prueba en un dispositivo real con un idioma no nativo. Configura el idioma del dispositivo a un idioma en el que no escribes y ejecuta el onboarding. Los problemas de localización pueden permanecer invisibles a menos que se prueben en el contexto internacional exacto, porque los dispositivos reales y los navegadores manejan fuentes, métodos de entrada, configuraciones de localización y renderizado de manera diferente.

La auditoría es barata porque apunta a los lugares donde un desarrollador individual ahorra más tiempo. No se requiere una suite completa de QA antes del primer envío. La auditoría capta los estados que un revisor probablemente tocará primero y hace que cualquier rechazo sea más fácil de responder señalando el comportamiento exacto de la compilación en lugar de adivinar. Eso protege tu calendario, que es el verdadero activo.

Un envío repetible protege tus horas

El margen de un desarrollador individual se mide en horas, no solo en ingresos. Un rechazo puede costar espera, re-archivado y explicaciones. Las cinco comprobaciones convierten ese costo en una rutina breve.

Las pruebas automatizadas son más rápidas, más repetibles y generalmente dan un feedback más accionable antes en el proceso de desarrollo. La última hora antes del envío sigue siendo humana. Es la hora en la que empiezas a recorrer el camino del revisor. Hazlo, y la revisión dejará de devorar tus horas.

Si los agentes de código escriben el código rápidamente, el revisor sigue recorriendo la app. Mantén el envío lo suficientemente pequeño para que un rechazo no se convierta en una reconstrucción.