Cómo se aprueban las apps en la App Store y Google Play
La revisión rechaza a diario carcasas web vacías, enlaces rotos y fallos de privacidad. Aquí tienes por qué rechazan las apps, qué comprueban los revisores y cómo pasar en ambas tiendas.
Por qué existe la revisión (y qué está probando en realidad)
Antes de llegar a un solo usuario, tu app pasa por la revisión de Apple y de Google. La revisión no está para complicarte la vida: protege a las personas de apps inseguras, rotas, engañosas o simplemente vacías. Para conseguir que aprueben tu app en la App Store y Google Play tienes que cumplir dos reglamentos distintos: las App Review Guidelines de Apple y las Políticas del Programa para Desarrolladores de Google Play.
Ambas tiendas coinciden en lo esencial —seguridad, privacidad, metadatos honestos y funcionalidad real—, pero se diferencian en el tono y el proceso. La revisión de Apple es más estricta y en gran parte manual: una persona abre tu app y la usa. Google se apoya más en el análisis automático, con revisores humanos para los casos límite. En el fondo ambas preguntan lo mismo: '¿es esto un producto real, seguro y útil?'. Cuando lo interiorizas, dejas de adivinar y empiezas a diseñar pensando en la aprobación.
Los motivos de rechazo más habituales
El gran culpable es la carcasa web vacía. La directriz 4.2 de Apple (Funcionalidad mínima) dice de forma explícita que una app debe ofrecer funciones, contenido e interfaz que vayan más allá de una web reempaquetada, y Google Play penaliza las apps que son un simple envoltorio de una web móvil sin valor añadido. Si tu app es un navegador apuntando a tu URL, cuenta con el rechazo.
Los demás motivos son prácticos: enlaces rotos o pantallas sin salida, cierres inesperados y errores durante la revisión, una política de privacidad ausente o inaccesible, declaraciones de privacidad incompletas (las etiquetas de Apple, el formulario de Seguridad de los datos de Google), rastrear al usuario sin el aviso App Tracking Transparency de Apple, capturas o metadatos engañosos, y muros de acceso sin credenciales de prueba para el revisor. Todos son evitables y todos están documentados: son razones repetibles por las que rebotan un envío.
Qué buscan realmente los revisores de App Store y Google Play
Los revisores siguen una lista mental breve. Primero: ¿la app hace algo nativo y útil, o es una página que podrías abrir en Safari o Chrome? Segundo: ¿es estable, sin cierres, sin pantallas en blanco, sin flujos rotos evidentes? Tercero: ¿es honesta, es decir, coinciden las capturas, la descripción y la categoría con lo que la app hace de verdad?
Después llegan la privacidad y los permisos. Si tu app pide cámara, ubicación o notificaciones, el revisor espera una razón clara y en contexto, y una declaración de privacidad coherente. Si gestiona cuentas, necesita entrar, y por eso un acceso de prueba que funcione (o un modo invitado) es innegociable. Por último comprueban la clasificación de contenido, las opciones de inicio de sesión y las reglas propias de cada plataforma. Nada es secreto —está todo en las guías—, pero hay que cumplirlo de verdad, no solo declararlo.
Por qué una app nativa de verdad pasa la revisión (y una carcasa fina no)
La vía más fiable para superar la Funcionalidad mínima es ofrecer a la tienda comportamiento nativo real. Una app nativa de verdad —una carcasa Swift en iOS, una carcasa Kotlin en Android— que carga tu web en vivo dentro de un contenedor nativo de alto rendimiento y añade funciones del dispositivo mediante un puente JavaScript es un producto de otra categoría. Notificaciones push, modo offline, acceso biométrico, deep links, cámara, widgets en la pantalla de inicio y accesos directos son exactamente el 'valor nativo' que se pide a los revisores que busquen.
Este es el enfoque de Transform To APP. El contenido publicado en tu web sigue apareciendo al instante en la app —sin reenvíos por un artículo o un cambio de precio—, mientras la carcasa nativa aporta la funcionalidad que satisface a ambas tiendas. Obtienes las actualizaciones rápidas de la web y la profundidad nativa que supera la revisión, sin tener que elegir.
Tu checklist antes de enviar en ambas tiendas
Repásala antes de pulsar 'Enviar'. Evita la mayoría de los rechazos evitables:
- Valor nativo: al menos una o dos funciones reales del dispositivo (push, offline, biometría, cámara, widgets), no solo una URL cargada. - Estabilidad: pruébala en un dispositivo real; sin cierres, sin pantallas en blanco, con cada enlace y botón funcionando. - Política de privacidad: URL activa y accesible, enlazada dentro de la app y en la ficha de la tienda. - Declaraciones: etiquetas de privacidad de Apple y formulario de Seguridad de los datos de Google completos y exactos; aviso ATT si rastreas. - Permisos: pide solo lo que usas, cada uno con una explicación clara y en contexto. - Acceso: cuenta de prueba operativa o modo invitado para el revisor si hay inicio de sesión. - Metadatos: capturas y descripción acordes con la app real; categoría y clasificación correctas.
Marca todas las casillas y eliminas casi todos los motivos que un revisor tendría para rechazarte.
Publicar con tus propias cuentas de desarrollador
La aprobación también depende de dónde vive la app. Ambas tiendas exigen cuentas de desarrollador: el Apple Developer Program cuesta 99 USD al año y la cuenta de desarrollador de Google Play tiene un pago único de 25 USD. Publicar con tus propias cuentas hace que la app lleve tu marca, tu icono y el nombre de tu empresa, sin rastros de terceros en la ficha.
Transform To APP construye y envía con las cuentas de Apple y Google del propio cliente, no con una identidad de editor compartida, así que la ficha es tuya por completo y controlas las futuras actualizaciones. Como el contenido fluye desde tu web en vivo, solo los cambios nativos requieren una nueva compilación y un nuevo envío, y de eso nos ocupamos nosotros. El resultado es una app nativa de verdad que pasa la revisión, que posees por entero y que se mantiene al día sin pasar por la cola de revisión cada vez que cambias una palabra en tu web.
FAQ
¿Cuánto tarda la revisión de una app?+
Varía. Apple suele revisar en uno o dos días, mientras que Google puede ir de unas horas a varios días, y ambas pueden tardar más en un primer envío, ante una incidencia marcada o en periodos con mucha carga. Envía con margen antes de cualquier fecha de lanzamiento y nunca prometas un estreno público que dependa de una aprobación el mismo día.
¿Rechazarán una app hecha a partir de mi web?+
Una carcasa fina que solo carga tu web sin funcionalidad añadida es un motivo habitual de rechazo por la regla de Funcionalidad mínima de Apple y la política equivalente de Google. Una app nativa de verdad que carga tu web en vivo dentro de una carcasa nativa y añade funciones reales del dispositivo (push, offline, biometría, widgets) es justo lo que buscan los revisores, y por eso pasa.
¿Necesito mis propias cuentas de desarrollador de Apple y Google?+
Sí. El Apple Developer Program cuesta 99 USD al año y la cuenta de Google Play tiene un pago único de 25 USD. Publicar con tus propias cuentas mantiene la app bajo tu marca y te da la propiedad total de la ficha y de las futuras actualizaciones.
¿Qué pasa si rechazan mi app?+
Recibes el motivo concreto y la directriz relacionada. En la mayoría de los casos corriges el problema y vuelves a enviar; muchos rechazos se resuelven rápido cuando la causa está clara. Si crees que el rechazo es un error, ambas tiendas ofrecen un proceso de apelación o resolución.
Si actualizo mi web, ¿tengo que reenviar la app?+
No. Con una app nativa que carga tu web en vivo, los cambios de contenido —nuevos artículos, productos o precios— aparecen al instante en la app sin reenvío. Solo los cambios nativos, como una nueva función del dispositivo, requieren recompilar y volver a pasar la revisión.