Checklist de envío al App Store (2026): del build en Xcode 26 a Submit for Review

Un checklist de envío al App Store es la lista de cosas que tienen que estar listas a la vez antes de enviar: un build que funcione, una ficha precisa, respuestas de privacidad veraces y suficiente contexto para que un revisor pueda usar tu app. Un build que compila sin errores no basta. Las seis secciones siguientes siguen el orden en que App Store Connect te las pide, y cada una empieza con una respuesta breve que puedes aplicar.

¿Qué necesita un envío al App Store antes de pulsar Submit?

Un envío al App Store necesita un build procesado adjunto a la versión, los metadatos obligatorios de la versión, capturas de pantalla, una política de privacidad, los datos de contacto para App Review y, si la app tiene inicio de sesión, credenciales demo que funcionen. La propia lista "Before You Submit" de Apple en las App Review Guidelines añade dos puntos más: "Activa los servicios de backend para que estén operativos y accesibles durante la revisión" y explica en las notas de revisión las funciones que no sean evidentes.

¿Qué ajustes de la cuenta y del registro de la app deben estar listos?

Necesitas una membresía activa de Apple Developer, un registro de app cuyo bundle ID coincida con tu build firmado y a alguien del equipo con el rol de Account Holder, Admin o App Manager. Esos son los roles que la página Submit an app de Apple exige para enviar.

Al crear el registro, elige el nombre, el idioma principal y el SKU. El SKU es interno y los clientes nunca lo ven. Si vendes una app de pago o compras dentro de la app, completa primero los acuerdos de pago, los datos fiscales y los bancarios. Un acuerdo sin firmar puede frenar un lanzamiento comercial aunque el build esté bien.

¿Qué requisitos de build se aplican a las subidas al App Store en 2026?

A octubre de 2026, la página de próximos requisitos de Apple dice que "las apps subidas a App Store Connect deben compilarse con Xcode 26 o posterior usando un SDK para iOS 26, iPadOS 26, tvOS 26, visionOS 26 o watchOS 26" (desde el 28 de abril de 2026). También indica que las apps de iOS y iPadOS "deben tener como objetivo iOS 13 o posterior" (desde el 9 de septiembre de 2026).

• Incrementa el número de build en cada subida y asegúrate de que el número de versión coincide con la versión que quieres publicar.
• Actualiza la imagen de Xcode en tu CI (Codemagic, Expo EAS, GitHub Actions, etc.), además de en tu propia máquina.
• Tras el procesamiento, responde a cualquier pregunta de cumplimiento de exportación y adjunta el build procesado a la versión.
• Instala el build de TestFlight en un dispositivo físico. Prueba el onboarding, el inicio de sesión, los estados sin conexión, las compras y la restauración de compras. Que funcione en el simulador no demuestra que el build distribuido funcione.
• Lee el correo que App Store Connect envía tras la subida. Los avisos ITMS sobre privacy manifests o versiones de SDK se convierten en bloqueos si los ignoras.

La directriz 2.1(a) es tajante sobre lo que ocurre en caso contrario: "Rechazaremos los paquetes de app y binarios incompletos que fallen o presenten problemas técnicos evidentes." Elimina las pantallas de relleno, los menús de depuración y los enlaces rotos antes de archivar. Nuestro plan de pruebas del build de release para la 2.1 repasa estas comprobaciones en detalle.

¿Qué capturas y metadatos exige App Store Connect?

A octubre de 2026, las especificaciones de capturas de Apple exigen al menos una captura para "iPhone con Dynamic Island (pantalla mediana)", por ejemplo de 1206 × 2622 o 1179 × 2556 en vertical. Las apps que funcionan en iPad también necesitan al menos una captura de iPad de 13 pulgadas, como 2064 × 2752 o 2048 × 2732.

"Puedes subir hasta 10 capturas por tamaño de dispositivo en formato .jpeg, .jpg o .png", y "las imágenes no pueden incluir canales alfa ni transparencias." Si tu interfaz es igual en todos los tamaños, sube solo la resolución obligatoria más alta y App Store Connect la reduce. La directriz 2.3.3 dice que las capturas "deben mostrar la app en uso, y no solo la imagen del título, la página de inicio de sesión o la pantalla de bienvenida."

• Escribe una descripción que diga para quién es la app y qué puede hacer alguien en su primera sesión.
• Mantén el nombre, el subtítulo y las palabras clave relevantes. No repitas palabras clave ni uses nombres de la competencia.
• Asegúrate de que la URL de soporte y la de la política de privacidad cargan sin necesidad de iniciar sesión.
• Responde al cuestionario de clasificación por edad según lo que la app realmente contiene y permite hacer.
• Muestra el build actual en las capturas, incluido cualquier paywall con el que se vaya a encontrar el usuario.

¿Cómo haces que las respuestas de privacidad coincidan con la app?

Para que las respuestas de privacidad coincidan con la app, haz una lista de cada SDK que incluyes y de los datos que recopila, y usa esa lista para rellenar App Privacy, redactar la política de privacidad y configurar el comportamiento dentro de la app. La directriz 2.3 dice que tus metadatos, "incluida la información de privacidad", deben reflejar la app con precisión.

La directriz 5.1.1(i) establece: "Todas las apps deben incluir un enlace a su política de privacidad en el campo de metadatos de App Store Connect y dentro de la app, de forma fácilmente accesible." La directriz 5.1.1(v) añade: "Si tu app permite crear cuentas, también debes ofrecer la eliminación de la cuenta dentro de la app." Los SDK de analítica, informes de fallos, publicidad e inicio de sesión suelen cambiar tus respuestas, así que revísalos con nuestra auditoría de SDK para las etiquetas de privacidad. Comprueba también que tu app y cada SDK incluido traen un privacy manifest PrivacyInfo.xcprivacy que cubra las required-reason APIs que usen.

¿Qué debe incluir App Review Information?

App Review Information debe incluir un contacto que vaya a responder, credenciales demo que funcionen y no caduquen, y notas que lleven al revisor directamente a tus funciones principales. La directriz 2.1(a) pide "incluir los datos de una cuenta demo (¡y activar tu servicio de backend!) si tu app incluye inicio de sesión"; un modo demo integrado en lugar de una cuenta necesita la aprobación previa de Apple.

Aquí tienes un ejemplo práctico de notas de revisión: "Inicia sesión con la cuenta de revisión proporcionada. Abre Library, elige el proyecto de ejemplo y toca Export. La cuenta tiene todas las funciones premium desbloqueadas. Las funciones de ubicación usan una ciudad simulada, así que no hace falta desplazarse." No mandes a los revisores a una cuenta vacía, a un código de un solo uso que caduca ni a un flujo que solo funciona si estás conectado para aprobarlo. Nuestra guía para configurar la cuenta demo muestra cómo crear un acceso para el revisor que no falle.

¿Cómo se envía una app a revisión en App Store Connect?

Para enviar una app a revisión, adjunta el build a la versión, haz clic en Add for Review y después en Submit for Review. Add for Review por sí solo no envía nada a Apple. La secuencia siguiente sigue la página Submit an app de Apple a octubre de 2026.

1. En Apps, selecciona la app y luego haz clic en la versión de la app en la barra lateral.
2. Desplázate hasta la sección Build y confirma que está adjunto el build correcto.
3. En la sección App Store Version Release, elige la publicación manual si quieres controlar el día del lanzamiento y haz clic en Save.
4. Haz clic en Add for Review y elige un borrador de envío existente o crea uno nuevo. El estado cambia a Ready for Review.
5. Haz clic en Submit for Review. Cuando empieza la revisión, el estado cambia a In Review.
6. Guarda una copia de los metadatos y notas enviados, y vigila el correo del contacto de revisión por si llegan preguntas.

Si el envío vuelve rechazado, lee el número de la directriz y la explicación del revisor antes de cambiar nada. Algunas correcciones son solo de metadatos. Otras requieren un build nuevo. Nuestra guía de rechazos del App Store explica cómo saber cuál es tu caso.

¿Qué les salió mal a otros desarrolladores al enviar?

En los dos casos públicos siguientes, la app le funcionaba a su desarrollador, y el problema solo apareció en el build subido o en la primera sesión del revisor.

Un desarrollador en el foro de Adalo recibió un rechazo por la directriz 2.1: "no pudimos iniciar sesión con las credenciales de la cuenta demo que proporcionaste." Las credenciales eran válidas, pero el primer toque en el botón de inicio de sesión no hacía nada y solo funcionaba el segundo, porque la navegación condicional se ejecutaba en el botón antes de que se registrara la sesión del usuario. Lo resolvió haciendo que el botón de inicio de sesión llevara a una pantalla de transición en blanco que contenía las acciones condicionales, y volvió a enviar la app.

Un desarrollador en el foro de JUCE recibió "ITMS-91053: Missing API declaration" tras una subida, con el aviso de que las nuevas subidas "deben incluir un array NSPrivacyAccessedAPITypes en el privacy manifest de tu app." Las categorías señaladas eran SystemBootTime y FileTimestamp, y otro usuario mencionó UserDefaults. La solución fue un archivo PrivacyInfo.xcprivacy con códigos de motivo aprobados, añadido como recurso de Xcode. La primera versión de un usuario omitía una clave de tipo, lo que provocó ITMS-91056 por manifest no válido hasta que lo corrigió.

Ambos desarrolladores solo habían probado en su propio entorno. Prueba el build que Apple recibe realmente con un inicio de sesión desde cero, y lee cada correo posterior a la subida, antes de pulsar Submit for Review. Si quieres que alguien más revise el paquete, consulta nuestros servicios de envío.