wandres.dev
DE LA IDEA A LA APP STORE · el panorama completo

Publicar: de Xcode a la App Store

El último tramo: firmas, TestFlight, envío a revisión y automatización con CI. El recorrido completo para poner tu app en manos de la gente.

⏱ 15 min

Has construido la app. Ahora falta lo que muchos tutoriales omiten: llevarla a la App Store. Es un proceso con pasos concretos —cuenta de desarrollador, firmas, revisión— que la primera vez intimida y luego se vuelve rutina. Este es el mapa completo.

🎯 Al terminar esta lección sabrás
  • El programa de desarrollador y el bundle ID.
  • Firmas y provisioning (y por qué “automático”).
  • TestFlight para probar con gente real.
  • Enviar a revisión y automatizar con CI.

El recorrido de publicación

1
Apple Developer Program

Necesitas una cuenta del Apple Developer Program (de pago anual) para publicar en la App Store. Con ella accedes a App Store Connect, TestFlight y las capacidades como CloudKit o notificaciones.

2
Bundle ID e identidad de la app

Cada app tiene un bundle identifier único (p. ej. com.tunombre.miapp). Lo registras y creas la ficha de la app en App Store Connect (nombre, categoría, capturas, descripción).

3
Firmas y provisioning

iOS solo ejecuta apps firmadas. Xcode ofrece firma automática: activa “Automatically manage signing” y Xcode gestiona certificados y perfiles por ti. La primera vez que esto “solo funciona” es un alivio; entender que hay certificados detrás ayuda cuando algo falla.

4
Archivar y subir

En Xcode: Product ▸ Archive crea una compilación de distribución. Desde el Organizer, la subes a App Store Connect. Xcode la valida y la procesa.

5
TestFlight: probar con gente real

Antes de publicar, distribuye la build por TestFlight a testers (internos o externos). Reciben la app, la prueban y te mandan feedback y reportes de fallos. Es tu red antes del gran público.

6
Enviar a revisión

Cuando estés listo, envías la versión a revisión de Apple. Un revisor comprueba que cumple las directrices (privacidad, contenido, funcionalidad). Puede aprobarse en horas o pedir cambios. Al aprobarse, publicas — de inmediato o en la fecha que elijas.

⚠️
Las directrices de revisión son reales

El rechazo más común de los novatos no es técnico: es incumplir las App Review Guidelines. Privacidad mal declarada, funcionalidad incompleta, uso indebido de APIs, faltar la política de privacidad… Léelas antes de enviar, no después del rechazo. Y sé honesto en la ficha de privacidad (“nutrition labels”): declara qué datos recoges de verdad. Apple lo verifica.

Automatizar con CI

Hacer todo esto a mano en cada versión cansa. La integración continua lo automatiza: compilar, probar y distribuir en cada cambio.

☁️

Xcode Cloud

El CI de Apple, integrado en Xcode: compila, corre tus tests (Swift Testing) y distribuye a TestFlight automáticamente al hacer push.

🛠️

fastlane

La herramienta clásica de terceros: automatiza firmas, capturas, subidas y publicación con scripts. Muy usada en equipos.

Publicar es una habilidad, no un misterio

La primera publicación se siente como escalar un muro: cuentas, certificados, perfiles, revisión… Pero es un camino trillado por millones de apps, con pasos deterministas. Hazlo una vez con calma, apunta cada paso, y la segunda será media hora. Cuando le sumas CI (Xcode Cloud o fastlane), publicar una actualización pasa a ser casi un git push. Dominar este tramo final es lo que convierte “sé programar apps” en “he publicado apps” — y esa diferencia es la que de verdad importa. Enhorabuena: acabas de recorrer el camino completo, de print("Hola") a la App Store.

⚔️ Cierra el círculo
  1. Repasa qué necesitas del Apple Developer Program para publicar.
  2. En un proyecto, activa “Automatically manage signing” y elige tu equipo.
  3. Haz Product ▸ Archive y explora el Organizer (aunque no subas nada aún).
  4. Lee por encima las App Review Guidelines y la sección de privacidad.
  5. Investiga Xcode Cloud o fastlane para tu flujo de CI.