Cómo pasar la revisión de la App Store en 2026 (y evitar rechazos)

Si quieres saber cómo pasar la revisión de la App Store en 2026, empieza analizando cómo ha cambiado la situación. Las herramientas de IA para programar permiten crear y enviar una app en una tarde, y mucha gente lo hace. Los desarrolladores han estado reportando que la revisión de la App Store tarda demasiado, y ahora los revisores ven muchas apps casi idénticas, de poco esfuerzo y hechas solo por 'vibe'. Apple niega que los tiempos de revisión sean cada vez mayoresDe cualquier forma, la cantidad de aplicaciones que compiten por la atención de un revisor ha cambiado.

Eso cambia la forma en que debes prepararte. Un revisor que acaba de ver diez webs envueltas en un contenedor y cinco trackers de hábitos clonados no va a buscar qué hace que tu app sea buena. Tienes que hacerlo obvio.

Esta guía se resume en una idea: reducir el alcance de lo que Apple tiene que auditar. Lanza menos features nativas, haz que cada una sea sólida y que el valor diferencial de tu app sea imposible de ignorar. Ese enfoque cubre los dos motivos de rechazo que más afectan a las apps nuevas en 2026: directriz 4.2 (Funcionalidad mínima) y directriz 4.3 (Spam).

Por qué la revisión de la App Store tarda tanto en 2026

No hay una cifra oficial sobre los tiempos de espera actuales, así que ten cuidado con cualquier dato específico que leas. Esto es lo que sabemos:

Varios desarrolladores, incluso equipos consolidados, han reportado que sus envíos pasan en “Waiting for Review” mucho más tiempo de lo habitual (9to5Mac, Business Insider).
La postura de Apple, según reportó 9to5Mac, que los tiempos de revisión no están aumentando y que procesan el 90% de los envíos en menos de 48 horas."
Las propias App Review guidelines de Apple indican que las apps complejas pueden requerir “mayor escrutinio” y que las apps “rechazadas repetidamente por la misma infracción” tardan más en revisarse.

Ese último punto es el que tú puedes controlar. El camino más lento en la revisión de la App Store es ser rechazado y volver a enviar. Cada rechazo te devuelve a la cola. El objetivo es pasar a la primera.

Los motivos de rechazo más comunes en la App Store

Apple publica las cifras. En su App Store Transparency Report de 2025, Apple reporta 2.093.244 envíos rechazados. Por sección, Performance (1.354.418) lidera sobre Legal (495.673), Design (415.532), Business (283.820) y Safety (151.159). Un envío puede ser rechazado por varias secciones.

De Apple Página de App Review también indica que, en promedio, más del 40 % de los problemas sin resolver se relacionan con directriz 2.1: Integridad de la aplicación, que cubre crashes, contenido placeholder e información incompleta.

En la práctica, los motivos de rechazo de la App Store más comunes son:

2.1 Integridad de la app: crashes, cuentas demo rotas, backends caídos o contenido de relleno.
5.1.1 Recolección y almacenamiento de datos: falta de política de privacidad, textos de permisos vagos o falta de eliminación de cuenta.
2.3 Metadatos precisos: capturas de pantalla o descripciones que no coinciden con la app.
4.2 Funcionalidad mínima: “esto es solo un sitio web”.
4.3 Spam: “esto es como apps que ya existen”.

La checklist de abajo cubre los puntos 1 al 3. Los puntos 4 y 5 son donde entran en juego el alcance y la diferenciación, y son el foco de esta guía.

Por qué el alcance es el problema real

Cada funcionalidad que envías es algo que un revisor puede abrir, probar y rechazar. Cada prompt de permiso, proveedor de login, compra in-app y SDK conlleva más directrices:

Añadir un social login y la directriz 4.8 se aplica, por lo que podrías necesitar una opción de login equivalente que respete la privacidad.
Añadir creación de cuenta y 5.1.1(v) significa que también debes ofrecer la eliminación de cuenta in-app.
Añadir ubicación y necesitarás un purpose string que la justifique, además de un fallback para quienes la rechacen.
Añadir una suscripción y quedas sujeto a todo el 3.1.2, además de los checks de IAP en 2.1(b).
Enviar datos de usuario a un servicio de IA de terceros y 5.1.2(i) te exige que lo declares y obtengas permiso explícito.

Ninguna de estas reglas es descabellada. Pero sumadas, el impacto es mayor: a mayor superficie, más probabilidades hay de que algo falle, y un solo fallo rechaza todo el build.

Así que la estrategia para el primer envío es lanzar la versión más pequeña de tu app que sea claramente útil, nativa y propia. Puedes crecer después de la aprobación.

Cómo evitar un rechazo por la directriz 4.2 (Funcionalidad Mínima)

Directriz 4.2 es la regla que más afecta a las web apps y web wrappers:

Tu app debe incluir funciones, contenido y una UI que la eleven más allá de un sitio web empaquetado. Si tu app no es especialmente útil, única o parece una “app”, no pertenece a la App Store.

La 4.2.2 añade que las apps no deben ser principalmente “material de marketing, anuncios, recortes web, agregadores de contenido o una colección de enlaces”. Y la 4.2.6 rechaza apps “creadas a partir de una plantilla comercial o servicio de generación de apps”, a menos que el proveedor del contenido las envíe directamente.

El error habitual es intentar responder a la 4.2 añadiendo todos los plugins disponibles: cámara, contactos, geolocalización, haptics, share sheet, biometría, todo a la vez. Eso no hace que una app se sienta nativa. La hace sentir dispersa, y cada plugin trae su propio prompt de permisos y aviso de privacidad.

Lo que realmente necesitas es una o dos funciones nativas que el caso de uso principal realmente requiera, donde un revisor puede ver de inmediato por qué un sitio web no puede cumplir la misma función.

Buenas funciones nativas para elegir

Función nativa	Por qué se siente como una “app”	Ten cuidado con
Notificaciones push	Alertas oportunas y relevantes en la pantalla de bloqueo sin pasos extra. Los sitios web solo obtienen Web Push en iOS 16.4+ después de que el usuario los añade a la Home Screen y concede permiso	4.5.4: push must not be required for the app to work; marketing pushes need explicit opt-in
Escaneo de cámara / documentos	Capturar el mundo real es una fortaleza clave de los móviles	String de propósito claro; usa el selector del sistema si solo necesitas fotos (5.1.1(iii))
Modo offline con almacenamiento local	La app funciona en un avión o en un sótano	Asegúrate de que el revisor pueda activarlo y verlo
Widgets en la pantalla de inicio	Valor visual rápido fuera de la app	2.5.16: los widgets deben estar relacionados con el contenido y función de tu app
HealthKit	Integración profunda con el OS para fitness y salud	2.5.1: debe usarse para fines de salud; las reglas 5.1.3 de datos de salud son estrictas
Desbloqueo biométrico (Face ID / Touch ID)	Seguridad nativa para datos sensibles	Usa LocalAuthentication (2.5.13)
Audio en segundo plano, geofencing, NFC, Bluetooth	Capacidades de hardware o del SO que un navegador no ofrece	2.5.4: modos en segundo plano solo para su propósito previsto

Cómo elegir una o dos funcionalidades

Haz tres preguntas sobre cada candidata:

¿Se daría cuenta mi usuario principal si faltara? Si no, elimínala de la v1.
¿Puede un revisor verla funcionando en menos de un minuto con la cuenta demo? Si solo aparece tras tres días de uso, no te servirá en la revisión.
¿Implica un área sensible de las directrices? ¿(salud, niños, pagos, rastreo de ubicación, contenido generado por usuarios)? Si es así, añádelo solo cuando sea el núcleo de la app.

Algunos ejemplos:

Una herramienta de inspección de campo: captura de cámara y sincronización offline. Sáltate los contactos y el social login.
Un recordatorio de medicación: notificaciones locales y un widget con la siguiente dosis. Evita HealthKit hasta que lo necesites, porque impone reglas estrictas sobre datos de salud.
Un dashboard de estado del equipo: notificaciones push para incidentes y desbloqueo con Face ID. Con eso basta.

Dos funciones nativas bien construidas y centrales para la app son una respuesta más sólida a la 4.2 que ocho a medio integrar.

Cómo superar la directriz 4.3 Spam: sé claramente diferente y dilo al principio

La segunda regla que detecta apps asistidas por IA es 4.3 (Spam), junto con 4.1 (Copias no autorizadas). El 4.3(b) es tajante:

No envíes apps que no se distingan de lo que ya está ampliamente disponible.

Enumera categorías que Apple considera saturadas: citas, linternas, efectos de sonido, fondos de pantalla, temporizadores simples, adivinación. En esas categorías, Apple dice que no aceptará nuevos envíos “a menos que ofrezcan una experiencia significativamente diferente o mejorada”.

Los desarrolladores también reportan rechazos por “Guideline 4.3(a) - Design - Spam” indicando que la app comparte un binario, metadatos o concepto similar con apps de otros desarrolladores. Si tu app se generó con un prompt común o una plantilla base, asume que el revisor ya ha visto algo muy parecido.

Lo que nos pasó con el 4.3 Spam

Nosotros mismos chocamos con esta regla en Capgo. Creamos varias apps sobre el mismo app shell, con la misma estructura, las mismas pantallas y solo cambiando el contenido entre ellas. Luego las enviamos todas a revisión a la vez.

Para Apple, eso parece exactamente una granja de spam: una cuenta de desarrollador enviando un lote de binarios casi idénticos a la cola de una sola vez. Las apps fueron marcadas bajo el 4.3 Spam, y nos costó mucho más trabajo salir de esa situación de lo que nos habría costado evitarla.

Lo que hacemos ahora, y lo que recomendamos:

No uses un shell compartido entre apps. Si dos apps tienen el mismo layout, navegación y pantallas pero distinto contenido, Apple verá una app enviada dos veces. Cada app necesita su propia estructura, UX y razón de ser. Si el contenido es la única diferencia, lanza una sola app que lo incluya.
No hagas envíos por lotes. No envíes varias apps a revisión al mismo tiempo, especialmente si son nuevas y de la misma cuenta. Envía una, espera su aprobación y luego espacia las siguientes.
No uses metadatos casi idénticos. Las apps distintas requieren nombres, descripciones, capturas y keywords diferentes; no uses una plantilla donde solo cambias palabras.
Una app por cada producto real. Las variantes para distintas ciudades, clientes o nichos deben ir en una sola app con un selector, a menos que cada una sea un producto realmente distinto.

El 4.3(a) La normativa es clara al respecto: “No crees múltiples Bundle IDs de la misma app”. Si tienes varias versiones para ubicaciones, equipos o universidades específicas, “considera enviar una sola app y ofrece las variaciones mediante in-app purchase”. El spam repetido puede poner en riesgo toda la cuenta de desarrollador, no solo una app.

Encuentra tu valor diferencial

Una ventaja competitiva es algo concreto que el usuario obtiene de tu app y que no encontrará en los cinco primeros resultados de tu palabra clave principal. Por ejemplo:

Un público específico que las apps genéricas ignoran (ej. trabajadores por turnos, no "todo el mundo")
Un flujo de trabajo que otros no admiten (p. ej., compatible con tu hardware o fuente de datos actual)
Una limitación que resuelves y otros no (offline-first, privacy-first, sin necesidad de cuenta)
Conocimiento de dominio integrado en el producto (reglas, plantillas o datos de una profesión real)

“Diseño limpio” e “IA” ya no son ventajas competitivas en 2026. Cualquier clon lo presume.

Pon lo más importante en las primeras líneas de tu descripción de la App Store

Tanto los revisores como los usuarios leen primero el inicio de la descripción en la App Store. Úsalo para responder a una pregunta: ¿por qué existe esta app si ya hay otras que hacen lo mismo?

Un inicio flojo:

¡Presentamos FocusFlow, la app de productividad definitiva! Mantén el enfoque, crea mejores hábitos y alcanza tus metas con nuestro timer intuitivo y elegante. Impulsado por IA.

Esto podría describir a docenas de apps que ya están en la tienda. Es un "temporizador simple", algo que la regla 4.3(b) menciona directamente.

Apertura sólida:

FocusFlow es un temporizador de concentración para enfermeros de turno nocturno. Programa descansos en turnos de 12 horas, funciona totalmente offline en zonas sin cobertura de hospitales y muestra el próximo descanso en un widget de la pantalla de bloqueo, para que no tengas que desbloquear el móvil mientras trabajas.

En dos frases, el revisor entiende el público, el problema y las funciones nativas (offline, widget). Suena a producto real, no a un clon.

Luego, respáldalo en las notas de App Review. Escribe dos o tres frases indicando para quién es la app, qué la hace diferente y exactamente dónde encontrar las funciones nativas. 2.3.1(a) indica que las nuevas funciones “deben describirse con especificidad en la sección Notes for Review” y que “las descripciones genéricas serán rechazadas”. Usa las notas como un breve tour guiado.

Checklist de revisión de la App Store para 2026

La mayor parte proviene directamente de “Antes de enviar” de la sección y la directriz 2. Repásalo antes de cada envío:

Cada punto sin marcar es un rechazo probable, y cada rechazo supone otra espera en la cola.

¿Rechazaron tu app? Cómo responder o apelar

Si te rechazan de todos modos, las directrices describe dos opciones:

Responde en App Store Connect. Responde a la directriz exacta citada, no al tono general del mensaje. Para la 4.2 o 4.3, sé específico: a quién va dirigida la app, qué funciones nativas tiene, dónde encontrarlas y en qué se diferencia de las apps con las que el revisor pueda compararla. Un breve screen recording de la app ayuda.
Presenta una apelación ante el App Review Board si crees que el revisor se equivocó.

Para un proceso paso a paso, consulta nuestra guía sobre cómo responder a un rechazo de la App Store.

Antes de hacer cualquiera de las dos, soluciona la causa si es real. Si te citan bajo la 4.3, cambiar solo las capturas de pantalla no servirá de mucho. Lo que sí ayuda es definir mejor el público y hacer que el valor diferencial sea visible en la app y en la descripción.

Para apps que ya están en producción, Apple también indica que las correcciones de errores no se retrasarán por violaciones de directrices, salvo por temas legales o de seguridad. Solicítalo en App Store Connect y comprométete a solucionar el problema en tu próxima entrega.

Por qué las apps de Capacitor, React Native y Cordova suelen tener más facilidad

Esta parte se basa en mi experiencia, no en una estadística. Trabajando con muchos equipos que lanzan apps con Capacitor a través de Capgo, además de proyectos de React Native y Cordova antiguos, he visto que las apps cross-platform tienden a pasar la revisión de la App Store con menos fricción de la esperada. Mi explicación:

La capa nativa es ligera y estándar. Estas apps utilizan plugins conocidos y muy usados para cámara, push, almacenamiento y biometría. Los revisores ven estas integraciones constantemente y funcionan de forma predecible.
El alcance nativo es naturalmente pequeño. Añades plugins a propósito, uno a uno, lo que encaja con el enfoque de “una o dos funciones nativas reales” mencionado antes.
La app es un producto real, no una URL dentro de un frame. Una app Capacitor incluye su HTML, CSS y JavaScript dentro del binario y los carga localmente, con plugins nativos encima. Eso es distinto de un web wrapper que apunta a tu sitio web, que es justo lo que busca la regla 4.2.

Pero el cross-platform no es un atajo. Una app Capacitor que sea solo tu web de marketing será rechazada como cualquier otro web wrapper. El framework solo ayuda si sigues las reglas de alcance.

La primera revisión es la más difícil. Las actualizaciones siguen siendo dolorosas

Tu primera aprobación es el mayor obstáculo, porque Apple juzga todo el concepto. Pero las actualizaciones pasan por la misma cola. Una corrección de un typo, un botón roto o un cambio de copy pueden seguir esperando, y cualquier actualización puede ser rechazada por algo no relacionado que el revisor note esta vez.

Por eso muchos equipos separan los lanzamientos nativos de los lanzamientos de la capa web.

Live Updates, cumpliendo las reglas de Apple

La regla de Apple aquí se encuentra en la Acuerdo de licencia del Apple Developer Program, sección 3.3.1(B) “Executable Code”. El texto actual dice:

Salvo lo dispuesto en el siguiente párrafo, una Aplicación no puede descargar o instalar code ejecutable. Se permite la descarga de code interpretado en una Aplicación siempre que dicho code: (a) no cambie el propósito principal de la Aplicación mediante funciones o funcionalidades inconsistentes con su propósito previsto y anunciado (b) no eluda el firmado, el sandbox u otras funciones de seguridad del SO; y (c) para Aplicaciones distribuidas en el App Store, no cree una tienda o escaparate para otras Aplicaciones.

Directrices de revisión de la App Store 2.5.2 es la regla de revisión: las apps no pueden “descargar, instalar o ejecutar code que introduzca o cambie funciones o funcionalidades de la app”. Léelas juntas y la línea es clara. JavaScript, HTML y CSS son code interpretados. Actualizarlos está permitido siempre que la app siga siendo la misma que Apple revisó.

En la práctica, los live updates son adecuados cuando:

Corriges bugs en tu JavaScript, HTML o CSS
Ajustar UI, copy, diseño o contenido
Mejoras funciones ya revisadas sin cambiar su propósito

Las nuevas funciones, o los cambios en el funcionamiento de las existentes, deben enviarse en un binario revisado.

Y son necesitas apropiados cuando:

Cambias el propósito de la app. Una app de notas no se convierte en un casino.
Cambias precios, ofertas o el flujo de compra. Los cambios en el modelo de negocio pasan por revisión (ver 3.1 y 2.3).
Haces algo engañoso tras la descarga: funciones ocultas, engaños o contenido que el revisor no vio (2.3.1(a), 5.6).
Cambias el code nativo, añades plugins o solicitas nuevos permisos. Eso requiere un nuevo binario.

Dentro de esos límites, una herramienta de live update te permite lanzar cambios menores sin esperar la revisión de cada uno. Eso es lo que Capgo hace por las apps de Capacitor: subes un nuevo web bundle desde tu CI, los dispositivos lo descargan en segundo plano y, si algo falla, puedes activar el bundle anterior en el channel inmediatamente. Los dispositivos aplicarán el rollback la próxima vez que busquen una update. Para más detalles sobre la política, consulta ¿Permite Apple los live updates?.

FAQ

¿Cuánto tarda la revisión de la App Store en 2026?

Apple afirma que procesa el 90% de los envíos en menos de 48 horas (según informa 9to5Mac). Algunos desarrolladores reportan esperas mucho mayores en 2026. No hay un tracker público fiable, así que planifica con margen de error y evita los rejections, que añaden una espera completa cada vez.

¿Por qué tarda tanto mi revisión de la App Store?

Un mayor volumen de envíos, una app compleja o sensible (salud, finanzas, niños, pagos) o un historial de rejections recurrentes pueden ralentizar la revisión. Las guidelines de Apple indican que las apps complejas pueden requerir un escrutinio mayor y las infracciones repetidas tardan más. Si tienes una fecha límite crítica, puedes solicitar una revisión acelerada, pero Apple pide que solo la uses cuando sea realmente necesario.

¿Cuál es el motivo más común de rejection en la App Store?

Directriz 2.1, Integridad de la App. Apple indica que, de media, más del 40% de los problemas sin resolver se deben a esto: crashes, contenido de relleno, información incompleta y cuentas de demo que no funcionan.

¿Cómo soluciono un rechazo por la directriz 4.2 de Funcionalidad Mínima?

Añade una o dos funciones nativas esenciales para el caso de uso principal (push notifications, cámara, modo offline, widgets, HealthKit, biometría), asegúrate de que el revisor pueda verlas rápido con la cuenta de demo y explícalo en las notas de revisión. No envíes un sitio web dentro de un frame.

¿Cómo supero la directriz 4.3 de Spam (o 4.3(a) Diseño - Spam)?

Muestra una diferencia concreta y verificable frente a las apps que ya están en la tienda: un público, flujo de trabajo o restricción específica. Ponlo en las dos primeras líneas de tu descripción en la App Store y en las notas de revisión, y elimina pantallas de plantillas o boilerplate. No reutilices el mismo app shell en varias apps, ni envíes varias apps similares a revisión a la vez. Luego, responde a App Review con detalles específicos.

¿Puedo apelar un rechazo de la App Store?

Sí. Puedes responder a App Review en App Store Connect o enviar una apelación al App Review Board. Responde a la directriz exacta citada con hechos, no con adjetivos.

¿Puede una app tipo web wrapper entrar en la App Store?

Un simple wrapper de tu sitio web suele ser rechazado bajo la 4.2. Una app construida con Capacitor que incluye su code web de forma local y usa funciones nativas reales es otra historia, y puede pasar si es útil y claramente distinta.

¿Permite Apple los live updates?

Sí, con límites. La DPLA 3.3.1(B) permite descargar code interpretado (JS, HTML, CSS) siempre que no cambie el propósito principal de la app, eluda la seguridad del SO ni cree una tienda para otras apps. No uses live updates para cambiar precios u ofertas, añadir code nativo ni hacer nada engañoso.

Resumen

Reduce la superficie de auditoría. Lanza la app más pequeña que sea claramente útil.
Elige una o dos funciones nativas que el caso de uso principal necesite y que un revisor pueda ver en un minuto.
Muestra tu valor diferencial en las dos primeras líneas de la descripción en la App Store y en las notas de revisión.
Nunca lances varias apps desde un mismo shell ni las envíes en lote. Es la forma más rápida de recibir un flag de Spam 4.3.
Ejecuta el checklist antes de cada envío. Cada elemento que omitas puede costarte otra espera completa.
Tras la aprobación, mantén los lanzamientos nativos poco frecuentes y deliberados, y lanza correcciones de la capa web mediante live updates que cumplan las normas.

Si desarrollas con Capacitor y quieres dejar de esperar la revisión por cada pequeño fix, prueba Capgo. Configura los live updates una vez y reserva tus envíos a la App Store para cambios nativos reales.