Tu fecha de lanzamiento está en manos de un revisor que nunca ha visto tu producto. Puede devolver toda la compilación por una contraseña de demostración caducada o un formulario de clasificación por edad sin responder. Los requisitos de la App Store son en su mayoría administrativos, y ese trabajo es lo primero que se descuida cuando un lanzamiento se aprieta. Los problemas fáciles son los que nadie comprueba. Detectarlos antes de enviar es para lo que sirven las pruebas de cumplimiento de la App Store.
La propia página de App Review de Apple dice que más del 40% de los problemas sin resolver se remontan a la directriz 2.1, App Completeness. La categoría cubre bloqueos, contenido de marcador de posición, y cualquier cosa dejada en blanco. Así que tu app puede funcionar perfectamente y aun así fallar la revisión. La aprobación empieza con una lista corta que no tiene nada que ver con lo buena que sea tu app.
Necesitas una membresía activa del Apple Developer Program y un registro completo en App Store Connect. La compilación en sí tiene que estar compilada con Xcode 26 y el SDK de iOS 26. Apple también pide una cuenta de demostración funcional, respuestas actuales de clasificación por edad, y una política de privacidad que coincida con lo que tu app recopila.
Cada elemento de esa lista es fácil de confirmar, pero cualquiera de ellos puede detener un lanzamiento. Este artículo cubre qué comprobar antes de enviar, qué cuesta un rechazo en tiempo de calendario, y quién debería ser dueño de cada decisión.
Requisitos de la App Store que Debes Superar Antes de Enviar
Dos requisitos de envío de la App Store de Apple cambiaron en 2026, y ninguno tiene que ver con pruebas. Sin embargo, siguen atrapando a equipos que envían su primera actualización del año. Uno hizo obligatorias las respuestas a las preguntas revisadas de clasificación por edad de Apple el 31 de enero. El otro exige que compiles cada binario con Xcode 26 y el SDK de iOS 26. Entró en vigor el 28 de abril y ahora se aplica a todas las apps.
Ambos plazos están en la página de próximos requisitos, y perder cualquiera de los dos te detiene en la etapa de subida, antes de que empiece la revisión. Confirmar cada uno toma minutos, pero nadie programa tiempo para algo que no es una función.
El tercer elemento es el cumplimiento de exportación, y tampoco tiene nada que ver con las pruebas. La ley comercial estadounidense cubre el software que usa cifrado, así que Apple tiene que preguntar si el tuyo lo hace. La verdad es que casi todas las apps lo hacen, porque cualquier conexión por HTTPS cuenta. Puedes responder esa pregunta a mano en cada envío. La alternativa es resolverlo una vez dentro del archivo de configuración Info.plist de la app, tras lo cual Apple deja de preguntar.
Esos tres forman parte de una lista más larga. La tabla de abajo muestra los requisitos de la App Store que bloquean la subida, junto con quién en tu empresa posee cada uno realmente.
Membresía del Developer Program
developer.apple.com
Finanzas u operaciones
Inscripción activa, renovada más allá de tu fecha de lanzamiento
Registro de la app
App Store Connect
Producto
Nombre, categoría, URL de soporte, y URL de política de privacidad todos completados
Cadena de herramientas de compilación
Xcode
Ingeniería
Compilado con Xcode 26 y el SDK de iOS 26
Respuestas de clasificación por edad
App Store Connect
Producto con legal
Cuestionario actual completado
Declaraciones de privacidad
App Store Connect
Producto con legal
Cada tipo de dato recopilado está declarado, SDKs de terceros incluidos
Cumplimiento de exportación
Info.plist o App Store Connect
Ingeniería
Pregunta de cifrado respondida, o resuelta una vez en la compilación
Capturas de pantalla y ficha
App Store Connect
Marketing
Los tamaños más grandes de iPhone y iPad suministrados, mostrando funciones que existen
Estatus de comerciante en la UE
App Store Connect
Legal o finanzas
Verificado, o la app no puede distribuirse en la UE
Esa última fila es una parada obligatoria si vendes en la Unión Europea. La Ley de Servicios Digitales obliga a Apple a publicar un nombre comercial y dirección verificados para cada desarrollador que lista una app allí. Por lo tanto, hasta que aportes el tuyo y Apple lo verifique, tu app se retira por completo de la App Store de la UE. Legal y finanzas son dueños de esto, no ingeniería, así que empieza pronto. Una brecha así pertenece a las pruebas de cumplimiento de software en lugar del ciclo de QA móvil.
Los requisitos de la App Store de Apple van más allá de esta tabla, aunque solo las filas de arriba realmente bloquean la subida. Si estás enviando la compilación de Android en la misma ventana, nuestra guía para superar la revisión de Google Play cubre el terreno equivalente.
Las Seis Preguntas que Responder Antes de Enviar
Superar esos requisitos solo te mete en la cola. Luego todo depende de lo que un revisor pueda realmente hacer con tu compilación. Busca una lista de verificación de envío a la App Store y encontrarás una escrita para ingenieros. Enumera todo lo que un desarrollador hace clic y no le dice nada a un dueño de negocio sobre si el lanzamiento es seguro. En cambio, la versión de abajo está organizada en torno a lo que deberías poder confirmar, en voz alta, en una reunión de lanzamiento.
¿Puede un Desconocido Entrar en Tu App sin Tu Ayuda?
Un revisor tiene que alcanzar cada función que envías, y empieza sin nada más que tu compilación. Por eso la directriz 2.1 de Apple pide detalles de cuenta de demostración y un backend en vivo siempre que tu app incluya un inicio de sesión. La mayoría de los equipos aportan ambos, pero pocos confirman que las credenciales todavía funcionan la mañana en que un revisor las abre.
Verifica tres cosas:
- La cuenta de demostración no caduca ni se bloquea tras intentos fallidos.
- El backend al que apunta está funcionando, no solo desplegado.
- Las notas para la revisión describen cada función nueva específicamente, ya que Apple rechaza redacción genérica.
Si reglas legales o de seguridad te impiden entregar una cuenta en vivo, Apple acepta en su lugar un modo de demostración incorporado, con aprobación previa. Obtener esa aprobación toma tiempo que debes presupuestar.
¿Es la Compilación que Envías la Compilación que Probaste?
En muchos casos, las compilaciones de lanzamiento divergen de lo que probaste de formas pequeñas y costosas:
- Un feature flag dejado activado
- Un endpoint de staging codificado en un archivo de configuración
- Una compra dentro de la app que todavía apunta al sandbox
Ninguno de esos aparece en el uso diario, porque tu equipo ejecuta una compilación distinta. La confirmación es una sola frase: alguien instaló el binario exacto en un dispositivo limpio y recorrió la ruta principal de principio a fin. Conseguir eso es por lo que las pruebas de aplicaciones móviles deberían ejecutarse contra el candidato de lanzamiento en lugar de una rama anterior. Ese es también el lugar más barato para detectar problemas de estabilidad.
¿Promete Tu Ficha Algo que la Compilación No Hace?
Marketing escribe la ficha de la tienda semanas antes de que ingeniería termine la compilación, extrayendo capturas de pantalla de diseños y descripciones de la hoja de ruta. Luego una función se retrasa, y nadie actualiza el texto.
La directriz 2.3 de Apple trata ese desajuste como metadatos inexactos, así que lee tu propia ficha contra la compilación que estás a punto de enviar. Cada afirmación necesita una función correspondiente que un revisor pueda alcanzar sin instrucciones.
¿Has Respondido a Cada Pregunta que Apple Hace Ahora?
Los formularios en App Store Connect no son una formalidad, y cambian más a menudo de lo que los equipos esperan. Las declaraciones de privacidad en particular tienen que coincidir con lo que tu app realmente recopila, incluyendo datos extraídos por SDKs de terceros que tú no escribiste. Nadie en tu equipo puede saber qué transmiten esas librerías, por lo que esto necesita comprobación en lugar de memoria.
La inteligencia artificial (IA) es el área más nueva que Apple ha endurecido. La directriz 5.1.2(i) exige divulgar cualquier dato personal que envíes a una IA de terceros. También necesitas permiso explícito antes de que se mueva, lo cual cubrimos en las directrices de Apple sobre el uso compartido de datos de IA.
¿Pueden los Usuarios Eliminar, Restaurar, y Denunciar Dentro de Tu App?
Algunos requisitos tratan sobre lo que hace tu app, no lo que dices de ella. Cualquier producto que admita registro también debe ofrecer eliminación de cuenta dentro de la app. Las compras tienen que poder restaurarse, y cada una debe ser visible para el revisor. Las apps que permiten a los usuarios publicar contenido deben dar a todos la opción de denunciar una publicación y bloquear a su autor.
Un revisor probará cada uno de estos, así que pruébalos de la misma forma en la compilación que se envía. La eliminación tiene la mayoría de los casos límite, así que presupuesta tiempo para ella.
¿Quién Es Dueño de la Respuesta si Vuelve?
Esta es la pregunta que los dueños de negocio se saltan, y es la que más tiempo de calendario cuesta. Un rechazo llega al Centro de Resolución de Apple, el hilo de mensajes adjunto a tu envío, con un número de directriz y una breve explicación. Luego alguien tiene que leerlo, decidir si necesita una edición de metadatos o una nueva compilación, y responder.
Nombra a esa persona antes de enviar, añade un suplente, y comprueba que ninguno esté de vacaciones durante la ventana de revisión. Cada hora que esa respuesta permanece sin leer retrasa tu fecha de lanzamiento.
Lo que Cuesta a Tu Lanzamiento un Envío Fallido
Un rechazo no es un ticket de ingeniería, sino más bien un evento de negocio con una factura adjunta. La mayor parte del costo recae en personas que nunca leen las directrices. Apple aprueba el 90% de los envíos en menos de 24 horas, así que una compilación limpia se mueve rápido. Sin embargo, la segunda revisión solo empieza una vez que tu corrección está lista, y esa espera es lo que te cuesta días. La tabla de abajo muestra qué se retrasa y quién lo absorbe.
La fecha de lanzamiento
Producto y liderazgo
Replanificación, más lo que estuviera reservado alrededor
Una campaña de adquisición pagada
Marketing
Comisiones de reprogramación, o dar por perdido el gasto
Una función prometida a un cliente
Ventas y soporte
Una conversación que nadie planeó
El siguiente lanzamiento en cola
Ingeniería
Retraso, porque el equipo está en remediación en su lugar
Otro paso por revisión
Todos
24 horas como mínimo, una vez lista la nueva compilación
Atención ejecutiva
Liderazgo
Horas sacadas de lo que el lanzamiento debía habilitar
Cuánto dure eso depende de qué se rompió. Una corrección de captura de pantalla o descripción es una tarde de trabajo, luego una revisión fresca. Los cambios de código necesitan primero pruebas de regresión, que es cómo un pequeño error se convierte en una semana de retraso.
La forma más barata de acortar ese ciclo es saber qué suele activarlo. Enumeramos las causas comunes en motivos de rechazo en la App Store, el artículo que abrir si tu envío ya ha vuelto.
Dónde Suelen Fallar las Comprobaciones Previas al Envío
Los equipos se equivocan de dos formas opuestas:
- La primera es tratar la lista de verificación de envío de apps a iOS como un evento único. La ejecutan a fondo antes del lanzamiento inicial, luego se la saltan en las actualizaciones, que es exactamente cuando la plataforma se ha movido bajo ellos. Las reglas de Apple cambiaron dos veces solo en los primeros 4 meses de 2026.
- La segunda es sobreprobar la capa equivocada. La accesibilidad es el ejemplo más claro, ya que rara vez bloquea una revisión de la App Store. Los equipos por lo tanto la ignoran o la tratan como una puerta de envío, y ambas lecturas fallan el punto. La presión real viene de la Ley Europea de Accesibilidad y los usuarios que pierdes silenciosamente. Eso pone las pruebas de accesibilidad de aplicaciones móviles en el plan de lanzamiento en lugar del formulario de envío.
Comprobar los requisitos de la App Store temprano toma una hora, más un recordatorio de calendario para los más lentos. Encontrar las mismas brechas durante la revisión puede costarte la fecha de lanzamiento.
Cómo Verifica QAwerk una Compilación de iOS Antes del Envío
Probamos tu candidato de lanzamiento real, no una descripción de él. Eso significa ejecutar la lista de verificación de revisión de la App Store contra el binario exacto, instalado en dispositivos reales. Nuestros ingenieros completan los flujos de registro, compra, restauración, y eliminación, luego comparan tu ficha con lo que la compilación realmente hace.
Recibes un informe escrito de lo que podría fallar y por qué, con cada elemento vinculado a la directriz que toca. Hicimos exactamente eso para BeFamily, ejecutando más de 500 casos de prueba en 9 dispositivos antes del lanzamiento. La app no ha tenido problemas importantes en producción desde entonces. Tráenos mientras la fecha de envío todavía pueda moverse, y hay margen para arreglar lo que encontremos sin un sprint de emergencia.
QAwerk lleva probando lanzamientos móviles desde 2015, y nos conectamos a la etapa en la que esté tu proyecto. Tu fecha de lanzamiento es lo único que no puedes recuperar, así que habla con nosotros y encontremos juntos lo que Apple podría señalar.
Preguntas Frecuentes
¿Cuánto tarda en arreglarse un envío rechazado en la App Store?
Depende de qué requisitos de la App Store no cumpliste. Los problemas de metadatos como una captura de pantalla o descripción toman unas horas, luego una nueva revisión que Apple suele devolver en un día. Las correcciones de código tardan más, porque la app reconstruida necesita primero pruebas de regresión. Planifica para el caso más lento, ya que no sabrás cuál enfrentas hasta que recibas respuesta.
¿Cuánto dura la revisión de la App Store?
Apple revisa el 90% de lo que recibe en menos de 24 horas. Los primeros envíos de una cuenta de desarrollador nueva a menudo tardan más, al igual que las apps en categorías sensibles. Presupuesta de 1 a 3 días en lugar de aprobación el mismo día, y nunca programes un evento de lanzamiento alrededor de un plazo de 24 horas.
¿Necesitas una cuenta de demostración si tu app no tiene inicio de sesión?
No necesitas una, porque Apple pide credenciales de demostración solo cuando tu app incluye un inicio de sesión. El campo Notas para la Revisión sigue importando, sin embargo, describiendo cualquier función que no sea obvia desde la interfaz, ya que la redacción genérica se rechaza. Sin credenciales, quien recoja tu envío simplemente abre el producto y lo recorre sin asistencia.
¿Puedes pedirle a Apple que revise tu app más rápido?
Puedes, aunque solo dos situaciones califican para una solicitud de revisión acelerada. La primera es un error crítico que afecta a usuarios en producción, y la segunda es una app ligada a una fecha pública fija. Aporta pasos de reproducción del defecto, o el nombre y la fecha del evento. La aprobación se decide individualmente y nunca está garantizada, así que no planifiques en torno a ella.
¿Deberías apelar un rechazo o corregir y reenviar?
Corrige y reenvía cuando Apple tiene razón, que es la mayoría de las veces. Desafíalo con el App Review Board cuando creas que la directriz se aplicó incorrectamente. Apple permite una apelación por envío que no pasó, y espera que respondas primero a cualquier solicitud de más información. Impugnar una infracción genuina solo te cuesta días.
Mira cómo una app de iOS corrigió errores críticos, bloqueos, y brechas de UX antes del envío, y se lanzó sin retrabajos costosos
