Sobre los textos de rechazo de esta guía. Ninguno está inventado. Los marcados 📋 Literal son texto que desarrolladores han pegado verbatim en los foros oficiales de Apple o en la comunidad de Google Play, o el texto exacto de un error ITMS-* de App Store Connect. Los marcados 📖 De la política son el texto de la guideline o de la política que la tienda cita en la cabecera del rechazo. El literal varía según el caso y las dos tiendas ajustan sus plantillas sin avisar: sirve para reconocer el rechazo, no como cita jurídica.

⏰ Lo más urgente ahora mismo

Google Play: las apps existentes tienen que targetear Android 15 (API level 35) o superior antes del 31 de agosto de 2026. Si no, la app deja de ser visible para usuarios con una versión de Android superior a tu target — no se retira, se vuelve invisible para el mercado nuevo. Hay formulario de extensión hasta el 1 de noviembre de 2026 en Play Console. Los usuarios que ya la tienen instalada no se ven afectados.

Requisitos por plataforma: Wear OS API 34, Android TV API 33, Android XR API 34.

Antes de la lista: en qué escalón estás

En Google Play los cuatro estados no son lo mismo, y la diferencia importa:

EstadoQué pasaEfecto en la cuenta
RechazoLa app o la actualización no se publica. La versión anterior sigue disponible.Ninguno
RetiradaLa app y todas sus versiones anteriores desaparecen de Google Play.Ninguno inmediato; varias retiradas llevan a suspensión
SuspensiónPor violaciones graves o repetidas — incluidos rechazos repetidos.Cuenta como strike
TerminaciónCierre de la cuenta y de las cuentas relacionadas.Permanente

Google no publica un número de strikes: los criterios son cualitativos («graves», «repetidas», «múltiples»). Malware, fraude y apps que puedan dañar al usuario o al dispositivo van directas a terminación.

En Apple no hay escala pública equivalente, pero las guidelines avisan de que los envíos repetidos de apps spam «pueden llevar a la expulsión del Apple Developer Program».

App Store — 21 rechazos

1 · Guideline 2.1 — Performance: App Completeness · crash en el arranque

📋 Literal

Guideline 2.1 - Performance - App Completeness We were unable to review your app as it crashed on launch.

Por qué llega. Probado en simulador, no en dispositivo. O una dependencia que solo existe en tu máquina.

Cómo se arregla. Ejecutar el build exacto que subiste en un dispositivo físico limpio, sin Xcode conectado. Si no reproduces el crash, pide el crash log en el Resolution Center: el revisor lo adjunta.

2 · Guideline 2.1 · el revisor no pasa del login

📖 De la política

Include detailed explanations of non-obvious features and in-app purchases in the App Review notes, including supporting documentation where appropriate. If your app requires a login, provide a demo account.

Por qué llega. Cuenta demo vacía, caducada, o con datos insuficientes para recorrer la app. Un caso documentado en los foros de Apple: la API bloqueaba por geo el tráfico fuera de la UE por cumplimiento de GDPR, y el revisor probando desde EE. UU. veía la app rota.

Cómo se arregla. Cuenta demo con datos suficientes para ver todas las funciones, sin caducidad, y con el backend accesible durante toda la revisión. Si tienes geobloqueo o rate limiting, mete las IPs de App Review en la lista blanca o desactívalo para la cuenta demo, y dilo en las notas.

3 · Guideline 2.1 · el backend estaba apagado

📖 De la política

Make sure your app has been tested on-device for bugs and stability before you submit it, and include demo account info if your app includes a login. […] make sure your backend services are live and accessible during review.

Por qué llega. El staging que se apaga por la noche o el fin de semana. La revisión no ocurre cuando enviaste.

Cómo se arregla. Apuntar el build de revisión a un entorno que esté vivo 24/7 durante toda la ventana de revisión. Y no desplegar cambios rompientes en el backend mientras hay un envío en cola.

4 · Guideline 2.3.1 — Accurate Metadata · notas de review genéricas

📖 De la política

Don't include any hidden, dormant, or undocumented features in your app; your app's functionality should be clear to end users and App Review. All new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected) and accessible for review.

Por qué llega. «Bug fixes and improvements» en una release que añade una pantalla nueva. Apple lo dice literalmente: las descripciones genéricas se rechazan.

Cómo se arregla. Una línea por función nueva, con la ruta para llegar a ella dentro de la app. Si una función está detrás de un feature flag, dilo y da la forma de activarla.

5 · Guideline 2.3.3 — Accurate Metadata · capturas

📋 Literal

Guideline 2.3.3 - Performance - Accurate Metadata We noticed that your screenshots do not sufficiently reflect your app in use.

Por qué llega. Capturas del splash, del login o del título. También: capturas de iPhone tomadas en iPad, o en el marco de dispositivo equivocado.

Cómo se arregla. Capturas de la app funcionando, en el dispositivo correcto para cada tamaño declarado. En juegos, gameplay real.

6 · Guideline 2.3.7 — Accurate Metadata · nombre y keywords

📖 De la política

Choose a unique app name, assign keywords that accurately describe your app, and don't try to pack any of your metadata with trademarked terms, popular app names, pricing information, or other irrelevant phrases just to game the system. App names must be limited to 30 characters.

Por qué llega. El clásico «MiApp - Gestión, Facturas, CRM, Contabilidad y Clientes». Pasa de 30 caracteres y además es keyword stuffing.

Cómo se arregla. Nombre de 30 caracteres o menos. El subtítulo es de 30 más y ahí sí cabe posicionamiento. Las keywords, en su campo, sin marcas ajenas.

7 · Guideline 2.3.8 — Accurate Metadata · metadatos no aptos para 4+

📖 De la política

Metadata should be appropriate for all audiences, so make sure your app and in-app purchase icons, screenshots, and previews adhere to a 4+ age rating even if your app is rated higher.

Por qué llega. La app puede ser 17+; la captura, no. Pilla a apps de citas, salud y juegos.

Cómo se arregla. Revisar iconos, capturas y previews —incluidos los de las compras integradas— con el criterio de 4+.

8 · Guideline 2.3.10 — Accurate Metadata · otras plataformas

📖 De la política

Make sure your app is focused on the experience of the Apple platforms it supports, and don't include names, icons, or imagery of other mobile platforms or alternative app marketplaces in your app or metadata, unless there is specific, approved interactive functionality.

Por qué llega. El badge de Google Play en una captura, un «también en Android» en la descripción, un icono de Play Store en la pantalla de compartir.

Cómo se arregla. Quitarlo de la app y de todos los metadatos. Sin excepciones.

9 · Guideline 3.1.1 — In-App Purchase · códigos, claves, QR

📋 Literal

Guideline 3.1.1 - Business - Payments - In-App Purchase Your app unlocks or enables additional functionality with mechanisms such as promo codes, data transfer codes, license keys, augmented reality markers, or QR codes, which is not appropriate for the App Store.

Por qué llega. El flujo típico de SaaS: el usuario paga en la web y mete un código en la app. Para Apple eso es desbloquear contenido sin IAP.

Cómo se arregla. O el desbloqueo pasa por IAP, o la app es «reader» y no ofrece ningún camino a la compra dentro (y entonces tampoco puede enlazar a ella, salvo bajo las excepciones vigentes). Es una decisión de modelo de negocio, no un fix técnico: decidirla antes de construir.

10 · Guideline 3.1.1 · monedas virtuales que caducan

📖 De la política

Credits or in-game currencies purchased via in-app purchase may not expire, and you should make sure you have a restore mechanism for any restorable in-app purchases.

Por qué llega. Créditos que caducan a los 12 meses, muy común en apps de suscripción con bolsa de consumo.

Cómo se arregla. Los comprados con IAP no caducan. Si necesitas caducidad, sepáralos de los comprados: los de regalo o promocionales sí pueden caducar.

11 · Guideline 4.1 — Design: Copycats

📋 Literal

Guideline 4.1 - Design - Copycats This app or its metadata appears to be attempting to misrepresent itself as another popular app or game already available on the App Store or a third-party platform. Apps submitted to the App Store should be unique and should not attempt to deceive users into thinking they are downloading something they are not.

Por qué llega. A veces es un falso positivo: tu propia versión Android o una app anterior tuya bajo otra cuenta. El texto de Apple menciona explícitamente «a third-party platform».

Cómo se arregla. Si es tuyo, documentarlo: certificado de marca, capturas de la ficha de Play con el mismo nombre de desarrollador, o cesión de derechos. En el Resolution Center, con adjuntos.

12 · Guideline 4.2 — Design: Minimum Functionality

📖 De la política

Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or "app-like," it doesn't belong on the App Store. […] Apps that are simply a song or movie should be submitted to the iTunes Store. Apps that are primarily marketing materials or advertisements will be rejected.

Por qué llega. WebView de la web corporativa. También agregadores de contenido sin funcionalidad nativa: «apps that only include links, images, or content aggregated from the Internet» no se diferencian de navegar en el móvil.

Cómo se arregla. Funcionalidad nativa real: notificaciones con valor, funcionamiento offline, cámara, Face ID, widgets, atajos. Y en el Resolution Center, nombrar qué capacidades de iOS usa la app y para quién.

13 · Guideline 4.3(a) — Design: Spam · múltiples Bundle IDs

📖 De la política

Don't create multiple Bundle IDs of the same app (for example, submitting a separate map app for every city in the world instead of a single worldwide map that allows users to search any city).

Por qué llega. La estrategia de una app por ciudad, por cliente o por idioma.

Cómo se arregla. Una app con selector. Si de verdad necesitas builds separados por cliente (white label), el camino es el Apple Developer Enterprise Program o el Custom App Distribution, no la App Store pública.

14 · Guideline 4.3(b) — Design: Spam · misma feature set

📋 Literal

Guideline 4.3 - Design - Spam Upon further review, we noticed that your app provides the same feature set as other apps submitted to the App Store; it simply varies in content or language, which is considered a form of spam.

Por qué llega. Apple nombra las categorías que mira con lupa: citas, linternas, efectos de sonido, fondos de pantalla, temporizadores simples y adivinación.

Cómo se arregla. Es el rechazo más difícil de revertir porque es de criterio. Lo que funciona es demostrar diferenciación funcional real, no de contenido: un dato propio, una integración que nadie tiene, un flujo distinto. Si el único diferencial es el idioma o el catálogo, no hay respuesta que lo salve.

15 · Guideline 4.8 — Design: Login Services

📋 Literal

Guideline 4.8 - Design - Login Services The app uses a third-party login service, but does not appear to offer an equivalent login option with the following features:

  • The login option limits data collection to the user's name and email address.
  • The login option allows users to keep their email address private as part of setting up their account.
  • The login option does not collect interactions with the app for advertising purposes without consent.

Next Steps: Revise the app to offer an equivalent login option that meets all of the above requirements.

Por qué llega. Login con Google o Facebook sin una alternativa equivalente.

Cómo se arregla. Sign in with Apple cumple los tres requisitos, pero no es obligatorio: cualquier opción que los cumpla vale — por ejemplo email + contraseña propio que no comparta datos con terceros. Lo más rápido suele ser Sign in with Apple.

16 · Guideline 5.1.1 — Privacy · purpose string insuficiente

📋 Literal

Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage We noticed that your app requests the user's consent to access their camera, microphone, and location but does not clarify the use of this feature in the permission modal alert.

Por qué llega. «Esta app necesita acceso a la cámara.» No dice para qué.

Cómo se arregla. El purpose string tiene que describir el uso y dar un ejemplo. El propio ejemplo de Apple: "Our app uses the camera to capture photos for updating and sharing on your gardener profile." Cuidado con dos cosas: NSCameraUsageDescription no cubre el micrófono, y NSLocationWhenInUseUsageDescription no cubre la ubicación en segundo plano.

17 · Guideline 5.1.1 — Privacy · política de privacidad

📖 De la política

All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner. The privacy policy must clearly and explicitly: identify what data, if any, the app/service collects, how it collects that data, and all uses of that data […] explain its data retention/deletion policies and describe how a user can revoke consent and/or request deletion of the user's data.

Por qué llega. El enlace está en App Store Connect pero no dentro de la app. O la política no dice cómo revocar el consentimiento ni pedir el borrado.

Cómo se arregla. Enlace accesible dentro de la app (típicamente en Ajustes), y que el texto cubra los tres puntos: qué datos, para qué, y cómo se revoca o se borra.

18 · Guideline 5.1.1(v) — Privacy · borrado de cuenta

📋 Literal

Guideline 5.1.1(v) - Data Collection and Storage The app supports account creation but does not include an option to initiate account deletion. Apps that support account creation must also offer account deletion to give users more control of the data they've shared while using an app.

Por qué llega. El que más veces pilla a un equipo con la release lista. No vale un email a soporte ni un formulario en la web: tiene que iniciarse dentro de la app.

Cómo se arregla. Flujo de borrado dentro de la app. El borrado no tiene que ser instantáneo, pero el plazo y qué pasa con los datos tienen que quedar claros al usuario. Ojo: Google Play pide lo mismo y además un enlace web — ver la entrada 29.

19 · Guideline 5.1.2 — Privacy · compartir datos con terceros

📖 De la política

Unless otherwise permitted by law, you may not use, transmit, or share someone's personal data without first obtaining their permission. […] You must clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so.

Por qué llega. La mención explícita a IA de terceros es reciente y afecta a cualquier app que mande texto o imágenes del usuario a un modelo alojado fuera.

Cómo se arregla. Declararlo y pedir permiso explícito antes del primer envío. Y no reutilizar datos recogidos para un propósito en otro sin consentimiento nuevo. Datos de HealthKit, HomeKit, ClassKit, MovementDisorder y de mapeo facial o de profundidad (ARKit, Camera, Photos) no pueden usarse para marketing ni publicidad, ni por ti ni por terceros.

20 · ITMS-90683 · falta el purpose string en el Info.plist

📋 Literal

ITMS-90683: Missing purpose string in Info.plist - Your app's code references one or more APIs that access sensitive user data, or the app has one or more entitlements that permit such access. The Info.plist file for the [app].app bundle should contain a NSCameraUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data.

Por qué llega. Casi siempre por una SDK de terceros que referencia la API, aunque tu código no la use. Se rechaza igual.

Cómo se arregla. Añadir la clave que pide el error. Si no sabes de dónde sale, strings sobre el binario o busca el símbolo en los frameworks embebidos. No es un rechazo de App Review: es un rechazo en la subida, llega en minutos.

21 · ITMS-91053 · falta la declaración de API en el privacy manifest

📋 Literal

ITMS-91053: Missing API declaration - Your app's code in the "[fichero]" file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryUserDefaults.

Por qué llega. Desde el 1 de mayo de 2024, los envíos deben incluir un array NSPrivacyAccessedAPITypes en el privacy manifest con las razones aprobadas para las required reason APIs. Las categorías más frecuentes: UserDefaults y FileTimestamp.

Cómo se arregla. Un PrivacyInfo.xcprivacy en el bundle con las categorías y sus razones. El nombre del fichero es obligatorio, exactamente ese. Las SDK de terceros deben traer el suyo; si una no lo trae, actualízala o sustitúyela — el envío es tu responsabilidad.

Google Play — 11 rechazos

22 · Broken Functionality

📋 Literal

Issue found: Violation of Broken Functionality policy App installs, but doesn't load. Make sure to fix all broken experiences within your app.

y en otra variante:

Your app contains content that isn't compliant with the Broken Functionality policy.

Por qué llega. En vigor desde el 31 de agosto de 2024, y es el rechazo que más ha crecido. Dispara con mucho más que crashes:

  • Crash en el arranque
  • Enlace de política de privacidad roto — sí, solo eso
  • Un permiso que la app pide y no necesita
  • Apps estáticas sin funcionalidad propia: solo texto, solo un PDF, un único fondo de pantalla
  • Apps que no instalan o no cargan

Cómo se arregla. El rechazo suele llegar sin decir qué lo causó, lo que hace que la gente reenvíe a ciegas y acumule rechazos —que escalan a suspensión—. Antes de reenviar, pide el detalle desde la página de Ayuda del Play Console. Y comprueba lo obvio primero: que el enlace de privacidad devuelve 200 y que no queda ningún permiso heredado de una SDK que ya no usas.

23 · Invalid Data Safety Form

📋 Literal

Invalid Data Safety Form

Por qué llega. Discrepancia entre lo declarado y lo que la app hace de verdad. La causa casi nunca es tu código: son las SDK. AdMob, Firebase Analytics y las de crash reporting recogen datos en segundo plano, y cualquier dato que salga del dispositivo desde una librería tuya hay que declararlo, aunque nunca toque tu servidor. Otro clásico: interacciones in-app e historial de búsqueda cuentan como app activity y casi nadie lo declara.

Cómo se arregla. Inventario de SDK con qué recoge cada una, y el formulario reconstruido a partir de eso. Y un punto en el checklist de release: si cambia una versión de SDK, se revisa el formulario. La responsabilidad de la declaración es tuya, no de la SDK.

24 · ACCESS_BACKGROUND_LOCATION

📖 De la política

Apps should request the minimum scope necessary (for example, using foreground instead of background device location permissions) to provide the feature or service that requires location, and users should reasonably expect that an app's feature or service needs the level of location requested. Background location may only be used to provide features beneficial to the user and relevant to the core functionality of the app.

Por qué llega. El permiso que más se pide «por si acaso». Google rechaza si no hay justificación convincente ligada a la funcionalidad principal.

Cómo se arregla. O se elimina y se pasa a foreground, o se rellena la declaración explicando la función principal que lo necesita, con vídeo de la función en uso. La prueba a superar: sin ese permiso la funcionalidad principal no existe.

25 · QUERY_ALL_PACKAGES

📖 De la política

You must be able to adequately justify why a less intrusive method of app visibility will not sufficiently enable your app's policy-compliant user-facing core functionality. Core functionality is defined as the main purpose of the app, and without this core ability to search for all apps on the device, the app is "broken" or becomes unusable.

Por qué llega. Suele venir de una SDK (antifraude, seguridad, algunos SDK de pago) que lo mete en el manifest sin que tú lo sepas.

Cómo se arregla. Usos permitidos: buscadores de dispositivo, antivirus, gestores de ficheros y navegadores. Si no eres uno de esos, quítalo del manifest. Localízalo con el manifest fusionado (app/build/outputs/logs/manifest-merger-*-report.txt) para saber qué dependencia lo introduce.

26 · Metadata policy

📖 De la política

We don't allow apps with misleading, improperly formatted, non-descriptive, irrelevant, excessive, or inappropriate metadata, including but not limited to the app's description, developer name, title, icon, screenshots, and promotional images.

Por qué llega. Keywords repetidas o no relacionadas, longitud excesiva, formato raro (emojis o mayúsculas en el título), repetición.

Cómo se arregla. Título descriptivo sin relleno, descripción que describa la app y no una lista de términos. También cae aquí el nombre del desarrollador si es engañoso.

27 · Repetitive Content

📖 De la política

We don't allow apps that offer a low-value or disruptive user experience, including apps with copy-paste content or clones of existing apps, apps that are functionally identical to others the developer has published, and repetitive listing practices of uploading many similar apps under one developer account.

Por qué llega. El equivalente del 4.3 de Apple. Muy habitual en white label y en catálogos generados.

Cómo se arregla. Consolidar en una app configurable. Google publica una guía específica de buenas prácticas para desarrolladores de white label — leerla antes de subir la segunda variante, no después de la décima.

28 · Deceptive Behavior

📖 De la política

Your app must always maintain honesty and transparency, and must never mislead users. All metadata, including the store listing, screenshots, and title, must precisely reflect the app's functionality.

Por qué llega. El caso más común: capturas que muestran funciones que la app no tiene — mockups de roadmap, pantallas de la versión de escritorio, funciones detrás de un paywall que el revisor no ve.

Cómo se arregla. Capturas de lo que hay hoy en producción. Si una función está en la ficha, tiene que ser alcanzable en la revisión.

29 · Account deletion · in-app y enlace web

📖 De la política

If an app allows users to create an account, it must allow users to request for their account to be deleted in the app and through a web resource. […] Some users may have uninstalled the app or be unable to access the in-app experience, so developers must ensure users can request data deletion via the web link without needing to re-download the app.

Por qué llega. Aquí Google va más allá que Apple: además del flujo dentro de la app, exige un recurso web donde pedir el borrado sin reinstalar. Mucha gente cumple el 5.1.1(v) de Apple y da esto por hecho.

Cómo se arregla. Flujo in-app + una URL pública de solicitud de borrado, declarada en Play Console. Al borrar la cuenta hay que borrar los datos asociados, con las excepciones legítimas de seguridad, prevención del fraude y cumplimiento normativo.

⚠ Fecha: hay al menos 30 días desde el 15 de abril de 2026 para adaptarse a los cambios de política anunciados en esa tanda. Confirmar el plazo vigente en Play Console antes de publicar.

30 · Target API level

📋 Literal

App must target Android 15 (API level 35) or higher

Por qué llega. Las apps existentes tienen que targetear API 35 antes del 31 de agosto de 2026. Las que se queden en API 34 o inferior solo estarán disponibles en dispositivos con una versión de Android igual o inferior a su target: no se retiran, dejan de ser descubribles en el mercado nuevo.

Cómo se arregla. Subir targetSdk y resolver los cambios de comportamiento de la versión. Si no llegas, hay formulario de extensión hasta el 1 de noviembre de 2026 en Play Console. Los usuarios que ya la tienen instalada pueden seguir usándola y reinstalándola.

31 · Propiedad intelectual

📖 De la política

We don't allow apps that infringe on the intellectual property rights of others.

Por qué llega. Puede que te pidan pruebas de que tienes derecho a usar el material. Google nombra: imágenes de películas, series, videojuegos, portadas de discos y arte de cómics o dibujos animados.

Cómo se arregla. Documentación de la licencia o cesión, adjunta en la apelación. Si el material es de un cliente, pide el contrato antes de subir la app, no cuando llegue el rechazo.

32 · Contenido de la ficha, no de la app

📖 De la política

Content that is lewd or profane – including content which may contain profanity, slurs, explicit text, or adult/sexual keywords in the store listing or in-app – violates policies.

Por qué llega. Se revisa la ficha, no solo el binario. Pilla a apps de citas, salud sexual y humor.

Cómo se arregla. Revisar título, descripción corta, descripción larga y capturas con el mismo criterio que la app.

Cómo responder

A Apple: tres niveles, en este orden

1 · Resolution Center. El sitio por defecto. La regla que más cambia el resultado: explica cómo cumple tu app la guideline que citan, no por qué crees que la guideline no debería aplicar. Cita el número. Si el rechazo pide información, dala antes de hacer cualquier otra cosa. Si el revisor entendió mal una función, explica cómo estaba pensada que funcionase.

2 · App Review Board. Si después del Resolution Center sigues pensando que es un error, puedes apelar para que se reevalúe. Las reglas de Apple:

  • Sé específico sobre cómo la app cumple las guidelines
  • Una sola apelación por envío rechazado
  • Responde primero a cualquier petición de información

3 · Revisión acelerada. Solo por circunstancias excepcionales: un bug crítico o un lanzamiento que coincide con un evento con el que estás directamente relacionado. No es para llegar a una fecha de marketing autoimpuesta, y gastarla mal quema el crédito para la próxima vez.

Plazos. Apple revisa el 90 % de los envíos en menos de 24 horas. El 10 % restante no tiene plazo garantizado; los primeros envíos y las actualizaciones grandes son los que más caen ahí.

A Google: por el correo, y con cuidado

Google dirige el proceso por el email de notificación: hay que seguir las instrucciones de ese correo, o usar la herramienta de apelación. También se puede pedir ayuda desde la página de Ayuda del Play Console. Reinstalan la app si hubo error y confirman que no viola las políticas.

Dos cosas que conviene tener presentes:

  • Pide el detalle antes de reenviar. Los rechazos de Broken Functionality llegan sin explicación concreta, y reenviar a ciegas suma rechazos que escalan a suspensión.
  • No dan asesoramiento legal. Lo dicen explícitamente en su documentación.

Checklist antes de enviar

Las dos tiendas

  • No crashea en dispositivo físico, con el build exacto que se sube
  • El enlace de política de privacidad devuelve 200 y es accesible dentro de la app
  • Cada permiso está justificado por una función que el revisor puede ver
  • Las capturas muestran la app de hoy funcionando, no el login ni un roadmap
  • Ficha sin marcas ajenas, sin precios y sin relleno de keywords
  • Si hay creación de cuenta, hay borrado de cuenta

App Store

  • Cuenta demo con datos suficientes para recorrer toda la app, sin caducidad
  • Backend accesible 24/7 durante toda la ventana de revisión
  • Notes for Review con una línea por función nueva, con la ruta para llegar
  • Borrado de cuenta iniciable dentro de la app
  • Nombre de 30 caracteres o menos
  • Iconos, capturas y previews aptos para 4+
  • Sin nombres, iconos ni imágenes de otras plataformas o tiendas
  • Todo desbloqueo de contenido pasa por IAP; las monedas compradas no caducan
  • Purpose strings con ejemplo de uso, uno por API sensible
  • PrivacyInfo.xcprivacy al día, incluidas las SDK de terceros
  • Si hay login de terceros, hay opción equivalente (4.8)

Google Play

  • targetSdk 35 o superior (fecha límite: 31/08/2026)
  • Formulario de Data safety reconstruido desde el inventario de SDK
  • Ubicación en segundo plano: justificada con vídeo, o eliminada
  • QUERY_ALL_PACKAGES fuera del manifest fusionado, salvo uso permitido
  • Enlace web de solicitud de borrado de cuenta, además del flujo in-app
  • Derechos documentables sobre todo el material con copyright
  • AAB firmado con Play App Signing

Lo que suele estar detrás

Ninguno de estos 32 es una discusión de criterio, salvo el 4.3(b) de Apple y el de Repetitive Content de Google. El resto son cosas verificables antes de enviar que se saltan porque la release va con prisa: el backend que se apagó, la nota de review genérica, el borrado de cuenta que nadie implementó, el permiso heredado de una SDK que ya no se usa, el formulario de Data safety de hace tres versiones.

Si tu app está rechazada ahora mismo, así lo abordamos nosotros. Si aún no has enviado, empieza por los requisitos para subir una app a la App Store y por cuánto cuesta publicar en Google Play.

Fuentes

Apple

Google