Cómo publicar una app en la App Store

Publicar requiere cuatro cosas en este orden: una cuenta de Apple Developer de pago por 99 USD al año, un contrato firmado, un registro de app en App Store Connect y un build asociado. Apple lo revisa después, y resuelve el 90 % de los envíos en menos de 24 horas.

La mayoría de primeros envíos no fallan por el código. Fallan porque se saltó algo de esa lista.

Qué necesitas antes de poder enviar nada

Paso	Detalle
Apple Developer Program	99 USD por año de membresía. Los particulares necesitan su nombre legal real, no un apodo, y una dirección física. Nada de apartados de correos.
Número D-U-N-S	Solo organizaciones. Gratuito vía Dun & Bradstreet, hasta 5 días hábiles para emitirse, y hasta 2 más para que Apple lo reciba.
Contratos	Firma el Account Holder. Vender cualquier cosa, compras dentro de la app incluidas, exige el Paid Apps Agreement más datos fiscales y bancarios.
Bundle ID	Registrado en Certificates, Identifiers & Profiles. Explícito para una sola app.
Registro de app	Creado en App Store Connect antes de tu primera subida. Xcode se ofrece a crearlo por ti.
Build	Subido y con el procesado terminado. Apple te envía un correo cuando está listo.

El orden es el de la propia Apple: firmar el contrato e introducir datos fiscales y bancarios, añadir usuarios y roles, añadir la app y subir un build, probar y enviar, y luego vigilar.

Si eres una organización, lanza primero la solicitud del D-U-N-S. Es el único paso de la lista con una cola que no controlas, y puede comerse una semana antes de que hayas escrito una línea de texto de tienda.

Qué hay que rellenar

Obligatorio: nombre de la app, categoría principal, declaración de derechos de contenido, clasificación por edad, número de versión, build. Opcional pero recomendable: subtítulo, texto promocional, URL de soporte, categoría secundaria.

Dos cosas que se olvidan.

La URL de la política de privacidad. Las propias páginas de Apple no se ponen de acuerdo sobre si es técnicamente obligatoria, pero la guía 5.1.1 dice que toda app debe incluir un enlace a su política de privacidad, y tiene que ser accesible también desde dentro de la app, no solo desde tu ficha. Trátala como obligatoria.

Los datos de App Privacy. Declaras qué datos recoge tu app y qué recogen tus socios externos. Esa segunda mitad es donde cae la gente: estás respondiendo por los SDK que integraste, no solo por tu propio código. Desde mayo de 2024, las apps que no describen su uso de las required-reason API en un privacy manifest las rechaza App Store Connect antes de que las vea una persona.

Las capturas necesitan un tamaño para iPhone y otro para iPad. La guía de capturas tiene las medidas y las reglas de contenido.

El botón que no envía tu app

En App Store Connect pulsas Add for Review. El estado cambia a Ready for Review.

Tu app no se ha enviado. Ready for Review significa que has declarado una intención. El envío llega a Apple solo cuando abres el borrador de envío y pulsas Submit for Review, momento en el que el estado pasa a In Review.

Hay quien pierde días con esto. Mira el estado, no el botón que pulsaste por última vez.

La guía que tumba más primeros envíos

Apple publica la cifra: más del 40 % de las incidencias sin resolver tienen que ver con la guía 2.1, App Completeness.

Esa guía no va de calidad de código. Va de si la persona que revisa puede usar tu app de verdad. En palabras de la propia Apple: los envíos deben ser versiones finales, con todos los metadatos necesarios y URL funcionales, y el texto de relleno y las webs vacías deben limpiarse antes de enviar.

Lo concreto que pilla a la gente:

Sin cuenta de demostración. Si tu app tiene login, tienes que aportar credenciales que funcionen, y Apple añade un paréntesis que revela con qué frecuencia falla esto: enciende tu servicio de backend. Una cuenta demo que apunta a un servidor apagado es lo mismo que no tener cuenta demo.

Notas de revisión genéricas. La guía 2.3.1 exige describir las funciones nuevas con concreción en el campo Notes for Review, y dice sin rodeos que las descripciones genéricas se rechazan.

Compras dentro de la app que no están activas. Tienen que estar completas, visibles para quien revisa y operativas.

Sin borrado de cuenta. Guía 5.1.1(v): si la gente puede crear una cuenta en tu app, tiene que poder borrarla en tu app. No escribiéndote un correo.

TestFlight, y si lo necesitas

No lo necesitas. Apple recomienda probar en beta, pero no lo exige.

Si lo usas: hasta 100 testers internos y hasta 10.000 externos. Las pruebas internas no pasan revisión. Las externas sí. El primer build que añades a un grupo externo pasa por App Review, y los builds siguientes puede que no necesiten revisión completa. Los builds caducan a los 90 días.

Conviene saber lo de esa primera revisión externa antes de prometerle una beta a nadie. Es una cola aparte, con sus propios estados, y Apple no publica tiempos para ella.

Elegir cómo se publica

Tres opciones, con las etiquetas de Apple: publicar esta versión manualmente, publicarla automáticamente, o publicarla automáticamente tras la revisión no antes de una fecha que tú eliges.

La publicación manual deja la app en Pending Developer Release. Apple envía un recordatorio por correo si lleva ahí más de 30 días. Después de pulsar publicar, puede tardar hasta 24 horas en aparecer en la tienda.

El lanzamiento por fases es para actualizaciones, no para apps nuevas. Se despliega a lo largo de siete días al 1 %, 2 %, 5 %, 10 %, 20 %, 50 % y luego 100 %, y solo gobierna las actualizaciones automáticas. Cualquiera puede descargar la versión nueva manualmente durante todo ese tiempo. Puedes pausar hasta 30 días en total y reanudar donde lo dejaste, o terminarlo antes con Release to All Users.

Para un primer lanzamiento, la opción útil es la programada: elige una fecha lo bastante lejana como para que la revisión no te la haga fallar, y adelántala si sales pronto.

Cuatro cosas que han cambiado hace poco

El SDK de Xcode 26 es el mínimo. Desde el 28 de abril de 2026, las subidas tienen que estar compiladas con Xcode 26 y el SDK de iOS 26 o posterior.

Las clasificaciones por edad se rehicieron. Los niveles ahora son 4+, 9+, 13+, 16+ y 18+, y todo migró el 31 de enero de 2026. El cuestionario pregunta ahora por controles dentro de la app, temas médicos y de bienestar, y funcionalidad de asistente de IA o chatbot.

Las preguntas sobre redes sociales pasaron a ser obligatorias en septiembre de 2026. Añaden un descriptor de Redes Sociales a tu página de producto y alimentan los límites de tiempo parentales. Si desactivas funciones sociales para menores de 13 años, tu app no cuenta en ese límite.

El estatus de comerciante en la UE aplica aunque no distribuyas allí. Aun así tienes que declararlo. Si sí distribuyes, tu dirección verificada, teléfono y correo se publican de forma pública en tu página de producto en los 27 territorios. Los particulares sí pueden dar un apartado de correos para esto.

Por contraste, Google Play

Veinticinco dólares, una vez, no al año. Verificación de identidad con documento oficial y una tarjeta de crédito al mismo nombre legal.

La trampa es más reciente: las cuentas personales de Play Console creadas después del 13 de noviembre de 2023 tienen que hacer una prueba cerrada con al menos 12 testers apuntados de forma continua durante 14 días antes de poder solicitar acceso a producción. Esa solicitud se revisa a su vez, normalmente en siete días.

Así que la forma está invertida. Apple cuesta más al año y puede tenerte publicado en un día. Play cuesta menos y puede retener tres semanas a alguien que publica en solitario por primera vez, antes incluso de que la app sea revisable.

Qué hace Uprate con esto

El agente de envíos revisa tus envíos de Apple y Google en busca de bloqueos y vuelve con el campo exacto y la solución. Antes de que envíe, no después de que Apple te lo devuelva.

Nada se publica hasta que tú lo apruebas.