Motivos de rechazo en App Store en 2026 y cómo resolver cada uno

La mayoría de los rechazos en App Store vienen de envíos incompletos o que fallan, no de reglas sobre el contenido. La página de App Review dice que, en promedio, más del 40 % de los problemas sin resolver tienen que ver con la guideline 2.1, App Completeness, que cubre cierres inesperados, contenido de relleno e información incompleta. En el Informe de transparencia de 2025, la sección de rendimiento de las guidelines, donde está la 2.1, apareció en 1 354 418 rechazos, más que las otras cuatro secciones juntas.

Fuera de la integridad, los motivos de rechazo frecuentes caben en cuatro grupos. Legal abarca políticas de privacidad, solicitudes de permiso, eliminación de cuenta y propiedad intelectual. Diseño abarca spam, imitaciones y apps con poca funcionalidad. Negocios abarca las reglas de compras dentro de la app y suscripciones. Seguridad abarca el contenido censurable y el contenido generado por usuarios. Cada grupo corresponde a una sección numerada de las App Review Guidelines, y cada mensaje de rechazo nombra la guideline en la que se basa.

Por eso esta guía se ordena por número de guideline, que es lo que vas a leer en el rechazo: "Guideline 2.1 Performance: App Completeness", "Guideline 4.3(a) Design: Spam", "Guideline 5.1.1(v) Data Collection and Storage". Los títulos se citan en inglés, que es como los busca la mayoría de los desarrolladores. Para cada uno tienes lo que dice Apple, las causas habituales y la solución. Las guidelines se actualizaron por última vez el 16 de octubre de 2026, y todo lo que sigue se comparó con las App Review Guidelines en inglés y con la ayuda de Apple el 4 de noviembre de 2026.

Si prefieres leer las reglas en español, Apple publica los Lineamientos de revisión de apps para Latinoamérica. Ten en cuenta que esa traducción dice "Última actualización: 8 de junio de 2026", así que todavía no incluye las reglas nuevas de octubre, como la 2.3.14 y la 2.5.19. Apple anunció que las traducciones de la versión de octubre llegarían en el plazo de un mes. Cuando haya diferencias, manda la versión en inglés.

Un rechazo casi nunca es el final. En 2025 Apple aprobó 387 087 envíos que antes había rechazado, y la mayoría de los demás se corrigieron y se volvieron a enviar como una revisión nueva. Lo que separa perder un día de perder dos semanas suele ser cómo respondes, y de eso trata la segunda mitad de esta página: leer el mensaje, responder, reenviar, aceptar una Bug Fix Submission y apelar ante el App Review Board.

"Unable to Add for Review" no es un rechazo. App Store Connect lo muestra cuando haces clic en Add for Review y falta algo que el envío necesita, de modo que la versión nunca llega a App Review. Debajo del título aparece "The items below are required to start the review process:" y una línea por cada elemento que falta. La ayuda de Apple para enviar una app describe el camino normal: revisas la build, haces clic en Add for Review, agregas la versión a un envío en borrador y luego haces clic en Submit for Review; el estado cambia a In Review cuando empieza la revisión. En hilos más antiguos de los foros de Apple aparece la misma comprobación con el título Unable to Submit for Review.

La referencia de propiedades obligatorias de Apple lista lo que tiene que estar completo. A nivel de app: nombre, bundle ID, SKU, idioma principal, categoría principal, derechos de contenido, clasificación por edad y estado ante la Digital Services Act. En la versión: URL de soporte, número de versión, copyright, la información para App Review y las opciones de publicación de la versión, más el texto de What's New si es una actualización. En precios y disponibilidad: la disponibilidad y un precio, incluido Free (gratis). En privacidad de la app: la URL de la política de privacidad y tus respuestas sobre tipos de datos. La referencia de información de la versión suma como obligatorios las capturas, la descripción y las palabras clave, y cada versión necesita una build elegida en su apartado Build.

Casi siempre el mensaje nombra lo que falta, y la tabla de abajo da la solución para cada mensaje que han reportado los desarrolladores. Cuando solo dice "This field is required." y no hay nada resaltado, recorre la lista anterior de arriba abajo. En los foros de Apple, desarrolladores rastrearon ese mensaje hasta un campo de copyright vacío en abril de 2021 y hasta las URL de App Store Server Notifications vacías en octubre de 2021. Solo los roles Account Holder, Admin o App Manager pueden agregar una versión a revisión.

La guideline 2.1(a), que Apple llama en español integridad de la app, pide que cada envío sea una versión final, con todos los metadatos necesarios y las URL funcionando, y sin texto de relleno, sitios web vacíos ni otro contenido temporal. Pide probar en el dispositivo para encontrar errores y comprobar la estabilidad, e incluir los datos de una cuenta de demostración, con el servidor encendido, si la app tiene inicio de sesión. Termina con la regla que provoca la mayoría de los rechazos: Apple rechaza los paquetes de apps incompletos y los binarios que se cierran o tienen problemas técnicos evidentes. El texto completo está en los Lineamientos de revisión de apps.

Las causas suelen ser cotidianas. Un cierre en un dispositivo o una versión de iOS que no probaste. Un inicio de sesión que falla porque la cuenta de demostración caducó o pide un código de verificación en dos pasos que nadie anotó. Un servidor caído justo cuando el revisor abrió la app. Un enlace de soporte que apunta a una página que ya no existe. Una función que dice próximamente. Ninguna tiene que ver con si a Apple le gusta la app.

La guideline 2.1(b) trata las compras dentro de la app: tienen que estar completas, actualizadas, visibles para el revisor y funcionando, y si un producto configurado no se puede encontrar ni revisar en la app, tienes que explicar el motivo en las notas de revisión. Una versión frecuente de este rechazo viene de la primera compra. La ayuda de Apple para enviar compras dentro de la app dice que el primer producto de cada tipo (consumible, no consumible, suscripción con renovación automática y suscripción sin renovación) tiene que enviarse junto con una versión nueva de la app; cuando el primero de un tipo está aprobado, los siguientes de ese tipo pueden ir solos, siempre que la app tenga al menos una versión aprobada.

La solución es un envío completo. La página de Apple sobre cómo dar información para una revisión completa pide el concepto y el modelo de negocio si la app es nueva, qué cambió y dónde encontrarlo si es una actualización, el propósito y el público de la app, los dispositivos y versiones del sistema donde la probaste, los servicios externos de los que depende, una cuenta de demostración que siga funcionando cuando empiece la revisión, credenciales para cada tipo de cuenta, una cuenta con una suscripción vencida para que el revisor vea todo el flujo de compra, y cualquier código de un solo uso en el campo Notes. Si tu inicio de sesión no se puede compartir por obligaciones legales o de seguridad, la guideline 2.1(a) permite un modo de demostración integrado con la aprobación previa de Apple.

Un detalle sobre la numeración: las guidelines dividen hoy la 2.1 en 2.1(a), integridad, y 2.1(b), compras dentro de la app, y los mensajes de rechazo citan una u otra. La página de App Review de Apple sigue hablando de "guideline 2.1: App Completeness" para las dos juntas, y la cifra de más del 40 % se refiere a ese conjunto.

"Guideline 2.1 Information Needed" no es del todo un rechazo. Significa que el revisor no pudo terminar sin algo que tienes que darle tú: un inicio de sesión que funcione, la explicación de una función, un documento, un video de la app funcionando con su hardware o una respuesta sobre de dónde sale el contenido. La revisión se queda en pausa hasta que respondes.

Responde al mensaje en App Store Connect. No reenvíes. La ayuda de Apple sobre el estado de la revisión dice que, cuando App Review pidió más información y no hay otros problemas, puedes responder directamente, y que reenviar inicia una revisión nueva, después de la cual App Review ya no puede responder a tu mensaje anterior. Contesta exactamente lo que te pidieron, adjunta capturas o una grabación corta de pantalla si lo aclaran, y actualiza los campos de App Review Information para que el siguiente revisor vea los mismos datos.

Si la petición es una llamada porque el inicio de sesión necesita un código, Apple dice que las llamadas suelen completarse en un plazo de tres a cinco días hábiles, según su página sobre la revisión completa. Si dejas el código, o una cuenta de demostración que no lo pida, en el campo Notes desde el principio, te ahorras esa espera por completo.

La sección 2.3 cubre todo lo que aparece en la página de producto. La guideline 2.3.1(a) dice que todas las funciones nuevas y los cambios del producto tienen que describirse con precisión en las notas para la revisión (las descripciones genéricas se rechazan), y que promocionar una app de forma engañosa, por ejemplo con servicios que no ofrece o con un precio falso, es motivo para retirarla. La guideline 2.3.2 pide que la descripción, las capturas y las vistas previas dejen claro qué elementos requieren una compra adicional. La guideline 2.3.12 pide que el texto de What's New liste los cambios importantes; las correcciones simples de errores y las mejoras de rendimiento pueden usar una descripción genérica.

Las capturas son el rechazo de metadatos que Apple explica con más detalle. Su página de ayuda sobre la guideline 2.3.3 dice que las capturas tienen que mostrar la app en uso, no solo el arte del título, una página de inicio de sesión o una pantalla de bienvenida, y que App Review aprueba el conjunto de un dispositivo solo cuando más de la mitad de las capturas muestran la app en uso. Con tres capturas, dos tienen que mostrar la app; con cuatro, tres. Se permiten textos e imágenes superpuestos mientras no tapen la app ni oculten su función principal, y las capturas tienen que coincidir con la interfaz actual. Nuestra guía de tamaños de capturas para el App Store cubre los tamaños que exige Apple, y la de ejemplos de capturas del App Store muestra cómo lo resuelven otras apps.

La guideline 2.3.7 limita el nombre de la app a 30 caracteres y prohíbe llenar los metadatos de marcas registradas, nombres de apps populares, precios o frases sin relación. La guideline 2.3.8 pide que los íconos, las capturas y las vistas previas sean aptos para una clasificación 4+ aunque la app tenga una más alta, y reserva expresiones como "For Kids" para la categoría Niños. La guideline 2.3.10 prohíbe nombres, íconos o imágenes de otras plataformas móviles en la app o en sus metadatos. La regla más nueva, la 2.3.14, agregada el 16 de octubre de 2026, aplica los mismos criterios a los nuevos recursos creativos que se usan en la cabecera de la página de producto y en los resultados de búsqueda: nada de referencias a otras apps con intención de engañar, ni afirmaciones que no se puedan comprobar, ni precios concretos o con descuento.

El estado Metadata Rejected significa que solo hay que corregir la página de producto. La lista de estados de Apple dice que leas el mensaje, edites los metadatos para resolver el problema y respondas a App Review. No necesitas una build nueva, y la revisión suele seguir rápido una vez que respondes.

La guideline 2.5.1 dice que las apps solo pueden usar API públicas, tienen que funcionar en el sistema operativo vigente y deben ir dejando los frameworks obsoletos. La guideline 2.5.2 dice que las apps tienen que ser autónomas y no pueden descargar, instalar ni ejecutar código que agregue o cambie funciones. Esa regla explica por qué se rechaza o se retira una app que carga funciones nuevas desde un servidor después de la revisión, y por qué las mini apps en HTML5, los chatbots y los complementos tienen su propio tratamiento en la guideline 4.7.

Apple agregó la guideline 2.5.19 el 16 de octubre de 2026. Prohíbe las funciones ocultas, inactivas o no documentadas, y dice que intentar esconderlas en el binario, con ofuscación de código u otros métodos, es motivo para retirar la app del App Store y cancelar la cuenta de desarrollador. Según la nota de Apple sobre los cambios de octubre, la regla aclara una política que ya existía y que antes estaba dentro de la 2.3.1. El anuncio de Apple sobre el cambio describe el objetivo como el cebo y cambio: apps que ocultan su propósito durante la revisión y muestran otras capacidades después de la aprobación. Si tu app usa configuración remota para activar funciones más tarde, cada función a la que el usuario pueda llegar después del lanzamiento tiene que estar presente y descrita en la versión que envías.

Los requisitos de compilación también son requisitos de software, aunque se aplican al subir y no durante la revisión. Desde el 28 de abril de 2026, las apps que se suben a App Store Connect tienen que estar compiladas con el SDK de iOS 26 o posterior, según el aviso de Apple sobre los requisitos mínimos de SDK, y desde abril de 2027 con el SDK de iOS 27. Una build que no cumple los requisitos de binario vigentes muestra el estado Invalid Binary y necesita una subida nueva.

La privacidad es el segundo grupo de rechazos por tamaño y el que tiene las reglas más concretas. La guideline 5.1.1(i) dice que toda app tiene que enlazar su política de privacidad en el campo de metadatos de App Store Connect y dentro de la app, en un lugar fácil de encontrar. La política tiene que decir qué datos recopila la app, cómo y para qué, confirmar que cualquier tercero que reciba los datos les da la misma protección o una equivalente, y explicar la conservación, la eliminación y cómo retira el usuario su consentimiento.

La guideline 5.1.1(ii) exige el consentimiento antes de recopilar datos del usuario o de uso, aunque se consideren anónimos, y dice que las funciones de pago no pueden depender de que se conceda el acceso a esos datos. También exige que los textos de propósito, la frase que iOS muestra en cada aviso de permiso, describan el uso de forma clara y completa. La página de ayuda de Apple sobre los textos de propósito pone el contraste que busca. Como ejemplo insuficiente da "To use location."; como ejemplo claro, una frase que, traducida, dice que la app usa los datos de ubicación para calcular la ruta recomendada hasta tu destino y dar indicaciones paso a paso. Escribe una frase concreta por cada recurso protegido, tradúcela a cada idioma que admita tu app y quita el código de SDK que pida un permiso que no necesitas.

La guideline 5.1.1(iv) dice que las apps tienen que respetar los ajustes de permisos y no engañar ni obligar a nadie a conceder accesos innecesarios. El ejemplo de Apple es una app que publica fotos en una red social pero pide primero el micrófono. Si alguien no comparte su ubicación, ofrécele escribir una dirección a mano. La guideline 5.1.2(i) agrega que tienes que indicar con claridad cuándo se comparten datos personales con terceros, incluida una IA de terceros, y obtener un permiso explícito antes de hacerlo. Una app que manda textos o fotos del usuario a un modelo de IA externo necesita ese aviso y ese consentimiento dentro de la app, no solo en la política de privacidad.

Dos requisitos técnicos provocan rechazos de privacidad al subir. Desde el 1 de mayo de 2024, las apps que usan API de la lista de motivos obligatorios de Apple tienen que declarar un motivo aprobado en un manifiesto de privacidad, según la actualización de privacidad para los envíos. Y cuando agregas un SDK de la lista de Apple de SDK de terceros de uso frecuente, con 86 entradas entre ellas Firebase, Alamofire, Flutter, OneSignal y Lottie, tienes que usar una versión que traiga su propio manifiesto de privacidad, firmada si es una dependencia binaria. Esa lista sí está en español.

La guideline 4.3 es el rechazo que más cuesta resolver, porque tiene que ver con la idea y no con un error. Tiene dos partes. La guideline 4.3(a) dice que no crees varios bundle ID de la misma app. El ejemplo de Apple es una app de mapas distinta para cada ciudad en lugar de un solo mapa que permita buscar cualquier ciudad, y su consejo es enviar una sola app y ofrecer las variantes por lugar, equipo o universidad mediante compras dentro de la app.

La guideline 4.3(b) dice que no envíes apps que no se distinguen de lo que ya está ampliamente disponible. Nombra categorías muy consolidadas en el App Store, entre ellas citas, linterna, efectos de sonido, fondos de pantalla, temporizadores simples y adivinación, y dice que Apple no aceptará apps nuevas de ese tipo salvo que ofrezcan una experiencia significativamente diferente o mejorada. Las apps hechas con plantillas comerciales o servicios de generación de apps tienen su propia regla, la guideline 4.2.6: se rechazan salvo que las envíe directamente el proveedor del contenido de la app.

Apple revisó las dos partes el 8 de junio de 2026: aclaró la base de la guideline y agregó ejemplos. La recopilación de Michael Tsai relaciona en parte el aumento de envíos de 2025 y 2026 con apps hechas rápido con herramientas de programación con IA, y ese es el contexto en el que se aplica hoy la 4.3.

Lo que funciona, según los casos que cuentan los desarrolladores: cambia la app, no el argumento. Une las apps casi idénticas en una. Quita las pantallas de plantilla y los recursos genéricos. Agrega la función que hace diferente a la app y luego explica en las notas para la revisión, en dos o tres frases sencillas, qué hace esta app que no hagan las alternativas obvias. Una respuesta que solo insiste en que la app es única, sin cambios en la build, rara vez mueve un rechazo por 4.3. Si varias de tus apps se rechazaron por la 4.3(a), tómalo en serio: los envíos repetidos de este tipo pueden terminar en la expulsión del Apple Developer Program.

La guideline 4.2 empieza con una frase que explica casi todos estos rechazos: tu app tiene que incluir funciones, contenido e interfaz que le permitan, en la traducción de Apple, "ser más que un simple sitio web renovado". Sigue diciendo que si una app no es particularmente útil, única o con el aspecto típico de una app, no es para el App Store. La guideline 4.2.2 agrega que, salvo los catálogos, las apps no deben ser sobre todo material de marketing, anuncios, recortes de sitios web, agregadores de contenido o una colección de enlaces. La guideline 4.2.3 dice que una app tiene que funcionar por sí sola, sin exigir que se instale otra, y que tiene que avisar del tamaño de cualquier descarga adicional antes de empezarla.

Las apps webview son el caso clásico. Envolver un sitio web en un contenedor nativo está permitido, pero una app que muestra el mismo sitio sin nada más suele recibir un rechazo por 4.2. Pasa lo mismo con las utilidades de una sola pantalla que hacen algo pequeño que ya hace una función integrada de iOS, y con las apps cuyo contenido es un libro o una guía de juego, que según Apple van en Apple Books.

La solución es darle al revisor una razón para que la app exista. Usa capacidades del dispositivo que el sitio web no tiene: acceso sin conexión, widgets, notificaciones que la gente activa por elección, la cámara, Apple Pay, Sign in with Apple, compartir con otras apps o datos que se quedan en el dispositivo. Haz que la app se pueda usar sin iniciar sesión cuando sea posible. Luego explica en las notas para la revisión qué hace la app que no hace el sitio web. Estas sugerencias son nuestra lectura de la guideline y de la experiencia que publican los desarrolladores, no una lista de Apple.

La guideline 4.1 pide no copiar la última app de moda ni hacer cambios menores al nombre o a la interfaz de otra app para hacerla pasar por propia. La guideline 4.1(b) considera que suplantar otras apps o servicios viola el código de conducta para desarrolladores, y la 4.1(c) prohíbe usar el ícono, la marca o el nombre de producto de otro desarrollador en tu ícono o en tu nombre sin su aprobación. La página de ayuda de Apple sobre las imitaciones lista lo que suele provocar este rechazo: funciones o aspecto copiados, un nombre o un ícono parecido al de una app existente, otras marcas en el título, el subtítulo o las palabras clave, capturas que no muestran tu app real y un nombre de desarrollador o una URL de soporte desactualizados. En cada caso la solución es que la app sea claramente tuya, o conseguir un permiso por escrito y adjuntarlo.

La guideline 4.8 se aplica a las apps que usan un inicio de sesión de terceros o de una red social, como Google Sign In, Facebook Login, Sign In with LinkedIn o Log in with X, para configurar o autenticar la cuenta principal del usuario. Esas apps también tienen que ofrecer, como opción equivalente, otro servicio de inicio de sesión que limite los datos al nombre y al correo, que permita mantener el correo privado y que no recopile interacciones con fines publicitarios sin consentimiento. Sign in with Apple cumple las tres condiciones, y por eso la mayoría de los desarrolladores lo agrega cuando llega este rechazo, aunque la guideline describe las funciones y no nombra un servicio.

El requisito solo aplica cuando un inicio de sesión de terceros o social configura la cuenta principal, así que una app que solo usa el sistema de cuentas y de inicio de sesión de su propia empresa queda fuera. La guideline lista otras excepciones, como las apps educativas o empresariales que piden una cuenta existente de la institución y las que usan un sistema de identificación ciudadana. Si tu app ofrece Sign in with Apple, recuerda la regla de eliminación de cuenta: al eliminar una cuenta también hay que revocar los tokens de Sign in with Apple.

La guideline 3.1.1 dice que para desbloquear funciones dentro de una app, como suscripciones, monedas de juego, niveles, contenido premium o la versión completa, tienes que usar compras dentro de la app, y que no puedes usar tus propios mecanismos de desbloqueo, como claves de licencia, códigos QR o billeteras de criptomonedas. Es el centro de la sección de negocios, que apareció en 283 820 rechazos en 2025.

Las suscripciones tienen sus propias reglas. La guideline 3.1.2(a) dice que una suscripción con renovación automática tiene que dar valor continuo, durar al menos siete días y estar disponible en todos los dispositivos del usuario. La guideline 3.1.2(c) dice que, antes de pedirle a alguien que se suscriba, tienes que describir con claridad qué obtiene por ese precio y comunicar los requisitos del anexo 2 (Schedule 2) del contrato de licencia del Apple Developer Program. Los muros de pago que esconden el precio, el periodo de renovación o lo que incluye la suscripción son un rechazo de negocios frecuente.

Hay excepciones que mucha gente pasa por alto. Las apps lectoras de la 3.1.3(a), como las de revistas, periódicos, libros, audio, música y video, pueden dar acceso a contenido comprado en otro lugar. Los servicios multiplataforma de la 3.1.3(b) pueden desbloquear compras hechas en otras plataformas, siempre que esos artículos también se ofrezcan como compras dentro de la app. Y la guideline 3.1.1(a) dice que en la tienda de Estados Unidos los desarrolladores no necesitan ningún permiso especial (entitlement) para incluir botones, enlaces externos u otras llamadas a la acción. En el resto de las tiendas, la misma guideline describe los permisos que los desarrolladores pueden solicitar para enlazar a un destino permitido para compras.

La mayoría de los rechazos por compras dentro de la app son mecánicos y no de política: un producto que el revisor no encuentra, un botón de restaurar compras que no hace nada, una compra que falla en el entorno de pruebas (sandbox) o una primera suscripción enviada sin versión de la app. Prueba cada producto en el sandbox con una cuenta nueva antes de enviar, y déjale al revisor una cuenta con una suscripción vencida.

Los rechazos de seguridad fueron el grupo más pequeño en 2025, con 151 159 menciones, pero son estrictos. La guideline 1.2 dice que las apps con contenido generado por usuarios tienen que incluir un método para filtrar el material censurable, una forma de denunciar contenido ofensivo con respuestas a tiempo, la posibilidad de bloquear a usuarios abusivos y datos de contacto publicados. Si tu app tiene comentarios, chat, perfiles, subidas o reseñas, las cuatro cosas tienen que estar en la build que ve el revisor.

Apple endureció la 1.2 dos veces en 2026. El 6 de febrero de 2026 aclaró que las apps con chat aleatorio o anónimo están sujetas a las reglas de contenido generado por usuarios. El 16 de octubre de 2026 agregó que la moderación de contenido cubre ahora de forma explícita las imágenes íntimas sin consentimiento, incluidas las generadas con herramientas de IA, y que los desarrolladores que no pongan salvaguardas, o que no corrijan las infracciones después de un aviso, se arriesgan a que retiren su app. Las apps que generan o editan imágenes de personas con IA deberían tratar la moderación como un requisito de lanzamiento.

El resto de la sección de seguridad trata el contenido censurable, las apps para niños de la categoría Niños, el daño físico y las afirmaciones médicas. Las apps médicas que se puedan usar para diagnosticar o tratar pacientes se revisan con más rigor, y la página de Apple sobre la revisión completa pide, para las que hacen afirmaciones de diagnóstico o tratamiento, la autorización regulatoria de cada país o región donde estén disponibles. Esa documentación tiene que estar adjunta antes de enviar.

"Apple rechaza apps hechas con IA" es una búsqueda que ya sugiere Google, y el patrón existe aunque Apple no tiene ninguna regla sobre cómo se programa una app. Las apps generadas rápido con herramientas de programación con IA suelen chocar con las mismas cuatro guidelines. Se parecen a muchas otras apps de una categoría saturada, que es la 4.3(b). Envuelven una idea simple o un sitio web, que es la 4.2. Salen con pantallas de relleno, flujos sin probar o un servidor que no está encendido, que es la 2.1. Y a veces mandan datos del usuario a un modelo de IA sin el aviso y el consentimiento que exige la 5.1.2(i).

El volumen detrás de esto es grande. La recopilación de Michael Tsai cita datos de Appfigures según los cuales los envíos al App Store subieron un 24 % en 2025 hasta noviembre, y un artículo de The Information según el cual las apps nuevas crecieron alrededor de un 30 % en 2025. Apple no ha vinculado sus decisiones de rechazo con la forma en que se hizo una app, y su regla más nueva, la 2.5.19 contra funciones ocultas o no documentadas, se aplica a todas las apps por igual.

Si programas con herramientas de IA, trata el envío como la parte que no hacen por ti: prueba en un dispositivo, quita el contenido de plantilla, escribe la política de privacidad y los textos de los permisos, agrega la eliminación de cuenta si hay cuentas, y redacta con tus propias palabras las notas para la revisión sobre lo que hace diferente a tu app.

Cuando un envío no pasa, el estado de la versión cambia a Rejected, o a Metadata Rejected si el problema está solo en la página de producto, y el envío muestra Unresolved Issues. La lista de estados de Apple dice que App Review avisa a los usuarios de App Store Connect con rol Admin, App Manager o Developer, y su página de contacto dice que el mensaje en App Store Connect detalla los problemas que requieren tu atención, con la guideline y, por lo general, una captura o los pasos.

Muchos desarrolladores lo siguen llamando Resolution Center. La ayuda actual de Apple lo llama la sección App Review de App Store Connect, y el botón para contestar es Reply to App Review. Allí te responde un especialista que conoce tu app. Apple pide que seas concreto sobre la función, la guideline o el paso que necesitas aclarar, y que no uses ese campo para apelar ni para pedir una revisión acelerada, que tienen sus propios formularios.

Un rechazo no afecta a la versión que ya está en el App Store. Tu app publicada sigue disponible mientras corriges la nueva. Solo queda retenida la versión enviada, junto con las compras dentro de la app u otros elementos del mismo envío. Si algunos elementos se aceptaron y otros se rechazaron, Apple indica quitar los rechazados y reenviar para que los aceptados sigan adelante.

Cuánto tiempo suma todo esto depende del camino que elijas, que explican la tabla siguiente y nuestra guía sobre cuánto tarda la revisión del App Store.

Si crees que la app cumple las guidelines, puedes apelar ante el App Review Board. La página de ayuda de Apple sobre las apelaciones dice que apelar tiene sentido cuando una app se rechazó o se retiró pero crees que cumple las App Review Guidelines y el contrato de licencia del Apple Developer Program, cuando tu cuenta está a punto de cancelarse, o cuando crees que recibiste un trato injusto o parcial. No es el canal para preguntar por el estado de una app ni para pedir una revisión acelerada.

Los pasos están definidos. Primero responde al rechazo en App Store Connect y aclara el problema; apela solo si eso no lo resuelve. Luego usa el formulario Submit an appeal de Apple, señala los requisitos concretos y explica cómo los cumple tu app, uno por uno. El Board te escribe en App Store Connect cuando termina su investigación, y puede pedirte más información o proponer una llamada. Envía una sola apelación por app rechazada y cubre en ella todas las guidelines citadas; el formulario admite hasta cinco apps a la vez. Si reenvías la app, la apelación se cierra.

Apple muestra cómo es una buena apelación. Su ejemplo completo dice, en esencia, que la app se rechazó por la 2.1 por información incompleta, que la cuenta de demostración y los pasos de configuración están en App Review Information, y que hay capturas que muestran la función funcionando. Su ejemplo incompleto solo dice que la app es importante para el negocio y que no debió rechazarse. Apple agrega que una apelación completa ayuda al Board a trabajar rápido, pero no garantiza que se revoque la decisión.

Apple no publica cuántas apelaciones de rechazo prosperan. Su Informe de transparencia de 2025 da en cambio las apelaciones de apps retiradas: 26 305 apelaciones y 423 apps restablecidas, alrededor del 1,6 % según nuestra división. En el Reino Unido, los compromisos de Apple ante la CMA del 30 de marzo de 2026 prometen el derecho a apelar ante el App Review Board, una explicación de cómo cada envío rechazado incumple las guidelines y cifras anuales para los desarrolladores del Reino Unido sobre apelaciones de rechazos, apps aprobadas después de apelar y la parte de las apelaciones resueltas en 60 días. El primer informe, sobre 2026, tiene que publicarse a más tardar el 31 de marzo de 2027.

Si se rechaza una actualización de una app que ya está en el App Store por algo que no plantea problemas legales ni de seguridad, Apple puede dejarte publicarla y corregir el problema la próxima vez. La página de Apple sobre las Bug Fix Submissions dice que la oferta aparece al principio del mensaje de rechazo, con una línea que indica que los problemas se pueden resolver en tu próxima actualización. La oferta solo existe para actualizaciones de apps que Apple ya aprobó antes.

Para aceptarla, responde al mensaje, di que quieres que se apruebe el envío actual y que resolverás los problemas en la próxima actualización, y no reenvíes, porque eso inicia una revisión nueva. App Review responde para confirmar y aprueba el envío. En la siguiente actualización tienes que resolver todos los problemas aplazados, y lo que se aplazó una vez no se puede volver a aplazar. Si la nota no aparece en el mensaje, el envío no califica y tienes que corregir los problemas primero.

Google Play revisa según sus Developer Program Policies, y su página sobre el proceso de aplicación de políticas lista los resultados posibles: rechazo, retirada, suspensión, visibilidad o regiones limitadas, cuentas restringidas y cancelación. El mensaje de rechazo nombra la política, y Google manda por correo las instrucciones para apelar si crees que se equivocó. Los datos de Google en esta sección son los de su ayuda consultada el 2 de noviembre de 2026.

El rechazo de Google Play que no tiene equivalente en el App Store es el formulario de Data safety. La ayuda de Google sobre la sección Data safety dice que toda app publicada en Google Play tiene que completarlo, incluso las que no recopilan datos, que los desarrolladores son los únicos responsables de que las declaraciones sean completas y exactas, y, a la pregunta de si una app puede bloquearse por su envío de Data safety, responde "In short, yes." Las declaraciones inexactas tienen que corregirse, y a las apps que no cumplen se les pueden bloquear las actualizaciones o se pueden retirar.

Hay dos diferencias más que importan al planificar. Las cuentas personales de desarrollador nuevas, creadas después del 13 de noviembre de 2023, tienen que hacer una prueba cerrada con al menos 12 testers durante al menos 14 días antes de pedir acceso a producción, según los requisitos de prueba de Google. Y la ayuda de Google sobre retiradas y apelaciones permite una apelación por cada medida, con respuesta en chino, inglés, japonés o coreano. Si publicas en las dos tiendas, mantén sincronizados la política de privacidad, las respuestas de privacidad de Apple y el formulario de Data safety de Google, porque una diferencia entre ellos es el rechazo más fácil de provocar en cualquiera de los dos lados.

Algunas de estas reglas también se aplican a cómo promocionas la app. La guideline 2.3.1 advierte que promocionar una app de forma engañosa, dentro o fuera del App Store, por ejemplo con funciones que no tiene o con un precio falso, es motivo para retirarla. Las pautas de marketing de Apple, aparte, regulan cómo muestras la insignia del App Store, los dispositivos de Apple y tu calificación en anuncios y publicaciones en redes sociales.

Nuestra guía sobre el logo de App Store y las reglas de marketing de Apple explica esas reglas con palabras sencillas, y la página de estadísticas del App Store sigue las cifras anuales de rechazos y retiradas a medida que Apple las publica. Si todavía no tienes cuenta, la guía del precio del Apple Developer Program cuenta qué incluye la membresía. Para la clasificación por edad, que App Store Connect exige antes de enviar, tienes la guía de clasificaciones por edad del App Store, y para el texto de What's New que pide la 2.3.12, los ejemplos de notas de versión.

Pasar App Review es la parte difícil de publicar una actualización. Contarle a la gente que salió no debería serlo. Spreadcast revisa cada día tu ficha pública del App Store, detecta cada versión aprobada en cuanto sale y la convierte en una publicación diseñada con tu propio ícono y tus capturas dentro de un marco de iPhone, con un texto escrito para cada red. Publica en Instagram, Facebook, LinkedIn, Pinterest y tus otras cuentas conectadas según el calendario que definas.

Las publicaciones siguen las reglas de marketing de Apple: capturas reales de la app actual, ninguna función inventada y ningún precio que pueda cambiar. La misma revisión diaria convierte las nuevas reseñas de 5 estrellas y los hitos de calificación en publicaciones. Pega el enlace de tu app en el App Store en la página de inicio para ver una publicación creada a partir de tu ficha, y revisa los planes para la publicación automática.