Checklist de aprobación en la App Store: apps de fidelización y el límite de 30 caracteres

Envía solo una build terminada y probada, con metadatos precisos, una divulgación de privacidad completa y un acceso fiable para el revisor. Con estas tres cosas eliminas la mayoría de las causas habituales de rechazo: una etiqueta de privacidad que no coincide, una cuenta demo bloqueada o un fallo en el primer arranque. El resto de este checklist recorre todas las categorías que revisa el equipo de App Review de Apple, en el orden en que deberías revisarlas tú mismo.

En resumen:

• Mantén cada recurso de la ficha alineado con el comportamiento real de la app: las capturas deben coincidir con las pantallas actuales y los nombres deben respetar el límite de 30 caracteres de Apple.
• Revisa la etiqueta de privacidad (Privacy Nutrition Label) en cada versión, compara el manifiesto de cada SDK externo con la recopilación real de datos y ofrece eliminación de cuenta y enlaces activos a la política de privacidad.
• Prueba los flujos clave en dispositivos físicos con todas las versiones del sistema compatibles, y da a los revisores credenciales que funcionen, servicios activos y acceso a las recompensas restringidas sin necesidad de compra.
• Haz que cada compra dentro de la app sea visible en la build y documenta en las notas de revisión la renovación de suscripciones, las condiciones de cancelación, la clasificación por edades y la documentación necesaria.

Checklist de la ficha de la tienda: nombre, descripción, capturas y vistas previas definitivos

La página de producto es lo primero que ve un revisor, y cualquier incoherencia genera dudas antes incluso de que alguien abra tu build. Apple trata las App Review Guidelines como una promesa de que lo que muestras coincide con lo que publicas, así que cada recurso necesita una revisión final antes del envío.

Empieza por lo básico. El nombre de la app tiene un límite de 30 caracteres, y Apple rechazará nombres que usen marcas registradas que no te pertenecen o que induzcan a error sobre la funcionalidad. La descripción debe explicar de forma directa lo que la app hace realmente, no lo que aspira a hacer. Si escribiste la descripción antes de los últimos tres sprints, lo más probable es que todavía mencione una función que eliminaste u omita una que añadiste.

• Comprueba que el nombre de la app respeta el límite de 30 caracteres y evita marcas registradas o afirmaciones engañosas
• Reescribe la descripción para que coincida exactamente con las funciones publicadas, sin dejar texto de relleno
• Haz capturas de flujos reales dentro de la app, en todos los tamaños de dispositivo compatibles, incluidas las versiones localizadas cuando corresponda
• Añade vídeos de vista previa cuando aclaren un flujo que Apple podría malinterpretar, y evita superposiciones que exageren la funcionalidad
• Define el subtítulo, el texto promocional, las palabras clave y las variantes de metadatos localizados

En una app de fidelización o recompensas, este paso importa más de lo que parece. Las capturas que muestran una tarjeta de sellos, un saldo de cashback o un flujo de referidos deben reflejar exactamente tu interfaz actual, hasta el texto de los botones. Los revisores comparan tus capturas con la build en ejecución, y una pantalla de recompensas rediseñada que no coincide con los recursos de App Store Connect es una alerta fácil de evitar.

Mantén el campo de palabras clave conciso y relevante en lugar de rellenarlo. Una larga lista de términos poco relacionados no mejora la visibilidad y puede interpretarse como un intento de manipular la búsqueda, algo que las directrices de Apple desaconsejan expresamente. Trata tus metadatos como un contrato con el revisor: todo lo que lea debe sostenerse en cuanto toque tu icono.

Detalles de privacidad y SDK de terceros: qué declarar y cómo preparar los manifiestos

Toda app enviada a la App Store debe incluir detalles de privacidad completos en App Store Connect, y esas respuestas alimentan la etiqueta de privacidad (Privacy Nutrition Label) de la página de producto. Es obligatorio en cada nuevo envío y en cada actualización, así que una etiqueta de privacidad que completaste hace dos versiones no basta si desde entonces has añadido un SDK de analítica.

Un dato que conviene recordar: los problemas de completitud de la app y de directrices relacionadas representan más del 40 % de los problemas de revisión sin resolver, lo que convierte la precisión en privacidad y la estabilidad de la build en las dos comprobaciones más rentables que puedes hacer antes de enviar.

Sigue este orden:

1. Completa las preguntas de la etiqueta de privacidad en App Store Connect y revísalas en cada versión, no solo en el primer envío
2. Usa la agregación de manifiestos de privacidad de SDK de Xcode para comprobar que cada SDK de terceros integrado declara lo que realmente recopila
3. Confirma que la URL de tu política de privacidad está activa y es accesible tanto desde la app como desde tu página de producto en la App Store
4. Crea un flujo de eliminación de cuenta dentro de la app y describe claramente en la propia política cómo conservas y eliminas los datos
5. Añade en Info.plist textos de propósito para cada permiso sensible que solicite tu app, redactados en un lenguaje sencillo que cualquier usuario entienda

Los SDK de terceros merecen especial atención. Si un SDK de fidelización, analítica o notificaciones push recopila más de lo que indica tu etiqueta de privacidad, la discrepancia aparece durante la revisión y provoca un rechazo que no tiene nada que ver con tu propio código. Compara el manifiesto de cada proveedor con lo que declara tu etiqueta de privacidad antes de enviar, no después de que un rechazo te obligue a hacerlo.

Comprobaciones de funcionalidad y rendimiento: estabilidad, compatibilidad de dispositivos y capacidades requeridas

La completitud de la app es la categoría de las directrices que frena más envíos, y en su mayor parte se reduce a cosas que puedes probar tú mismo antes de que Apple vea tu build. Los revisores ejecutan tu app en dispositivos reales, así que todo lo que solo funcionaba bien en el simulador es un riesgo.

Prueba todas las versiones del sistema compatibles en hardware físico, no solo el iPhone más reciente en el simulador. Los dispositivos y versiones de iOS más antiguos sacan a la luz problemas de memoria y errores de diseño que el hardware nuevo oculta. Corrige todo lo que provoque fallos o bloquee un flujo principal antes de pulsar el botón de envío.

• Prueba en dispositivos reales con todas las versiones del sistema que dices admitir, y resuelve primero los fallos y errores bloqueantes
• Verifica que tus servicios de backend y cualquier integración externa están activos y son accesibles para el revisor, no solo para tu entorno de pruebas interno
• Proporciona una cuenta demo, o un modo demo aprobado, siempre que se necesite iniciar sesión o un hardware concreto para ver la funcionalidad principal
• Haz que las declaraciones de capacidades del dispositivo en Info.plist coincidan con lo que la app usa realmente, en lugar de dejar los valores por defecto de una plantilla
• Elimina el contenido de relleno, el texto lorem ipsum y las pantallas sin terminar antes de enviar

Consejo: Mantén una cuenta dedicada para revisores activa en un entorno de staging o producción que replique tu backend real, para no tener que crearla a toda prisa la noche antes de una fecha límite.

La propia guía de Apple sobre App Review deja claro que disponer de cuentas demo y servicios de backend activos durante el periodo de revisión evita gran parte de los retrasos evitables. Si tu app de fidelización condiciona el canje de recompensas a un historial de compras o a una tarjeta vinculada, crea un recorrido para el revisor que muestre ese flujo sin requerir una transacción real.

Reglas de negocio y compras dentro de la app: configurar, mostrar y documentar IAP y suscripciones

Si tu app vende algo a través del sistema de pago de Apple, la configuración debe estar completa y la compra debe ser visible para el revisor dentro de tu build real. Una compra que existe en App Store Connect pero no aparece en ninguna parte de la app es uno de los rechazos más frustrantes, porque la solución suele ser un problema de build y no de políticas.

• Añade y configura por completo cada compra dentro de la app y cada suscripción en App Store Connect, y confirma después que cada una se puede encontrar en la build enviada
• Documenta las condiciones de la suscripción, la frecuencia de renovación y los pasos de cancelación tanto en las notas de revisión como en los metadatos de la app
• Responde con sinceridad al cuestionario de clasificación por edades, incluidos los descriptores de contenido que se apliquen a tu contenido real
• Adjunta la documentación de la entidad en la sección de archivos adjuntos para cualquier servicio regulado que toque tu app, como funciones financieras o relacionadas con la salud

En las apps de fidelización y recompensas que ofrecen niveles de pago, recargas de cashback o funciones de suscripción premium, asegúrate de que el revisor pueda llegar a la pantalla de compra sin un muro de inicio de sesión ajeno en medio. Si una función solo se desbloquea tras alcanzar un umbral de puntos o subir de nivel de fidelización, dilo claramente en las notas de revisión en lugar de dejar que el revisor lo descubra por su cuenta.

Pasos de envío en App Store Connect y cómo comunicarte con App Review

El proceso de envío en App Store Connect sigue una secuencia concreta, y saltarse pasos normalmente solo significa repetirlos después. Síguelo en orden.

1. Rellena la sección App Review Information con notas claras, credenciales de demo y cualquier paso de configuración especial que el revisor deba seguir
2. Adjunta documentación de apoyo para las categorías reguladas e incluye un vídeo demo breve si una función depende de un hardware al que el revisor no tiene acceso
3. Elige el tipo de revisión adecuado para tu envío y confirma que incluyes instrucciones localizadas si tu app admite varios idiomas
4. Si Apple te envía un mensaje pidiendo aclaraciones, responde directamente a través de App Store Connect y adjunta capturas o archivos en lugar de reenviar a ciegas
5. Haz una última revisión de los metadatos y del binario, y envía

Apple recomienda familiarizarse con las directrices desde el principio del desarrollo en lugar de tratarlas como un checklist de última hora, y el flujo de revisión lo confirma: las notas de revisión y los adjuntos solo ayudan si son precisos y concretos. La revisión se realiza de forma continua, y según las propias cifras de Apple alrededor del 50 % de los envíos se revisan en 24 horas y el 90 % en 48 horas, así que un envío limpio y completo suele ser un envío rápido.

Plan de pruebas previo al envío: smoke tests, control de fallos y validación de accesibilidad

Antes de enviar, haz una ronda de pruebas breve y deliberada en lugar de confiar en las pruebas que se hicieron durante el desarrollo. No tiene que ser exhaustiva, pero sí debe cubrir los recorridos que un revisor va a probar realmente.

• Haz smoke tests del registro, del flujo principal, de cualquier recorrido de compra y del cierre de sesión en cada tipo de dispositivo compatible
• Revisa el panel de informes de fallos en busca de regresiones introducidas en la build final y comprueba los registros de errores críticos
• Valida las funciones de accesibilidad que has declarado en App Store Connect, incluidos el soporte de VoiceOver, los subtítulos y el manejo de texto grande
• Confirma que tus cuentas demo y endpoints de backend son accesibles desde el entorno de producción que usará el revisor
• Decide si un vídeo demo o una cuenta demo muestra mejor una función que depende de hardware, ubicación o un dispositivo vinculado

Consejo: Cuando una función necesita hardware especializado, como un wearable o un lector NFC, un vídeo demo breve adjunto a las notas de revisión suele ser más rápido que intentar simular el hardware para el revisor.

También es el momento adecuado para usar TestFlight y hacer una última ronda de pruebas beta con un grupo reducido ajeno a tu equipo. Una mirada nueva detecta enlaces rotos y flujos confusos en los que tu equipo ya ha dejado de fijarse.

Principales causas de rechazo y soluciones rápidas para desbloquear un nuevo envío

La mayoría de los rechazos encajan en unas pocas categorías recurrentes, y casi todas tienen una solución rápida cuando sabes qué buscar.

• Capturas o descripciones que no coinciden con el comportamiento actual de la app: actualiza los recursos, o termina la función, para que ambos coincidan
• Fallos o errores evidentes en dispositivos compatibles: revierte el cambio problemático o corrígelo, y verifícalo en un dispositivo real antes de volver a enviar
• Divulgaciones de privacidad incompletas o manifiestos de SDK que no coinciden con la recopilación real de datos: actualiza a la vez la etiqueta de privacidad y los manifiestos de los SDK
• Una cuenta de revisor que no funciona o un endpoint de backend caído: proporciona credenciales que funcionen y adjunta un vídeo demo breve como respaldo
• Una compra dentro de la app que el revisor no encuentra: comprueba que está bien configurada y visible en la build, y explica dónde se encuentra en las notas de revisión

La referencia de directrices de Apple sobre la precisión de los metadatos es clara en este punto: los usuarios deben saber exactamente qué van a obtener, así que cualquier diferencia entre tu página de producto y el comportamiento real de la app se trata como un problema de confianza, no estético. Corrige la causa de fondo y no el síntoma, vuelve a probar y reenvía con una nota breve que explique qué ha cambiado.

Cómo deben prepararse las apps con funciones de fidelización: un checklist práctico

Las apps basadas en puntos, sellos o cashback tienen algunos elementos adicionales que conviene revisar antes del envío, y los vemos aparecer a menudo con las funciones de fidelización que desarrollamos en BonusQR.

• Confirma que la integración de pases de Apple Wallet está terminada, incluidos el diseño de la tarjeta y el comportamiento de actualización, y descríbela en las notas de revisión
• Ofrece flujos demo para acumular puntos, canjear recompensas y enviar referidos, con opciones en el backend que el revisor pueda usar sin hacer una compra real
• Documenta cualquier dato que un SDK de fidelización envíe a terceros, como un proveedor de wallet o un servicio de notificaciones push, y asegúrate de que tu etiqueta de privacidad lo refleje exactamente
• Mantén el flujo de eliminación de cuenta visible desde la pantalla del perfil de fidelización, no escondido tras una solicitud de soporte

Una app de recompensas que oculta su mejor función tras un nivel bloqueado o un código promocional escondido suele confundir a los revisores más que cualquier otro tipo de envío. Crea un recorrido demo visible y funcional para cada mecánica de recompensa que publiques.

Una nota de Michal sobre cómo acertar a la primera

Si solo vas a priorizar tres cosas de este checklist, que sean estas: una etiqueta de privacidad que coincida con tu recopilación real de datos, una cuenta de revisor que funcione al primer intento y una build sin ningún fallo en el dispositivo más antiguo que admitas. Casi todos los rechazos que hemos visto se deben a una de esas tres cosas.

Integra este checklist en tu proceso de publicación en lugar de tratarlo como una tarea puntual antes de un gran lanzamiento. Una revisión interna breve, hecha siempre de la misma manera, detecta mucho más que una comprobación apresurada la noche antes de una fecha límite.

— Michal

Preguntas frecuentes

¿Es difícil conseguir que aprueben una app en la App Store?

La aprobación es sencilla cuando el envío está completo: unos metadatos precisos, una cuenta demo que funcione y la ausencia de fallos resuelven más del 40 % de los problemas que, de otro modo, frenan la revisión. La mayor parte de la dificultad viene de envíos incompletos más que de políticas estrictas, y una build limpia suele avanzar con rapidez.

¿Cómo puedo aprobar la solicitud de una app de mi hijo?

Esta pregunta suele referirse a las opciones En familia o Solicitar la compra de Apple, que permiten a un progenitor aprobar descargas y compras desde una cuenta infantil vinculada directamente en Ajustes. Es un permiso del dispositivo y de la cuenta, no forma parte del proceso de App Review del lado del desarrollador que cubre este checklist.

¿Cuáles son las directrices de Apple para aprobar una app?

Las App Review Guidelines de Apple abarcan seguridad, rendimiento, reglas de negocio, diseño y requisitos legales, y la completitud y la precisión de los metadatos están entre las áreas que más se revisan. Los revisores comparan el comportamiento real de tu app con lo que afirman tu página de producto y tu etiqueta de privacidad.

¿Cuánto suele tardar la aprobación de una app en la App Store?

La revisión se realiza de forma continua, y Apple indica que aproximadamente el 50 % de los envíos se revisan en 24 horas y el 90 % en 48 horas. Los metadatos incompletos, la falta de acceso para el revisor o el contenido de relleno son las causas más habituales de retrasos más allá de ese plazo.

¿Qué debo comprobar antes de elegir una plataforma de fidelización para las funciones de recompensas de mi app?

Busca una plataforma que admita pases de Apple Wallet, que te dé control sobre las divulgaciones de privacidad de los SDK de terceros que incluya y que ofrezca modos demo o sandbox que puedas facilitar a los revisores. Diseñamos los planes de fidelización y la configuración de app white-label de BonusQR teniendo en cuenta estos requisitos de revisión, desde el comportamiento de los pases de Wallet hasta las opciones de backend para cuentas demo.

Fuentes

• App privacy details - Apple Developer
• App Review - Distribute - Apple Developer
• Submitting - App Store - Apple Developer
• 5.1.1(v) — Offering account deletion in your app - Apple Developer

Documentación clave de Apple y recursos de referencia

• App privacy details - Apple Developer
• App Review - Distribute - Apple Developer
• Submitting - App Store - Apple Developer
• 5.1.1(v) - Offering account deletion in your app - Apple Developer
• App Review Guidelines - Apple Developer