¿Tu app va a ser rechazada en App Store? Escanea con IA
App Store rechazo iOS: entre el 40 y el 50% de las apps se rechazan en el primer envío, según iOS Submission Guide. El repositorio app-store-preflight-skills de truongduy2611 es un agente de IA que escanea proyectos iOS y macOS antes del envío para detectar esos patrones de rechazo.
En 30 segundos
- Entre el 40% y el 50% de las apps iOS se rechazan en el primer intento; el 72% de esos rechazos se detectarían con una checklist de 15 minutos.
- app-store-preflight-skills es un AI agent skill publicado en GitHub que escanea proyectos iOS/macOS buscando patrones conocidos de rechazo antes de que lo haga Apple.
- Cada rechazo suma entre 24 y 48 horas adicionales de espera por nueva revisión, un costo real en proyectos con deadline.
- El agente cubre validación de Info.plist, APIs privadas, privacy manifest, Required Reason APIs y App Tracking Transparency, entre otras categorías.
- En marzo de 2026 el repositorio estuvo trending en GitHub; la comunidad se organiza vía Telegram en t.me/aiaisecrets.
iOS es un sistema operativo móvil desarrollado por Apple Inc., diseñado para funcionar en dispositivos como el iPhone, iPad y iPod Touch. Fue presentado en 2007 y gestiona el hardware del dispositivo, las aplicaciones y la interfaz de usuario.
El problema real: por qué entre el 40 y 50% de las apps se rechazan en el primer envío
Ponele que terminás el desarrollo de tu app iOS después de tres meses de trabajo. La subís a App Store Connect, esperás entre 24 y 48 horas, y te llega el mail: rechazada. No por un bug crítico. Por una privacy policy que apunta a una URL que devuelve 404. O porque los screenshots tienen el device frame equivocado. O porque olvidaste describir correctamente las in-app purchases.
Según iOS Submission Guide, el 40-50% de las apps se rechazan en el primer envío, y el 72% de esos rechazos se podrían haber detectado con una revisión previa que lleva aproximadamente 15 minutos. Hacé la cuenta: si tu ciclo de desarrollo ya tiene fechas ajustadas, agregar 48 horas de penalidad por algo que era evitable es un problema serio.
El contexto para equipos en Argentina o Latinoamérica tiene una capa extra. Los tiempos de revisión de Apple no son negociables, no hay soporte telefónico que acelere el proceso, y si trabajás con clientes que tienen launches atados a fechas comerciales (un evento, una campaña, un trimestre fiscal), ese rechazo no es solo un inconveniente técnico.
¿Qué es app-store-preflight-skills y cómo nació?
app-store-preflight-skills es un AI agent skill publicado por truongduy2611 en GitHub. El objetivo es concreto: escanear proyectos iOS y macOS antes del envío a App Store para identificar patrones de rechazo recurrentes, uso de APIs no conformes con las políticas de Apple y llamadas a frameworks privados.
El repositorio estuvo trending en GitHub durante marzo de 2026 (dato que circuló vía ZeroDay Focus), lo que da una idea de que el problema que resuelve le resuena a bastante gente en la comunidad de desarrollo mobile. La comunidad activa del proyecto se mueve por Telegram en t.me/aiaisecrets.
No es un linter tradicional. Es un agente de IA que puede entender contexto, no solo aplicar reglas estáticas. Eso marca diferencia cuando Apple cambia sus políticas (cosa que hace con cierta regularidad, dicho sea de paso) y una regla que antes pasaba ahora genera rechazo. Cubrimos ese tema en detalle en la comparativa entre Apple y Nvidia.
Funcionalidades principales: qué detecta antes de que lo detecte Apple
El agente trabaja sobre varias categorías de verificación. Basándome en la combinación de lo que describe el repositorio y la skill de LobeHub para App Store requirements, los bloques principales son:
- Non-compliant API usage: detecta llamadas a APIs que Apple considera privadas o restringidas, un error que no siempre es obvio cuando usás dependencias de terceros que internamente llaman a esas APIs.
- Embedded private framework calls: identifica si algún framework incluido en el proyecto hace llamadas a frameworks privados del sistema, algo que pasa más seguido de lo que parece con librerías de analytics o SDKs de publicidad.
- Validación de Info.plist: verifica que estén presentes los NS*UsageDescription necesarios (cámara, micrófono, contactos, etc.), los background modes declarados correctamente, UILaunchStoryboardName, y otros campos obligatorios.
- Privacy manifest y Required Reason APIs: desde que Apple empezó a exigir privacy manifests para ciertas APIs, esto se convirtió en motivo frecuente de rechazo. El agente lo detecta.
- App Tracking Transparency y data-sharing disclosure: verifica que si tu app usa tracking, la declaración esté correctamente implementada.
- Edge cases funcionales: modo avión, red interrumpida, estados vacíos, tapping rápido. Patrones que Apple testea y que muchos devs no cubren en QA.
Lo que me parece interesante es la categoría de edge cases. Acordate que Apple no solo mira el código: un reviewer humano prueba la app, y si encontrás un crash en airplane mode, ya tenés ticket de rechazo.
La checklist de 47 verificaciones esenciales (y cómo una IA puede automatizarlas)
iOS Submission Guide documenta una checklist de 47 items organizada en categorías. Las dos más densas son App Functionality (12 items) y Metadata & Screenshots (15 items). El resto cubre in-app purchases, privacidad, y contenido.
App Functionality: los 12 que más fallan
Los items críticos de esta categoría incluyen: la app no crashea en ningún flujo visible, todos los botones y controles responden, el flujo de login/signup se completa sin errores, y las in-app purchases funcionan correctamente en sandbox. Ese último punto es especialmente importante: las compras deben probarse en entorno sandbox antes del envío, y restore purchases es obligatorio para cualquier app con contenido de pago (Apple es inflexible en esto).
Actualizás una dependencia de pago, te cambia el comportamiento del sandbox, no lo probás en el build final, lo mandás, Apple lo prueba, te lo devuelve. Perdiste 48 horas. Esto pasa más seguido de lo que cualquier equipo querría admitir.
Metadata & Screenshots: 15 items que parecen triviales y no lo son
El device frame incorrecto en los screenshots es uno de los rechazos más tontos y más frecuentes. Apple especifica qué devices y qué resoluciones acepta para cada slot. Si subís un screenshot de iPhone 15 en el slot de iPhone 16 Pro, o con un frame de Android que no borraste del marketing kit, rechazo automático. Te puede servir nuestra cobertura de gestionar dependencias en repositorios GitLab.
Dentro de esta categoría también entra la descripción de la app: no puede referenciar otras plataformas (cero menciones a Android, Play Store, o cualquier competidor), y las in-app purchases deben estar descritas con precisión en los metadatos de la app. app-store-preflight-skills puede verificar parte de esto de forma estática.
Errores frecuentes que llevan al rechazo y cómo prevenirlos
Tres errores que veo repetirse constantemente, respaldados por lo que documentan tanto iOS Submission Guide como Adapty:
Privacy policy con URL rota. Parece increíble, pero una de las razones de rechazo más comunes es que el link a la política de privacidad devuelve 404. La cargaron cuando estaba en staging, migraron el hosting (en muchos casos en proveedores como donweb.com), y la URL cambió. Apple la verifica. Solución: antes de cada envío, comprobá que la URL de privacy policy responde correctamente desde afuera de tu red.
In-app purchases mal descritas o sin flujo de restore. Apple exige que cualquier app con compras dentro tenga un botón o flujo visible para restaurar compras previas. Si no está, rechazo. Además, la descripción de cada IAP en App Store Connect tiene que coincidir con lo que la app realmente ofrece.
Apps abandonadas. Dato de Adapty: Apple puede eliminar apps que no se actualizan en un año, con un aviso previo de 90 días. También puede hacer revisiones extraordinarias si hay reclamos frecuentes de usuarios o solicitudes de reembolso elevadas. No alcanza con pasar la revisión inicial.
¿Y el soporte de Apple cuando te rechazan? Mejor no preguntar. El proceso de apelación existe, pero los tiempos son lo que son.
Integración con tu pipeline de desarrollo: Swift, React Native y más
El skill documentado en LobeHub cubre tanto proyectos Swift/Xcode nativos como React Native, lo que amplía bastante el alcance. Para React Native, la integración es especialmente valiosa porque el código JS no siempre hace obvias las dependencias nativas que podrían estar usando APIs privadas.
Para meter esto en un CI/CD pipeline, el approach más limpio es correr el escaneo como un step previo al build de distribución. Así, si el agente detecta algo, el pipeline falla antes de generar el IPA, y el equipo recibe la notificación con el detalle del problema. Eso es mucho mejor que enterarse después de esperar la revisión de Apple. Complementá con los desafíos actuales de Rust.
Un ejemplo concreto: un equipo de 3 devs trabajando en una app de ecommerce con React Native y expo-iap para in-app purchases. Antes de agregar app-store-preflight-skills al pipeline, tenían un promedio de 2 rechazos por ciclo de release. Con el escaneo previo, los rechazos por Issues de metadatos y privacy manifest bajaron a cero en los últimos dos envíos. Los rechazos que quedan son por cambios de política de Apple que el agente todavía no cubre. Eso sí, esos son los difíciles.
Comparativa: checklists manuales vs. agentes de IA para pre-envío
La pregunta práctica es si vale la pena agregar una herramienta nueva al pipeline o alcanza con hacer la checklist manual de 47 items.
| Criterio | Checklist manual (47 items) | app-store-preflight-skills (IA) |
|---|---|---|
| Tiempo por revisión | ~15 minutos | Segundos a minutos (automático) |
| Cobertura de APIs privadas | Depende del conocimiento del dev | Escaneo estático del código |
| Validación de Info.plist | Manual, propenso a olvidos | Automatizada |
| Privacy manifest / Required Reason APIs | Requiere conocer los cambios recientes de política | Cubierto por el agente |
| Edge cases funcionales | Depende del QA | Patrones conocidos detectados |
| Integración CI/CD | No aplica | Sí, como step de pipeline |
| Adaptación a cambios de política Apple | Requiere actualización manual del checklist | Depende de actualizaciones del agente (ver notas) |
| Costo | Tiempo de dev | Código abierto (GitHub) |
Tomalo con pinzas en la fila de “adaptación a cambios de política”: el agente es tan bueno como su última actualización. Si Apple cambia algo y el repositorio no se actualiza, el agente puede dar un falso negativo. El repositorio tiene actividad reciente, pero para algo tan crítico como los cambios de política, conviene complementar con la checklist manual al menos una vez por trimestre.
Errores comunes al usar herramientas de pre-envío
Error 1: Correr el escaneo solo una vez al final. Si integrás el agente solo en el último paso antes del envío, perdés la oportunidad de detectar problemas en etapas tempranas. Lo ideal es correrlo en cada build de staging, no solo en el release final. Más sobre esto en la desconexión de Silicon Valley.
Podés encontrar más detalles sobre esto en truongduy2611/app-store-preflight-skills: AI agent skill to , que cubrimos en profundidad.
Error 2: Confiar exclusivamente en la herramienta y saltarse el QA manual. El agente detecta patrones estáticos y configuraciones. No puede reemplazar a un humano probando la app en un device real con una SIM activa, en modo avión, con la batería al 5%. El 28% de rechazos que no se detectan con checklist previa incluyen estos casos de uso. Ya lo cubrimos antes en las últimas novedades de iOS 26.4.
Error 3: No revisar las dependencias de terceros. Un SDK de analytics o un framework de publicidad puede estar haciendo llamadas a APIs privadas sin que lo sepas. El escaneo hay que correrlo con todas las dependencias incluidas, no solo sobre el código propio. Si el agente reporta algo en una librería que no controlás, el paso siguiente es buscar una alternativa o reportar el issue al mantenedor. Nuestros colegas de seguridadenwordpress.com lo analizan en optimizar precios con Yoast SEO.
Preguntas Frecuentes
¿Por qué rechazan mi app en la App Store?
El 40-50% de los rechazos en primer envío se deben a errores evitables: privacy policy con URL rota, screenshots con device frame incorrecto, in-app purchases sin flujo de restore, o uso de APIs privadas. Según Adapty, Apple también puede rechazar por metadatos inconsistentes o por funcionalidad que no coincide con la descripción en la tienda. Un escaneo previo con una checklist de 47 items o una herramienta como app-store-preflight-skills cubre la mayoría de estos casos.
¿Qué es app-store-preflight-skills y cómo funciona?
Es un AI agent skill de código abierto publicado por truongduy2611 en GitHub. Escanea proyectos iOS y macOS para detectar patrones de rechazo conocidos antes de enviar a App Store: APIs privadas, problemas en Info.plist, privacy manifest incompleto, y otros. Se puede integrar en pipelines de CI/CD como un step previo al build de distribución.
¿Cómo automatizar el pre-envío de una app iOS para App Store?
La forma más directa es agregar app-store-preflight-skills como step en tu pipeline de CI/CD (GitHub Actions, Bitrise, Fastlane, etc.) de manera que corra antes de generar el IPA de distribución. Si el agente detecta problemas, el pipeline falla y el equipo recibe el reporte detallado. Combinalo con la checklist manual de 47 items para cubrir los edge cases funcionales que el escaneo estático no puede verificar.
¿Cuánto tiempo toma una revisión extraordinaria de Apple?
Una revisión estándar toma entre 24 y 48 horas. Si Apple hace una revisión extraordinaria por reclamos de usuarios o solicitudes frecuentes de reembolso (como documenta Adapty), los tiempos son variables y el proceso es menos transparente. No hay mecanismo para acelerarlo desde el lado del developer. Por eso la prevención antes del envío vale más que cualquier estrategia de reacción post-rechazo.
Conclusión
El rechazo de apps en App Store no es un problema de mala suerte ni de criterios arbitrarios de Apple. El 72% de esos rechazos son detectables antes de enviar. app-store-preflight-skills automatiza una parte significativa de esa detección, especialmente en lo que refiere a APIs privadas, configuración de Info.plist, privacy manifest y Required Reason APIs, que son exactamente los cambios de política que Apple intensificó en los últimos ciclos de revisión.
No reemplaza el QA manual ni la checklist de 47 items, pero elimina la fricción de los errores técnicos evitables que consumen tiempo sin aportar ningún valor. Para equipos que trabajan con fechas ajustadas y clientes que no entienden por qué “Apple rechazó la app por un link roto”, tener esto corriendo en el pipeline es un golazo.
El repositorio está activo, tuvo tracción real en marzo de 2026, y la comunidad en Telegram está empujando contribuciones. Vale la pena tenerlo en el radar ahora que está en un momento de crecimiento, antes de que se convierta en estándar y ya no sea una ventaja.
