Ocho motivos por los que la revisión de App Store devuelve tu app

La respuesta corta: la mayoría de los rechazos de apps en App Store y Google Play no se deben a un error de programación. Se deben a elementos administrativos que controla el dueño del negocio, no el desarrollador: una cuenta de demostración con la que el revisor pueda iniciar sesión, una política de privacidad completa, una declaración de datos que coincida con la realidad, una cuenta de desarrollador a nombre de la empresa y un plazo técnico que ya ha vencido. Todo ello se puede preparar dos semanas antes del lanzamiento sin escribir una sola línea de código.

El impacto en el calendario es mayor de lo que parece. Un rechazo no significa que la app sea mala; significa que la app vuelve al final de la cola después de cada corrección, de modo que una campaña de lanzamiento ligada a una temporada o a un evento se convierte en un retraso indefinido. Por eso el expediente de publicación merece tratarse como parte del proyecto, no como un trámite que se deja para el último día.

1 — No hay una cuenta de demostración con la que el revisor pueda abrir tu app

Este es el motivo más repetido en las apps que empiezan con una pantalla de inicio de sesión. El revisor no es uno de tus clientes y no tiene un número de teléfono registrado en tu sistema, así que, sin credenciales preparadas, se queda en la primera pantalla. La regla de integridad de la app de Apple (App Completeness, 2.1) es explícita: envía una versión final, incluye los datos de una cuenta de demostración si tu app tiene inicio de sesión y mantén activo tu servicio de back-end. Si obligaciones legales o de seguridad te impiden proporcionar una cuenta real, puedes incluir un modo de demostración integrado que muestre toda la funcionalidad de la app, con la aprobación previa de Apple.

En la práctica: prepara una cuenta permanente que no caduque y que no se borre durante las limpiezas de datos, y asegúrate de que los servidores de staging estén funcionando durante el periodo de revisión, no solo en tu horario de oficina.

2 — La tienda ve tu app como un sitio web reempaquetado

La regla de funcionalidad mínima (Minimum Functionality, 4.2) establece que una app debe incluir funciones, contenido e interfaz que la eleven por encima de un sitio web reempaquetado, y que no son aceptables las apps que son principalmente material de marketing, recortes web, agregadores de contenido o una colección de enlaces. Muchas empresas piden una app porque la competencia tiene una, y el producto sale como una copia del sitio web dentro de un envoltorio.

Hay dos salidas: o das a la app un valor real que el navegador no puede ofrecer —uso sin conexión, notificaciones según el estado del pedido, escaneo de códigos de barras, datos guardados en el dispositivo, integración de pagos y mapas— o publicas una aplicación web progresiva en lugar de pasar por las tiendas. Analizamos esta disyuntiva en aplicación web progresiva o app nativa.

3 — La política de privacidad está incompleta o no aparece dentro de la app

La regla de recopilación de datos de Apple (Data Collection, 5.1.1) exige un enlace a la política de privacidad en los metadatos de App Store Connect y dentro de la app, en un lugar de fácil acceso. La política debe identificar qué datos se recopilan, cómo y todos los usos que se les dan; confirmar que cualquier tercero con el que compartas datos —herramientas de analítica, redes publicitarias, SDK de terceros— ofrece la misma protección; y explicar las políticas de conservación y eliminación y cómo revoca el usuario su consentimiento.

No es una página que se copia de otro sitio web. Es una descripción de lo que hace realmente tu sistema, y debe ajustarse a tus obligaciones bajo la Ley de Protección de Datos Personales de Arabia Saudí (PDPL), tal como explicamos en nuestra guía práctica de la PDPL.

4 — No hay eliminación de cuenta dentro de la app

La regla 5.1.1 (v) es clara: si tu app permite crear una cuenta, también debes ofrecer la eliminación de la cuenta dentro de la app. Y añade una norma que muchos equipos pasan por alto: si tu app no incluye funciones importantes basadas en una cuenta, deja que la gente la use sin iniciar sesión, y no pidas información personal salvo que sea directamente relevante para la funcionalidad principal o la exija la ley.

La eliminación de la cuenta aquí no es solo un botón en la interfaz; es un recorrido completo en el back-end. ¿Qué pasa con los pedidos, las facturas y los registros contables del cliente que legalmente no se pueden borrar? La respuesta habitual es separar los datos de identidad de los registros financieros antes de que empiece el desarrollo, no después.

5 — La declaración de seguridad de los datos de Google Play no coincide con lo que hace la app

Google exige a todo desarrollador declarar los datos que la app recopila y transmite fuera del dispositivo, incluidos los datos recopilados por bibliotecas y SDK de terceros, si la recopilación es obligatoria u opcional, la finalidad, si los datos se cifran en tránsito y si existe un mecanismo para solicitar su eliminación. La política establece que el desarrollador es el único responsable de que las declaraciones sean exactas, y que las infracciones conllevan el bloqueo de las actualizaciones o la retirada de Google Play.

El error habitual es sencillo: un desarrollador añadió una herramienta de analítica o de informes de fallos para facilitarse el trabajo, y nadie la incluyó en la declaración. Hazle a tu equipo una sola pregunta antes de enviar: ¿cuál es la lista completa de paquetes de terceros de esta app y qué envía cada uno de ellos?

6 — La actualización se rechaza porque la app apunta a una versión antigua de Android

Desde el 31 de agosto de 2026, Google Play exige que las apps nuevas y las actualizaciones tengan como objetivo Android 16 (nivel de API 36) o superior, con excepciones: Wear OS y Android Automotive en el nivel 35, y Android TV y Android XR en el nivel 34. Los desarrolladores que solicitaron una prórroga tienen hasta el 1 de noviembre de 2026.

La consecuencia operativa para el dueño de un negocio: tu app publicada sigue en la tienda, pero no puedes publicar ninguna actualización —ni siquiera una corrección de seguridad urgente o un cambio de precio— hasta que se recompile con el nivel exigido. Cualquier app que no se haya actualizado en un año merece una revisión de este punto antes de que necesites una publicación urgente.

7 — Las cuentas nuevas necesitan 12 testers y 14 días antes de publicar

Las cuentas personales de desarrollador creadas en Google Play después del 13 de noviembre de 2023 no pueden publicar de forma pública de inmediato. Necesitan una prueba cerrada con un mínimo de 12 testers inscritos de forma continua durante al menos 14 días antes de solicitar el acceso a producción. Son dos semanas más en el calendario y 12 personas reales con cuentas de Google reales.

Por otro lado, inscribirse en el Apple Developer Program como organización requiere un número D-U-N-S y una entidad jurídica con capacidad para celebrar contratos, bajo la razón social de la organización, no un nombre comercial ni una sucursal. Obtener el número y superar la verificación lleva días. Empieza con esto en la primera semana del proyecto, no en la semana del lanzamiento.

8 — Metadatos de la tienda, capturas de pantalla y una app distinta por sucursal

Tres reglas pequeñas hunden lanzamientos enteros: las capturas de pantalla deben mostrar la app en uso, no la imagen del título, la página de inicio de sesión ni la pantalla de bienvenida (2.3.3); el nombre de la app está limitado a 30 caracteres y los metadatos no pueden llenarse de términos de marcas registradas, nombres de apps populares o precios (2.3.7); y no puedes crear varios bundle IDs de la misma app (4.3a), que es justo lo que ocurre cuando una empresa pide una app distinta por sucursal o por ciudad. El patrón correcto es una sola app en la que el usuario selecciona la sucursal.

Cómo encaja esta puerta en el plan del proyecto

  • Registra la cuenta de desarrollador a nombre de tu empresa, no del desarrollador ni de la agencia. Es un activo de la empresa, como el dominio, tal como explicamos en quién es el dueño de los derechos de tu software.
  • Abre las cuentas en la primera semana: Apple cobra 99 $ al año y Google Play un pago único de 25 $, y lo que lleva tiempo es la verificación, no el pago.
  • Incluye una cláusula en el contrato que indique quién envía la compilación y responde a las observaciones de la revisión, y cuántos ciclos de revisión cubre el precio.
  • Trata el expediente de publicación como un entregable propio: política de privacidad, declaración de datos, capturas de pantalla, descripción, cuenta de demostración y la lista de paquetes de terceros.
El código se termina una semana antes del lanzamiento. El expediente de publicación necesita dos semanas. Equivocarse en ese orden está detrás de la mayoría de los lanzamientos retrasados.

Fuentes