Notas para la revisión, vídeo de demostración, llamada con Apple, revisión acelerada, aumento del alcance, avalancha de apps generadas con IA: qué ayuda realmente a superar App Review, qué pertenece al terreno de la leyenda y qué puede costar mucho más que un rechazo.
Los ánimos están caldeados entre los desarrolladores de iOS, tanto en X como en las comunidades de WhatsApp, incluida una que coordino. Se habla de revisiones que se eternizan, de cuentas canceladas y se intercambian recetas para «conseguir la aprobación en menos de 48 horas»: notas detalladas para la revisión, vídeo de demostración, llamada con Apple para entrar en una cola aparte, MVP minimalista para evitar «la pila de los 14 días»…
Estos consejos contienen intuiciones muy acertadas. También hay afirmaciones imposibles de verificar y una o dos ideas que, mal aplicadas, pueden costar mucho más que un rechazo.
Los plazos y las cancelaciones merecen cada uno su propio capítulo, porque ayudan a entender todo lo demás.
Para situarnos (aunque, si has llegado a este sitio, seguramente ya «sabes» quién soy): publico en el App Store desde 2008, tanto mis propias apps como las de mis clientes. He repasado cada consejo y lo he contrastado con lo que Apple escribe negro sobre blanco en su página de App Review, sus App Review Guidelines y la ayuda de App Review. Esto es lo que se sostiene y lo que no.
Primero, pongamos las 48 horas en perspectiva
Las recetas que circulan dan a entender que 48 horas es todo un logro. Sobre el papel, es la norma que anuncia Apple: el equipo de App Review trabaja las 24 horas del día por todo el planeta (Cupertino, Cork y otros lugares), y su objetivo es tramitar al menos el 50 % de los envíos en menos de 24 horas y el 90 % en menos de 48 horas.
En la práctica, hay más matices. Estas cifras son promedios calculados sobre todos los envíos, y gran parte son actualizaciones de apps ya publicadas, que suelen aprobarse en unas pocas horas. En las últimas semanas, he tenido actualizaciones aprobadas en 7 horas y otras en 12. Una app nueva, en cambio, puede esperar mucho más: mientras escribo estas líneas, algunas de mis nuevas apps llevan más de diez días en revisión. Es mucho tiempo, pero así son las cosas.
Apple también ha compartido cifras recientes. Preguntada por MobileGamer.biz el 20 de octubre, la empresa indica que ha tramitado una media de 378 000 envíos por semana durante las últimas doce semanas, con un plazo medio de 1,5 días para el conjunto de las apps y 14 horas para las actualizaciones menores. También precisa que algunas apps nuevas tardan más cuando requieren un examen exhaustivo. Para semejante volumen, la media es notable; las diferencias se concentran en los primeros envíos.
La comunidad tenía antes su propia herramienta para seguir estos plazos. Los más veteranos recordarán appreviewtimes.com, lanzada a principios de la década de 2010 por mi amigo Dave Verwer, autor de iOS Dev Weekly. El principio era sencillo: los desarrolladores tuiteaban la duración de sus revisiones con el hashtag #iosreviewtime (sí, todavía era Twitter), y el sitio calculaba una media. En una época en la que había que contar por semanas, era una herramienta indispensable para gestionar las expectativas de los clientes.
En 2019, Dave cerró el sitio por la mejor de las razones: las revisiones se habían vuelto tan rápidas, de alrededor de un día, que medirlas ya no tenía mucho sentido. Nunca volvió a abrirlo. Por cierto, Dave se incorporó a Apple este verano junto con el Swift Package Index, y Alex Ozun se hizo cargo de iOS Dev Weekly.
El resultado: en 2026 ya no existe un barómetro comunitario de referencia, solo testimonios dispersos en foros y redes sociales. Un signo de los tiempos: la herramienta que cerró porque la revisión se había vuelto rápida volvería a tener hoy su lugar.
Una breve historia del tiempo
No es la primera vez que cambian los plazos. En los inicios del App Store, una revisión podía durar varias semanas. Mi primera app esperó 26 días antes de ser aprobada, para salir el 14 de julio de 2008, cuatro días después de la apertura del App Store. Después bajamos a una semana, que fue la norma durante mucho tiempo. Luego Apple aceleró considerablemente, hasta que lo habitual pasó a ser de uno a tres días. Desde principios de 2026, los plazos vuelven a subir para las apps nuevas, y el motivo merece un capítulo propio (justo debajo).
Aspirar a 48 horas no es, por tanto, buscar un trato de favor: es no salirse del flujo normal, sabiendo que para un lanzamiento el flujo normal se cuenta hoy en días. Planifica en consecuencia.
La verdadera pregunta pasa a ser: ¿qué hace que un envío se salga de ese flujo? Apple da una pista valiosa en su página de App Review: más del 40 % de los problemas sin resolver corresponden a la directriz 2.1, App Completeness: cierres inesperados, contenido provisional, información ausente. No es la subjetividad de la persona que revisa lo que retrasa a la mayoría de las apps. Es un envío incompleto.
Los agentes de código: más apps, más espera
¿Por qué vuelven a aumentar los plazos? La explicación más probable cabe en una palabra: los agentes.
Claude Code, Codex, Cursor, los agentes integrados en Xcode: escribir una app para iOS nunca había sido tan accesible. Según Sensor Tower, citado por The Information, el App Store recibió 235 800 apps nuevas en el primer trimestre de 2026, un 84 % más que un año antes, el mayor crecimiento registrado en cuatro años. Para el conjunto del primer semestre, Sensor Tower estima el número de apps nuevas en unas 560 000, el doble que el año anterior, mientras que las descargas solo aumentaron un 2 %. La propia Apple escribió en su balance antifraude de mayo que las herramientas de desarrollo con IA están haciendo crecer los envíos.
Apple mantiene su objetivo del 90 % en 48 horas y ha adaptado su organización: más automatización y prioridad para las actualizaciones. La experiencia de los desarrolladores concuerda con esa decisión: las actualizaciones de apps consolidadas siguen pasando rápido; las apps nuevas esperan más.
El lado bueno: what a great time to be a developer
Para empezar, es una noticia excelente por muchas razones. La barrera del código nunca había sido tan baja. Diseñadores, expertos en sus respectivos sectores y desarrolladores independientes que nunca habrían aprendido Swift pueden ahora lanzar una app útil. Los desarrolladores experimentados entregan en una semana lo que antes llevaba un trimestre. Yo mismo trabajo a diario con agentes: escriben SwiftUI, pruebas e incluso un primer borrador de las notas para la revisión.
Ahora bien, decir que la barrera ha desaparecido sería mentir. Un agente escribe código; no sabe por ti qué framework elegir, qué patrón resistirá cuando la app crezca, cómo se comportan la concurrencia de Swift, StoreKit o los permisos, ni por qué se atasca una revisión. Los agentes amplifican lo que ya sabes. Cuanto mejor conoces la plataforma, más rápido te hacen; cuanto menos la conoces, más deprisa acumulas problemas que no sabes interpretar.
Los ingredientes son los mismos para todo el mundo: Swift, SwiftUI, Xcode, las Human Interface Guidelines y, ahora, un agente. Lo que hace que una app sea excelente es la forma de combinarlos, con intención y cuidado: una razón de existir que pueda expresarse en una frase, una única fuente de verdad para los datos, una accesibilidad auditada honestamente y pruebas en dispositivos reales. Un agente puede escribir la pantalla; no te dirá si la app merece existir. O peor aún: se pondrá en modo madre orgullosa: «¡Es una idea fantástica, cariño!», y después te ayudará a quemar mil millones de tokens construyendo una app cuyo público objetivo completo sois tú, tu madre, tu gato, tu canario y quizá, solo quizá, tu pareja. He detallado todo este proceso, desde los ocho principios de diseño de Apple hasta la publicación, en La receta de una gran app para iOS.
Bien utilizados, también ayudan a cumplir las normas. Un agente puede revisar tus purpose strings, comprobar que existe la eliminación de cuenta, contrastar tu flujo con las directrices y enumerar las funcionalidades no evidentes que hay que documentar. Un agente puede comprobar antes que tú todo lo que describe este artículo.
De hecho, para facilitarte la tarea, te regalo una skill que te ayudará a descubrir los errores antes de enviar la app: app-review-skill. No garantiza la aprobación, pero al menos es una salvaguarda. 😉
En fin: what a great time to be a developer.
El espejismo del millonario en tres prompts
La otra cara de la moneda es el discurso que acompaña a esta ola. Por todas partes aparece la misma promesa: tres prompts, una suscripción (o anuncios por todas partes) y ya eres millonario en tres días.
Spoiler: es falso. Y las cifras son incontestables. El informe State of Subscription Apps 2026 de RevenueCat, que abarca más de 115 000 apps y 16 000 millones de dólares en ingresos, muestra que:
- un año después de su lanzamiento, la app mediana genera unos 72 $ al mes;
- solo el 17,3 % de las apps alcanza los 1 000 $ de ingresos mensuales en sus dos primeros años, y el 4,6 % supera los 10 000 $;
- incluso el 10 % con mejores resultados apenas supera los 2 574 $ al mes después de un año: lejos, muy lejos del millón;
- las apps lanzadas en 2025 o después solo representan el 3 % de los ingresos por suscripciones, mientras que las lanzadas antes de 2020 captan el 69 %.
Y hablamos de apps lo suficientemente serias como para haber integrado un sistema de suscripción.
Todo el mundo cree tener la next big idea. Siento hacerte bajar de las nubes. Si tu idea aún no existe en el App Store, solo hay dos posibilidades: o ya se intentó y no funcionó, o un centenar de personas la están construyendo justo ahora. Y con los agentes, ese centenar se convierte pronto en un millar.
No es pesimismo, es un fenómeno bien documentado: los descubrimientos simultáneos. Alexander Graham Bell y Elisha Gray presentaron su solicitud de patente para el teléfono el mismo día, en 1876. Darwin y Wallace llegaron cada uno por su cuenta a la selección natural, hasta el punto de presentar sus trabajos juntos en 1858. Newton y Leibniz inventaron el cálculo infinitesimal en paralelo. Nada de magia: en una época determinada, todo el mundo comparte las mismas herramientas, los mismos problemas y el mismo acceso a la información. Dos mentes ante el mismo problema, con las mismas herramientas, llegan naturalmente a la misma solución. Como dice la frase que suele atribuirse a Victor Hugo, nada es más poderoso que una idea a la que le ha llegado su momento.
El consejo que se desprende de esto: no guardes tu idea en secreto por miedo a que te la roben. Otros ya están trabajando en ella. Las personas con las que hables quizá incluso te señalen apps competidoras que se te habían pasado por alto. La diferencia no estará en la idea, sino en la ejecución, la distribución, el tiempo y tu toque personal.
Conozco a desarrolladores cuyas apps generan entre 80 000 y más de un millón de dólares al mes. Existen, son brillantes y a menudo tienen años de iteraciones a sus espaldas. Claramente no son la mayoría.
Eso no es una razón para no lanzarse. Es una razón para hacerlo por buenos motivos: resolver un problema real, aprender, construir algo duradero. Y para cuidar lo que no se automatiza: la calidad.
El lado menos bueno
Llegan apps hechas a la carrera a revisión, y la cola es compartida. Generar una app en un fin de semana no significa que esté lista: muchos envíos llegan sin haber sido probados en un dispositivo, con contenido provisional, sin política de privacidad ni notas para la revisión. Otros no interesan a nadie más que a su desarrollador. Sin embargo, Apple lo dice desde la introducción de sus directrices: una app que solo se quiere enseñar a familiares y amigos no tiene cabida en el App Store; Xcode y la distribución Ad Hoc están para eso. Cada uno de estos envíos ocupa a una persona del equipo de revisión que no está atendiendo el tuyo. Al dar prioridad a las actualizaciones de apps existentes, Apple protege a los usuarios actuales y a los desarrolladores consolidados; la contrapartida es una espera más larga para las apps nuevas.
El spam es el primer objetivo. La directriz 4.3 prohíbe enviar varias variantes de una misma app y apps de categorías saturadas sin una diferencia real. Con un agente, producir cinco clones lleva una tarde; eso es precisamente lo que Apple filtra. Apple indica que ha reforzado la automatización y la detección de abusos, y que ha añadido salvaguardas contra los envíos repetidos con los mismos problemas sin resolver. Sus directrices ya lo decían: un rechazo repetido por el mismo motivo alarga la revisión.
Las apps que generan código están en el punto de mira. Apple ha bloqueado actualizaciones o retirado varias apps de vibe coding este año, entre ellas Replit, Vibecode y Anything. El motivo no es el vibe coding en sí, sino la directriz 2.5.2: una app no puede descargar ni ejecutar código que cambie sus funcionalidades después de la revisión.
Más apps no significa más usuarios. Con unas descargas prácticamente estables, cada nueva app compite por la misma atención. La barrera técnica ha bajado; la barrera de la calidad, en cambio, ha subido.
Qué cambia esto para ti
- Sigues siendo responsable. Las directrices lo recuerdan: todo lo que hay en tu app, incluidos los SDK de terceros, es responsabilidad tuya. «Lo ha escrito el agente» no es un argumento aceptable.
- La calidad del envío se convierte en una ventaja. En una cola congestionada, una app completa con notas claras destaca aún más que antes.
- Una app, no cinco variantes. Utiliza las compras integradas o los ajustes para las variantes, en lugar de multiplicar los bundle IDs.
- Nunca vuelvas a enviar sin corregir. Una ida y vuelta innecesaria te cuesta días y puede hacer que tu conducta se incluya entre las que Apple vigila.
- Deja margen. Para una app nueva, calcula una semana, más una posible ida y vuelta. Si pasa en 48 horas, mejor que mejor.
Los consejos que se sostienen
La calidad cuenta y está escrita en las reglas
«Una app cuidada recibirá un mejor trato»: es cierto, pero no depende del humor de quien la revise. La sección 4 de las directrices lo dice claramente: Apple espera interfaces sencillas, refinadas y fáciles de usar. La directriz 4.2 (Minimum Functionality) rechaza las apps que no son más que un sitio web empaquetado, una colección de enlaces o contenido sin valor duradero.
«Hazlo nativo con SwiftUI»: un buen consejo, no una regla
Soy desarrollador nativo de iOS: lo practico, lo defiendo, lo promuevo y lo enseño. Para mí, es la vía de referencia para construir una app que respete los usos de la plataforma y aproveche plenamente lo que pueden hacer el iPhone y el iPad. Con SwiftUI disfrutas de Dynamic Type, las safe areas, las sheets, la navegación del sistema y la adaptación a iPhone/iPad, con acceso directo a widgets, Live Activities, App Intents y muchas otras posibilidades de los frameworks de Apple. Esta integración marca una diferencia real en el día a día y reduce de forma natural los pequeños defectos que detecta quien revisa la app.
Pero ninguna directriz impone SwiftUI. Una app bien hecha con Expo, Flutter o UIKit pasa sin problemas. Lo que se penaliza es el resultado: una web view disfrazada, una interfaz que se rompe en el iPad (la directriz 2.4.1 fomenta la compatibilidad con iPad siempre que sea posible), un teclado que tapa un campo. El desarrollo nativo aumenta tus posibilidades de alcanzar la excelencia; no la garantiza.
P. D.: Martin, no pegues, no pegues, no pegueeeee... zas
Política de privacidad, soporte y permisos
Aquí a menudo nos quedamos cortos frente a la realidad. No son buenas prácticas, son obligaciones:
- Una política de privacidad accesible en App Store Connect y en la app (5.1.1(i)). Debe describir los datos recopilados y sus usos, comprometer a los terceros a ofrecer un nivel de protección equivalente y explicar la conservación, la eliminación y la retirada del consentimiento.
- Un enlace de soporte con datos de contacto actualizados, y todos los enlaces funcionando (2.1 y 5.1).
- Purpose strings claras para cada permiso sensible, idealmente con un ejemplo concreto de uso.
- La minimización de datos (5.1.1(iii)): prioriza los selectores del sistema, como el selector de fotos, frente al acceso completo a la fototeca.
- La eliminación de cuenta dentro de la app siempre que se pueda crear una (5.1.1(v)).
El formato «HTML estático» que suele recomendarse no es obligatorio. Lo que importa es que la página sea accesible, esté actualizada y sea coherente con lo que hace la app.
Las apps sociales: cuatro requisitos concretos
Denuncia, bloqueo, contacto, moderación: eso es exactamente lo que recoge la directriz 1.2 (User-Generated Content), que exige:
- una forma de filtrar el contenido inaceptable antes de su publicación;
- un mecanismo de denuncia y una respuesta rápida a las denuncias;
- la posibilidad de bloquear a los usuarios abusivos;
- datos de contacto publicados para poder localizarte.
Desde la actualización del 16 de octubre de 2026, la directriz menciona explícitamente las apps de creación mediante IA, y Apple precisa que las imágenes íntimas no consentidas, incluidas las generadas por IA, deben prevenirse activamente y retirarse. Se puede considerar que un desarrollador que no establezca salvaguardas, o que no corrija el problema tras recibir un aviso, infringe el código de conducta.
La API gratuita de moderación de OpenAI aparece a menudo en las conversaciones. Es una opción técnica válida, con una precisión importante: la directriz 5.1.2(i) exige informar claramente cuando se comparten datos personales con terceros, incluida una IA de terceros, y obtener permiso explícito. Enviar las fotos de tus usuarios a un modelo externo sin decirlo es sustituir un rechazo por otro.
Las compras integradas deben funcionar
Parece obvio, pero a menudo falla: la directriz 2.1(b) exige que las compras integradas estén completas, visibles y funcionen para quien revisa la app. Si un producto configurado no es accesible en la build enviada, explica por qué en las notas. Y añade un botón «Restaurar compras».
Las notas para la revisión: la herramienta más infravalorada
Este es el consejo más útil de todos, y Apple va aún más lejos.
Lo que Apple pide en la checklist «Before You Submit»:
- acceso completo a la app: una cuenta de demostración activa o un modo de demostración completo, además del material o los recursos necesarios (credenciales, código QR de ejemplo…);
- un back-end en línea durante toda la revisión;
- una explicación detallada de las funcionalidades no evidentes y de las compras integradas en las notas, con documentación si hace falta.
Sí, hay una parte de automatización, y es normal con este volumen. Pero Apple lo escribe negro sobre blanco en la introducción de sus directrices: cada app es examinada por expertos. En nueve de cada diez casos, si no más, hay un ser humano a los mandos que pulsa el botoncito verde (o rojo).
Tus notas se dirigen, por tanto, a una persona que descubre tu app en unos minutos. Escríbelas para ella.
Y la directriz 2.3.1(a) no deja lugar a dudas: toda nueva funcionalidad debe describirse con precisión en las notas, y las descripciones genéricas se rechazan.
Atención a un detalle: un modo de demostración en lugar de una cuenta de demostración solo se acepta con la autorización previa de Apple y únicamente si obligaciones legales o de seguridad te impiden proporcionar una cuenta.
Una estructura que funciona
No hace falta copiar la novela de otra persona. Este es el esquema que utilizo:
Hola:
[Nombre de la app] es [una frase: qué hace la app, para quién y qué problema resuelve].
Modelo de negocio: [gratuita / suscripción / compra única], mediante In-App Purchase.
Acceso:
- Cuenta de demostración: [identificador] / [contraseña]
(o: no se requiere cuenta)
Recorrido principal:
1. …
2. …
3. …
Compras integradas:
- Dónde aparece el paywall, cómo probarlo en sandbox.
- «Restaurar compras»: [ubicación].
Funcionalidades no evidentes:
- [Función]: cómo acceder a ella, qué hace.
Datos y permisos:
- Qué permisos, cuándo se solicitan y por qué.
- Datos compartidos con terceros (incluida la IA) y consentimiento.
Servicios externos:
- [Servicio]: para qué sirve (datos, autenticación, pagos, IA, publicidad…).
Diferencias regionales:
- [Ninguna / cuáles].
Normativa y contenidos de terceros:
- [No aplicable / documentos adjuntos].
Cuenta y seguridad:
- Eliminación de cuenta: [ruta].
- Denunciar / bloquear: [ruta] (si hay contenido de usuarios).En cuanto al estilo, la regla de oro: frases cortas, comprensibles para alguien que descubre la app. Solo matizaría el «no uses IA» que a veces se lee: encargar un primer borrador a un agente que conoce tu código ahorra realmente tiempo. Lo que importa es revisar y simplificar antes de enviar.
Un ejemplo real: declarar lo que se controla a distancia
Esta es una nota que dejé en una de mis apps (anonimizada). El caso es habitual: el SDK publicitario está integrado, pero los anuncios no pueden activarse antes de la publicación, porque AdMob exige una app publicada en una tienda para validar su «app readiness». Por tanto, los anuncios están desactivados mediante un feature flag en el momento de la revisión.
ADVERTISING DISCLOSURE - INITIAL 1.0 RELEASE
This app includes the Google Mobile Ads (AdMob) SDK and Google UMP consent integration. Production advertising is currently disabled through a remote feature flag. This is the general launch configuration, not a condition targeting App Review. We are disclosing the advertising integration explicitly; it is not disabled to hide it from reviewers.
The reason is that this initial release is not yet publicly available on the App Store. AdMob requires a published, downloadable app linked to a supported store for its app readiness review, and approval before full ad serving. We therefore cannot complete that activation process before publication. After release, we plan to link the App Store listing, complete AdMob's readiness process and enable production advertising through the feature flag.
The absence of ads during review should not be interpreted as an ad-free product. Ad presentation will remain subject to the applicable consent and tracking permissions.
Google's explanation: https://support.google.com/admob/answer/10564477?hl=enPor qué funciona esta nota:
- Nombra lo que hay en el binario: el SDK AdMob y el módulo de consentimiento UMP.
- Declara el feature flag y precisa que no está dirigido a la revisión. Es exactamente lo contrario de una funcionalidad oculta en el sentido de la directriz 2.5.19.
- Explica por qué, con una fuente externa verificable.
- Anuncia lo que cambiará después de la publicación, para que la activación de los anuncios no sea una sorpresa.
- Recuerda el consentimiento: los anuncios personalizados seguirán sujetos a los permisos de seguimiento.
Nada oculto, nada que interpretar: quien revisa la app sabe exactamente qué está aprobando.
El vídeo de demostración: no es obligatorio, pero se solicita cada vez más
A veces se lee que los primeros envíos sin notas ni vídeo se rechazarían automáticamente. Nada en la documentación de Apple dice eso. Lo que Apple escribe es que hay que estar preparado para proporcionar un vídeo de demostración o el material necesario cuando ciertas funcionalidades dependen de un entorno difícil de reproducir o de hardware específico.
En la práctica, una breve grabación de pantalla comentada, adjuntada en App Review Information, ayuda mucho en cuanto la app se sale de lo habitual: un dispositivo conectado, geolocalización, una función social que requiere varias cuentas. Para una app de notas sin cuenta, es superflua.
El objetivo sigue siendo acertado: hacer que la revisión sea evidente. Quien entiende tu app en tres minutos no tiene ninguna razón para hacerte preguntas.
Cuando Apple te pide «más información»
Para las apps nuevas, hay un mensaje que aparece cada vez más a menudo: una solicitud de información estandarizada, vinculada a la directriz 2.1. Esta es la que recibí recientemente para una de mis apps:
We need additional information to better understand the app and complete the review.
Reply in App Store Connect with all of the following information and also add this
information to the Notes field of the App Review Information section in App Store
Connect, for reference on future submissions:
1. A screen recording captured on a physical device, running the latest operating
system, demonstrating the app's functionality. The recording must begin with
launching the app and show the typical user flow. If the app has any of the
following, include them in the recording:
- Account registration, login, and account deletion flows.
- Any user-generated content, including the required content reporting and
blocking mechanisms.
- Accessing paid content or features within the app.
2. A description of the app's purpose and target audience, including the problem
it solves and the value it provides
3. Instructions for setting up and accessing the app's main features, including
any required login credentials or sample files
4. A list of the external services, tools, or platforms the app uses to deliver
its core functionality (for example, data providers, authentication services,
payment processors, or AI services)
5. Describe any regional differences in the app's features or content, or confirm
that the app functions consistently across all regions
6. If the app operates in a highly regulated industry or includes protected
third-party material, provide any relevant documentation or credentials to
demonstrate you are authorized to provide these services or protected materialEl mensaje recuerda de paso las trampas habituales: errores en un dispositivo físico, cuenta de demostración, capturas de pantalla que muestran la app en uso, compras integradas configuradas junto con la app y distribución reservada a empresas.
Y esta es mi respuesta, anonimizada:
1. [Screen recording attached, captured on a physical device.]
2. [App] is a [category] app that [what the app does]. It's inspired by
[well-known reference], but adds [its own distinctive features]. It's designed
for [target audience], and [the problem it solves / the value it provides].
3. There's no account to create and no login required. Users can simply open the
app and start using it. The main flow consists of [main interaction]. Users
can also [secondary features] directly from the app. The app includes optional
rewarded ads to unlock [optional extra].
4. The app runs primarily on the device. [Core processing] is handled locally,
so there's no external API involved in the core functionality. Google's AdMob
is used to display advertisements, including optional rewarded ads.
5. The app works the same way in every region where it's available. The main
difference is the language: the app has a localized name and content adapted
to each language. Features and core mechanics remain consistent across all
supported regions.
6. Not applicable. [App] is an original app and doesn't operate in a regulated
industry.Tres lecciones:
- El vídeo no se exige de oficio, pero aquí se solicita explícitamente, grabado en un dispositivo físico, con la última versión de iOS y desde el lanzamiento de la app. Más vale prepararlo antes del primer envío.
- Apple pide añadir estas respuestas en el campo Notes, para los siguientes envíos. Dicho de otro modo: si hubieran estado allí desde el principio, probablemente se habría evitado la ida y vuelta.
- Las seis preguntas son una excelente checklist. Propósito, público, acceso, servicios externos, diferencias regionales y normativa: las he incorporado al modelo de notas anterior.
Lo que no hay que hacer (y por qué a veces es peor que un rechazo)
Las pantallas de «próximamente»
Contenido provisional, botones que no funcionan, enlaces vacíos: eso es el núcleo de la directriz 2.1, y la primera causa de problemas según Apple. Elimina la funcionalidad de la build en lugar de mostrarla a medias.
Modificar el paywall después de la revisión
A veces se clasifica «hacer que un paywall remoto deje de cumplir las normas después de la revisión» entre los simples patrones oscuros. Es mucho más grave que eso.
La directriz 2.5.19, añadida el 16 de octubre de 2026 para abordar expresamente el bait-and-switch, prohíbe las funcionalidades ocultas, inactivas o no documentadas, y prevé la retirada de la app y la cancelación de la cuenta de desarrollador. La introducción de las directrices es aún más directa: intentar engañar al proceso de revisión conduce a la retirada de las apps y a la expulsión del Apple Developer Program. No es una apuesta por la clemencia de quien revisa la app, sino un riesgo para toda tu actividad.
Configurar el paywall a distancia no está prohibido. Cambiarlo por algo que quien revisa la app no ha visto, sí.
Las solicitudes de valoración
La directriz 5.6.1 exige usar la API proporcionada por Apple para pedir una valoración y prohíbe los avisos personalizados. La directriz 3.2.2(x) prohíbe condicionar el acceso a una funcionalidad a que se valore la app.
Pedir una valoración durante el onboarding no está explícitamente prohibido, pero es absurdo: el usuario aún no ha visto nada y, en cualquier caso, el sistema limita la frecuencia con la que se muestra esta solicitud. Espera a un verdadero momento de satisfacción.
La falsa prueba social y las promesas imposibles de verificar
Un «millón de usuarios» inventado, reseñas falsas, «corrige el 100 % de tus problemas»: la directriz 5.6.3 prohíbe cualquier manipulación de reseñas, clasificaciones o búsquedas, y la 2.3.7 prohíbe las afirmaciones imposibles de verificar en los metadatos. Para las apps de salud, la 1.4.1 exige documentar la metodología que respalda cualquier afirmación sobre precisión.
Copiar una app
Parece obvio, y Apple va más lejos. La directriz 4.1 rechaza las copias, y hacerse pasar por otra app es una infracción del código de conducta. La 4.3 cierra la puerta a las categorías saturadas (linternas, fondos de pantalla, apps de citas, temporizadores sencillos…), salvo que ofrezcan una experiencia realmente diferente. Ya existe un millón de cojines de pedos, linternas y apps de citas: Apple menciona expresamente las apps de pedos y eructos entre las que no aportan nada al App Store.
Las ofertas de retención: recurrir a las herramientas oficiales
Se habla mucho de «transaction abandon» y de «exit offers» (proponer una oferta a alguien que duda o quiere cancelar). Estas prácticas no están prohibidas en sí mismas, y StoreKit ofrece mecanismos oficiales para ello: ofertas promocionales, ofertas de recuperación (win-back offers) y la pantalla del sistema para gestionar suscripciones.
Guardarlas para una actualización posterior es razonable: menos superficie, menos preguntas. Pero la verdadera regla está en otra parte. La directriz 3.1.2(c) exige describir claramente qué obtiene el usuario por el precio, y la 5.6 prohíbe empujar a compras no deseadas. Una oferta clara, descrita en las notas, no tiene nada que temer. Una oferta que confunde sobre el precio, sí.
Las cancelaciones de cuentas: entenderlas para no verse afectado
Un rechazo cuesta unos días. Una cancelación cuesta todas tus apps. El tema ocupa mucho espacio en las redes estas últimas semanas y merece abordarse con calma.
Por qué Apple aprieta las tuercas
El 16 de octubre de 2026, Apple reforzó sus directrices en dos puntos: las imágenes íntimas no consentidas, incluidas las generadas por IA, que las apps deben prevenir y retirar (1.2), y el bait-and-switch, esas apps que se presentan como inofensivas durante la revisión y activan funcionalidades dañinas después de la aprobación (2.5.19). En el mismo anuncio, Apple indica que el año pasado impidió que más de 150 000 apps con problemas de seguridad llegaran a los usuarios y que canceló más de 193 000 cuentas de desarrollador por fraude y abuso.
Estas cifras dicen lo esencial: el fraude en el App Store es masivo y organizado. Las apps para «desnudar» personas se han multiplicado, autoridades como la ciudad de San Francisco han exigido su retirada y la avalancha de envíos generados con IA aumenta aún más la presión. Si la confianza de los usuarios en el App Store se mantiene pese a todo, es en gran parte gracias a este trabajo.
A esta escala, también ocurre que desarrolladores de buena fe quedan atrapados en la red. Precisamente para esos casos existe la apelación ante el App Review Board.
Lo que cuentan algunos desarrolladores
Las notificaciones compartidas invocan la sección 3.2(f) del Developer Program License Agreement y hablan de un «patrón de comportamiento manipulador o engañoso», seguido de una lista de posibles conductas: metadatos inexactos, contenido engañoso, reseñas falsas, respuestas engañosas al soporte o en App Store Connect, compras con bait-and-switch…
Phillip Shoemaker, que dirigió App Review, publicó a finales de octubre su análisis. Considera que el historial de rechazos pesa ahora mucho: número de envíos, cambios de nombre, rechazos repetidos por contenido inaceptable, especialmente en apps de fotografía generativa. También reconoce la dificultad desde el lado de Apple: las apps generativas son muy difíciles de revisar, una corrección en el servidor puede revertirse en cualquier momento y Apple relaciona las cuentas entre sí, lo que le da una visión que el desarrollador no siempre tiene. Sus propuestas son constructivas: rechazos más precisos sobre lo que debe cambiar y elementos concretos en las notificaciones para que la apelación sea útil.
Quien juega con fuego acaba quemándose
No hace falta dar nombres: las historias que circulan se parecen. Y cuando se leen de cerca, a menudo aparecen las mismas reacciones. Rara vez nacen de una mala intención, pero vistas desde Cupertino se parecen muchísimo a lo que Apple intenta detectar:
- Volver a enviar una y otra vez cambiando un detalle cada vez, «a ver si pasa».
- Cambiar el nombre de la app, el concepto o la categoría sobre la marcha, a veces varias veces.
- Corregir superficialmente: quitar una opción de un menú mientras la funcionalidad sigue siendo accesible por otra vía.
- Mantener un interruptor en el servidor que quien revisa la app nunca ha visto.
- Atiborrar de palabras clave, o inspirarse demasiado en el nombre de una app competidora.
- Multiplicar las cuentas, o prestar la propia, para eludir un rechazo.
- Maquillar la verdad en las respuestas a App Review.
Por separado, cada uno de estos gestos puede parecer inofensivo. Juntos, dibujan un patrón. Y a la escala de cientos de miles de envíos por semana, eso es lo que Apple lee: el patrón, no tus intenciones.
La moraleja es sencilla: intentar ser más listo que App Review es apostar contra la casa. Y la casa tiene el historial completo.
El App Review Board sigue ahí para corregir errores y los desarrolladores de buena fe consiguen que les den la razón. Pero la mejor apelación es la que nunca necesitas presentar.
Qué cambia esto para ti
No voy a hacerme pasar por jurista: ante una cancelación, la única vía es apelar ante el App Review Board y, en los casos comunicados, la notificación abre un plazo de 30 días para hacerlo. Si te sucede, busca asesoramiento. En cambio, algunas pautas reducen notablemente el riesgo:
- Tu historial de rechazos cuenta. Cada envío deja huella. Nunca vuelvas a enviar «a ver qué pasa»: plantea una pregunta precisa en App Store Connect antes de corregir.
- No cambies la identidad de la app sobre la marcha. Nombre, concepto, categoría: los cambios repetidos se parecen a lo que Apple intenta detectar. Si te lo pide App Review, pide que lo confirmen por escrito en App Store Connect, incluso después de una llamada, y resume por escrito lo que se dijo por teléfono.
- Cuando un rechazo se repite en bucle, deja de enviar. Pide por escrito la lista completa de los puntos que bloquean la aprobación y después recurre al App Review Board en lugar de encadenar intentos.
- Documenta todo lo configurable a distancia. Feature flags, paywall, modelos de IA: indícalo en las notas y muestra qué puede cambiar.
- Para una app generativa, corrige en origen. Quitar una opción de un menú no basta si el modelo sigue produciendo el contenido con un simple prompt. El filtrado debe ser real, tanto en el modelo como en la salida.
- Responde con exactitud en App Store Connect. Las «respuestas engañosas» figuran explícitamente en la lista de motivos.
- Guarda un archivo de cada envío. Build, notas, capturas, intercambios con App Review: es tu único expediente en caso de apelación.
- Vigila con quién te relacionas. Cuentas compartidas, certificados prestados, socios con prácticas dudosas: Apple relaciona las cuentas entre sí.
Por eso tampoco comparto la idea, que a veces se plantea, de que «Apple quiere que busquemos el límite». En 2026, cada envío cuenta en tu historial. Es mejor aspirar a la claridad que buscar el límite.
Acelerar una revisión: lo que realmente existe
Aquí es donde circulan más ideas preconcebidas.
La revisión acelerada (expedite)
Existe para circunstancias excepcionales: un error crítico o un lanzamiento vinculado a un evento con el que estás directamente relacionado. Algunas precisiones que suelen olvidarse:
- solo se puede acelerar un envío que ya se haya remitido a revisión;
- para un error crítico, indica en las notas los pasos para reproducirlo en la versión actual;
- para un evento, indica el evento, su fecha y la relación de la app con él;
- Apple tramita la solicitud según la disponibilidad y la demanda, sin garantías;
- y, sobre todo, en caso de abuso, Apple se reserva el derecho de rechazar tus futuras solicitudes.
Por tanto, «no hace falta dar un motivo» es engañoso: el formulario es sencillo, pero la justificación debe estar en las notas. En cuanto al «momento viral» o al «marketing», no figuran entre los criterios. Yo no gastaría ese cartucho en eso.
La llamada con Apple: no es una cola rápida
A menudo se presenta la llamada como un método poco conocido que permitiría pasar a una cola aparte. Eso no es lo que describe Apple.
Se puede solicitar una llamada con un representante de Apple desde la ventana de respuesta a App Review, después de una primera respuesta por su parte, indicando la zona horaria y el idioma. Estas llamadas suelen tener lugar en un plazo de tres a cinco días laborables. Es una herramienta excelente para resolver un malentendido sobre un rechazo. En ningún caso es un atajo hacia las 48 horas. Ten presente que la siguiente revisión puede hacerla otra persona: pide siempre que confirmen las conclusiones por escrito en App Store Connect.
Las citas con App Review: el verdadero secreto
Algo que rara vez se menciona y que recomiendo a todos mis clientes antes de un primer envío delicado: las citas con App Review a través de Meet with Apple. Treinta minutos por videollamada con un experto de App Review, los martes y jueves según disponibilidad, para hacer preguntas concretas sobre cómo se aplica una directriz a tu app.
Hay dos límites que conviene conocer: la cita es informativa, no sustituye, acelera ni garantiza la revisión, y Apple no aprueba previamente ninguna funcionalidad. Pero llegar al envío sabiendo ya cómo interpreta Apple tu caso es la mejor inversión posible.
Salir del bucle de rechazos sucesivos
La pesadilla es bien conocida: un rechazo, una corrección y luego otro rechazo por un motivo distinto. Para salir de ella, hay que utilizar los canales adecuados:
- Responder en App Store Connect con una pregunta concreta: la funcionalidad, la directriz o el paso que quieres aclarar. Te responde un especialista que conoce tu app. Preguntar «¿hay otros puntos que bloqueen la aprobación?» es legítimo, aunque nadie pueda garantizártelo.
- La Bug Fix Submission: para una app ya publicada, una actualización correctiva no queda bloqueada por otros problemas relacionados con las directrices, salvo que exista un problema legal o de seguridad. Corriges el resto en el siguiente envío.
- La apelación al App Review Board si consideras que la app no se ha entendido bien: una sola vez por envío rechazado, con argumentos precisos.
Y en cuanto al tono, la directriz 5.6 recuerda que hay que tratar a todo el mundo con respeto, también en los intercambios con Apple. Quejarse no sirve de nada; argumentar con las directrices, sí.
El scope creep: el mejor consejo, con un matiz
«Envía un MVP» es un consejo excelente, y Apple lo confirma a su manera: una app compleja o que plantea nuevas cuestiones puede requerir un examen más exhaustivo, y los rechazos repetidos por la misma directriz alargan la revisión.
En cambio, la descripción de «dos pilas» con una derivación a un especialista sénior y 14 días de espera no está documentada en ninguna parte. Lo que Apple documenta son ámbitos regulados que requieren más documentación y tiempo:
- las apps de banca, finanzas, salud, juegos de azar, cripto o transporte aéreo deben ser enviadas por la entidad jurídica que presta el servicio (5.1.1(ix));
- los juegos de azar deben prever un plazo adicional (5.3);
- las apps médicas o relacionadas con contenidos sujetos a licencia deben aportar las autorizaciones correspondientes.
Por último, un matiz: un MVP no es una app raquítica. El umbral de la directriz 4.2 se aplica desde la primera versión. Reduce el número de funcionalidades, no su acabado.
En resumen: verdadero, con matices, falso
| Lo que se lee | Veredicto | Lo que dice Apple |
|---|---|---|
| Se puede conseguir la aprobación en 48 horas | Con matices | Objetivo oficial, cumplido para la mayoría de las actualizaciones; una app nueva puede esperar más de una semana |
| Las notas detalladas para la revisión ayudan | Verdadero | Exigidas para las funcionalidades no evidentes (2.3.1(a)) |
| Hace falta una cuenta de demostración | Verdadero | Obligatoria si la app tiene inicio de sesión (2.1(a)) |
| Las apps sociales deben moderar | Verdadero | Filtrar, denunciar, bloquear y publicar un contacto (1.2) |
| Hay que construir con SwiftUI | Con matices | No es obligatorio, solo cuenta el resultado (4.2) |
| Un vídeo de demostración es casi obligatorio | Con matices | No hay rechazo automático documentado, pero se solicita cada vez más a las apps nuevas |
| Guardar las ofertas agresivas para más adelante | Con matices | Prudente, pero la verdadera regla es la claridad (3.1.2, 5.6) |
| Un MVP pasa más rápido | Con matices | Sí, sin bajar del umbral de la 4.2 |
| No hace falta justificar una solicitud de revisión acelerada | Falso | La justificación va en las notas; el abuso se sanciona |
| La llamada permite pasar a una cola aparte | Falso | Después de una respuesta de App Review, en un plazo de 3 a 5 días laborables |
| Sin notas ni vídeo, rechazo automático | No documentado | Ninguna fuente oficial |
| Dos pilas, una de ellas de 14 días | No documentado | Apple solo habla de un examen más exhaustivo |
| Apple quiere que busquemos el límite | Falso | Engañar a la revisión conduce a la expulsión del programa |
Mi checklist antes del envío
Integridad (2.1)
Información para la revisión
Privacidad y seguridad (5.1, 1.2)
Metadatos (2.3)
Estrategia
El verdadero secreto: ser aburrido y honesto
A veces se lee que Apple querría que buscáramos el límite. No estoy de acuerdo. Las directrices son un documento vivo, y Apple asume que hay cierto margen de apreciación. Pero la introducción es clara: el principio es una experiencia segura para los usuarios, y cualquier intento de engañar a la revisión se paga muy caro.
Por lo demás, hay una regla que genera consenso: sé claro, sé honesto, explica lo que haces y muéstralo. Un envío completo, legible y sin sorpresas pasa dentro de los plazos normales. Para una actualización, suele ser menos de 48 horas. Para una app nueva en 2026, cuenta más bien con una semana y deja que te sorprendan para bien.
Con agentes que permiten a cualquiera enviar una app en un fin de semana, App Review vuelve a ser lo que era al principio: un filtro. Y eso es bueno. Ese filtro permite a un usuario instalar una app desconocida sin desconfiar, y esa confianza es lo que da valor al App Store para nosotros, los desarrolladores. Los equipos de App Review tramitan cientos de miles de envíos por semana; facilitarles el trabajo también es hacernos la vida más fácil.
Mejor estar del lado bueno del filtro.
Creo y publico apps desde el nacimiento del App Store, para mí, para startups o para firmas que tienen su tienda en los Champs-Élysées. Si estás preparando un primer envío delicado, una app social, un modelo de suscripción o una app en un ámbito regulado, ese es el tipo de acompañamiento que ofrezco con BNC Consulting. Escríbeme.
Y para hablar de ello entre desarrolladores, únete a la comunidad ⌘+F: las historias de rechazos también las compartimos en meetups, tomando un café o cenando.
Y para terminar, un beso enorme a Raph’, Anders, Erica, Ewelina y a todos mis demás amigos de App Review, que hacen un trabajo especialmente difícil. Otro para Martin, Mac, SiQing y los equipos de WWDR, que a menudo hacen de intermediarios, y para todas las demás personas que conozco por el mundo y a las que no puedo nombrar aquí.
Gracias por estar ahí para proteger a los usuarios. Eso también es el lado bueno del App Store.
— Clément
Fuentes oficiales (consultadas el 1 de noviembre de 2026)
- App Review — Apple Developer
- App Review Guidelines (actualización del 16 de octubre de 2026)
- Solicitar una revisión acelerada
- Contactar con App Review y solicitar una llamada
- Solicitar una cita con App Review
Datos y prensa
- MobileGamer.biz — plazos de revisión y avalancha de apps generadas con IA (20 de octubre de 2026, con la respuesta de Apple en cifras)
- 9to5Mac — aumento del 84 % de las apps nuevas
- TweakTown — 560 000 apps nuevas en el primer semestre de 2026
- RevenueCat — State of Subscription Apps 2026
- iPhoneSoft — AppReviewTimes cierra sus puertas (marzo de 2019)
- Apple — Strengthening App Review Guidelines against nonconsensual intimate imagery and bait-and-switch apps (16 de octubre de 2026)
- Phillip Shoemaker — Apple approved the fix. Then it called the developer a liar. (30 de octubre de 2026)
- 9to5Mac — nuevas reglas contra la desnudez generada por IA y el bait-and-switch
Como de costumbre, este artículo se escribió a mano en francés. La traducción al español y las ilustraciones se realizaron con las herramientas de OpenAI.