Por Qué Apple y Google Rechazan la App de tu Tienda Online (y el Checklist 2026 para Publicarla a la Primera)

Hay una conversación que se repite con casi todos los responsables de tienda que se plantean dar el salto al móvil: "he pedido presupuesto para la app, pero me han dicho que Apple rechaza las apps de tiendas". No es del todo falso, y tampoco es del todo cierto. Lo que ocurre es que Apple y Google rechazan cosas muy concretas, y casi todas se pueden anticipar antes de escribir la primera línea de código.

Lo incómodo del proceso no es la exigencia técnica, sino el calendario: un rechazo en la App Store cuesta días, y un requisito de Google Play mal planificado cuesta semanas. Si tu objetivo es llegar con la app publicada a una campaña concreta —el Black Friday, la temporada alta de tu sector— el error no se paga en dinero, se paga en el trimestre entero.

Este artículo recoge los filtros que están vigentes en septiembre de 2026, con las fechas y las cifras exactas, y el orden en el que conviene resolverlos.

Los Cinco Filtros de 2026, en una Tabla

Antes del detalle, el mapa completo. Esta es la vista que conviene tener encima de la mesa cuando alguien te dice que "la app estará lista en dos semanas":

Apple 4.2: Por Qué No Basta con tu Web Dentro de un Icono

Es, con diferencia, el motivo de rechazo más frecuente en apps de comercio electrónico. La guía dice, en esencia, que tu app debe incluir funciones, contenido e interfaz que la eleven por encima de un sitio web reempaquetado, y que si no resulta especialmente útil, única o "app-like", no pertenece a la App Store.

Conviene deshacer un malentendido muy extendido: Apple no prohíbe el uso de tecnología web dentro de una app. Miles de apps perfectamente aprobadas muestran parte de su contenido con componentes web. Lo que Apple rechaza es otra cosa: que la app no aporte nada que el navegador del usuario no diera ya. Si abro tu app y veo exactamente tu web móvil, con su misma navegación y su misma barra de direcciones disfrazada, el revisor concluye que el usuario no gana nada instalándola.

Lo que mira en la práctica un revisor cuando duda:

• Navegación nativa. Pestañas inferiores, transiciones y gestos del sistema, no un menú web dentro de un marco.
• Notificaciones push. Implementadas y con un uso que tenga sentido, no un permiso pedido y nunca usado.
• Acceso a funciones del dispositivo. Biometría para entrar en la cuenta, cámara, geolocalización para tiendas físicas.
• Comportamiento sin conexión. No hace falta un modo offline completo, pero sí que la app no muestre el error de un navegador sin internet.
• Algo que la web no haga. Un buscador propio más rápido, el carrito persistente entre sesiones, la sesión iniciada de forma permanente.

Ese último punto es el que suele decidir el resultado, y también el que más beneficia al negocio. Un buscador que entiende lo que el cliente teclea —y no solo lo que coincide literalmente con el título del producto— es exactamente el tipo de función que justifica la instalación. Lo contamos con datos reales en la prueba que hicimos sobre una tienda en funcionamiento.

5.1.1(v): Si se Crea Cuenta, se Tiene que Poder Borrar

Este es el rechazo tonto por excelencia, porque llega cuando todo lo demás está bien. Desde el 30 de junio de 2022, cualquier app que permita crear una cuenta debe permitir también iniciar su borrado desde dentro de la propia app, junto con los datos personales asociados.

Los matices que provocan la mayoría de los rechazos:

• No vale desactivar o "pausar" la cuenta: tiene que poder eliminarse.
• No vale un formulario de soporte genérico donde el borrado sea uno más de los asuntos posibles.
• No vale obligar a llamar por teléfono o a escribir un correo, salvo en sectores muy regulados.
• Sí vale una opción clara dentro del área de cuenta que inicie el proceso y lo confirme.

Para una tienda online hay una consideración adicional que conviene resolver antes: borrar la cuenta del cliente no puede borrar sus facturas, porque la normativa fiscal obliga a conservarlas. La solución habitual es eliminar el perfil y los datos de contacto, y mantener el registro contable anonimizado. Deja explicado ese punto en la política de privacidad y en la pantalla de confirmación.

Google Play: 12 Testers Durante 14 Días Seguidos

Aquí es donde se rompen los calendarios. Las cuentas de desarrollador personales creadas después del 13 de noviembre de 2023 no pueden publicar directamente en producción: antes tienen que ejecutar una prueba cerrada con un mínimo de 12 testers dados de alta de forma continua durante 14 días. Solo cuando se cumplen ambas condiciones se puede solicitar el acceso a producción desde el panel de Play Console.

Los detalles que la gente descubre tarde y mal:

• Los 14 días son continuos. Si un tester se da de baja y vuelve a entrar, su contador vuelve a empezar; necesitas 12 simultáneos durante todo el periodo.
• Tienen que ser personas. Emuladores, bots y cuentas duplicadas no cuentan, y Google lo detecta.
• Antes eran 20. El requisito se rebajó a 12 en diciembre de 2024, pero los 14 días nunca han cambiado. Buena parte de la información que circula está desactualizada.
• Las cuentas de organización están exentas. Si registras la cuenta como entidad jurídica —con su número de identificación de empresa verificable— este requisito no se te aplica.

A esto se suma que Google está desplegando la verificación de identidad de los desarrolladores de forma progresiva desde 2026: documento oficial, domicilio y teléfono verificados. Los plazos varían por país y siguen ampliándose, así que conviene tener la documentación preparada antes de empezar, no cuando la app ya está lista.

Target API 36: la Fecha que Ya Ha Pasado

Desde el 31 de agosto de 2026, Google Play exige que las apps nuevas y las actualizaciones apunten a Android 16 (nivel de API 36) o superior. Play Console directamente rechaza la subida de un paquete que apunte a un nivel inferior. Google contempla solicitar una prórroga hasta el 1 de noviembre de 2026, pero es una excepción, no un plan.

El efecto sobre las apps que se quedan atrás es más silencioso y más peligroso: no desaparecen de la tienda, pero dejan de poder instalarse en dispositivos con una versión de Android superior a su target. Desde el panel de ventas eso no parece un problema de cumplimiento, parece que las instalaciones se han parado sin motivo. Es el tipo de avería que se diagnostica tarde porque no genera ningún aviso visible.

Si tu app la mantiene un proveedor, esta es la pregunta concreta que merece la pena hacerle por escrito: ¿a qué nivel de API apunta hoy mi paquete y quién se encarga de subirlo cada año? La obligación se repite cada temporada, no es un trámite de una vez.

Trader Status del DSA: el Filtro que Retira Apps Ya Publicadas

Este es distinto a todos los anteriores, y por eso se le presta menos atención de la que merece: no afecta a la publicación, afecta a la permanencia.

El Reglamento de Servicios Digitales de la Unión Europea obliga a las tiendas de aplicaciones a mostrar los datos de contacto de quien distribuye una app con fines comerciales. Apple lo instrumentó pidiendo a cada desarrollador que declarase su trader status y verificase una dirección, un teléfono y un correo electrónico. Desde el 17 de febrero de 2025, las apps que no lo habían hecho fueron retiradas de las tiendas de la Unión Europea hasta regularizar la situación.

Dos consecuencias prácticas para una tienda online:

• Se aplica a apps ya aprobadas y en funcionamiento. No hace falta que cambies nada en tu app para que te afecte.
• Los datos son públicos. Aparecen en la ficha de la app. Si operas como autónomo desde casa, piensa antes qué dirección y qué teléfono quieres publicar.

El Mito del 30%: los Productos Físicos No Pasan por Compras Integradas

Vale la pena desmontar esto porque frena más proyectos que cualquier requisito técnico. Mucha gente cree que publicar la app de su tienda significa entregarle a Apple un 30% de cada venta. Es exactamente al revés.

La guía 3.1.3(e) obliga a que las compras de bienes físicos y servicios que se consumen fuera de la app se cobren con métodos distintos a las compras integradas: Apple Pay, tarjeta o la pasarela que ya uses. Las compras integradas —y su comisión— están reservadas a los bienes digitales: suscripciones a contenido, funciones desbloqueables, moneda virtual.

Dicho de otro modo: si vendes zapatillas, cosmética, alimentación o repuestos, el cobro sigue pasando por tu pasarela de siempre, con tus condiciones de siempre. Lo desarrollamos, con las particularidades españolas de Bizum y Redsys, en la guía de pasarelas de pago en app nativa.

Cuánto Cuesta y Cuánto Tarda de Verdad

Las cifras que importan para planificar, sin contar el desarrollo:

La conclusión honesta de esta tabla es que el coste de las tiendas es marginal y el cuello de botella es administrativo. Si alguien te presupuesta una app "publicada en una semana" con cuenta personal de Google Play, no es que vaya rápido: es que aún no ha leído los requisitos. Si quieres el desglose del coste real de un proyecto completo, lo analizamos en cuánto cuesta crear la app de una tienda online en 2026.

Checklist Antes de Pulsar "Enviar a Revisión"

Esta es la lista que usamos internamente antes de cada envío. Si los doce puntos están en verde, el rechazo deja de ser lo normal y pasa a ser la excepción:

1. La app hace algo que la web no hace. Escrito en una frase, y visible en los primeros 30 segundos de uso.
2. Navegación nativa con pestañas o secciones propias, no un menú web embebido.
3. Notificaciones push operativas y con un caso de uso real explicado en la ficha.
4. Al menos una función del dispositivo integrada: biometría, cámara o ubicación.
5. Pantalla digna sin conexión, con un mensaje propio y un botón de reintento.
6. Borrado de cuenta accesible desde el área de usuario, no por soporte.
7. Política de privacidad accesible desde dentro de la app y coherente con la ficha de privacidad declarada.
8. Compras de producto físico fuera de las compras integradas, y catálogo digital separado si lo hay.
9. Cuenta de prueba funcional entregada al revisor, con su usuario, su contraseña y productos con stock.
10. Target API 36 comprobado en el paquete que vas a subir.
11. Prueba cerrada lanzada con 12 testers reales, si tu cuenta de Google Play es personal.
12. Trader status declarado y verificado, con los datos de contacto que estás dispuesto a publicar.

Y un punto trece que no es un requisito, pero decide el resultado comercial: comprueba cuánto tarda en abrirse tu app frente a tu web móvil. Pasar la revisión es el mínimo; que el cliente la conserve instalada es el objetivo.

Preguntas Frecuentes

Conclusión

La idea de que "Apple rechaza las apps de tiendas" es un resumen perezoso de algo bastante más manejable. Apple rechaza apps que no aportan nada sobre la web, y Google no rechaza casi nada: simplemente no te deja llegar a producción hasta que cumples unos trámites que llevan tiempo.

El fallo caro casi nunca es técnico. Es de calendario: empezar la prueba cerrada de Google Play el último día, descubrir el target API al subir el paquete, o enterarse del trader status cuando la app ya no aparece en la tienda española. Los cinco filtros de este artículo se resuelven en paralelo al desarrollo si se conocen desde el principio, y cuestan semanas si se descubren al final.

Si quieres ver el punto de partida completo —qué incluye una app nativa de tienda, cómo se sincroniza con WooCommerce y qué se puede publicar sin programar— lo tienes en la guía completa de WebImpulser.

Fuentes y fecha de verificación: los requisitos citados se han contrastado en septiembre de 2026 con las App Review Guidelines y los avisos de Apple Developer News sobre el trader status en la UE, y con la ayuda oficial de Play Console sobre los requisitos de prueba para cuentas personales. Las políticas de las tiendas cambian con frecuencia: comprueba siempre la fuente original antes de planificar un lanzamiento.