Revisión acelerada App Store: cómo pedírsela a Apple
Por Mehdi Azizi
Publicado el , 9 min
Apple menciona dos casos: un bug crítico en la versión publicada o un lanzamiento ligado a un evento. El proceso, qué escribir y qué pasa después.
La revisión acelerada existe, pero Apple la reserva para circunstancias excepcionales y menciona dos: corregir un bug crítico en una versión ya publicada o lanzar una versión ligada a un evento con el que tu app tiene relación directa. Primero envías tu versión, explicas la urgencia en las Notes para el revisor y después mandas el formulario de solicitud. Apple estudia cada solicitud y acelera según su disponibilidad: nunca es una garantía.
Mis apps, Solys, TradaZen y Nolera, están hechas con Expo. Cuando un bug viene del código JavaScript, la corrección sale como actualización remota, sin pasar por App Review. Así que la revisión acelerada solo me sirve para un build nativo, y esa es también la primera pregunta que debes hacerte antes de pedirla. Esta guía sigue la página de ayuda de Apple sobre la revisión acelerada, revisada el 6 de noviembre de 2026.
Lo que Apple menciona y lo que no pasa
Apple habla de circunstancias excepcionales y pide reservar las solicitudes para urgencias reales. Su página de App Review da dos ejemplos y lo que hay que aportar en cada caso. Las tres filas rechazadas de la tabla son mi lectura de esas páginas, no una lista de Apple.
| Motivo | Según Apple | Qué aportar, o qué entender |
|---|---|---|
| Bug crítico en la versión publicada | Citado como ejemplo | Pasos para reproducirlo, versión actual |
| Lanzamiento ligado a un evento | Citado como ejemplo | El evento, su fecha, la relación entre tu app y él |
| Primera publicación con retraso | No, en mi opinión | Nada la vuelve urgente a ojos de Apple |
| Fecha de marketing sin evento | No, en mi opinión | Una campaña no es un evento ligado a la app |
| Espera más larga de lo habitual | No, en mi opinión | Un plazo normal no es una urgencia |
Apple no define el término. En la práctica, un bug crítico es una app que se cierra, que bloquea una función esencial o que impide pagar, a usuarios reales, en la versión publicada. Una errata en una pantalla no lo es. Y si tu app sigue en revisión cuando se acerca un evento, Apple aclara que también puedes pedir la aceleración por ese motivo.
El proceso en tres pasos
- Envía la versión en App Store Connect. Solo se puede acelerar un envío que ya se hizo. Si hay funciones que requieren iniciar sesión, indica una cuenta de demostración en la sección App Review Information.
- Llena el campo Notes al enviar. Para un bug crítico, describe el bug corregido y cómo reproducirlo en la versión actual. Para un evento, indica su nombre, su fecha y qué relaciona tu app con él.
- Envía el formulario Request an Expedited App Review, disponible desde la página de ayuda de Apple tras iniciar sesión en tu cuenta de desarrollador. Ahí eliges la app y la plataforma, y lo envías.
Apple estudia la solicitud y te responde; luego sigues el envío en App Store Connect. Si la aceptan, la versión pasa a In Review antes de lo que la fila habría permitido. Si la rechazan, la revisión sigue su curso normal: no pierdes nada.
El botón Reply to App Review, en App Store Connect, no sirve para pedir una revisión acelerada. La página de contacto de App Review lo reserva para conversaciones sobre un envío en curso; la solicitud acelerada y la apelación tienen cada una su formulario.
Qué escribir: dos plantillas
App Review lee en inglés. Estos son los dos textos que tengo listos, para adaptar en las Notes y en el formulario si te deja un campo libre. Caben en cinco líneas porque un revisor tiene que entender la urgencia sin abrir la app.
Bug crítico en la versión publicada:
Version 2.0.3, currently live, crashes at launch for users who enabled notifications on iOS 26.1. Steps to reproduce: install 2.0.3, allow notifications, force quit, relaunch. The app closes immediately. Version 2.0.4 fixes the crash (notification permission is now read after the first screen loads). No other change in this build.
Lanzamiento ligado a un evento:
This version adds the official schedule and live results for the Nantes Trail Festival on June 5, 2027. Our app is the event's official companion app (see the link to the organizer's page in the App Review Information section). Attendees need the update before the start on June 5 at 8:00 AM CEST.
Estos dos textos son ejemplos, no solicitudes que yo haya enviado. Dos reglas para los tuyos. Hechos verificables: versión, sistema, pasos, fecha, relación con el evento. Nada más que la urgencia: si tu build también trae una función nueva, dilo en una frase, pero no la defiendas.
Antes de pedirla, comprueba que la necesitas
Apple pide reservarla para urgencias reales. Tres preguntas, y una trampa, antes de enviar el formulario.
¿La corrección puede salir sin revisión? Con Expo, una actualización remota reemplaza el código JavaScript de las apps ya instaladas sin un build nuevo. Es la vía que uso para mis correcciones. No cubre ni el código nativo, ni los permisos, ni las dependencias nativas: para eso hace falta un build y una revisión. Y su contenido debe mantenerse dentro de lo que Apple aprobó, como recuerda la presentación de EAS Update: una actualización remota no cambia el propósito de la app. La guía sobre el despliegue progresivo de una actualización iOS detalla qué pasa por dónde.
¿La espera es anormal? Apple dice que en general revisa al menos el 50 % de los envíos en menos de 24 horas y el 90 % en menos de 48 horas. Si tu versión lleva un día en espera de revisión, estás dentro de lo normal del plazo de aprobación del App Store. La página de seguimiento de un envío recuerda también qué alarga una revisión: primera app sin historial, documentos por verificar, tema regulado.
¿El envío está completo? Una revisión acelerada sobre un envío incompleto no acelera nada. Apple advierte que un envío incompleto retrasa la revisión o fracasa. Cuenta de demo, notas, documentos: todo tiene que estar antes del formulario.
Y sobre todo, no retires tu versión para volver a enviarla. Una versión retirada sale de la fila y empieza de cero. Si Apple te hace una pregunta durante la revisión, responde en App Store Connect en lugar de reenviar, como explica la guía sobre responder a App Review en el Resolution Center.
Si Apple rechaza la aceleración
Conservas tu lugar en la fila: un rechazo de la aceleración no cambia nada de la revisión en curso. Para no volver a pasar por esto:
- Programa tus lanzamientos. Para un evento, Apple recomienda elegir la publicación programada en App Store Connect: la versión se revisa con antelación y sale en la fecha que quieras. La opción de publicación de una versión se configura en la página de la versión, en la sección App Store Version Release.
- Envía con tiempo. Una versión lista una semana antes del evento deja margen para una revisión normal, e incluso para corregir un rechazo.
- Ten un canal sin revisión para el JavaScript. Con Expo, es lo que convierte un bug crítico en una corrección de unos minutos.
Mis plantillas de notas para el revisor, mi checklist antes del envío y las respuestas a los rechazos más frecuentes están reunidas en el Review Kit. Y si quieres saber qué le falta a tu envío antes de mandarlo, el diagnóstico gratuito te lo dice y te envía mi checklist contra rechazos de Apple. Todos los pasos de la publicación están en publicar una aplicación en el App Store.
Preguntas frecuentes
¿Cuánto tarda una revisión acelerada del App Store?
Apple no da ningún plazo. Indica que estudia cada solicitud y acelera la revisión según su disponibilidad y la demanda del momento. Una solicitud aceptada hace que la versión pase a In Review antes de su turno, sin promesa de hora.
¿Se puede pedir una revisión acelerada para una primera app?
Nada lo prohíbe, pero Apple reserva la aceleración para urgencias reales y menciona dos ejemplos: un bug crítico en una versión ya publicada o un lanzamiento ligado a un evento con fecha. Una primera publicación retrasada respecto a tu planificación no entra, en mi opinión, en ninguno de los dos.
¿Cuántas veces se puede pedir una revisión acelerada?
Apple no publica un número. Pide reservar las solicitudes para urgencias reales. En mi opinión, cada solicitud sin motivo real le resta credibilidad a la siguiente: guárdala para un bug que afecte a tus usuarios.
¿Hay que retirar el envío antes de pedir la aceleración?
No, es al revés. Solo se puede acelerar un envío ya hecho, y una versión retirada pierde su lugar en la fila. Envía, llena las Notes y luego manda el formulario.
¿Dónde está el formulario de revisión acelerada?
En el sitio para desarrolladores de Apple, tras iniciar sesión en tu cuenta: la página de ayuda sobre la revisión acelerada lleva a él con el enlace Request an Expedited App Review. Ahí eliges la app y la plataforma.
¿Una revisión acelerada garantiza que la app será aprobada?
No. Solo cambia la posición en la fila. La versión debe cumplir las App Review Guidelines como cualquier otra, y un rechazo sigue siendo posible.
¿Se puede corregir un bug sin pasar por App Review?
Con Expo o React Native, una actualización remota reemplaza el código JavaScript sin build nuevo ni revisión. El código nativo, los permisos y las dependencias nativas siempre requieren un build enviado a Apple.

