Publicar una app iOS en la App Store: paso a paso

Apps mobile · Por · Publicado el · Actualizado el · 9 min de lectura

Persona usando un portátil con código en la pantalla, smartphone conectado y taza de café al lado
Escena de desarrollo: código en el portátil, smartphone conectado y café. Foto: Christina Morillo / Pexels

Esta guía muestra, de extremo a extremo, cómo publicar una app iOS en la App Store. Verás los requisitos, la configuración del proyecto, la creación del registro en App Store Connect, la generación del build con Xcode o CI, el upload con Transporter o Fastlane, las pruebas en TestFlight y el envío para revisión. Sigue los pasos y evita rechazos comunes.

Requisitos previos y cuentas necesarias

Antes de publicar, asegúrate de cumplir los requisitos esenciales. Necesitas una cuenta activa en el Apple Developer Program y un Mac con Xcode instalado. También debes definir el identificador de la app y preparar los materiales obligatorios, como iconos, capturas de pantalla y la política de privacidad.

Usa este checklist para comenzar sin bloqueos.

  • Cuenta activa en el Apple Developer Program.
  • Mac con una versión de Xcode compatible con el SDK objetivo.
  • Acceso a App Store Connect con permisos para gestionar apps.
  • Bundle ID reservado y único.
  • Certificados y perfiles de aprovisionamiento de distribución iOS.
  • Versión de la app y número de build definidos.
  • URL de política de privacidad y sitio de soporte.
  • Iconos y capturas de pantalla en los tamaños exigidos.
  • Credenciales de prueba y datos ficticios, si la app requiere login.
  • Clave de API para App Store Connect (opcional, para automatización).
Requisito Para qué sirve
Apple Developer Program Firma de código y publicación en la App Store.
App Store Connect Registro de la app, metadatos y envíos.
Certificados y perfiles Firmar builds de distribución con validez.
Iconos y capturas de pantalla Componer la página de la app en la App Store.
Política de privacidad Transparencia sobre la recopilación y uso de datos.

Configurar el proyecto iOS (Bundle ID, versión y firma)

En Xcode, abre el proyecto y ajusta identificadores y versiones. El Bundle Identifier debe coincidir con el registrado en App Store Connect. En Signing & Capabilities, activa la firma automática o carga certificados y perfiles de aprovisionamiento.

Revisa el Info.plist. Para APIs que usan cámara, fotos, micrófono, ubicación o Bluetooth, incluye mensajes de uso. Sin ellos, la app será rechazada.

  • Actualiza CFBundleShortVersionString (versión) y CFBundleVersion (build).
  • Confirma que el Product Bundle Identifier es único y estable.
  • Añade entitlements y capabilities necesarios (por ejemplo: Push Notifications).
<!-- Exemplo de chaves no Info.plist para permissões -->
<key>NSCameraUsageDescription</key>
<string>Precisamos da câmera para ler QR Codes.</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>Usamos sua galeria para selecionar imagens do perfil.</string>
<key>NSLocationWhenInUseUsageDescription</key>
<string>Usamos sua localização para mostrar lojas próximas.</string>

Crear la app en App Store Connect y metadatos obligatorios

En App Store Connect, crea el registro de la app con nombre, plataforma, Bundle ID y SKU. Después, completa la información requerida para la ficha de la app.

Incluye descripción, palabras clave, categoría, clasificación por edad, política de privacidad y detalles sobre la recopilación de datos. Si usas anuncios, declara el uso del IDFA. Prepara notas de revisión y credenciales de prueba, si la app requiere login.

Si tu proceso de release tiene fallos recurrentes, una revisión del flujo ayuda a reducir riesgos. Mira ideas en auditoría de procesos de deploy y plan de corrección.

  • Nombre de la app e idioma principal definidos.
  • Bundle ID vinculado correctamente al registro.
  • Descripción clara y objetiva de la app.
  • Palabras clave coherentes para búsquedas.
  • Categoría principal y secundaria compatibles.
  • Clasificación por edad completada con precisión.
  • URL de soporte y política de privacidad válidas.
  • Detalles de recopilación de datos y rastreo informados.

Generar el build (Archive) con Xcode o pipeline de CI

Con el proyecto configurado, genera un Archive. En Xcode: Product > Archive y, a continuación, exporta para la App Store. En automatización, usa xcodebuild en un runner macOS. Esto requiere certificados válidos y perfiles de distribución.

Para estandarizar builds y reducir errores, los pipelines de CI/CD son útiles. Consulta un guía introductoria para estructurar pipelines y adáptala para jobs iOS en runners macOS: pipelines de CI/CD.

  • Usa un número de build creciente en cada upload.
  • Exporta el .ipa con ExportOptions de distribución.
  • Gestiona la firma de manera automática o con herramientas como Fastlane Match.
# Archive do esquema de Release
xcodebuild -scheme "SeuEsquema" \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  -archivePath build/SeuApp.xcarchive \
  clean archive

# Exporta o .ipa para distribuição (usa ExportOptions.plist)
xcodebuild -exportArchive \
  -archivePath build/SeuApp.xcarchive \
  -exportPath build/export \
  -exportOptionsPlist ExportOptions.plist

# Exemplo mínimo de ExportOptions.plist (coloque em arquivo separado)
# <?xml version="1.0" encoding="UTF-8"?>
# <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
# <plist version="1.0">
# <dict>
#   <key>method</key><string>app-store</string>
#   <key>signingStyle</key><string>automatic</string>
#   <key>uploadSymbols</key><true/>
# </dict>
# </plist>

Upload del .ipa con Transporter o Fastlane

Sube el .ipa generado. Opción gráfica: Transporter (app para macOS). Opción automatizada: Fastlane, que integra build y upload. Asegúrate de tener 2FA habilitado y una sesión válida para evitar fallos en la línea de comandos.

Ejemplo de lanes para beta (TestFlight) y release (App Store) con Fastlane.

  • Almacena credenciales de forma segura y rota tokens cuando sea necesario.
  • Evita commitear certificados y perfiles; gestionalos con control de acceso.
  • Si prefieres, sube directamente desde Xcode en Distribute App.
# Fastfile (exemplo simplificado)
default_platform(:ios)

platform :ios do
  desc "Build + upload para TestFlight"
  lane :beta do
    build_ios_app(
      scheme: "SeuEsquema",
      export_method: "app-store"
    )
    upload_to_testflight
  end

  desc "Upload para App Store (sem mexer em metadata)"
  lane :release do
    upload_to_app_store(
      skip_screenshots: true,
      skip_metadata: true
    )
  end
end

TestFlight: pruebas beta y criterios de aprobación

Después del upload, el build pasa por procesamiento. Cuando esté disponible, habilita TestFlight para pruebas internas o externas. Los builds externos pasan por una validación básica antes de liberarse a los testers.

Recopila feedback, reportes de fallos y métricas de estabilidad. Define criterios de salida claros para avanzar al release. Si aún estás puliendo roadmap y alcance, consulta ideas en apps para dispositivos móviles.

  • Prueba en dispositivos y versiones de iOS soportadas.
  • Valida onboarding, login y flujos críticos, incluso en modo offline.
  • Especifica notas de la versión claras para los testers.
  • Rastrea crashes y corrige regresiones antes del envío final.

Enviar para revisión: checklist de cumplimiento

Con el build aprobado en pruebas, selecciona el build en la versión, completa las notas de la versión y envía para revisión. El tiempo de análisis varía según la app y la cola.

Finaliza este checklist para reducir rechazos y retrabajo.

  • Export compliance: indica si usas criptografía y cómo.
  • Derechos de contenido: licencias para medios de terceros, si aplica.
  • Política de privacidad accesible y actualizada en el sitio.
  • Acceso a recursos pagos: proporciona entorno y cuentas de prueba.
  • Transparencia del rastreo: decláralo si aplica (por ejemplo: IDFA).
  • Mensajes de uso en el Info.plist para datos sensibles.
  • Flujo de eliminación de cuenta, si la app requiere registro.

Cómo confirmar que funcionó y publicar

Sigue los estados en App Store Connect. Tras “Waiting For Review” y “In Review”, la app aprobada pasa a “Ready for Sale”. Puedes lanzar manualmente o usar un despliegue progresivo.

Si el build no procesa o regresa con error, ajusta firma, versiones y metadatos y vuelve a enviar. Estos errores son comunes y aquí verás cómo resolver rápidamente.

  • ITMS-90164/90035: problemas de firma — revisa certificados y entitlements.
  • Invalid Bundle Identifier: Bundle ID en Xcode difiere del registrado en App Store Connect.
  • Duplicate CFBundleVersion: incrementa el número de build.
  • Missing Purpose String: añade mensajes de permiso en el Info.plist.

Preguntas frecuentes

¿Necesito una cuenta de pago para publicar en la App Store?

Sí. Es necesario tener una suscripción activa al Apple Developer Program para firmar builds de distribución y gestionar la app en App Store Connect. Sin esa cuenta no puedes enviar builds ni publicar.

¿Cuál es la diferencia entre versión y número de build?

La versión (por ejemplo: 1.2.0) es el número visible para el usuario y cambia cuando hay nuevas funcionalidades. El número de build (por ejemplo: 45) es interno y debe incrementarse en cada upload. Puedes enviar varios builds de la misma versión, pero cada build debe tener un número mayor.

¿Puedo publicar sin usar un Mac?

La compilación de apps iOS requiere macOS y herramientas compatibles. Si no dispones de un Mac local, usa proveedores de CI con runners macOS para compilar y firmar la app, y luego hacer el upload vía línea de comandos o Transporter.

¿Cuánto tarda la revisión de la app?

Varía según el tipo de app, su complejidad y la cola de revisión. En algunos casos la aprobación ocurre el mismo día; en otros puede tardar varios días. Las rejecciones extienden el plazo. Prepárate para responder con rapidez a solicitudes del equipo de revisión.

¿Necesito una política de privacidad para publicar?

Si la app recopila datos de usuarios, integra logins de terceros o usa APIs sensibles, debes proporcionar una política de privacidad. Incluso cuando la recopilación es mínima, tener la política pública y actualizada evita rechazos y aporta transparencia al usuario.

¿Qué hago si mi app es rechazada?

Lee el motivo de la rejección, corrige el punto indicado y envía una nueva compilación o actualización de metadatos. Incluye notas objetivas explicando la corrección. Si es necesario, adjunta vídeos o credenciales de prueba para demostrar el funcionamiento.

¿Quieres automatizar tu pipeline de publicación iOS?

Si necesitas revisar la firma, estandarizar builds o integrar Fastlane y CI, hablemos sobre tu escenario y próximos pasos.

Hablar sobre publicación iOS

Ver también